Els pods de GKE van perdre l'accés a la VPN després de la 1.14: dues maneres d'arreglar l'origen

Arriba una actualització i els sistemes de l'altre costat del túnel comencen a rebutjar el trànsit de pods que funcionava la setmana anterior. El túnel està aixecat, les regles del tallafoc no s'han tocat i ningú no ha editat la política del parell. El que ha canviat és invisible als registres del clúster: l'adreça d'origen que aquests sistemes veuen ara. Aquest buit explica una fallada que sembla una caiguda de xarxa i es comporta com un problema de permisos.

Hi ha dues respostes vàlides i us porten a llocs diferents. Trieu el contracte d'origen abans d'editar un ConfigMap.

La regla per defecte que es va deixar d'instal·lar

Les versions anteriors de GKE instal·laven una regla de masquerade que substituïa els orígens dels pods per l'adreça del node sempre que la destinació quedava fora de 10.0.0.0/8. Una passarel·la VPN dins d'aquest rang veia l'adreça del pod, mentre que qualsevol cosa més llunyana semblava venir del node. Els parells van construir llistes de permisos i rutes de retorn al voltant de les adreces dels nodes perquè això és el que observaven.

Les versions posteriors van deixar d'instal·lar aquesta regla per defecte. El trànsit dels pods ara arriba a la passarel·la amb adreces de pod, sigui quina sigui la destinació. Un parell que només encamina adreces de node descarta les respostes i cap dels dos costats escriu una entrada útil al registre. La petició pot fins i tot tenir èxit a l'extrem llunyà, i això és el que fa que la fallada sigui confusa de perseguir.

No hi ha res trencat en el sentit d'un component mort. Les dues bandes simplement no es posen d'acord sobre quin origen és legítim.

Trieu l'origen que el parell hauria de veure

Mantenir les adreces dels pods és el contracte més precís. El costat llunyà veu la càrrega de treball que va produir el trànsit, els registres es mantenen honestos i la política per pod esdevé possible. El preu és que el parell ha de portar el prefix dels pods.

Mantenir les adreces dels nodes és el contracte més barat. Torneu a activar el masquerade per a aquesta destinació i el parell continua veient una adreça en què ja confia.

Una pregunta decideix entre tots dos: què fa el parell amb l'origen? Si registra, aplica política per origen o imposa un encaminament de retorn estret, les adreces de pod justifiquen la configuració extra. Si només ha d'enviar respostes, el masquerade costa menys i no demana res a l'altre costat. Qualsevol de les dues opcions és defensable mentre tots dos equips ho deixin per escrit.

Una tercera opció sol ser un error: fer masquerade de tot i perdre la capacitat d'atribuir el trànsit. Eviteu-la tret que un parell realment no pugui encaminar res més que adreces de node.

Apunteu nonMasqueradeCIDRs als rangs reals

GKE executa l'ip-masq-agent a kube-system, i el seu ConfigMap llista les destinacions que s'estalvien el masquerade. Per preservar els orígens dels pods cap al túnel, el rang dels pods, la subxarxa dels nodes i el prefix local pertanyen tots a aquesta llista.

Substituïu els valors d'exemple per rangs del vostre clúster. No feu la llista més àmplia del que el requisit dicta, perquè cada entrada extra canvia què veu alguna altra destinació. Les tres entrades següents representen la xarxa de pods, la subxarxa de nodes i el prefix darrere del túnel:

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

Una entrada 0.0.0.0/0 desactiva el masquerade per a totes les destinacions, cosa que altera com les càrregues de treball no relacionades apareixen davant de serveis externs i poques vegades és intencionada. L'agent rellegeix la seva configuració a resyncInterval, així que normalment no cal reiniciar. Comproveu que el pod de l'agent s'estigui executant i després obriu el fitxer muntat dins seu. Llegir aquest fitxer és el que demostra que el canvi ha arribat.

La ruta de resposta és l'altra meitat

El masquerade altera l'origen de la petició i res més. Sigui quin sigui l'origen que el parell rep, encara necessita una ruta de tornada cap a ell, i el clúster encara necessita una ruta cap al parell.

Una captura a la passarel·la VPN separa ràpidament les dues fallades. Els paquets que arriben amb adreces de pod i mai no reben resposta volen dir que el parell no té ruta per al prefix dels pods. Una resposta que apareix a la passarel·la però que mai no arriba al clúster vol dir que falta la ruta local. Escriviu el contracte al tiquet en qualsevol cas: quin origen veu el parell i cap a quin prefix encamina la resposta.

Torneu a comprovar-ho després de cada actualització

El comportament per defecte del masquerade ja ha canviat una vegada, i la substitució d'un pool de nodes pot reiniciar la xarxa del clúster. Tracteu el contracte d'origen com una cosa a verificar i no com una cosa a pressuposar.

Després d'una actualització, envieu una petició des d'un pod a un servei local i llegiu l'origen que registra el parell. Aquesta única observació atrapa una regressió que una pàgina d'estat del túnel reportarà alegrement com a saludable. Repetir-ho costa un minut i estalvia un vespre a la persona següent.