Um sidecar de VPN precisa de uma regra de arranque e de uma regra de falha

Um pod arranca o contentor do túnel antes da aplicação e os primeiros pedidos têm sucesso, e é exatamente esse o caso que esconde o problema. A ordem resolve uma corrida e não diz nada sobre o tráfego que a aplicação inicia quatro horas depois, quando o túnel já falhou. São duas decisões separadas. Normalmente só se desenha uma delas.

A ordem só controla o primeiro pedido

O Kubernetes suporta um ciclo de vida de sidecar construído com contentores init reiniciáveis. Nesse modelo, uma sonda de arranque pode reter o passo de inicialização seguinte até o túnel reportar prontidão. É uma melhoria real, e vale a pena usá-la deliberadamente em vez de acrescentar um sleep a um script de entrada. A porta só é tão boa como a condição que testa.

Fora desse modelo, a semântica da ordem pertence ao runtime ou sistema de dependências que estiver a usar, e não têm de coincidir. Uma implementação copiada de outra plataforma pode parecer esperar pelo túnel porque a aplicação começa devagar por acaso. Não é a mesma garantia, e falha sob carga.

Diga o que a porta observa: existe um processo, existe uma interface, um handshake foi concluído. Cada uma dessas afirmações é mais fraca do que «o caminho de dados até aos destinos de que este pod precisa funciona».

Imponha o caminho de dados em vez de o assumir

Uma sonda é uma verificação num momento e uma firewall é uma propriedade que vale entre momentos. Se o requisito é que o tráfego da aplicação nunca saia fora do túnel, tem de ser expresso no espaço de nomes de rede partilhado como uma regra de aceitar ou descartar. A ordem de arranque dos contentores não pode transportar esse requisito. Só uma regra pode.

Os contentores de um mesmo pod partilham esse espaço de nomes, pelo que o ponto de imposição é o próprio espaço de nomes. Escreva o que escrever, tem de deixar disponível a ligação exterior do próprio túnel, porque bloqueá-la para proteger a aplicação corta o caminho de que a aplicação precisa.

Decida a política de falha explicitamente: o tráfego da aplicação deve parar por completo quando o túnel não está saudável, ou continuar e ser marcado como não protegido? Ambas são defensáveis, e nenhuma é o que se obtém arrancando contentores numa ordem específica.

Teste o tráfego de que não falou

Faça um novo pedido durante uma falha controlada do túnel e veja se sai. Depois repita a verificação para os caminhos que um teste de endereço de saída nunca toca: resolução de DNS dentro do cluster, destinos IPv6 e serviços alcançados por endereços internos do cluster em vez da internet pública. Esses são os caminhos que continuam a funcionar em silêncio depois de o túnel morrer.

Uma página de endereço de saída prova que um pedido foi onde esperava naquele momento. Não consegue inventariar os outros caminhos, e a lacuna entre o que testou e o que o pod consegue alcançar é onde vivem as falhas interessantes.

Repita o teste depois de um reinício do sidecar e não apenas depois de um arranque limpo. Um contentor de túnel reiniciado pode deixar o espaço de nomes com rotas e política num estado intermédio.

Escreva o registo de implementação

Três factos pertencem às notas de implementação: o teste de prontidão e o que observa, a ação de recuperação quando esse teste falha, e a regra de imposição que governa a saída. A documentação dos contentores sidecar cobre a mecânica do ciclo de vida e deixa essa decisão de política consigo. Essa divisão está correta, e é também por isso que a política costuma faltar.

Uma verificação de saúde confundida com proteção é o tipo mais caro de indicador verde, porque impede as pessoas de fazer perguntas. Nomeá-la com precisão na documentação custa uma frase e evita isso.

Por fim, teste o caminho de recuperação uma vez com a aplicação a correr. Um desenho que exige recriar o pod para restaurar a saída é uma decisão, e deveria ser uma que tomou, não uma que descobriu.