Pod, nó ou cluster: o que um sidecar VPN realmente redireciona

Um sidecar VPN dentro de um Pod do Kubernetes parece uma VPN em nível de host com melhores maneiras, e a semelhança termina na fronteira do namespace. Os contêineres de um Pod compartilham o namespace de rede, incluindo o espaço de endereços e portas, então um sidecar que instala rotas e políticas muda de fato para onde vão os pacotes da aplicação. Ele não muda nada para os outros Pods no nó, e não toca na pilha do próprio nó a menos que você o configure para isso. Entender bem essa fronteira decide tanto o que você pode implantar quanto o que precisa testar. As seções abaixo seguem isso do namespace para fora.

Namespace compartilhado, consequências compartilhadas

Dois contêineres em um Pod conversam via loopback e veem as mesmas interfaces, e é por isso que o padrão de sidecar funciona: a aplicação não precisa saber que existe um túnel, porque a rota que ela resolve foi instalada no namespace que ela usa. A mesma propriedade significa que os erros do sidecar são erros da aplicação. Uma rota que captura demais, ou uma mudança de DNS que aponta para um resolvedor dentro do túnel, aplica-se imediatamente a cada processo naquele Pod. Em um namespace compartilhado não há roteamento por contêiner, então um sidecar não pode ser limitado a um processo.

Esse é o mecanismo a ter em mente durante a revisão: o raio de impacto é o Pod, não o nó e não o cluster.

Aonde o sidecar não chega

Os outros Pods mantêm seus próprios namespaces e seu próprio roteamento, então uma carga de trabalho que precisa da mesma saída precisa do mesmo sidecar ou, em vez disso, de um desenho em nível de nó. O tráfego do nó também está fora do namespace do Pod, e Pods com rede do host abrem mão deliberadamente desse isolamento por completo. Se você executar o sidecar com rede do host para alcançar algo conveniente, ampliou o escopo de um Pod para o nó inteiro e deveria dizer isso em voz alta.

O tráfego para os serviços do cluster é a outra surpresa comum. Uma rota padrão ampla dentro do Pod pode capturar requisições destinadas ao servidor de API ou a um serviço ClusterIP, que então falham de formas que parecem um túnel quebrado.

Plano de rotas: faixas de Pod, serviço, nó e VPN

Anote as quatro faixas e verifique sobreposição antes de implantar qualquer coisa: CIDR do Pod, CIDR do serviço, endereços do nó e destinos atrás da VPN. A sobreposição entre as faixas privadas da VPN e o espaço do próprio cluster não é rara, e uma rota padrão é a solução errada para isso. O plano de rotas pertence ao mesmo repositório do manifesto, porque o próximo cluster pode distribuir faixas de Pod e de serviço completamente diferentes.

O DNS é parte do plano e não uma preocupação separada. Um sidecar que reescreve a configuração do resolvedor pode quebrar a descoberta de serviços dentro do cluster enquanto faz as consultas externas funcionarem perfeitamente.

Início e falha são estados explícitos

Um processo de sidecar em execução não é uma política de saída. Decida qual tráfego pode fluir antes de o túnel estar pronto e o que acontece se ele morrer depois, e então implemente essa decisão: uma sonda que condiciona o contêiner da aplicação, uma política de rede que nega por padrão, ou ambas. Sem uma delas, a aplicação inicia, resolve e envia tráfego fora do caminho normal do nó enquanto o túnel ainda está conectando.

Essa lacuna é breve em um cluster saudável e permanente em um quebrado, e é exatamente a propriedade que um atacante ou um vazamento acidental de dados prefere.

Combine a ordem com um teste de falha. Mate o sidecar e confirme que a aplicação perde a saída pretendida em vez de recuar silenciosamente.

Capacidades, políticas e testes a partir do contêiner da aplicação

Conceder as capacidades necessárias para criar interfaces e alterar rotas é uma decisão de privilégios, e um privilégio adequado a um Pod isolado não é automaticamente adequado na pilha do nó. Use os mecanismos de política de rede e de segurança suportados pelo cluster e não presuma que toda implementação de CNI ou de política trate uma interface VPN da mesma forma; as diferenças aparecem justamente nos casos de falha que lhe importam.

Teste a partir do contêiner real da aplicação, com requisições novas para um destino privado, um serviço do cluster e a internet pública. Um teste a partir do sidecar prova que o túnel funciona, não que a aplicação alcança o que precisa.

Documente as premissas de rede do cluster ao lado da configuração da VPN. Mover a carga de trabalho para outro cluster passa a ser um exercício de verificar o plano de rotas em vez de uma mudança de imagem que para de funcionar em silêncio.