Por que os pods de GKE non chegan aos servidores locais por VPN

O ping funciona desde o nodo e falla desde o pod, e non chega nada á rede local. O túnel e a ruta están ben; o enderezo de orixe no cable non. O que distingue eses dous casos é o que o paquete afirma ser cando sae do clúster, e GKE ten unha opinión ao respecto. O mecanismo é unha lista de exclusións de masquerade, e lela require un só comando.

Lea a lista efectiva antes de cambiar nada

GKE inclúe un axente que decide, para cada rango de destino, se o tráfico dos pods se reescribe ao enderezo do nodo na saída. A súa configuración de serie nomea os tres bloques RFC1918, 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16, como destinos exentos. Por iso todo o que envía desde un pod a un servidor 10.x local sae do nodo co enderezo propio do pod aínda adxunto. O tráfico do propio nodo non se reescribe, e é exactamente por iso que o seu ping funciona.

Lea a configuración prevista e as regras instaladas, porque poden non coincidir. kubectl -n kube-system get configmap ip-masq-agent -o yaml mostra que se lle dixo ao axente, e kubectl -n kube-system get pods -l k8s-app=ip-masq-agent mostra se hai algo en execución que o aplique. Nun nodo, iptables-save | grep -i masq mostra as regras que existen realmente no kernel. Cando o ConfigMap di unha cousa e as regras outra, o sospeitoso é o axente e non a rede.

Confirme o enderezo de orixe cunha captura

Faga unha captura antes de cambiar unha lista. Un filtro sobre o único destino mantén a saída lexible: tcpdump -ni any host 10.20.30.40.

Compare iso co que informa o outro lado. Unha captura local que mostra o enderezo do pod e ningunha resposta pecha o círculo: a lista de exclusións explica a asimetría sen ningunha falla do túnel. Dúas observacións dun mesmo enderezo de orixe abondan para deixar de especular sobre a CNI.

Estreite a exclusión ao CIDR dos pods

A reparación admitida estreita a exención en lugar de eliminarla: manteña o CIDR dos pods exento e descarte o resto do espazo 10.x. Esa lista vive no ConfigMap do axente baixo nonMasqueradeCIDRs, e cambiala é unha edición seguida dun despregamento. Substitua a entrada ampla polo rango real de pods do clúster, manteña os outros bloques privados se o tráfico interno do clúster aínda os necesita, e deixe resyncInterval en paz salvo que teña un motivo. Aplíqueo, confirme que os pods do axente se reiniciaron e confirme que as regras do kernel cambiaron.

Este é un cambio en todo o clúster cun radio de impacto real. Unha vez aplicado, o tráfico que antes conservaba a súa orixe de pod agora chega reescrito ao nodo, así que todo o que dependía deses enderezos de pod ve un emisor distinto. As vítimas son os rexistros, as listas de permisos e as regras de firewall locais que nomean enderezos de pod, e fallan en silencio. Anuncie o cambio como un cambio de comportamento e non como unha corrección.

Nun clúster con varios pools de nodos, comprobe que o axente está programado nos nodos onde os pods afectados se executan realmente. Un pool sen o DaemonSet conserva as súas regras antigas, e nada no ConfigMap o mostrará.

A alternativa e o seu custo

A outra opción mantén intactos os enderezos de pod e ensina a ruta sobre eles. O CIDR dos pods entra nos selectores de tráfico de Cloud VPN, e o lado local necesita unha ruta de volta para el, de xeito que as respostas saiban onde ir. Iso preserva a identidade do pod, que algúns modelos de seguridade queren, e amplía tanto o alcance do encamiñamento como o do firewall que o outro lado debe aceptar.

O intercambio é lexibilidade fronte a alcance. A tradución fai que o lado local vexa un enderezo por nodo, algo fácil de poñer nunha lista de permisos e que oculta que pod enviou que. Sen tradución, o enderezo do pod mantense de extremo a extremo, o que é mellor para a atribución e peor para cada dispositivo da ruta que debe aprender un rango novo. Ningunha das dúas opcións é un defecto de Docker ou da CNI; ambas son decisións de encamiñamento cunha factura operativa. Escolla a que o seu equipo poida pagar e escriba por que.

Verifique e reverta

Executar a mesma captura outra vez. Unha captura a nivel de nodo que segue mostrando o enderezo do pod despois da súa edición significa que as regras nunca cambiaron, diga o que diga o ConfigMap. O cable é o feito; todo o demais é inferencia.

Logo comprobe a dirección inversa, porque metade destes cambios só se verifican de saída. Confirme que a resposta chega ao nodo ou ao pod que enviou a petición e confirme que a aplicación rematou en lugar de só recibir un SYN. Unha captura que mostra unha petición sen resposta é un problema de encamiñamento no outro lado, non un problema de masquerade neste.

Reverter é o ConfigMap anterior, aplicado do mesmo xeito, coa mesma confirmación de que o axente se reiniciou e as regras cambiaron. Garde o enderezo de orixe de antes e despois para unha petición coñecida no rexistro de cambios, xa que esa única liña é o que demostra que o cambio fixo o que vostede dixo. A guía do axente de masquerade IP de GKE documenta os valores predeterminados e os campos do ConfigMap. Se o enderezo de orixe non cambia tras o despregamento, o axente non se executa nese nodo e ningunha edición de YAML o arranxará.