Crea un clúster nativo de la VPC

En esta página se explica cómo configurar los clústeres nativos de la VPC en Google Kubernetes Engine.

Descripción general

En GKE, los clústeres se pueden distinguir de acuerdo con la forma en la que enrutan el tráfico de un pod a otro. Un clúster que usa rangos de IP de alias se denomina clúster nativo de la VPC. Un clúster que usa rutas de Google Cloud se denomina clúster basado en rutas.

Beneficios de los clústeres nativos de la VPC

Los clústeres nativos de la VPC tienen varios beneficios:

  • Las direcciones IP del pod se pueden enrutar de forma nativa dentro de la red de VPC del clúster y otras redes de VPC conectadas mediante intercambio de tráfico de la red de VPC.
  • Las direcciones IP de un pod se reservan en la red de VPC antes de que se creen los pods en tu clúster. Esto evita conflictos con otros recursos de la red de VPC y te permite planificar mejor las asignaciones de direcciones IP.
  • Los rangos de IP de un pod no dependen de rutas estáticas personalizadas. No consumen la cuota de rutas estáticas personalizadas y generadas por el sistema. En su lugar, las rutas de subred generadas automáticamente manejan el enrutamiento para los clústeres nativos de la VPC.
  • Puedes crear reglas de firewall que se apliquen solo a los rangos de IP del pod en lugar de cualquier dirección IP en los nodos del clúster.
  • Los nodos de un clúster nativo de la VPC tienen habilitada la verificación contra la falsificación de identidad. Las herramientas de redes de VPC realizan verificaciones contra la falsificación de identidad que evitan que los nodos puedan enviar paquetes con direcciones IP de origen arbitrarias. (La verificación contra la falsificación de identidad está inhabilitada para los clústeres basados en rutas).
  • En general, los rangos de IP del pod y los rangos de IP secundarios de la subred se pueden compartir con redes locales conectadas con Cloud VPN o Cloud Interconnect mediante Cloud Routers.
  • Los rangos de IP de alias permiten a los pods acceder directamente a los servicios alojados sin usar una puerta de enlace NAT.

Restricciones

  • No puedes convertir un clúster nativo de la VPC en un clúster basado en rutas, y no puedes convertir un clúster basado en rutas en un clúster nativo de la VPC.

  • Los clústeres nativos de la VPC requieren redes de VPC. Las redes heredadas no son compatibles.

  • Al igual que con cualquier clúster de GKE, las direcciones de servicio (ClusterIP) solo están disponibles en el clúster. Si necesitas acceder a un servicio de Kubernetes desde instancias de VM fuera del clúster, pero dentro de su red y región de VPC, crea un balanceador de cargas TCP/UDP interno.

Rangos de IP para clústeres nativos de la VPC

Cuando creas un clúster nativo de la VPC, especificas una subred en una red de VPC. El clúster usa tres rangos de IP de subred únicos:

  • Utiliza el rango de IP principal de la subred para todas las direcciones IP de nodo.
  • Utiliza un rango de IP secundario para todas las direcciones IP del pod.
  • Utiliza otro rango de IP secundario para todas las direcciones del servicio (IP del clúster).

En la siguiente tabla, se proporciona un resumen de los rangos de direcciones IP para nodos, pods y servicios:

Rango Explicación Ejemplo
Nodos

Las direcciones IP de nodo se asignan a partir del rango de direcciones IP principales de la subred asociada a tu clúster.

Tanto las direcciones IP de nodo como el tamaño del rango de IP secundario de la subred para pods limitan la cantidad de nodos con los que es compatible un clúster. Consulta los rangos de límite de nodo para obtener más información.

Si planeas crear un clúster de 900 nodos, el rango de direcciones IP principal de la subred del clúster debe ser al menos un /22 (2(32-22) = 210 = 1,024 direcciones). De esas 1,024 direcciones, se pueden utilizar 1,020 porque cuatro direcciones IP están reservadas en cada rango de direcciones IP principal.

Para obtener más información, consulta las secciones Rango de direcciones IP principal de la subred y Rango de direcciones IP secundario de la subred para los pods.

Pods

Las direcciones IP del pod se toman del rango de direcciones IP secundario de la subred del clúster para los pods. A menos que defina un número máximo de pods por nodo diferente, GKE asigna un rango de IP de alias de /24 (256 direcciones) a cada nodo para los pods que se ejecutan en él. En cada nodo, esas 256 direcciones IP de alias son compatibles con hasta 110 pods.

Para un clúster de 900 nodos compatible con hasta 110 pods por nodo, necesitas 900 × 256 = 230,400 direcciones IP para los pods. (Cada nodo tiene asignado un rango de IP de alias con un tamaño de máscara de red de /24). Este clúster requiere una subred con un rango de IP secundario para pods que tenga una máscara de subred no mayor que /14. Este rango de IP secundario proporciona 2(32-14) = 218 = 262,144 direcciones IP para los pods.

Consulta Rango de direcciones IP secundario de la subred para los pods si deseas obtener más información.

Servicios

Las direcciones de servicio (IP del clúster) se toman del rango de direcciones IP secundario de la subred del clúster para los servicios. Debes asegurarte de que este rango sea lo suficientemente grande como para proporcionar direcciones a todos los servicios de Kubernetes que alojes en tu clúster.

Para un clúster que ejecute hasta 3,000 servicios, necesitarás 3,000 direcciones IP del clúster. Necesitas un rango secundario de tamaño /20 o superior. Un rango de direcciones IP de /20 da como resultado 2(32-20) = 212 = 4,096 direcciones IP.

Consulta Rango de direcciones IP secundario de la subred para los servicios si deseas obtener más información.

Métodos de asignación del rango secundario

Puedes asignar rangos de IP de pod y rangos de direcciones de servicio (ClusterIP) a un clúster nativo de la VPC mediante uno de estos dos métodos:

Administrado por GKE (predeterminado)

GKE puede crear y administrar los rangos secundarios de la subred automáticamente. Cuando creas el clúster, especificas un rango completo de CIDR o el tamaño de una máscara de red para los pods y los servicios. Por ejemplo, puedes especificar 10.1.0.0/16 para pods y 10.2.0.0/20 para servicios, o puedes especificar /16 para pods y /20 para servicios.

Si creas el clúster y la subred de forma simultánea, GKE administrará los rangos de IP del pod y del servicio.

Administrado por el usuario

Puedes crear los rangos de IP secundarios de la subred y, luego, crear un clúster que use esos rangos. Si creas los rangos secundarios de forma manual, debes administrarlos tú mismo.

Diferencias con los clústeres basados en rutas

El esquema de asignación para direcciones de pods y servicios (ClusterIP) es diferente del esquema utilizado por un clúster basado en rutas. En lugar de especificar un solo CIDR para pods y servicios, debes elegir o crear dos rangos de IP secundarios en la subred del clúster: uno para pods y otro para servicios.

Consideraciones de VPC compartida

Cuando se crea un clúster nativo de la VPC en un entorno de VPC compartida, el propietario del proyecto, editor o miembro de IAM con la función Administrador de red en el proyecto host de VPC compartida debe crear la subred del clúster y los rangos de IP secundarios manualmente. Un administrador de proyecto de servicio que crea un clúster debe tener al menos permisos de nivel de subred en la subred deseada en el proyecto host de la red de VPC compartida.

En un entorno de VPC compartida, GKE no puede administrar los rangos de IP secundarios. Un administrador de red del proyecto host de VPC compartida debe crear la subred y los rangos de IP secundarios antes de que puedas crear el clúster. Para ver un ejemplo sobre cómo configurar un clúster nativo de la VPC en una red de VPC compartida, consulta Configura clústeres con VPC compartida.

Planificación del rango de IP

Utiliza la información de las siguientes secciones para calcular los tamaños de los rangos de IP principales y secundarios de la subred que usa tu clúster.

Rango de direcciones IP principal de la subred

Cada subred debe tener un rango de direcciones IP principal. Puedes expandir el rango de direcciones IP principal en cualquier momento, incluso cuando los recursos de Google Cloud usen la subred. Sin embargo, no se puede reducir ni cambiar el esquema principal de direcciones IP de una subred después de crearla. Google Cloud se reserva las dos primeras y las dos últimas direcciones IP de un rango de IP principal.

En la siguiente tabla, se muestra la cantidad máxima de nodos que se pueden crear en todos los clústeres que usan la subred, según el tamaño del rango de direcciones IP principal de la subred.

Rango de IP principal de la subred Cantidad máx. de nodos
/29
Tamaño mínimo del rango de IP principal de una subred
4 nodos
/28 12 nodos
/27 28 nodos
/26 60 nodos
/25 124 nodos
/24 252 nodos
/23 508 nodos
/22 1,020 nodos
/21 2,044 nodos
/20
Tamaño predeterminado del rango de IP principal de una subred en redes de modo automático
4,092 nodos
/19 8,188 nodos
/8
Tamaño máximo del rango de IP principal de una subred
16,777,212 nodos

Fórmulas útiles

Puedes usar estas fórmulas para lo siguiente:

  • Calcular la cantidad máxima de nodos, N, compatible con una máscara de red específica. Usa S para el tamaño de la máscara de red, cuyo rango válido está entre 8 y 29, inclusive.

    N = 2(32 -S) - 4

  • Calcular el tamaño de la máscara de red, S, que se requiere para ser compatible con un máximo N de nodos:

    S = 32 - ⌈registro2(N + 4)⌉

    ⌈⌉ es la función techo (mínimo entero), es decir, redondea al siguiente número entero. El rango válido para el tamaño de la máscara de red, S, se encuentra entre 8 y 29, inclusive.

Rango de direcciones IP secundario de la subred para pods

Planifica cuidadosamente el rango de IP secundario para pods. Si bien es posible reemplazar el rango de direcciones IP secundario de una subred, no es compatible porque tiene el potencial de colocar el clúster en un estado inestable.

En la siguiente tabla, se muestra la cantidad máxima de nodos y pods que puedes crear en todos los clústeres que usan la subred, dado el tamaño del rango de direcciones IP secundario de la subred que usan los pods. En esta tabla, se supone que el número máximo de pods por nodo es 110 (la densidad máxima posible y predeterminada del pod).

Rango de IP secundario de la subred para pods Cantidad máx. de direcciones IP del pod Cantidad máx. de nodos Cantidad máx. de pods
/24
El menor rango de IP de pod posible cuando el método de asignación del rango secundario es administrado por el usuario
256 direcciones 1 nodo 110 pods
/23
Solo es posible cuando el método de asignación del rango secundario es administrado por el usuario
512 direcciones 2 nodos 220 pods
/22
Solo es posible cuando el método de asignación del rango secundario es administrado por el usuario
1,024 direcciones 4 nodos 440 pods
/21
El menor rango de IP de pod posible cuando el método de asignación del rango secundario es administrado por GKE
2,048 direcciones 8 nodos 880 pods
/20 4,096 direcciones 16 nodos 1,760 pods
/19 8,192 direcciones 32 nodos 3,520 pods
/18 16,384 direcciones 64 nodos 7,040 pods
/17 32,768 direcciones 128 nodos 14,080 pods
/16 65,536 direcciones 256 nodos 28,160 pods
/15 131,072 direcciones 512 nodos 56,320 pods
/14
Tamaño predeterminado del rango de IP secundario de la subred para los pods cuando el método de asignación del rango secundario es administrado por GKE
262,144 direcciones 1,024 nodos 112,640 pods
/13 524,288 direcciones 2,048 nodos 225,280 pods
/12 1,048,576 direcciones 4,096 nodos 450,560 pods
/11
El mayor rango de direcciones posible de pods
2,097,152 direcciones 8,192 nodos 901,120 pods

Si cambiaste el número máximo de pods por nodo, puedes usar las siguientes fórmulas a fin de calcular la cantidad máxima de nodos y pods compatibles con un rango de IP secundario de subred para pods:

  1. Calcula el tamaño de la máscara de red del rango de pods de cada nodo, M.
    M = 31 - ⌈log2(Q)⌉ donde:

    • Q es la cantidad de pods por nodo.
    • ⌈⌉ es la función techo (mínimo entero), es decir, redondea al siguiente número entero.
  2. Calcula la cantidad máxima de nodos, N, compatible con el rango de IP secundario de la subred para pods:
    N = 2(M - S) donde:

    • M es el tamaño de la máscara de red del rango de IP de alias de cada nodo para pods, calculado en el primer paso.
    • S es el tamaño de la máscara de subred del rango de IP secundario de la subred.
  3. Calcula la cantidad máxima de pods, P, compatible con el rango de IP secundario de la subred para pods:
    P = N × Q donde:

    • N es la cantidad máxima de nodos calculada en el paso anterior.
    • Q es la cantidad de pods por nodo.

Rango de direcciones IP secundario de la subred para servicios

Planifica cuidadosamente el rango de IP secundario para servicios. Debido a que este también es un rango de IP secundario de subred, solo puedes reemplazarlo cuando ningún recurso de Google Cloud lo usa. Este rango no se puede cambiar, mientras un clúster lo use para servicios (direcciones IP del clúster).

A diferencia de los rangos de IP de nodos y pods, cada clúster debe tener un rango de IP secundario de subred único para servicios.

La siguiente tabla muestra la cantidad máxima de servicios que puedes crear en un solo clúster con la subred, dado el tamaño del rango de direcciones IP secundario de la subred para servicios.

Rango de IP secundario para servicios Cantidad máxima de servicios
/27
El menor rango de direcciones del servicio posible
32 servicios
/26 64 servicios
/25 128 servicios
/24 256 servicios
/23 512 servicios
/22 1,024 servicios
/21 2,048 servicios
/20
Tamaño predeterminado del rango de IP secundario de la subred para servicios cuando el método de asignación del rango secundario es administrado por GKE
4,096 servicios
/19 8,192 servicios
/18 16,384 servicios
/17 32,768 servicios
/16
El mayor rango de direcciones del servicio posible
65,536 servicios

Rangos de límite de nodo

La cantidad máxima de pods y servicios para un clúster de GKE determinado está limitada por el tamaño de los rangos secundarios del clúster. La cantidad máxima de nodos en el clúster está limitada por el tamaño del rango de direcciones IP principal de la subred del clúster y del rango de direcciones del pod del clúster.

Cloud Console muestra mensajes de error como los siguientes para indicar que se agotó el rango de direcciones IP principal de la subred o el rango de direcciones IP del pod del clúster (el rango de direcciones IP secundario de la subred):

Instance [node name] creation failed: IP space of [cluster subnet] is
exhausted

Antes de comenzar

Sigue estos pasos a fin de prepararte para esta tarea:

  • Asegúrate de que habilitaste la API de Google Kubernetes Engine.
  • Habilitar la API de Google Kubernetes Engine
  • Asegúrate de que instalaste el SDK de Cloud.
  • Establece tu ID del proyecto predeterminado:
    gcloud config set project [PROJECT_ID]
  • Si trabajas con clústeres zonales, establece tu zona de procesamiento predeterminada:
    gcloud config set compute/zone [COMPUTE_ZONE]
  • Si trabajas con clústeres regionales, establece tu región de procesamiento predeterminada:
    gcloud config set compute/region [COMPUTE_REGION]
  • Actualiza gcloud a la versión más reciente:
    gcloud components update

Procedimientos

Usa los siguientes procedimientos para crear un clúster nativo de la VPC y verificar los rangos de IP configurados del pod y el servicio.

Crea un clúster en una subred existente

Las siguientes instrucciones demuestran cómo crear un clúster de GKE nativo de la VPC en una subred existente con el método de asignación del rango secundario que elijas.

Console

Los siguientes pasos muestran cómo crear un clúster con Cloud Console.

  1. Ve al menú de Google Kubernetes Engine en Cloud Console.

    Ir al menú Google Kubernetes Engine

  2. Haz clic en Crear clúster.

  3. Configura tu clúster como desees. Luego, haz clic en Disponibilidad, herramientas de redes, seguridad y características adicionales.

  4. En la sección Nativo de la VPC, asegúrate de que la opción Habilitar nativo de la VPC (con un alias de IP) esté seleccionada.

  5. Elige una VPC en el botón emergente Red.

  6. Selecciona una subred para el clúster con el botón emergente Subred del nodo.

  7. Marca Crear rangos secundarios automáticamente si deseas que GKE administre el método de asignación de rangos secundarios. Desmarca esta casilla si ya creaste rangos secundarios para la subred seleccionada y quieres que el método de asignación de rangos secundarios sea asignado por el usuario.

  8. Completa el campo Rango de direcciones de pods con el rango de pods (ejemplo: 10.0.0.0/14).

  9. Completa el campo Rango de direcciones del servicio con el rango del servicio (ejemplo: 10.4.0.0/19).

  10. Realiza otras selecciones de configuración para tu clúster y, luego, haz clic en Crear.

gcloud

  • Para usar un método de asignación de rango secundario administrado por GKE:

    gcloud container clusters create CLUSTER_NAME \
      --region=REGION \
      --enable-ip-alias \
      --subnetwork=SUBNET_NAME \
      --cluster-ipv4-cidr=POD_IP_RANGE \
      --services-ipv4-cidr=SERVICES_IP_RANGE
    
  • Para usar un método de asignación de rango secundario administrado por el usuario:

    gcloud container clusters create CLUSTER_NAME \
      --region=REGION \
      --enable-ip-alias \
      --subnetwork=SUBNET_NAME \
      --cluster-secondary-range-name=SECONDARY_RANGE_PODS \
      --services-secondary-range-name=SECONDARY_RANGE_SERVICES
    

Reemplaza los marcadores por valores válidos:

  • CLUSTER_NAME es el nombre del clúster de GKE.
  • REGION es la región en la que se crea el clúster. Para crear un clúster zonal, reemplaza esta marca por --zone=ZONE, donde ZONE es una zona de Google Cloud.
  • SUBNET_NAME es el nombre de una subred existente. El rango de IP principal de la subred se usa para los nodos. La subred debe existir en la misma región que usa el clúster. Si se omite, GKE intenta usar una subred en la red de VPC default en la región del clúster.
  • Si el método de asignación del rango secundario es administrado por GKE:
    • POD_IP_RANGE es un rango de direcciones IP en notación CIDR (por ejemplo, 10.0.0.0/14) o el tamaño de la máscara de subred de un bloque CIDR (por ejemplo, /14). Este valor se usa para crear el rango de direcciones IP secundario de la subred para los pods.
    • SERVICES_IP_RANGE es un rango de direcciones IP en notación CIDR (por ejemplo, 10.4.0.0/19) o el tamaño de la máscara de subred de un bloque CIDR (por ejemplo, /19). Este valor se usa a fin de crear el rango de direcciones IP secundario de la subred para los servicios.
  • Si el método de asignación del rango secundario es administrado por el usuario:
    • SECONDARY_RANGE_PODS es el nombre de un rango de direcciones IP secundario existente en la SUBNET_NAME especificada. GKE usa todo el rango de IP secundario de la subred para los pods del clúster.
    • SECONDARY_RANGE_SERVICES es el nombre de un rango de direcciones IP secundario existente en la SUBNET_NAME especificada. GKE usa todo el rango de IP secundario de la subred para los servicios del clúster.

API

Cuando creas un clúster nativo de la VPC, defines un objeto IPAllocationPolicy. Puedes hacer referencia a rangos de IP secundarios existentes de la subred o especificar bloques CIDR. Haz referencia a rangos de IP secundarios existentes de la subred para crear un clúster cuyo método de asignación del rango secundario sea administrado por el usuario, y proporciona bloques CIDR si deseas que el método de asignación del rango sea administrado por GKE.

{
  "name": [CLUSTER_NAME],
  "description": [DESCRIPTION],
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "clusterIpv4CidrBlock"      : string,
    "servicesIpv4CidrBlock"     : string,
    "clusterSecondaryRangeName" : string,
    "servicesSecondaryRangeName": string,

  },
  ...
}

Donde:

  • "clusterIpv4CidrBlock" es el tamaño o la ubicación del rango de CIDR para pods. Determina el tamaño del rango secundario para pods, que puede ser IP/tamaño en la notación CIDR (como 10.0.0.0/14) o /tamaño (como /14). Se elige un espacio vacío con el tamaño dado del espacio disponible en tu VPC. Si se deja en blanco, se encuentra un rango válido y se crea con un tamaño predeterminado.
  • "servicesIpv4CidrBlock" es el tamaño/ubicación del rango de CIDR para los servicios. Consulta la descripción de "clusterIpv4CidrBlock".
  • "clusterSecondaryRangeName" es el nombre del rango secundario para los pods. El rango secundario debe existir previamente y pertenecer a la subred asociada con el clúster (como la subred especificada con la marca --subnetwork).
  • "serviceSecondaryRangeName" es el nombre del rango secundario para los servicios. El rango secundario debe existir previamente y pertenecer a la subred asociada con el clúster (como la subred especificada con la marca --subnetwork).

Crea un clúster y una subred simultáneamente

Las siguientes instrucciones demuestran cómo crear un clúster y una subred de GKE nativos de la VPC al mismo tiempo. El método de asignación del rango secundario es administrado por GKE cuando realizas estos dos pasos con un comando.

Console

No puedes crear un clúster y una subred de forma simultánea con Cloud Console. En su lugar, primero debes crear una subred y, luego, crear el clúster en una subred existente.

gcloud

Para crear un clúster nativo de la VPC y una subred de forma simultánea, usa el siguiente comando:

gcloud container clusters create CLUSTER_NAME \
    --region=REGION \
    --enable-ip-alias \
    --create-subnetwork name=SUBNET_NAME,range=NODE_IP_RANGE \
    --cluster-ipv4-cidr=POD_IP_RANGE \
    --services-ipv4-cidr=SERVICES_IP_RANGE

--create-subnetwork name=my-subnet,range=/21

  • CLUSTER_NAME es el nombre del clúster de GKE.
  • REGION es la región en la que se crea el clúster. Para crear un clúster zonal, reemplaza esta marca por --zone=ZONE, donde ZONE es una zona de GKE.
  • SUBNET_NAME es el nombre de la subred que se creará. La región de la subred es la misma región que la del clúster (o la región que contiene el clúster zonal). Usa una string vacía (name="") si quieres que GKE genere un nombre automáticamente.
  • NODE_IP_RANGE es un rango de direcciones IP en notación CIDR (por ejemplo, 10.5.0.0/20) o el tamaño de la máscara de subred de un bloque CIDR (por ejemplo, /20). Este valor se usa a fin de crear el rango de direcciones IP principal de la subred para los nodos. Si se omite, GKE selecciona un rango de IP disponible en la VPC con un tamaño de /20.
  • POD_IP_RANGE es un rango de direcciones IP en notación CIDR (por ejemplo, 10.0.0.0/14) o el tamaño de la máscara de subred de un bloque CIDR (por ejemplo, /14). Este valor se usa a fin de crear el rango de direcciones IP secundario de la subred para los pods. Si se omite, GKE usa /14, que es el tamaño predeterminado del rango de IP del pod.
  • SERVICES_IP_RANGE es un rango de direcciones IP en notación CIDR (por ejemplo, 10.4.0.0/19) o el tamaño de la máscara de subred de un bloque CIDR (por ejemplo, /19). Este valor se usa a fin de crear el rango de direcciones IP secundario de la subred para los servicios. Si se omite, GKE usa /20, el tamaño predeterminado del rango de IP de los servicios.

API

Para crear un clúster nativo de la VPC, define un objeto IPAllocationPolicy en tu recurso de clúster:

{
  "name": [CLUSTER_NAME],
  "description": [DESCRIPTION],
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "createSubnetwork": true,
    "subnetworkName": [SUBNET_NAME]
  },
  ...
}

createSubnetwork crea y aprovisiona automáticamente una subred para el clúster. subnetworkName es opcional; si se deja vacío, se elige un nombre de la subred de forma automática.

Verifica los rangos del pod y el servicio

Después de crear un clúster nativo de la VPC, puedes verificar sus rangos del pod y el servicio.

gcloud

Para verificar el clúster, ejecuta el siguiente comando:

gcloud container clusters describe [CLUSTER_NAME]

En el resultado del comando, mira debajo del campo ipAllocationPolicy:

  • clusterIpv4Cidr es el rango secundario para los pods
  • servicesIpv4Cidr es el rango secundario para los servicios

Console

Para verificar el clúster, realiza los siguientes pasos:

  1. Dirígete al menú de Google Kubernetes Engine en Cloud Console.

    Ir al menú Google Kubernetes Engine

  2. Selecciona el clúster que desees.

Los rangos secundarios se muestran en la sección Clúster en la pestaña Detalles:

  • Rango de direcciones de contenedor es el rango secundario para pods
  • Rango de direcciones de servicio es el rango secundario para servicios

Soluciona problemas

Esta sección proporciona orientación para resolver problemas relacionados con los clústeres nativos de la VPC.

El recurso 'projects/[PROJECT_NAME]/regions/XXX/subnetworks/default' no está listo

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 no válido para el campo 'resource.secondaryIpRanges [1].ipCidrRange': 'XXX'. IPCidrRange no válido: XXX entra en conflicto con el valor 'default' de la subred existente en la región 'XXX'.

Causas posibles

Al mismo tiempo, se crea otro clúster nativo de la VPC que intenta asignar los mismos rangos.

Se agrega el mismo rango secundario a la subred.

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 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).

No se pueden agregar nodos nuevos a un clúster existente.

Causas posibles

El espacio no asignado en el rango de IP del pod no es lo suficientemente grande para los nodos solicitados en el clúster. Por ejemplo, si el rango de IP de un pod del clúster tiene una máscara de red con un tamaño de /23 (512 direcciones) y el máximo de pods por nodo es 110, no puedes crear más de dos nodos. (Cada nodo tiene asignado un rango de IP de alias con una máscara de red con un tamaño de /24).

Soluciones

Crea un clúster de reemplazo después de revisar y planificar rangos de IP principales y secundarios del tamaño adecuado. Consulta Rangos de IP para clústeres nativos de la VPC y Planificación del rango de IP.

Si no puedes reemplazar el clúster, podrías solucionar el problema si puedes crear un nuevo grupo de nodos con una cantidad máxima menor de pods por nodo. Si es posible, migra las cargas de trabajo a ese grupo de nodos y, luego, borra el grupo de nodos anterior. Reducir la cantidad máxima de pods por nodo brinda compatibilidad con más nodos en un rango de IP secundario fijo para pods. Consulta Rango de direcciones IP secundario de la subred para pods y Rangos de límite de nodo si deseas obtener más detalles sobre los cálculos pertinentes.

Próximos pasos