Per què els pods de GKE no poden arribar als servidors locals per VPN

El ping funciona des del node i falla des del pod, i no arriba res a la xarxa local. El túnel i la ruta estan bé; l'adreça d'origen al cable no. El que diferencia aquests dos casos és què afirma ser el paquet quan surt del clúster, i GKE té una opinió sobre això. El mecanisme és una llista d'exclusions de masquerade, i llegir-la només requereix una ordre.

Llegiu la llista efectiva abans de canviar res

GKE inclou un agent que decideix, per a cada rang de destinació, si el trànsit dels pods es reescriu a l'adreça del node en sortir. La seva configuració de sèrie anomena els tres blocs RFC1918, 10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16, com a destinacions exemptes. Per tant, tot el que envieu des d'un pod a un servidor 10.x local surt del node amb l'adreça pròpia del pod encara enganxada. El trànsit del propi node no es reescriu, i és exactament per això que el seu ping funciona.

Llegiu la configuració prevista i les regles instal·lades, perquè poden no coincidir. kubectl -n kube-system get configmap ip-masq-agent -o yaml mostra què se li va dir a l'agent, i kubectl -n kube-system get pods -l k8s-app=ip-masq-agent mostra si hi ha res en execució que ho apliqui. En un node, iptables-save | grep -i masq mostra les regles que existeixen realment al nucli. Quan el ConfigMap diu una cosa i les regles en diuen una altra, el sospitós és l'agent i no la xarxa.

Confirmeu l'adreça d'origen amb una captura

Feu una captura abans de canviar cap llista. Un filtre sobre l'única destinació manté la sortida llegible: tcpdump -ni any host 10.20.30.40.

Compareu-ho amb el que informa l'altre costat. Una captura a la xarxa local que mostra l'adreça del pod i cap resposta tanca el cercle: la llista d'exclusions explica l'asimetria sense cap fallada del túnel. Dues observacions d'una mateixa adreça d'origen són prou per deixar d'especular sobre la CNI.

Estrebeu l'exclusió al CIDR dels pods

La reparació admesa estreba l'exempció en lloc d'eliminar-la: manteniu el CIDR dels pods exempt i deixeu caure la resta de l'espai 10.x. Aquesta llista viu al ConfigMap de l'agent sota nonMasqueradeCIDRs, i canviar-la és una edició seguida d'un desplegament. Substituïu l'entrada àmplia pel rang real de pods del clúster, manteniu els altres blocs privats si el trànsit intern del clúster encara els necessita, i deixeu resyncInterval tranquil llevat que tingueu un motiu. Apliqueu-ho, confirmeu que els pods de l'agent s'han reiniciat i confirmeu que les regles del nucli han canviat.

Aquest és un canvi a tot el clúster amb un radi d'impacte real. Un cop aplicat, el trànsit que abans conservava l'origen del pod ara arriba reescrit al node, de manera que tot el que depenia d'aquelles adreces de pod veu un emissor diferent. Les víctimes són els registres, les llistes de permisos i les regles de tallafoc locals que anomenen adreces de pod, i fallen en silenci. Anuncieu el canvi com un canvi de comportament i no com una correcció.

En un clúster amb diversos pools de nodes, comproveu que l'agent està planificat als nodes on els pods afectats s'executen realment. Un pool sense el DaemonSet conserva les seves regles antigues, i res del ConfigMap ho mostrarà.

L'alternativa i el seu cost

L'altra opció manté intactes les adreces dels pods i ensenya el camí sobre elles. El CIDR dels pods entra als selectors de trànsit de Cloud VPN, i el costat local necessita una ruta de tornada per a ell perquè les respostes sàpiguen on anar. Això preserva la identitat del pod, que alguns models de seguretat volen, i amplia tant l'abast d'encaminament com el de tallafoc que l'altre costat ha d'acceptar.

L'intercanvi és llegibilitat contra abast. La traducció fa que el costat local vegi una adreça per node, cosa fàcil de posar en una llista de permisos i que amaga quin pod ha enviat què. Sense traducció, l'adreça del pod es manté d'extrem a extrem, cosa millor per a l'atribució i pitjor per a cada dispositiu del camí que ha d'aprendre un rang nou. Cap de les dues opcions no és un defecte de Docker o de la CNI; totes dues són decisions d'encaminament amb un compte operatiu. Trieu la que el vostre equip pugui pagar i escriviu per què.

Verifiqueu i revertiu

Torneu a fer la mateixa captura. Una captura a nivell de node que encara mostra l'adreça del pod després de la vostra edició vol dir que les regles no van canviar mai, digui el que digui el ConfigMap. El cable és el fet; la resta és inferència.

Després comproveu la direcció inversa, perquè la meitat d'aquests canvis només es verifiquen de sortida. Confirmeu que la resposta arriba al node o al pod que va enviar la petició i confirmeu que l'aplicació ha acabat en lloc de només rebre un SYN. Una captura que mostra una petició sense resposta és un problema d'encaminament a l'altre costat, no un problema de masquerade en aquest.

Revertir és el ConfigMap anterior, aplicat de la mateixa manera, amb la mateixa confirmació que l'agent s'ha reiniciat i que les regles han canviat. Guardeu l'adreça d'origen d'abans i de després per a una petició coneguda al registre de canvis, ja que aquesta sola línia és el que demostra que el canvi ha fet el que heu dit. La guia de l'agent de masquerade IP de GKE documenta els valors per defecte i els camps del ConfigMap. Si l'adreça d'origen no canvia després del desplegament, l'agent no s'executa en aquest node i cap edició de YAML ho arreglarà.