Os pods de GKE perderon o acceso á VPN tras a 1.14: dúas formas de arranxar a orixe

Chega unha actualización e os sistemas do outro lado do túnel comezan a rexeitar o tráfico de pods que funcionaba a semana anterior. O túnel está levantado, as regras da devasa non se tocaron e ninguén editou a política do par. O que cambiou é invisible nos rexistros do clúster: a dirección de orixe que eses sistemas ven agora. Esa fenda explica un fallo que parece unha caída de rede e compórtase como un problema de permisos.

Existen dúas respostas válidas e levan a lugares distintos. Escolla o contrato de orixe antes de editar un ConfigMap.

A regra predeterminada que deixou de instalarse

As versións anteriores de GKE instalaban unha regra de masquerade que substituía as orixes dos pods pola dirección do nodo sempre que o destino quedaba fóra de 10.0.0.0/8. Unha pasarela VPN dentro dese rango vía a dirección do pod, mentres que calquera cousa máis lonxe parecía vir do nodo. Os pares construíron listas de permitidos e rutas de retorno arredor das direccións de nodo porque iso é o que observaban.

As versións posteriores deixaron de instalar esa regra predeterminada. O tráfico de pods agora chega á pasarela con direccións de pod, calquera que sexa o destino. Un par que só encamiña direccións de nodo descarta as respostas e ningún dos dous lados escribe unha entrada útil no rexistro. A petición pode mesmo ter éxito no extremo afastado, e iso é o que fai que o fallo sexa confuso de perseguir.

Nada está roto no sentido dun compoñente morto. As dúas partes simplemente non coinciden en que orixe é lexítima.

Escolla a orixe que o par debería ver

Manter as direccións de pod é o contrato máis preciso. O lado afastado ve a carga de traballo que produciu o tráfico, os rexistros seguen sendo honestos e a política por pod faise posible. O prezo é que o par debe levar o prefixo dos pods.

Manter as direccións de nodo é o contrato máis barato. Volva activar o masquerade para ese destino e o par seguirá vendo unha dirección na que xa confía.

Unha pregunta decide entre ambos: que fai o par coa orixe? Se rexistra, aplica política por orixe ou impón un encamiñamento de retorno estreito, as direccións de pod xustifican a configuración extra. Se só precisa enviar respostas, o masquerade custa menos e non pide nada ao outro lado. Calquera das dúas opcións é defendible mentres os dous equipos a deixen por escrito.

Unha terceira opción adoita ser un erro: aplicar masquerade a todo e perder a capacidade de atribuír o tráfico. Evítea a menos que un par realmente non poida encamiñar nada máis que direccións de nodo.

Apunte nonMasqueradeCIDRs aos rangos reais

GKE executa o ip-masq-agent en kube-system, e o seu ConfigMap enumera os destinos que evitan o masquerade. Para preservar as orixes dos pods cara ao túnel, o rango de pods, a subrede de nodos e o prefixo local pertencen todos a esa lista.

Substitua os valores de exemplo por rangos do seu propio clúster. Non faga a lista máis ampla do que dita o requisito, porque cada entrada extra cambia o que ve algún outro destino. As tres entradas seguintes representan a rede de pods, a subrede de nodos e o prefixo detrás do túnel:

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

Unha entrada 0.0.0.0/0 desactiva o masquerade para todos os destinos, o que altera como as cargas de traballo non relacionadas aparecen ante servizos externos e raramente é intencionado. O axente relé a súa configuración en resyncInterval, así que normalmente non fai falta reiniciar. Comprobe que o pod do axente se está executando e despois abra o ficheiro montado dentro del. Ler ese ficheiro é o que demostra que o cambio chegou.

A ruta de resposta é a outra metade

O masquerade altera a orixe da petición e nada máis. Sexa cal sexa a orixe que reciba o par, aínda necesita unha ruta de volta cara a ela, e o clúster aínda necesita unha ruta cara ao par.

Unha captura na pasarela VPN separa rapidamente os dous fallos. Os paquetes que chegan con direccións de pod e nunca reciben resposta significan que ao par lle falta unha ruta para o prefixo dos pods. Unha resposta que aparece na pasarela pero nunca chega ao clúster significa que falta a ruta local. Escriba o contrato no tícket en calquera caso: que orixe ve o par e cara a que prefixo encamiña a resposta.

Volva comprobalo tras cada actualización

O comportamento predeterminado do masquerade xa cambiou unha vez, e a substitución dun grupo de nodos pode reiniciar a rede do clúster. Trate o contrato de orixe como algo que verificar e non como algo que supoñer.

Tras unha actualización, envía unha petición desde un pod a un servizo local e le o rexistro do par para ver a orixe. Esa única observación atrapa unha regresión que unha páxina de estado do túnel informará alegremente como saudable. Repetilo custa un minuto e aforra unha tarde á seguinte persoa.