Solucionar problemas de gestión de direcciones IP en clústeres de VPC

En esta página se explica cómo resolver problemas con la gestión de direcciones IP en clústeres de VPC en Google Kubernetes Engine (GKE).

En esta página se explica cómo pueden diagnosticar y resolver problemas los administradores y operadores de la plataforma, como el agotamiento de direcciones IP de nodos y pods, la solución de errores de configuración de red que bloquean las operaciones del clúster (como los conflictos de intervalos), la gestión de intervalos CIDR de direcciones IP y la configuración correcta de funciones como SNAT predeterminado, Cloud NAT y redes de pila dual.

Esta página también ayuda a los desarrolladores de aplicaciones a entender cómo pueden afectar a sus cargas de trabajo las limitaciones de la red subyacente, como el espacio de IP agotado, lo que puede provocar problemas como que no se puedan programar pods. Aunque los desarrolladores no configuren directamente las VPCs, conocer estos problemas habituales les ayuda a colaborar mejor con los administradores y operadores de la plataforma para resolverlos más rápido. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido deGoogle Cloud , consulta Roles y tareas habituales de los usuarios de GKE.

Diagnosticar el agotamiento de direcciones IP

Si te quedas sin direcciones IP en tu clúster, no podrás escalar los nodos y tus cargas de trabajo se verán afectadas. En esta sección se explica cómo usar la monitorizació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 mediante datos de estadísticas de Network Analyzer y otras fuentes de datos de GKE. Esta monitorización está disponible para todos los clústeres nativos de VPC.

Para ver el uso de las direcciones IP de un clúster, sigue estos pasos:

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

    Ir a clústeres de Kubernetes

  2. Haga clic en el nombre del clúster que quiera examinar. Al hacerlo, se abrirá la página Detalles del clúster.

  3. Ve a la página Utilización de IP con uno de los siguientes métodos:

    • Seleccione la pestaña Observabilidad y, a continuación, en el menú de navegación de observabilidad, haga clic en Utilización de IP.

    • En la sección Redes, busca la fila Intervalo de IPv4 de pods del clúster (predeterminado) y haz clic en Ver uso de IPs.

  4. Consulta la columna Estado de asignación de IP. En esta columna se muestra el porcentaje de direcciones IP asignadas en el intervalo de direcciones IP de tu pod. GKE considera que todas las direcciones IP del intervalo CIDR asignado a un nodo están asignadas, independientemente de si se han asignado direcciones IP individuales a los pods. Esto significa que el porcentaje refleja todo el intervalo de pods de un nodo, no solo las direcciones IP en uso. Si los clústeres comparten los mismos intervalos de direcciones IP, el porcentaje de utilización muestra el total combinado.

  5. Para ver un desglose detallado del uso de las direcciones IP, incluidos los intervalos CIDR, la información de las subredes y las recomendaciones, haga clic en Mostrar detalles.

Si el uso de tu dirección IP es alto (cercano al 100%), considera estas soluciones para evitar que se agoten las direcciones IP:

  • Añade más intervalos de direcciones IPv4 de pods mediante CIDR de varios pods no contiguos. Esta función te permite añadir más direcciones IPv4 a tus pods sin tener que volver a crear tu clúster ni configurar subredes nuevas.
  • Añade más subredes con intervalos de direcciones IPv4 adicionales al clúster. Esta función permite que los nuevos grupos de nodos usen direcciones IP de subredes recién añadidas.
  • Crea un clúster con un valor inferior para el número máximo de pods. Con este método, se reservan menos direcciones IP para cada nodo, lo que puede ayudarte a gestionar el consumo general de direcciones IP en el intervalo de red de tu clúster. Para obtener más información, consulta Configurar el número máximo de pods por nodo.
  • Si no tienes suficientes intervalos de direcciones IP o espacio de direcciones RFC 1918, considera la posibilidad de usar intervalos que no sean RFC 1918 (incluido el espacio de direcciones de clase E).

Solucionar problemas de red específicos

En las siguientes secciones se ofrecen directrices para resolver problemas relacionados con clústeres nativos de VPC. También puedes consultar estadísticas de uso de direcciones IP de GKE.

El recurso de red predeterminado no está listo

Síntomas

Aparece un mensaje de error similar al siguiente:

projects/[PROJECT_NAME]/regions/XXX/subnetworks/default
Posibles causas

Hay operaciones paralelas en la misma subred. Por ejemplo, se está creando otro clúster nativo de VPC o se está añadiendo o eliminando un intervalo secundario en la subred.

Resolución

Vuelve a intentar el comando.

Valor no válido para IPCidrRange

Síntomas

Aparece un mensaje de error similar al siguiente:

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

Se está creando otro clúster nativo de VPC al mismo tiempo y está intentando asignar los mismos intervalos en la misma red de VPC.

Se está añadiendo el mismo intervalo secundario a la subred en la misma red de VPC.

Resolución

Si se devuelve este error al crear un clúster cuando no se han especificado rangos secundarios, vuelve a intentar ejecutar el comando de creación del clúster.

No hay suficiente espacio de direcciones IP libres para los pods

Síntomas

El clúster se ha quedado bloqueado en un estado de aprovisionamiento durante un periodo prolongado.

La creación del clúster devuelve un error de grupo de instancias gestionado (MIG).

Cuando añades uno o varios 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]'.
Posibles causas

Agotamiento de las direcciones IP de los nodos: el intervalo de direcciones IP principal de la subred asignada a tu clúster se queda sin direcciones IP disponibles. Esto suele ocurrir al escalar grupos de nodos o crear clústeres grandes.

Agotamiento de las direcciones IP de los pods: el intervalo CIDR de los pods asignado a tu clúster está lleno. Esto ocurre cuando el número de pods supera la capacidad de Pod CIDR, sobre todo cuando hay una alta densidad de pods por nodo o en implementaciones grandes.

Convenciones de nomenclatura de subredes específicas: la forma en que se denomina una subred en un mensaje de error puede ayudarte a determinar si el problema está relacionado con el intervalo de direcciones IP de los nodos (donde los nodos obtienen su dirección IP) o con el intervalo de direcciones IP de los pods (donde los contenedores de los pods obtienen sus direcciones IP).

Agotamiento del intervalo secundario (Autopilot): en los clústeres de Autopilot, los intervalos secundarios asignados a las direcciones IP de los pods se agotan debido al escalado o a la alta densidad de pods.

Solución

Recoge la siguiente información sobre tu clúster: nombre, versión del plano de control, modo de funcionamiento, nombre de la VPC asociada y nombre y CIDR de la subred. Además, ten en cuenta los intervalos IPv4 de pods del clúster predeterminados y adicionales (incluidos los nombres y los CIDR), si el enrutamiento del tráfico nativo de VPC está habilitado y el ajuste de número máximo de pods por nodo tanto a nivel de clúster como de grupo de nodos (si procede). Anota los grupos de nodos afectados, sus intervalos de direcciones IP de pods IPv4 específicos y las configuraciones de número máximo de pods por nodo si difieren de los ajustes de todo el clúster. Además, registra las configuraciones predeterminadas y personalizadas (si las hay) del número máximo de pods por nodo en la configuración del grupo de nodos.

Confirmar el problema de agotamiento de direcciones IP

  • Network Intelligence Center: comprueba si hay tasas de asignación de direcciones IP elevadas en los intervalos de direcciones IP de pods en Network Intelligence Center de tu clúster de GKE.

    Si observa una tasa de asignación de direcciones IP alta en los intervalos de pods de Network Intelligence Center, significa que se ha agotado el intervalo de direcciones IP de los pods.

    Si los intervalos de direcciones IP de los pods muestran tasas de asignación normales, pero sigues experimentando agotamiento de direcciones IP, es probable que se haya agotado el intervalo de direcciones IP de tu nodo.

  • Registros de auditoría: examina el campo resourceName en las entradas de IP_SPACE_EXHAUSTED y compáralo con los nombres de subred o los nombres del intervalo de direcciones IP de Pod secundarias.

  • Comprueba si el intervalo de direcciones IP agotado es el del nodo o el del pod.

    Para verificar si el intervalo de direcciones IP agotado es el intervalo de direcciones IP de los nodos o el intervalo de direcciones IP de los pods, comprueba si el valor de resourceName en la parte ipSpaceExhausted de una entrada de registro IP_SPACE_EXHAUSTED se corresponde con el nombre de la subred o con el nombre del intervalo de direcciones IPv4 secundario de los pods utilizados en el clúster de GKE afectado.

    Si el valor de resourceName tiene el formato "[Subnet_name]", significa que se ha agotado el intervalo de direcciones IP del nodo. Si el valor de resourceName tiene el formato "[Subnet_name]-[Name_of_Secondary_IPv4_range_for_pods]-[HASH_8BYTES]", entonces se ha agotado el intervalo de direcciones IP de los pods.

Resuelve el agotamiento de las direcciones IP de los pods:

  • Cambiar el tamaño de la notación CIDR del pod: aumenta el tamaño del intervalo de direcciones IP del pod actual. Puedes añadir intervalos de IPs de pods al clúster mediante CIDR de varios pods no contiguos.
  • Crea subredes adicionales: añade subredes con CIDRs de pods dedicados al clúster.

Reduce el número de pods por nodo para liberar direcciones IP:

Agotamiento de direcciones IP de nodos de direcciones:

  • Revisa la planificación de las direcciones IP: asegúrate de que el intervalo de direcciones IP de los nodos se ajuste a tus requisitos de escalado.
  • Crea un clúster (si es necesario): si el intervalo de direcciones IP del nodo está muy limitado, crea un clúster de sustitución con un tamaño de intervalo de direcciones IP adecuado. Consulta los intervalos de IPs de los clústeres nativos de VPC y la planificación de intervalos de IPs.

Depurar problemas de agotamiento de direcciones IP con gcpdiag

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

Para examinar las causas del agotamiento de las direcciones IP en los clústeres de Autopilot y Standard de GKE, ten en cuenta lo siguiente:
  • Estado del clúster: comprueba el estado del clúster si se informa de que se han agotado las direcciones IP.
  • Analizador de red: consulta los registros de Stackdriver para confirmar si hay agotamiento de la dirección IP del pod o del nodo.
  • Tipo de clúster: comprueba el tipo de clúster y proporciona recomendaciones relevantes en función de él.

Google Cloud consola

  1. Completa y 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. Abrir la consola de Cloud
  3. Pega el comando copiado.
  4. Ejecuta el comando gcpdiag, que descarga la imagen de Docker gcpdiag y, a continuación, realiza comprobaciones de diagnóstico. Si procede, sigue las instrucciones de salida para corregir las comprobaciones fallidas.

Docker

Puedes ejecutar gcpdiag mediante un envoltorio que inicie gcpdiag en un contenedor Docker. Debes tener instalado 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 de este runbook.

Haz los cambios siguientes:

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

Marcas útiles:

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

Confirmar si la SNAT predeterminada está inhabilitada

Usa el siguiente comando para comprobar el estado de SNAT predeterminado:

gcloud container clusters describe CLUSTER_NAME

Sustituye CLUSTER_NAME por el nombre de tu clúster.

El resultado debería ser similar al siguiente:

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 definir explícitamente la marca --disable-default-snat al crear el clúster, ya que estás usando direcciones IP públicas en tu clúster privado.

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

Depurar Cloud NAT con SNAT predeterminada inhabilitada

Si has creado un clúster privado con la marca --disable-default-snat y has configurado Cloud NAT para acceder a Internet, pero no ves tráfico procedente de tus pods con destino a Internet, asegúrate de que el intervalo de pods esté incluido en la configuración de Cloud NAT.

Si hay un problema con la comunicación entre pods, examina las reglas de iptables de los nodos para verificar que las reglas de iptables no enmascaren los intervalos de pods.

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

Si no has configurado ningún agente de enmascaramiento de IP para el clúster, GKE se asegura automáticamente de que la comunicación entre pods no se enmascare. Sin embargo, si se configura un agente de enmascaramiento de IP, se anulan las reglas de enmascaramiento de IP predeterminadas. Verifica que se hayan configurado reglas adicionales en el agente de enmascaramiento de IP para ignorar el enmascaramiento de los intervalos de pods.

La comunicación de la red del clúster de pila dual no funciona como se espera

Posibles causas
Las reglas de cortafuegos creadas por el clúster de GKE no incluyen las direcciones IPv6 asignadas.
Resolución
Para validar la regla de cortafuegos, sigue estos pasos:

  1. Verifica el contenido de la regla de cortafuegos:

    gcloud compute firewall-rules describe FIREWALL_RULE_NAME

    Sustituye FIREWALL_RULE_NAME por el nombre de la regla de cortafuegos.

    Cada clúster de doble pila crea una regla de cortafuegos que permite que los nodos y los pods se comuniquen entre sí. El contenido de la regla de cortafuegos 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 de sourceRanges debe ser el mismo que el de subnetIpv6CidrBlock. El valor targetTags debe ser el mismo que el de las etiquetas de los nodos de GKE. Para solucionar este problema, actualiza la regla de cortafuegos con la información de bloqueo del clúster ipAllocationPolicy.

Siguientes pasos