VPN por Pod no Kubernetes contra gateway de saída: quem é dono do túnel?

Você implanta um Pod chamado vpn-gateway, aponta um cliente de teste para o endereço dele e vê os pacotes desaparecerem. Nada no manifesto está errado e o kubelet não tem do que reclamar. A razão é estrutural e não de configuração: o Kubernetes dá a cada Pod o seu próprio namespace de rede, então um nome, um rótulo ou um namespace de API compartilhado não mudam nada sobre para onde os pacotes vão. Por isso, decidir como o tráfego VPN sai do cluster começa com uma pergunta sobre propriedade, não sobre imagens de contêiner.

Dois mecanismos cobrem a maioria das implantações reais, e não são intercambiáveis. Um coloca o túnel dentro do próprio namespace de rede da carga de trabalho. O outro pede ao CNI que direcione o tráfego selecionado por um nó de gateway designado. Eles falham de formas diferentes, escalam de formas diferentes e respondem a equipes diferentes, e é por isso que a pergunta do contêiner costuma produzir discussões que nunca se resolvem.

O limite de um Pod é um namespace, não um host de salto

Um namespace de rede do Linux possui suas interfaces, endereços, rotas e regras de firewall, e cada Pod recebe um. Os contêineres dentro desse Pod juntam-se a ele, e é exatamente por isso que um contêiner auxiliar pode reescrever rotas que a aplicação depois segue. Um Pod vizinho tem uma pilha de aparência idêntica mas completamente separada. Não há tabela compartilhada que um Pod de gateway possa herdar, nem entrega implícita de tráfego de um namespace para outro.

Também é por isso que o padrão de Pod de gateway só funciona quando algo a montante realmente envia pacotes para ele: um Service, uma rota estática no nó ou uma política de direcionamento no CNI. Um endereço sozinho não atrai nada.

O que um túnel por Pod compra, e quanto custa

Um túnel que roda no namespace da carga de trabalho dá a essa carga a sua própria identidade de cliente, que muitos serviços de acesso remoto exigem antes de autorizar ou contabilizar uma sessão. O raio de impacto também fica local: um túnel quebrado derruba um Deployment em vez do caminho compartilhado usado por tudo. Como ele roda depende da implementação, e é aqui que as pessoas adivinham errado.

Uma configuração que só precisa de estado do kernel pode terminar num contêiner init e sair. Um daemon de espaço de usuário que precisa permanecer vivo durante toda a vida do Pod precisa da forma de contêiner init reiniciável introduzida como sidecar nativo no Kubernetes 1.29, e essa distinção vem da implementação do túnel e não do gosto. O custo desse modelo é a duplicação: cada réplica se autentica, recebe o seu próprio endereço de túnel e consome uma vaga de sessão remota, então um evento de autoscaling vira um evento de capacidade do outro lado do link. Copiar uma única credencial para todas as réplicas não remove esse custo, remove a trilha de auditoria. As capacidades merecem o mesmo escrutínio, porque um túnel que quer NET_ADMIN no próprio namespace não tem motivo para herdar a autoridade sobre todo o host de um exemplo com privileged: true.

Quando o CNI é dono da saída

Se o CNI permitir, um gateway de saída seleciona o tráfego por carga de trabalho e faixa de destino, e então o envia por nós escolhidos sob um endereço de origem previsível. A versão do Cilium é a referência comum, e a sua documentação deixa claro que o recurso exige uma configuração específica do Cilium além de nós de gateway provisionados com as interfaces e os endereços corretos. Também observa um período inicial após a criação do Pod em que o direcionamento ainda não é aplicado, o que é um dado de projeto e não uma nota de rodapé.

Leia esse atraso contra a sua própria promessa. Se a regra é que nenhum tráfego pode sair por outro caminho, um Pod novo que transmita durante a lacuna já a violou, então a sequência de inicialização precisa de uma resposta própria: segurar a aplicação até a política valer, ou aceitar a janela e documentá-la.

Mantenha a afirmação estreita. Um gateway de saída escolhe e traduz um caminho. Não termina uma VPN, e não transforma o cluster em cliente da sua rede remota sem uma conexão suportada por trás.

A tradução muda em silêncio o que o lado remoto vê

Assim que o gateway reescreve a origem, os endereços por Pod desaparecem, então uma lista de permitidos baseada em identidade torna-se uma lista baseada num único endereço compartilhado. É uma troca e não um defeito: menos regras para manter, atribuição mais grosseira quando algo se comporta mal.

A autenticação no nível da aplicação e o registro de pedidos têm de carregar o que a rede já não reporta. Trate a capacidade e a substituição do gateway como infraestrutura compartilhada, porque reiniciar um único nó agora interrompe cada carga de trabalho atrás dele, e verifique cedo o caminho de retorno: a ponta remota precisa de saber como alcançar o endereço traduzido, normalmente por uma rota ou NAT que uma pessoa, não um manifesto, tem de possuir. O planejamento de endereços também pertence aqui, porque faixas de cluster e remotas sobrepostas quebram qualquer um dos modelos e adotar IPv6 não desculpa um plano em conflito.

Decida por propriedade e depois teste a falha que prometeu

Escolha o túnel por Pod quando o serviço remoto autentica cargas de trabalho individuais, quando apenas alguns Deployment precisam do link e quando uma falha deve ficar local. Escolha o gateway quando uma equipa de rede já é dona do caminho, quando muitas cargas partilham um destino e quando um endereço de origem estável é todo o propósito do exercício.

De qualquer forma, verifique a propriedade que vendeu e não o estado estacionário. Crie um Pod, deixe-o transmitir de imediato e observe os primeiros segundos se a promessa era que nada escapa do túnel. Escale para cinco réplicas e conte as sessões que a ponta remota reporta se a promessa era identidade por carga de trabalho. Essas duas verificações expõem os limites do mecanismo muito mais depressa do que uma revisão do manifesto, e dizem-lhe qual equipa é dona do próximo incidente.