Soluciona problemas relacionados con la administración de direcciones IP en clústeres de VPC

En esta página, se te ayudará a resolver problemas relacionados con la administración de direcciones IP en clústeres de VPC en Google Kubernetes Engine (GKE).

En esta página, se orienta a los administradores y operadores de la plataforma para diagnosticar y resolver problemas, como el agotamiento de direcciones IP para nodos y Pods, la solución de errores de configuración de red que bloquean las operaciones del clúster (como conflictos de rangos), la administración de rangos de CIDR de direcciones IP y la configuración correcta de funciones como la SNAT predeterminada, Cloud NAT y las redes de doble pila.

Esta página también ayuda a los desarrolladores de aplicaciones a comprender cómo las limitaciones de la red subyacente, como el espacio IP agotado, pueden afectar sus cargas de trabajo y generar problemas como la imposibilidad de programar Pods. Si bien es posible que los desarrolladores no configuren las VPC directamente, comprender estos problemas comunes los ayuda a colaborar mejor con los administradores y operadores de la plataforma para lograr resoluciones más rápidas. Para obtener más información sobre los roles comunes y las tareas de ejemplo a los que hacemos referencia en el contenido deGoogle Cloud , consulta Roles y tareas comunes de los usuarios de GKE.

Diagnostica el agotamiento de direcciones IP

Si se agotan las direcciones IP en tu clúster, se puede impedir el ajuste de escala de los nodos y se pueden interrumpir tus cargas de trabajo. En esta sección, se explica cómo usar la supervisión de la utilización de direcciones IP en GKE para detectar y resolver posibles problemas de agotamiento.

GKE calcula la utilización de direcciones IP con datos de las estadísticas de Network Analyzer y otras fuentes de datos de GKE. Esta supervisión está disponible para todos los clústeres nativos de VPC.

Para ver el uso de direcciones IP de un clúster, haz lo siguiente:

  1. En la consola de Google Cloud , ve a la página de clústeres de Kubernetes.

    Ir a clústeres de Kubernetes

  2. Haz clic en el nombre del clúster que deseas examinar. Esta acción abre la página Detalles del clúster.

  3. Navega a la página Uso de IP con uno de los siguientes métodos:

    • Selecciona la pestaña Observabilidad y, luego, en el menú de navegación de observabilidad, haz clic en Uso de IP.

    • En la sección Herramientas de redes, busca la fila Rango IPv4 del Pod del clúster (predeterminado) y haz clic en Ver uso de IP.

  4. Revisa la columna Estado de la asignación de IP. En esta columna, se muestra el porcentaje de direcciones IP asignadas en el rango de direcciones IP de tu Pod. GKE considera que todas las direcciones IP del rango de CIDR asignado de un nodo están asignadas, independientemente de si las direcciones IP individuales están asignadas a Pods. Este comportamiento significa que el porcentaje refleja todo el rango de Pods para un nodo, no solo las direcciones IP en uso. Si los clústeres comparten los mismos rangos de direcciones IP, el porcentaje de uso muestra su total combinado.

  5. Para obtener una vista detallada del uso de direcciones IP, incluidos los rangos de CIDR, la información de subredes y las recomendaciones, haz clic en Mostrar detalles.

Si el uso de tu dirección IP es alto (cerca del 100%), considera estas soluciones para evitar el agotamiento de direcciones IP:

  • Agrega más rangos de direcciones IPv4 de Pods con CIDR de varios Pods discontinuos. Esta función te permite agregar más direcciones IPv4 para tus Pods sin necesidad de volver a crear tu clúster ni configurar subredes nuevas.
  • Agrega más subredes con rangos de direcciones IPv4 adicionales en el clúster. Esta función permite que los grupos de nodos nuevos usen direcciones IP de las subredes agregadas recientemente.
  • Crea un clúster nuevo con un valor más bajo para la cantidad máxima de Pods. Este enfoque reserva menos direcciones IP para cada nodo, lo que puede ayudarte a administrar el consumo general de direcciones IP en el rango de red de tu clúster. Para obtener más información, consulta Configura la cantidad máxima de Pods por nodo.
  • Si no tienes suficientes rangos de direcciones IP o espacio de direcciones RFC 1918, considera usar rangos que no sean RFC 1918 (incluido el espacio de direcciones de clase E).

Soluciona problemas específicos de redes

En las siguientes secciones, se proporciona orientación para resolver problemas relacionados con los clústeres nativos de la VPC. También puedes ver las estadísticas de uso de direcciones IP de GKE.

El recurso de red predeterminado no está listo

Síntomas

Recibirás un mensaje de error similar al siguiente:

projects/[PROJECT_NAME]/regions/XXX/subnetworks/default
Causas posibles

Hay operaciones paralelas en la misma subred. Por ejemplo, cuando se crea otro clúster nativo de la VPC o se agrega o borra un rango secundario en la subred.

Solución

Vuelve a ejecutar el comando.

Valor incorrecto para IPCidrRange

Síntomas

Recibirás un mensaje de error similar al siguiente:

resource.secondaryIpRanges[1].ipCidrRange': 'XXX'. Invalid IPCidrRange: XXX conflicts with existing subnetwork 'default' in region 'XXX'
Causas posibles

Se crea otro clúster nativo de la VPC al mismo tiempo, y este intenta asignar los mismos rangos en la misma red de VPC.

Se agrega el mismo rango secundario a la subred en la misma red de VPC.

Solución

Si se muestra este error cuando creas el clúster y no se especificaron rangos secundarios, vuelve a ejecutar el comando de creación del clúster.

No hay espacio suficiente de dirección IP para Pods

Síntomas

El clúster está atascado en un estado de aprovisionamiento durante un período prolongado.

La creación de clústeres muestra un error de grupo de instancias administrado (MIG).

Cuando agregas uno o más nodos a un clúster, aparece el siguiente error:

[IP_SPACE_EXHAUSTED] Instance 'INSTANCE_NAME' creation failed: IP space of 'projects/PROJECT_ID/regions/REGION/subnetworks/[SUBNET_NAME]-[SECONDARY_RANGE_NAME]-[HASH_8BYTES]' is exhausted. The secondary range name is in the format of 'gke-[CLUSTER_NAME]-[HASH_8BYTES]'.
Causas posibles

Agotamiento de direcciones IP de nodo: El rango de direcciones IP principal de la subred asignada a tu clúster se queda sin direcciones IP disponibles. Por lo general, esto sucede cuando escalas grupos de nodos o creas clústeres grandes.

Agotamiento de direcciones IP del pod: El rango de CIDR del pod asignado a tu clúster está completo. Esto ocurre cuando la cantidad de Pods excede la capacidad del CIDR del Pod, en especial con una densidad de Pod alta por nodo o implementaciones grandes.

Convenciones de nomenclatura de subredes específicas: la forma en que se nombra una subred en un mensaje de error puede ayudarte a averiguar si el problema es con el rango de direcciones IP del nodo (en el que los nodos obtienen sus dirección IP) o el rango de direcciones IP del Pod (en el que los contenedores dentro de los Pods obtienen sus direcciones IP).

Agotamiento del rango secundario (Autopilot): En los clústeres de Autopilot, los rangos secundarios asignados para direcciones IP del Pod se agotan debido al escalamiento o a una densidad alta del Pod.

Solución

Recopila la siguiente información sobre tu clúster: nombre, versión del plano de control, modo de operación, nombre de VPC asociada, nombre de la subred y CIDR. Además, ten en cuenta el rango predeterminado y cualquier rango IPv4 de Pod del clúster adicional (incluidos los nombres y los CIDR), si el enrutamiento de tráfico nativo de la VPC está habilitado y la configuración máxima de Pods por nodo en los niveles de clúster y grupo de nodos (si corresponde). Ten en cuenta los grupos de nodos afectados y sus rangos de direcciones IP de Pods específicos de IPv4 y máximos Pods por configuración de nodo si difieren de la configuración de todo el clúster. Además, registra la configuración predeterminada y personalizada (si existe) para la cantidad máxima de Pods por nodo en la configuración del grupo de nodos.

Confirma el problema de agotamiento de la dirección IP

  • Network Intelligence Center: Verifica las tasas de asignación de direcciones IP altas en los rangos de direcciones IP de Pods en Network Intelligence Center para tu clúster de GKE.

    Si observas una tasa de asignación de direcciones IP alta en los rangos de Pods dentro de Network Intelligence Center, entonces el rango de direcciones IP del Pod se agota.

    Si los rangos de direcciones IP del Pod muestran tasas de asignación normales, pero aún experimentas el agotamiento de la dirección IP, es probable que el rango de direcciones IP del nodo se haya agotado.

  • Registros de auditoría: Examina el campo resourceName en las entradas IP_SPACE_EXHAUSTED y lo compara con los nombres de las subredes o del rango de direcciones IP del Pod secundario.

  • Verifica si el rango de direcciones IP agotado es el rango de direcciones IP del nodo o el rango de direcciones IP del Pod.

    Para verificar si el rango de direcciones IP agotado es el rango de direcciones IP del nodo o el rango de direcciones IP del Pod, verifica si el valor deresourceName en la parte ipSpaceExhausted de una entrada de registro IP_SPACE_EXHAUSTED se correlaciona con el nombre de la subred o el nombre del rango de direcciones IPv4 secundario para los Pods que se usan en el clúster de GKE afectado.

    Si el valor de resourceName tiene el formato “[Subnet_name]”, entonces el rango de direcciones IP del nodo está agotado. Si el valor de resourceName tiene el formato “[Subnet_name]-[Name_of_Secondary_IPv4_range_for_pods]-[HASH_8BYTES]”, entonces se agota el rango de direcciones IP del pod.

Resuelve el agotamiento de la dirección IP del Pod:

  • Cambiar el tamaño del CIDR del Pod existente: aumenta el tamaño del rango de direcciones IP del Pod actual. Puedes agregar rangos de IP de Pod al clúster mediante CIDR de varios pods discontinuos.
  • Crea subredes adicionales: agrega subredes con CIDR de Pods dedicados al clúster.

Reduce los Pods por nodo para liberar direcciones IP:

Agotamiento de direcciones IP del nodo de dirección:

  • Revisa la planificación de las direcciones IP: Asegúrate de que el rango de direcciones IP del nodo se alinee con tus requisitos de escalamiento.
  • Crea un clúster nuevo (si es necesario): Si el rango de direcciones IP del nodo está muy restringido, crea un clúster de reemplazo con el tamaño de rango de direcciones IP adecuado. Consulta Rangos de IP para clústeres nativos de la VPC y Planificación del rango de IP.

Cómo depurar problemas de agotamiento de direcciones IP con gcpdiag

gcpdiag es una herramienta de código abierto. No es un producto Google Cloud compatible oficialmente. Puedes usar la herramienta gcpdiag para identificar y corregir Google Cloudproblemas del proyecto. Para obtener más información, consulta el proyecto en GitHub.

Para examinar las causas del agotamiento de las direcciones IP en los clústeres de GKE Autopilot y Standard, ten en cuenta lo siguiente:
  • Estado del clúster: Verifica el estado del clúster si se informa el agotamiento de direcciones IP.
  • Network Analyzer: Consulta los registros de Stackdriver en busca de registros de Network Analyzer para confirmar si hay un agotamiento de direcciones IP de Pods o nodos.
  • Tipo de clúster: Verifica el tipo de clúster y proporciona recomendaciones relevantes según el tipo de clúster.

Consola deGoogle Cloud

  1. Completa y, luego, copia el siguiente comando. 
    2. gcpdiag runbook gke/ip-exhaustion \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=ZONE|REGION \
    --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
    --parameter end_time=yyyy-mm-ddThh:mm:ssZ \
  2. Abre la Google Cloud consola y activa Cloud Shell.
    3. Abre la consola de Cloud
  3. Pega el comando copiado.
  4. Ejecuta el comando gcpdiag, que descarga la imagen de Docker gcpdiag y, luego, realiza verificaciones de diagnóstico. Si corresponde, sigue las instrucciones de salida para corregir las verificaciones que fallaron.

Docker

Puedes ejecutar gcpdiag con un wrapper que inicie gcpdiag en un contenedor de Docker. Se debe instalar Docker o Podman.

  1. Copia y ejecuta el siguiente comando en tu estación de trabajo local. 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Ejecuta el comando gcpdiag. 
    ./gcpdiag runbook gke/ip-exhaustion \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=ZONE|REGION \
    --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
    --parameter end_time=yyyy-mm-ddThh:mm:ssZ \

Consulta los parámetros disponibles para este runbook.

Reemplaza lo siguiente:

  • PROJECT_ID: Es el ID del proyecto que contiene el recurso.
  • CLUSTER_NAME: Es el nombre del clúster de GKE de destino dentro de tu proyecto.
  • LOCATION: Es la zona o región en la que se encuentra el clúster.
  • start_time: Es la hora en que comenzó el problema.
  • end_time: Es la hora en la que finalizó el problema. Establece la hora actual si el problema persiste.

Marcas útiles:

Para obtener una lista y una descripción de todas las marcas de la herramienta gcpdiag, consulta las instrucciones de uso de gcpdiag.

Confirma si la SNAT predeterminada está inhabilitada

Usa el siguiente comando para verificar el estado de la sNAT predeterminada:

gcloud container clusters describe CLUSTER_NAME

Reemplaza CLUSTER_NAME por el nombre del clúster.

El resultado es similar a este:

networkConfig:
  disableDefaultSnat: true
  network: ...

No se puede usar --disable-default-snat sin --enable-ip-alias

Este mensaje de error, y must disable default sNAT (--disable-default-snat) before using public IP address privately in the cluster, significan que debes configurar de manera explícita la marca --disable-default-snat cuando creas el clúster, ya que usas direcciones IP públicas en tu clúster privado.

Si ves mensajes de error como cannot disable default sNAT ..., esto significa que la SNAT predeterminada no se puede inhabilitar en tu clúster. Para resolver este problema, revisa la configuración de tu clúster.

Depura Cloud NAT con sNAT predeterminada inhabilitada

Si tienes un clúster privado creado con la marca --disable-default-snat, configuraste Cloud NAT para el acceso a Internet y no ves tráfico vinculado a Internet desde tus pods, asegúrate de que el rango de pod esté incluido en la configuración de Cloud NAT.

Si hay un problema con la comunicación de pod a pod, examina las reglas de iptables en los nodos para verificar que estas no enmascaren los rangos de pods.

Para obtener más información, consulta la documentación de enmascaramiento de IP de GKE.

Si no configuraste un agente de enmascaramiento de IP para el clúster, GKE garantiza de forma automática que la comunicación de pod a pod no esté enmascarada. Sin embargo, si se configura un agente de enmascaramiento de IP, este anula las reglas de enmascaramiento de IP predeterminadas. Verifica que las reglas adicionales estén configuradas en el agente de enmascaramiento de IP para ignorar el enmascaramiento de los rangos de Pods.

La comunicación de red de clústeres de pila doble no funciona como se espera.

Causas posibles
Las reglas de firewall creadas por el clúster de GKE no incluyen las direcciones IPv6 asignadas.
Solución
Puedes validar la regla de firewall si sigues estos pasos:

  1. Verifica el contenido de la regla de firewall:

    gcloud compute firewall-rules describe FIREWALL_RULE_NAME

    Reemplaza FIREWALL_RULE_NAME por el nombre de la regla de firewall.

    Cada clúster de pila doble crea una regla de firewall que permite que los nodos y los Pods se comuniquen entre sí. El contenido de la regla de firewall es similar al siguiente:

    allowed:
- IPProtocol: esp
- IPProtocol: ah
- IPProtocol: sctp
- IPProtocol: tcp
- IPProtocol: udp
- IPProtocol: '58'
creationTimestamp: '2021-08-16T22:20:14.747-07:00'
description: ''
direction: INGRESS
disabled: false
enableLogging: false
id: '7326842601032055265'
kind: compute#firewall
logConfig:
  enable: false
name: gke-ipv6-4-3d8e9c78-ipv6-all
network: https://www.googleapis.com/compute/alpha/projects/my-project/global/networks/alphanet
priority: 1000
selfLink: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/gke-ipv6-4-3d8e9c78-ipv6-all
selfLinkWithId: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/7326842601032055265
sourceRanges:
- 2600:1900:4120:fabf::/64
targetTags:
- gke-ipv6-4-3d8e9c78-node

    El valor sourceRanges debe ser el mismo que el de subnetIpv6CidrBlock. El valor targetTags debe ser el mismo que el de las etiquetas en los nodos de GKE. Para solucionar este problema, actualiza la regla de firewall con la información del bloque ipAllocationPolicy del clúster.

¿Qué sigue?