Configura la conectividad del pod de GKE con el extremo externo

En este documento, se explica cómo configurar la conectividad desde los Pods en GKE a extremos externos, incluidos los recursos en redes locales y los servicios de Internet públicos. Para controlar la dirección IP de origen del tráfico de Pods de GKE, puedes usar ip-masq-agent (traducción a nivel del nodo) y Cloud NAT (salida a nivel de la VPC).

Descripción general

Cuando un Pod en un clúster de GKE nativo de la VPC envía un paquete a un destino fuera del clúster, la dirección IP de origen del paquete cambia según la configuración del agente de enmascaramiento de IP a nivel del nodo (ip-masq-agent) y Cloud NAT.

  1. Traducción a nivel del nodo (ip-masq-agent): traduce la dirección IP de origen del paquete de la dirección IP del Pod (rango de subred secundario) a la dirección IP del nodo interna (rango de subred principal) según una lista nonMasqueradeCIDRs configurada.
  2. Puerta de enlace a nivel de la VPC (Cloud NAT): traduce las direcciones IP internas de la VPC (direcciones IP del nodo o direcciones IP del Pod) a direcciones IP públicas estáticas para permitir el acceso a Internet saliente.

Según si el nodo enmascara un destino, el paquete sale del nodo con la dirección IP del nodo o la dirección IP del Pod. Esta dirección IP de origen determina cómo configuras tus Cloud Routers o routers locales.

Cómo funcionan en conjunto el enmascaramiento de IP y Cloud NAT

Para el tráfico orientado a Internet, los paquetes de un Pod atraviesan la pila de red del nodo y la puerta de enlace de Cloud NAT.

Si la dirección IP de destino no coincide con ningún rango en la lista nonMasqueradeCIDRs:

  • ip-masq-agent realiza NAT de origen (SNAT) en el nodo de GKE. La dirección IP de origen se vuelve a escribir desde la dirección IP del Pod a la dirección IP del nodo.
  • El paquete ingresa a la red de VPC con la dirección IP del nodo como origen.
  • La puerta de enlace de Cloud NAT intercepta el paquete.
  • Cloud NAT traduce la dirección IP del nodo a una dirección IP pública y la enruta a Internet.

Situación B: Conservación de la dirección IP del Pod (sin enmascaramiento)

Si la dirección IP de destino coincide con un rango en la lista nonMasqueradeCIDRs (o si la SNAT predeterminada está inhabilitada):

  • ip-masq-agent deja el paquete sin modificar. La dirección IP de origen sigue siendo la dirección IP del Pod.
  • El paquete ingresa a la red de VPC con la dirección IP del Pod como origen.
  • La puerta de enlace de Cloud NAT intercepta el paquete.
  • Cloud NAT traduce la dirección IP del Pod a una dirección IP pública solo si Cloud NAT está configurado de forma explícita para traducir el rango de direcciones IP secundario de la subred que se usa para los Pods de GKE.

Verificador de enmascaramiento de IP

Usa este verificador para comprobar si se enmascarará una dirección IP de destino según la configuración de ip-masq-agent.

Ejemplo de flujo de tráfico

Para comprender la ruta de traducción, considera el siguiente ejemplo de configuración:

  • Rango de direcciones IP del Pod: 10.4.0.0/14 (dirección IP del Pod: 10.4.0.5)
  • Rango de direcciones IP del nodo: 10.128.0.0/20 (dirección IP del nodo: 10.128.0.10)
  • Dirección IP de destino: 8.8.8.8 (servidor DNS público, no en la lista nonMasqueradeCIDRs)

Cuando el Pod envía un paquete, ocurre lo siguiente:

  1. El paquete comienza en el Pod: el paquete se origina en la interfaz de red del Pod (dirección IP: 10.4.0.5) con una dirección IP de destino de 8.8.8.8.
  2. Enmascaramiento a nivel del nodo: debido a que la dirección IP de destino 8.8.8.8 no está en la lista nonMasqueradeCIDRs, ip-masq-agent en el nodo host intercepta el paquete cuando sale y realiza SNAT. La dirección IP de origen se vuelve a escribir desde la dirección IP del Pod 10.4.0.5 a la dirección IP del nodo host, que es 10.128.0.10.
  3. Salida de la VPC: el paquete llega a la red de VPC con la dirección IP del nodo host 10.128.0.10 como dirección IP de origen.
  4. Puerta de enlace de Cloud NAT: debido a que el destino es Internet pública, Cloud NAT procesa el paquete, traduce la dirección IP de origen de 10.128.0.10 a una dirección IP de NAT pública (por ejemplo, 203.0.113.1) y la reenvía a Internet.
  5. Control de respuesta: la respuesta regresa a la dirección IP pública de Cloud NAT, que Cloud NAT traduce de forma inversa a la dirección IP del nodo host 10.128.0.10. Luego, el nodo traduce de forma inversa la dirección IP del nodo host a la dirección IP del Pod, que es 10.4.0.5, y la entrega al contenedor del Pod.

Flujo de tráfico con Cloud Service Mesh (CSM)

Si tus cargas de trabajo usan Cloud Service Mesh, el enrutamiento del tráfico se comporta de la siguiente manera:

  • Proxy de sidecar o redireccionamiento de CNI sin sidecar: los paquetes salientes del contenedor de la aplicación son interceptados por la malla (mediante un proxy de sidecar como Envoy o a través de redireccionamiento basado en ebpf o CNI) antes de llegar al espacio de nombres de red del nodo.
  • Aplicación de políticas: la malla determina si se permite la conexión en función de sus políticas de autorización y salida.
  • Enrutamiento de salida:
    • Si el tráfico se dirige mediante una puerta de enlace de salida de Cloud Service Mesh, la dirección IP de origen del paquete que sale del nodo corresponde a la dirección IP del nodo o del Pod de la puerta de enlace de salida, en lugar del Pod de origen.
    • Si el tráfico se enruta directamente al extremo externo, el paquete sale del proxy y se enruta a través de la pila de red del nodo host estándar. En este caso, las políticas de ip-masq-agent y las configuraciones de Cloud NAT descritas anteriormente en este documento aún se aplican al tráfico de salida.
  • Para obtener más información sobre cómo configurar el enrutamiento, las puertas de enlace y administrar el tráfico externo en Cloud Service Mesh, consulta la documentación de Cloud Service Mesh.

Solución de problemas y aislamiento de problemas de conectividad

Si un Pod no puede conectarse a un extremo externo y usas una malla de servicios, debes aislar si el problema está en la configuración de la malla de servicios o en el enrutamiento subyacente de GKE. Para aislar el problema, usa el siguiente método:

  1. Omite la malla de servicios: implementa un Pod de cliente temporal en un espacio de nombres en el que la inserción de sidecar esté inhabilitada o usa la anotación sidecar.istio.io/inject: "false" en la especificación del Pod para evitar la inserción de la carga de trabajo de prueba.
  2. Prueba la conectividad: intenta conectarte al destino externo (por ejemplo, con curl, ping o nc) desde el Pod que no es de malla.
  3. Analiza los resultados:
    • Si la conexión se realiza correctamente: el enrutamiento de red subyacente de GKE, las reglas de ip-masq-agent y la puerta de enlace de Cloud NAT están configurados correctamente. El bloqueo de conectividad se debe a las políticas de Cloud Service Mesh, las reglas de salida faltantes o las reglas de mTLS. Para obtener más información sobre la solución de problemas, consulta Soluciona problemas de implementaciones que usan Envoy en la documentación de Cloud Service Mesh.
    • Si falla la conexión: el problema pertenece a la infraestructura de red subyacente (como el enmascaramiento de IP, Cloud Router, Cloud NAT, las reglas de firewall de VPC o los firewalls locales). Usa los pasos de esta página para verificar tu configuración de enrutamiento.

Determina el rango de direcciones IP de origen con el verificador

Antes de configurar routers o firewalls, usa el verificador de enmascaramiento de IP en este documento y haz lo siguiente:

  1. Pega el contenido YAML de tu ConfigMap ip-masq-agent en el campo de configuración.
  2. Ingresa la dirección IP de destino de tu extremo de destino (como tu base de datos local o un servicio de Internet externo).
  3. Haz clic en Verificar enmascaramiento.
  4. Toma nota del resultado:
    • Enmascarado: el paquete usa el rango de direcciones IP del nodo como origen.
    • No enmascarado: el paquete usa el rango de direcciones IP del Pod como origen.

Configura la conectividad a los extremos

Según los resultados del verificador de enmascaramiento de IP, configura tus rutas de red y puertas de enlace según el tipo de destino.

Extremos locales (VPN o Interconnect)

Cloud NAT no se usa para la conectividad local, pero debes configurar tus routers y firewalls según el rango de direcciones IP de origen que determinaste con el verificador de enmascaramiento de IP.

Si el tráfico está enmascarado (el origen es la dirección IP del nodo):

  1. Cloud Router: asegúrate de que los anuncios de Cloud Router incluyan el rango de direcciones IP principal de la subred del clúster de GKE.
  2. Router o firewall local: configura tus routers y firewalls locales para permitir y controlar el tráfico entrante desde el rango de direcciones IP del nodo de GKE.

Si el tráfico no está enmascarado (el origen es la dirección IP del Pod):

  1. Cloud Router: configura anuncios de ruta personalizados en tu Cloud Router para anunciar el rango de direcciones IP secundario del Pod de GKE a tu red local.
  2. Router o firewall local: configura tablas de enrutamiento y firewalls locales para permitir el tráfico que se origina en el rango de direcciones IP del Pod de GKE y asegúrate de que las rutas de retorno se anuncien de nuevo a la VPC.

Extremos de Internet (Cloud NAT)

Cuando enrutes el tráfico a extremos de Internet públicos, debes configurar una puerta de enlace de Cloud NAT dentro de la VPC.

  1. En la Cloud de Confiance consola, ve a la página Cloud NAT.
  2. Selecciona o crea tu puerta de enlace de Cloud NAT.
  3. En Origen de Cloud NAT, elige cómo la puerta de enlace controla los rangos de subred de GKE:
    • Si el tráfico está enmascarado (el origen es la dirección IP del nodo): selecciona los rangos de direcciones IP principales de la subred. Las implementaciones comerciales de GKE suelen usar esta opción de forma predeterminada.
    • Si el tráfico no está enmascarado (el origen es la dirección IP del Pod): debes seleccionar los rangos de direcciones IP principales y secundarias (o especificar el rango secundario del Pod de GKE de forma explícita). Si seleccionas solo rangos principales, se bloqueará el tráfico de Internet del Pod de GKE.