Por qué los pods de GKE no llegan a los servidores locales por VPN

El ping funciona desde el nodo y falla desde el pod, y no llega nada a la red local. El túnel y la ruta están bien; la dirección de origen en el cable no. Lo que distingue esos dos casos es qué afirma ser el paquete cuando sale del clúster, y GKE tiene una opinión al respecto. El mecanismo es una lista de exclusiones de masquerade, y leerla requiere un solo comando.

Lea la lista efectiva antes de cambiar nada

GKE incluye un agente que decide, para cada rango de destino, si el tráfico de los pods se reescribe a la dirección del nodo a la salida. Su configuración de serie nombra los tres bloques RFC1918, 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16, como destinos exentos. Por eso todo lo que envíe desde un pod a un host 10.x local sale del nodo con la dirección propia del pod todavía adjunta. El tráfico del propio nodo no se reescribe, y es exactamente por eso que su ping funciona.

Lea la configuración prevista y las reglas instaladas, porque pueden no coincidir. kubectl -n kube-system get configmap ip-masq-agent -o yaml muestra qué se le dijo al agente, y kubectl -n kube-system get pods -l k8s-app=ip-masq-agent muestra si hay algo ejecutándose que lo aplique. En un nodo, iptables-save | grep -i masq muestra las reglas que existen realmente en el kernel. Cuando el ConfigMap dice una cosa y las reglas otra, el sospechoso es el agente y no la red.

Confirme la dirección de origen con una captura

Haga una captura antes de cambiar una lista. Un filtro sobre el único destino mantiene la salida legible: tcpdump -ni any host 10.20.30.40.

Compare eso con lo que informa el otro lado. Una captura local que muestra la dirección del pod y ninguna respuesta cierra el círculo: la lista de exclusiones explica la asimetría sin ninguna falla del túnel. Dos observaciones de una misma dirección de origen bastan para dejar de especular sobre la CNI.

Estreche la exclusión al CIDR de los pods

La reparación admitida estrecha la exención en lugar de eliminarla: mantenga el CIDR de los pods exento y descarte el resto del espacio 10.x. Esa lista vive en el ConfigMap del agente bajo nonMasqueradeCIDRs, y cambiarla es una edición seguida de un despliegue. Sustituya la entrada amplia por el rango real de pods del clúster, mantenga los otros bloques privados si el tráfico interno del clúster todavía los necesita, y deje resyncInterval en paz salvo que tenga un motivo. Aplíquelo, confirme que los pods del agente se reiniciaron y confirme que las reglas del kernel cambiaron.

Este es un cambio en todo el clúster con un radio de impacto real. Una vez aplicado, el tráfico que antes conservaba su origen de pod ahora llega reescrito al nodo, así que todo lo que dependía de esas direcciones de pod ve un emisor distinto. Las víctimas son los registros, las listas de permisos y las reglas de firewall locales que nombran direcciones de pod, y fallan en silencio. Anuncie el cambio como un cambio de comportamiento y no como una corrección.

En un clúster con varios pools de nodos, compruebe que el agente está programado en los nodos donde los pods afectados se ejecutan realmente. Un pool sin el DaemonSet conserva sus reglas antiguas, y nada en el ConfigMap lo mostrará.

La alternativa y su coste

La otra opción mantiene intactas las direcciones de pod y enseña la ruta sobre ellas. El CIDR de los pods entra en los selectores de tráfico de Cloud VPN, y el lado local necesita una ruta de vuelta para él, de modo que las respuestas sepan adónde ir. Eso preserva la identidad del pod, que algunos modelos de seguridad quieren, y amplía tanto el alcance del enrutamiento como el del firewall que el otro lado debe aceptar.

El intercambio es legibilidad frente a alcance. La traducción hace que el lado local vea una dirección por nodo, algo fácil de poner en una lista de permisos y que oculta qué pod envió qué. Sin traducción, la dirección del pod se mantiene de extremo a extremo, lo que es mejor para la atribución y peor para cada dispositivo de la ruta que debe aprender un rango nuevo. Ninguna de las dos opciones es un defecto de Docker o de la CNI; ambas son decisiones de enrutamiento con una factura operativa. Elija la que su equipo pueda pagar y escriba por qué.

Verifique y revierta

Ejecute la misma captura otra vez. Una captura a nivel de nodo que sigue mostrando la dirección del pod después de su edición significa que las reglas nunca cambiaron, diga lo que diga el ConfigMap. El cable es el hecho; todo lo demás es inferencia.

Luego compruebe la dirección inversa, porque la mitad de estos cambios solo se verifican de salida. Confirme que la respuesta llega al nodo o al pod que envió la petición y confirme que la aplicación terminó en lugar de solo recibir un SYN. Una captura que muestra una petición sin respuesta es un problema de enrutamiento en el otro lado, no un problema de masquerade en este.

Revertir es el ConfigMap anterior, aplicado de la misma manera, con la misma confirmación de que el agente se reinició y las reglas cambiaron. Guarde la dirección de origen de antes y después para una petición conocida en el registro de cambios, ya que esa única línea es lo que demuestra que el cambio hizo lo que usted dijo. La guía del agente de masquerade IP de GKE documenta los valores predeterminados y los campos del ConfigMap. Si la dirección de origen no cambia tras el despliegue, el agente no se ejecuta en ese nodo y ninguna edición de YAML lo arreglará.