Solucionar problemas de pérdida de paquetes de Cloud NAT desde un clúster

En esta página se explica cómo resolver problemas de pérdida de paquetes de Cloud NAT en un clúster de Google Kubernetes Engine (GKE) nativo de VPC con nodos privados habilitados.

Las VMs de nodo de los clústeres de GKE nativos de VPC con nodos privados no tienen direcciones IP externas. Esto significa que los clientes de Internet no pueden conectarse a las direcciones IP de los nodos. Puedes usar Cloud NAT para asignar las direcciones IP externas y los puertos que permiten que los clústeres con nodos privados realicen conexiones públicas.

Si una VM de nodo se queda sin la asignación de puertos externos y direcciones IP de Cloud NAT, los paquetes se descartarán. Para evitarlo, puede reducir la tasa de paquetes salientes o aumentar la asignación de direcciones IP y puertos de origen de Cloud NAT disponibles. En las siguientes secciones se describe cómo diagnosticar y solucionar problemas de pérdida de paquetes de Cloud NAT en el contexto de clústeres de GKE con nodos privados.

Diagnosticar la pérdida de paquetes

En las siguientes secciones se explica cómo registrar los paquetes perdidos con Cloud Logging y cómo diagnosticar la causa de los paquetes perdidos con Cloud Monitoring.

Registrar paquetes descartados

Puedes registrar los paquetes perdidos con la siguiente consulta en Cloud Logging:

resource.type="nat_gateway"
resource.labels.region=REGION
resource.labels.gateway_name=GATEWAY_NAME
jsonPayload.allocation_status="DROPPED"

Haz los cambios siguientes:

  • REGION: el nombre de la región en la que se encuentra el clúster.
  • GATEWAY_NAME: nombre de la pasarela de Cloud NAT.

Este comando devuelve una lista de todos los paquetes descartados por una pasarela Cloud NAT, pero no identifica la causa.

Monitorizar las causas de la pérdida de paquetes

Para identificar las causas de los paquetes descartados, consulta el observador de métricas en Cloud Monitoring. Los paquetes se pierden por uno de estos tres motivos:

  • OUT_OF_RESOURCES
  • ENDPOINT_INDEPENDENT_CONFLICT
  • NAT_ALLOCATION_FAILED

Para identificar los paquetes descartados debido a los códigos de error OUT_OF_RESOURCES o ENDPOINT_ALLOCATION_FAILED, usa la siguiente consulta:

fetch nat_gateway
  metric 'router.googleapis.com/nat/dropped_sent_packets_count'
  filter (resource.gateway_name == GATEWAY_NAME)
  align rate(1m)
  every 1m
  group_by [metric.reason],
    [value_dropped_sent_packets_count_aggregate:
       aggregate(value.dropped_sent_packets_count)]

Si identifica paquetes que se descartan por estos motivos, consulte Paquetes descartados por falta de recursos y Paquetes descartados por conflicto independiente del endpoint para obtener consejos sobre cómo solucionar el problema.

Para identificar los paquetes descartados debido al código de error NAT_ALLOCATION_FAILED, usa la siguiente consulta:

fetch nat_gateway
  metric 'router.googleapis.com/nat/nat_allocation_failed'
  group_by 1m,
    [value_nat_allocation_failed_count_true:
       count_true(value.nat_allocation_failed)]
  every 1m

Si identificas paquetes que se han descartado por este motivo, consulta la sección Necesito asignar más direcciones IP.

Investigar la configuración de Cloud NAT

Si las consultas anteriores devuelven resultados vacíos y los pods de GKE no pueden comunicarse con direcciones IP externas, consulta la siguiente tabla para solucionar los problemas de tu configuración:

Configuración Solución de problemas
Cloud NAT configurado para aplicarse solo al intervalo de direcciones IP principal de la subred. Cuando Cloud NAT se configura solo para el intervalo de direcciones IP principal de la subred, los paquetes enviados del clúster a direcciones IP externas deben tener una dirección IP de nodo de origen. En esta configuración de Cloud NAT:
  • Los pods pueden enviar paquetes a direcciones IP externas si esos destinos están sujetos a enmascaramiento de IP. Al implementar el ip-masq-agent, comprueba que la lista nonMasqueradeCIDRs no contenga la dirección IP y el puerto de destino. Los paquetes enviados a esos destinos se convierten primero en direcciones IP de nodos de origen antes de que Cloud NAT los procese.
  • Para permitir que los pods se conecten a todas las direcciones IP externas con esta configuración de Cloud NAT, asegúrate de que se haya desplegado ip-masq-agent y de que la lista nonMasqueradeCIDRs solo contenga los intervalos de direcciones IP de los nodos y los pods del clúster. Los paquetes enviados a destinos fuera del clúster se convierten primero en direcciones IP de nodos de origen antes de que Cloud NAT los procese.
  • Para evitar que los pods envíen paquetes a algunas direcciones IP externas, debes bloquear explícitamente esas direcciones para que no se enmascaren. Cuando se haya implementado el ip-masq-agent, añade las direcciones IP externas que quieras bloquear a la lista nonMasqueradeCIDRs. Los paquetes enviados a esos destinos salen del nodo con sus direcciones IP de pod de origen originales. Las direcciones IP de los pods proceden de un intervalo de direcciones IP secundario de la subred del clúster. Con esta configuración, Cloud NAT no funcionará en ese intervalo secundario.
Cloud NAT configurado para aplicarse solo al intervalo de direcciones IP secundarias de la subred que se usa para las IPs de los pods.

Cuando Cloud NAT se configura solo para el intervalo de direcciones IP secundarias de la subred que usan las IPs de los pods del clúster, los paquetes enviados desde el clúster a direcciones IP externas deben tener una dirección IP de pod de origen. En esta configuración de Cloud NAT:

  • Si usas un agente de enmascaramiento de IP , los paquetes perderán la dirección IP del pod de origen cuando los procese Cloud NAT. Para conservar la dirección IP del pod de origen, especifica intervalos de direcciones IP de destino en una lista de nonMasqueradeCIDRs. Con ip-masq-agent implementado, los paquetes enviados a destinos de la lista nonMasqueradeCIDRs conservan sus direcciones IP de origen de Pod antes de que Cloud NAT los procese.
  • Para permitir que los pods se conecten a todas las direcciones IP externas con esta configuración de Cloud NAT, asegúrate de que ip-masq-agent esté desplegado y de que la lista nonMasqueradeCIDRs sea lo más grande posible (0.0.0.0/0 especifica todos los destinos de direcciones IP). Los paquetes enviados a todos los destinos conservan las direcciones IP de los pods de origen antes de que Cloud NAT los procese.

Reducir la pérdida de paquetes

Una vez que hayas diagnosticado la causa de la pérdida de paquetes, te recomendamos que sigas estas indicaciones para reducir la probabilidad de que el problema vuelva a producirse en el futuro:

  • Configura la pasarela de Cloud NAT para que use la asignación dinámica de puertos y aumenta el número máximo de puertos por VM.

  • Si usas la asignación de puertos estáticos, aumenta el número mínimo de puertos por VM.

  • Reduce la tasa de paquetes salientes de tu aplicación. Cuando una aplicación establece varias conexiones salientes a la misma dirección IP y puerto de destino, puede consumir rápidamente todas las conexiones que Cloud NAT puede establecer con ese destino usando el número de direcciones de origen NAT asignadas y las tuplas de puerto de origen.

    Para obtener información sobre cómo usa Cloud NAT las direcciones de origen y los puertos de origen de NAT para establecer conexiones, incluidos los límites del número de conexiones simultáneas a un destino, consulta Puertos y conexiones.

    Para reducir la tasa de conexiones salientes de la aplicación, reutiliza las conexiones abiertas. Entre los métodos habituales para reutilizar conexiones se incluyen la agrupación de conexiones, la multiplexación de conexiones mediante protocolos como HTTP/2 o el establecimiento de conexiones persistentes que se reutilizan para varias solicitudes. Para obtener más información, consulta Puertos y conexiones.

Siguientes pasos