Os pods do GKE perderam o acesso à VPN após a 1.14: duas formas de corrigir a origem

Chega uma atualização e os sistemas do outro lado do túnel começam a rejeitar o tráfego dos pods que funcionava na semana anterior. O túnel está ativo, as regras da firewall estão intactas e ninguém editou a política do par. O que mudou é invisível nos registos do cluster: o endereço de origem que esses sistemas veem agora. Essa lacuna explica uma falha que parece uma queda de rede e se comporta como um problema de permissões.

Existem duas respostas válidas e levam a sítios diferentes. Escolha o contrato de origem antes de editar um ConfigMap.

A regra predefinida que deixou de ser instalada

As versões anteriores do GKE instalavam uma regra de masquerade que substituía as origens dos pods pelo endereço do nó sempre que o destino ficava fora de 10.0.0.0/8. Um gateway VPN dentro desse intervalo via o endereço do pod, enquanto tudo o que estava mais longe parecia vir do nó. Os pares construíram listas de permitidos e rotas de retorno em torno dos endereços dos nós porque era isso que observavam.

As versões seguintes deixaram de instalar essa regra predefinida. O tráfego dos pods chega agora ao gateway com endereços de pod, seja qual for o destino. Um par que só encaminha endereços de nó descarta as respostas e nenhum dos lados escreve uma entrada de registo útil. O pedido pode até ter sucesso no extremo remoto, e é isso que torna a falha confusa de seguir.

Nada está avariado no sentido de um componente morto. Os dois lados simplesmente não concordam sobre qual origem é legítima.

Escolha a origem que o par deve ver

Manter os endereços de pod é o contrato mais preciso. O lado remoto vê a carga de trabalho que produziu o tráfego, os registos mantêm-se honestos e a política por pod torna-se possível. O preço é que o par tem de transportar o prefixo dos pods.

Manter os endereços de nó é o contrato mais barato. Volte a ativar o masquerade para esse destino e o par continua a ver um endereço em que já confia.

Uma pergunta decide entre os dois: o que faz o par com a origem? Se registar, aplicar política por origem ou impuser um encaminhamento de retorno estreito, os endereços de pod justificam a configuração extra. Se só precisar de enviar respostas, o masquerade custa menos e não pede nada ao outro lado. Qualquer das escolhas é defensável desde que as duas equipas a escrevam.

Uma terceira opção costuma ser um erro: aplicar masquerade a tudo e perder a capacidade de atribuir o tráfego. Evite-a, a menos que um par não consiga mesmo encaminhar nada além de endereços de nó.

Aponte nonMasqueradeCIDRs para os intervalos reais

O GKE executa o ip-masq-agent em kube-system, e o respetivo ConfigMap lista os destinos que saltam o masquerade. Para preservar as origens dos pods em direção ao túnel, o intervalo dos pods, a sub-rede dos nós e o prefixo local pertencem todos a essa lista.

Substitua os valores de exemplo por intervalos do seu próprio cluster. Não torne a lista mais ampla do que o requisito dita, porque cada entrada extra altera o que outro destino vê. As três entradas abaixo representam a rede dos pods, a sub-rede dos nós e o prefixo atrás do túnel:

nonMasqueradeCIDRs:
  - 10.12.0.0/14
  - 10.100.0.0/16
  - 172.16.0.0/12
masqLinkLocal: false
resyncInterval: 60s

Uma entrada 0.0.0.0/0 desativa o masquerade para todos os destinos, o que altera a forma como cargas de trabalho não relacionadas aparecem aos serviços externos e raramente é intencional. O agente relê a sua configuração em resyncInterval, pelo que normalmente não é necessário reiniciar. Verifique se o pod do agente está em execução e depois abra o ficheiro montado dentro dele. É a leitura desse ficheiro que prova que a alteração chegou.

O caminho de retorno é a outra metade

O masquerade altera a origem do pedido e nada mais. Qualquer que seja a origem que o par receba, continua a precisar de uma rota de volta para ela, e o cluster continua a precisar de uma rota em direção ao par.

Uma captura no gateway VPN separa rapidamente as duas falhas. Pacotes que chegam com endereços de pod e nunca recebem resposta significam que o par não tem rota para o prefixo dos pods. Uma resposta que aparece no gateway mas nunca chega ao cluster significa que falta a rota local. Escreva o contrato no ticket de qualquer forma: que origem vê o par e para que prefixo encaminha a resposta.

Verifique novamente após cada atualização

O comportamento predefinido do masquerade já mudou uma vez, e a substituição de um pool de nós pode repor a rede do cluster. Trate o contrato de origem como algo a verificar e não como algo a assumir.

Após uma atualização, envie um pedido de um pod para um serviço local e leia a origem que o par registra. Essa única observação apanha uma regressão que uma página de estado do túnel relataria alegremente como saudável. Repeti-la custa um minuto e poupa uma noite à pessoa seguinte.