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

En los clústeres de Google Kubernetes Engine (GKE) nativos de VPC, los nodos sin direcciones IP externas mejoran la seguridad. Estos nodos usan Cloud NAT para las conexiones salientes a Internet. La pérdida de paquetes puede producirse si una VM de nodo agota los puertos y las direcciones IP de Cloud NAT asignados, a menudo con una carga de salida alta, lo que interrumpe el tráfico de salida.

En este documento se explica cómo registrar y monitorizar los paquetes perdidos, investigar la configuración de Cloud NAT e implementar medidas para reducir la pérdida de paquetes en el futuro.

Esta información es importante para los administradores y operadores de la plataforma, así como para los administradores de redes que gestionan clústeres de GKE con nodos sin acceso a Internet y que dependen de Cloud NAT para la conectividad externa. Para obtener más información sobre los roles habituales y las tareas de ejemplo a los que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE.Google Cloud

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 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 bloquearlas explícitamente 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 fuentes de direcciones IP de pod 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 se usa un agente de enmascaramiento de IP, los paquetes pierden la dirección IP del pod de origen cuando los procesa Cloud NAT. Para conservar la dirección IP del pod de origen, especifica intervalos de direcciones IP de destino en una lista 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