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

Esta sección 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' is exhausted.
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 de Google Cloud compatible oficialmente. Puedes usar la herramienta gcpdiag para identificar y corregir problemas del proyecto de Google Cloud. 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 de Google Cloud

  1. Completa y, luego, copia el siguiente comando. 
    2. gcpdiag runbook gke/ip-exhaustion --project=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 consola de Google Cloud 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 --project=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:

  • --project: El PROJECT_ID
  • --universe-domain: Si corresponde, el dominio de Trusted Partner Sovereign Cloud que aloja el recurso
  • --parameter o -p: Parámetros del runbook

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.

Es posible que el extremo de Private Service Connect tenga filtraciones durante la eliminación del clúster.

Síntomas

No puedes ver un extremo conectado en Private Service Connect en tu clúster basado en Private Service Connect.

No puedes borrar la subred ni la red de VPC en la que se asignó el extremo de Private Service Connect. Aparecerá un mensaje de error similar al siguiente:

projects/<PROJECT_ID>/regions/<REGION>/subnetworks/<SUBNET_NAME> is already being used by projects/<PROJECT_ID>/regions/<REGION>/addresses/gk3-<ID>
Causas posibles

En los clústeres de GKE que usan Private Service Connect, GKE implementa un extremo de Private Service Connect con una regla de reenvío que asigna una dirección IP interna para acceder al plano de control del clúster en la red de un plano de control. Para proteger la comunicación entre el plano de control y los nodos con Private Service Connect, GKE mantiene el extremo invisible, y no puedes verlo en la consola de Google Cloud ni en gcloud CLI.

Solución

Para evitar que se filtre el extremo de Private Service Connect antes de borrar el clúster, completa los siguientes pasos:

  1. Asigna Kubernetes Engine Service Agent role a la cuenta de servicio de GKE.
  2. Asegúrate de que los permisos compute.forwardingRules.* y compute.addresses.* no se rechacen de forma explícita desde la cuenta de servicio de GKE.

Si ves que se filtró el extremo de Private Service Connect, comunícate con el equipo de asistencia.

¿Qué sigue?