Los pods de GKE perdieron el acceso a la VPN tras la 1.14: dos formas de arreglar el origen

Llega una actualización y los sistemas al otro lado del túnel empiezan a rechazar el tráfico de pods que funcionaba la semana anterior. El túnel está levantado, las reglas del cortafuegos no se han tocado y nadie ha editado la política del par. Lo que cambió es invisible en los registros del clúster: la dirección de origen que esos sistemas ven ahora. Esa brecha explica un fallo que parece una caída de red y se comporta como un problema de permisos.

Existen dos respuestas válidas y llevan a lugares distintos. Elija el contrato de origen antes de editar un ConfigMap.

La regla predeterminada que dejó de instalarse

Las versiones anteriores de GKE instalaban una regla de masquerade que sustituía los orígenes de los pods por la dirección del nodo siempre que el destino quedaba fuera de 10.0.0.0/8. Una pasarela VPN dentro de ese rango veía la dirección del pod, mientras que cualquier cosa más lejana parecía venir del nodo. Los pares construyeron listas de permitidos y rutas de retorno alrededor de las direcciones de nodo porque eso es lo que observaban.

Las versiones posteriores dejaron de instalar esa regla predeterminada. El tráfico de pods ahora llega a la pasarela con direcciones de pod, sea cual sea el destino. Un par que solo enruta direcciones de nodo descarta las respuestas y ninguno de los dos lados escribe una entrada útil en el registro. La petición puede incluso tener éxito en el extremo lejano, y eso es lo que hace que el fallo sea confuso de perseguir.

Nada está roto en el sentido de un componente muerto. Las dos partes simplemente no coinciden en qué origen es legítimo.

Elija el origen que el par debería ver

Mantener las direcciones de pod es el contrato más preciso. El lado lejano ve la carga de trabajo que produjo el tráfico, los registros siguen siendo honestos y la política por pod se vuelve posible. El precio es que el par debe llevar el prefijo de los pods.

Mantener las direcciones de nodo es el contrato más barato. Vuelva a activar el masquerade para ese destino y el par seguirá viendo una dirección en la que ya confía.

Una pregunta decide entre ambos: ¿qué hace el par con el origen? Si registra, aplica política por origen o impone un enrutamiento de retorno estrecho, las direcciones de pod justifican la configuración extra. Si solo necesita enviar respuestas, el masquerade cuesta menos y no pide nada al otro lado. Cualquiera de las dos opciones es defendible mientras ambos equipos la dejen por escrito.

Una tercera opción suele ser un error: aplicar masquerade a todo y perder la capacidad de atribuir el tráfico. Evítela a menos que un par realmente no pueda enrutar nada más que direcciones de nodo.

Apunte nonMasqueradeCIDRs a los rangos reales

GKE ejecuta el ip-masq-agent en kube-system, y su ConfigMap enumera los destinos que se saltan el masquerade. Para preservar los orígenes de los pods hacia el túnel, el rango de pods, la subred de nodos y el prefijo local pertenecen todos a esa lista.

Sustituya los valores de ejemplo por rangos de su propio clúster. No haga la lista más amplia de lo que dicta el requisito, porque cada entrada extra cambia lo que ve algún otro destino. Las tres entradas siguientes representan la red de pods, la subred de nodos y el prefijo detrás 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 para todos los destinos, lo que altera cómo las cargas de trabajo no relacionadas aparecen ante servicios externos y rara vez es intencionado. El agente relee su configuración en resyncInterval, así que normalmente no hace falta reiniciar. Compruebe que el pod del agente se está ejecutando y luego abra el archivo montado dentro de él. Leer ese archivo es lo que demuestra que el cambio llegó.

La ruta de respuesta es la otra mitad

El masquerade altera el origen de la petición y nada más. Sea cual sea el origen que reciba el par, todavía necesita una ruta de vuelta hacia él, y el clúster todavía necesita una ruta hacia el par.

Una captura en la pasarela VPN separa rápidamente los dos fallos. Los paquetes que llegan con direcciones de pod y nunca reciben respuesta significan que al par le falta una ruta para el prefijo de los pods. Una respuesta que aparece en la pasarela pero nunca llega al clúster significa que falta la ruta local. Escriba el contrato en el tique en cualquier caso: qué origen ve el par y hacia qué prefijo enruta la respuesta.

Vuelva a comprobarlo tras cada actualización

El comportamiento predeterminado del masquerade ya ha cambiado una vez, y la sustitución de un grupo de nodos puede reiniciar la red del clúster. Trate el contrato de origen como algo que verificar y no como algo que suponer.

Tras una actualización, envíe una petición desde un pod a un servicio local y lea el origen que registra el par. Esa única observación atrapa una regresión que una página de estado del túnel informará alegremente como saludable. Repetirlo cuesta un minuto y ahorra una tarde a la siguiente persona.