Crea un clúster nativo de la VPC

Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

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

Si quieres obtener más información sobre los beneficios y requisitos de los clústeres nativos de la VPC, consulta la descripción general de los clústeres nativos de la VPC.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
  • Habilitar la API de Google Kubernetes Engine
  • Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa la CLI de gcloud.

Procedimientos

Usa los siguientes procedimientos para crear un clúster nativo de la VPC y verificar los rangos de direcciones IP de los Pods y los servicios configurados.

Crea un clúster en una subred existente

En las siguientes instrucciones, se muestra cómo crear un clúster de GKE nativo de VPC en una subred existente con el método de asignación del rango secundario que elijas.

gcloud

  • Para usar un método de asignación del rango secundario administrado por GKE, ejecuta el siguiente comando:

    gcloud container clusters create CLUSTER_NAME \
        --region=COMPUTE_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 del rango secundario administrado por el usuario, ejecuta el siguiente comando:

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

Reemplaza lo siguiente:

  • CLUSTER_NAME es el nombre del clúster de GKE.
  • COMPUTE_REGION: es la región de procesamiento para el clúster. Para crear un clúster zonal, reemplaza esta marca por --zone=COMPUTE_ZONE, en la que COMPUTE_ZONE es una zona de procesamiento.
  • SUBNET_NAME: Es el nombre de una subred existente. El rango de direcciones 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: Un rango de direcciones IP en notación de CIDR, como 10.0.0.0/14, o el tamaño de la máscara de subred de un bloque CIDR, como /14. Esto se usa con el fin de crear el rango de direcciones IP secundario de la subred para los pods. Si omites la opción --cluster-ipv4-cidr, GKE elige un rango /14 (218 direcciones) de forma automática. Este rango se selecciona de forma aleatoria a partir de 10.0.0.0/8 (un rango de 224 direcciones) y no incluirá los rangos de direcciones IP asignados a las VM, rutas existentes o rangos asignados a otros clústeres. El rango elegido de forma automática podría entrar en conflicto con direcciones IP reservadas, rutas dinámicas o rutas dentro de VPC que intercambian el tráfico con este clúster. Si usas alguna de estas opciones, debes especificar --cluster-ipv4-cidr para evitar conflictos.
    • SERVICES_IP_RANGE: un rango de direcciones IP en una notación de CIDR (por ejemplo, 10.4.0.0/19) o el tamaño de la máscara de subred de un bloque de CIDR (por ejemplo, /19). Se usa con el fin de crear el rango de direcciones IP secundarias de la subred para los servicios.
  • Si el método de asignación del rango secundario es administrado por el usuario:
    • SECONDARY_RANGE_PODS: el nombre de un rango de direcciones IP secundario existente en el SUBNET_NAME especificado. GKE usa todo el rango de direcciones IP secundario de la subred para los Pods del clúster.
    • SECONDARY_RANGE_SERVICES: el nombre de un rango de direcciones IP secundario existente en el SUBNET_NAME especificado. GKE usa todo el rango de direcciones IP secundario de la subred para los servicios del clúster.

Console

  1. Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.

    Ir a Google Kubernetes Engine

  2. Haz clic en Crear.

  3. En el panel de navegación, en Clúster, haz clic en Redes.

  4. En la lista desplegable Red, selecciona una VPC.

  5. En la lista desplegable Subred del nodo, selecciona una subred para el clúster.

  6. Asegúrate de que la casilla de verificación Habilitar enrutamiento de tráfico nativo de la VPC (con alias de IP) esté seleccionada.

  7. Selecciona la casilla de verificación Crear rangos secundarios automáticamente si deseas que GKE administre el método de asignación del rango secundario. Desmarca esta casilla de verificación si ya creaste rangos secundarios para la subred elegida y deseas que el método de asignación del rango secundario esté administrado por el usuario.

  8. En el campo Rango de direcciones de pods, ingresa un rango de pods, como 10.0.0.0/14.

  9. En el campo Rango de direcciones del servicio, ingresa un rango del servicio, como 10.4.0.0/19.

  10. Configura tu clúster.

  11. Haga clic en Crear.

API

Cuando creas un clúster nativo de la VPC, defines un objeto IPAllocationPolicy. Puedes hacer referencia a rangos de direcciones IP secundarios existentes de la subred o especificar bloques CIDR. Haz referencia a rangos de direcciones 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,

  },
  ...
}

En esta salida, se incluyen los siguientes valores:

  • "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": 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).

Terraform

Puedes crear un clúster nativo de la VPC a través de Terraform mediante el uso de un módulo de Terraform.

Por ejemplo, puedes agregar el siguiente bloque a la configuración de Terraform:

module "gke" {
  source  = "terraform-google-modules/kubernetes-engine/google"
  version = "~> 12.0"

  project_id        = "PROJECT_ID"
  name              = "CLUSTER_NAME"
  region            = "COMPUTE_REGION"
  network           = "NETWORK_NAME"
  subnetwork        = "SUBNET_NAME"
  ip_range_pods     = "SECONDARY_RANGE_PODS"
  ip_range_services = "SECONDARY_RANGE_SERVICES"
}

Reemplaza lo siguiente:

  • PROJECT_ID: el ID de tu proyecto
  • CLUSTER_NAME: el nombre del clúster de GKE.
  • COMPUTE_REGION: es la región de procesamiento para el clúster.
  • NETWORK_NAME: el nombre de una red existente.
  • SUBNET_NAME: Es el nombre de una subred existente. El rango de direcciones IP principal de la subred se usa para los nodos. La subred debe existir en la misma región que usa el clúster.
  • SECONDARY_RANGE_PODS es el nombre de un rango de direcciones IP secundario existente en el SUBNET_NAME especificado. GKE usa todo el rango de direcciones IP secundario de la subred para los Pods del clúster.
  • SECONDARY_RANGE_SERVICES: el nombre de un rango de direcciones IP secundario existente en el SUBNET_NAME especificado. GKE usa todo el rango de direcciones IP secundario de la subred para los servicios del clúster.

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. GKE administra el método de asignación del rango secundario cuando realizas estos dos pasos con un comando.

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=COMPUTE_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

Reemplaza lo siguiente:

  • CLUSTER_NAME: el nombre del clúster de GKE.
  • COMPUTE_REGION: es la región de procesamiento para el clúster. Para crear un clúster zonal, reemplaza esta marca por --zone=COMPUTE_ZONE, en la que COMPUTE_ZONE es una zona de GKE.
  • SUBNET_NAME: 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: Un rango de direcciones IP en notación de CIDR, como 10.5.0.0/20, o el tamaño de la máscara de subred de un bloque CIDR, como /20 Esto se usa con el 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: Un rango de direcciones IP en notación de CIDR, como 10.0.0.0/14, o el tamaño de la máscara de subred de un bloque CIDR, como /14. Esto se usa con el fin de crear el rango de direcciones IP secundario de la subred para los pods. Si se omite, GKE usa un rango /14 elegido de forma aleatoria que contenga 218 direcciones. Este rango se selecciona de forma aleatoria a partir de 10.0.0.0/8 (un rango de 224 direcciones) y no incluirá los rangos de direcciones IP asignados a las VM, rutas existentes o rangos asignados a otros clústeres. El rango elegido de forma automática podría entrar en conflicto con direcciones IP reservadas, rutas dinámicas o rutas dentro de VPC que intercambian el tráfico con este clúster. Si usas alguna de estas opciones, debes especificar --cluster-ipv4-cidr para evitar conflictos.
  • SERVICES_IP_RANGE: Un rango de direcciones IP en notación de CIDR, como 10.4.0.0/19, o el tamaño de la máscara de subred de un bloque CIDR, como /19. Esto se usa con el fin de crear el rango de direcciones IP secundario de la subred para servicios. Si se omite, GKE usa /20, el tamaño predeterminado del rango de direcciones IP de los servicios.

Console

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

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
  },
  ...
}

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

Usa rangos de direcciones IP privadas que no sean RFC 1918

Los clústeres de GKE pueden usar rangos de direcciones IP privadas fuera de los rangos RFC 1918 para nodos, Pods y objetos Service. Consulta los rangos válidos en la documentación de red de la VPC a fin de obtener una lista de los rangos privados que no son RFC 1918 y que se pueden usar como direcciones IP internas para los rangos de subred.

Los rangos de direcciones IP privadas que no son RFC 1918 son compatibles con clústeres privados y no privados.

Los rangos privados que no son RFC 1918 son rangos de subred; puedes usarlos de forma exclusiva o junto con rangos de subred RFC 1918. Los nodos, los Pods y los objetos Service continúan usando rangos de subredes como se describe en Rangos de IP para clústeres nativos de la VPC. Si usas rangos que no son RFC 1918, ten en cuenta lo siguiente:

  • Los rangos de subred, incluso los que usan rangos que no son RFC 1918, deben asignarse de forma manual o mediante GKE antes de que se creen los nodos del clúster. No puedes cambiar a rangos de subred que no sean RFC 1918 o dejar de usarlos a menos que reemplaces el clúster.

  • Los balanceadores de cargas de TCP/UDP internos solo usan direcciones IP del rango de direcciones IP principal de la subred. Para crear un balanceador de cargas de TCP/UDP interno con una dirección que no sea RFC 1918, el rango de direcciones IP principal de la subred no debe ser RFC 1918.

Los destinos fuera del clúster pueden tener dificultades para recibir el tráfico de rangos privados que no sean RFC 1918. Por ejemplo, los rangos privados RFC 1112 (clase E) suelen usarse como direcciones de multidifusión. Si un destino fuera del clúster no puede procesar paquetes cuyas fuentes sean direcciones IP privadas fuera del rango RFC 1918, puedes realizar las siguientes acciones:

  • Usar un rango RFC 1918 para el rango de direcciones IP principal de la subred. De esta manera, los nodos del clúster usan direcciones RFC 1918.

  • Asegurarte de que el clúster ejecute el agente de enmascaramiento de IP y que los destinos no estén en la lista nonMasqueradeCIDRs. De esta manera, cambiaron las fuentes (SNAT) de los paquetes que se envían desde los Pods a direcciones de nodo, que son RFC 1918.

Habilita rangos de direcciones IP públicas que se usan de forma privada

Los clústeres de GKE pueden usar de forma privada ciertos rangos de direcciones IP públicas, como rangos de direcciones IP de subred internos. Puedes usar cualquier dirección IP pública de forma privada, excepto ciertos rangos restringidos, como se describe en la documentación de la red de VPC.

Tu clúster debe ser un clúster nativo de la VPC para usar rangos de direcciones IP públicas utilizados de forma privada. No se admiten clústeres basados en rutas.

Los rangos públicos de uso privado son rangos de subred: puedes usarlos de forma exclusiva o junto con otros rangos de subred que usen direcciones privadas. Los nodos, los Pods y los objetos Service continúan usando los rangos de subredes como se describe en Rangos de IP para clústeres nativos de la VPC. Ten en cuenta lo siguiente cuando reutilices direcciones IP públicas de forma privada:

  • Cuando usas un rango de direcciones IP públicas como un rango de subred, tu clúster ya no puede comunicarse con los sistemas de Internet que usan ese rango público; el rango se convierte en un rango de direcciones IP internas en la red de VPC del clúster.

  • Los rangos de subred, incluso los que utilizan los rangos de direcciones IP públicas de forma privada, deben asignarse de forma manual o mediante GKE antes de que se creen los nodos del clúster. No puedes cambiar a direcciones IP públicas utilizados de forma privada o dejar de usarlas a menos que reemplaces el clúster.

De forma predeterminada, GKE implementa SNAT en los nodos para los destinos de IP pública. Cuando se usan rangos de direcciones IP públicas utilizados de forma privada para el CIDR del Pod, esto generaría las reglas de SNAT que se aplican al tráfico de Pod a Pod. Para evitar que esto suceda, tienes 2 opciones:

Clúster de ejemplo con rangos públicos utilizados de forma privada

En el siguiente ejemplo, se usa la CLI de gcloud para crear un clúster que usa rangos de direcciones IP públicas reutilizados de forma privada. Debes usar la siguiente marca:

  • --enable-ip-alias: Esto crea un clúster nativo de la VPC, que es necesario para utilizar rangos de direcciones IP públicas de forma privada.

Con el siguiente comando, se crea un clúster privado nativo de la VPC con las siguientes propiedades:

  • Nodos que usan el rango de direcciones IP principal 10.0.0.0/24 de la subred
  • Pods que utilizan de forma privada el rango de direcciones IP públicas 5.0.0.0/16 como el rango de direcciones IP secundario de la subred para los Pods
  • Servicios que utilizan de forma privada el rango de direcciones IP públicas 5.1.0.0/16 como el rango de direcciones IP secundario de la subred para servicios
  • El rango de direcciones IP internas para el plano de control es 172.16.0.16/28.
gcloud container clusters create CLUSTER_NAME \
  --enable-ip-alias \
  --enable-private-nodes \
  --disable-default-snat \
  --zone=COMPUTE_ZONE \
  --create-subnetwork name=cluster-subnet,range=10.0.0.0/24 \
  --cluster-ipv4-cidr=5.0.0.0/16 \
  --services-ipv4-cidr=5.1.0.0/16 \
  --master-ipv4-cidr=172.16.0.16/28

Usa una red de pila doble para un clúster nativo de la VPC

En la versión más reciente de GKE 1.24, puedes crear un clúster nativo de la VPC con herramientas de redes de pila doble en una subred de pila doble nueva o existente. En esta sección, se muestra cómo completar las siguientes tareas:

  • Crea una subred de pila doble.
  • Actualiza una subred de pila doble existente.
  • Crear un clúster nativo de la VPC con GKE Dataplane V2 y el tipo de pila como IPv4-IPv6.

Para obtener más información sobre los beneficios y los requisitos de los clústeres de GKE con una descripción general de las redes de pila doble, consulta la documentación de los clústeres nativos de la VPC.

Crea una subred de pila doble.

Para crear una subred de pila doble, ejecuta el siguiente comando:

gcloud compute networks subnets create SUBNET_NAME \
    --stack-type=ipv4-ipv6 \
    --ipv6-access-type=ACCESS_TYPE \
    --network=NETWORK_NAME \
    --range=PRIMARY_RANGE \
    --region=COMPUTE_REGION

Reemplaza lo siguiente:

  • SUBNET_NAME: Es el nombre de la subred que eliges.
  • ACCESS_TYPE: Es la enrutabilidad a la Internet pública. Usa INTERNAL para clústeres privados y EXTERNAL para clústeres públicos. Si no se especifica --ipv6-access-type, el tipo de acceso predeterminado es EXTERNAL.
  • NETWORK_NAME: El nombre de una red de VPC que contendrá la subred nueva. Esta red de VPC debe ser una red de modo personalizado Para obtener más información, consulta cómo cambiar una red de VPC del modo automático al modo personalizado.
  • PRIMARY_RANGE: El rango de direcciones IP IPv4 principal de la subred nueva, en notación CIDR. Para obtener más información, consulta Rangos de subredes.
  • COMPUTE_REGION: Es la región de procesamiento para el clúster.

Actualiza una subred existente a una subred de pila doble

Para actualizar una subred existente a una subred de doble pila, ejecuta el siguiente comando. La actualización de una subred no afecta a ningún clúster de IPv4 existente en la subred.

gcloud compute networks subnets update SUBNET_NAME \
    --stack-type=ipv4-ipv6 \
    --ipv6-access-type=ACCESS_TYPE \
    --region=COMPUTE_REGION

Reemplaza lo siguiente:

  • SUBNET_NAME: El nombre de la subred.
  • ACCESS_TYPE: Es la enrutabilidad a la Internet pública. Usa INTERNAL para clústeres privados y EXTERNAL para clústeres públicos. Si no se especifica --ipv6-access-type, el tipo de acceso predeterminado es EXTERNAL.
  • COMPUTE_REGION: Es la región de procesamiento para el clúster.

Crea un clúster nativo de la VPC con herramientas de redes de pila doble

Para crear un clúster nativo de la VPC con una subred de pila doble existente, ejecuta el siguiente comando:

gcloud beta container clusters create CLUSTER_NAME \
    --enable-ip-alias \
    --enable-dataplane-v2 \
    --stack-type=ipv4-ipv6 \
    --cluster-version=VERSION \
    --network=NETWORK_NAME \
    --subnetwork=SUBNET_NAME \
    --region=COMPUTE_REGION

Reemplaza lo siguiente:

  • CLUSTER_NAME es el nombre del clúster nuevo.
  • VERSION: es la versión más reciente de GKE 1.24. Revisa las notas de la versión de GKE para conocer la versión más reciente actualizada. También puedes usar la opción --release-channel para seleccionar un canal de versiones.
  • NETWORK_NAME: El nombre de una red de VPC que contendrá la subred nueva. Esta red de VPC debe ser una red de modo personalizado Para obtener más información, consulta cómo cambiar una red de VPC del modo automático al modo personalizado.
  • SUBNET_NAME: El nombre de la subred.
  • COMPUTE_REGION: Es la región de procesamiento para el clúster.

Crea un clúster de pila doble y una subred simultáneamente

Puedes crear una subred y un clúster de pila doble de forma simultánea. GKE crea una subred IPv6 y le asigna un rango principal IPv6 externo a la subred.

gcloud beta container clusters create CLUSTER_NAME \
    --enable-ip-alias \
    --stack-type=ipv4-ipv6 \
    --ipv6-access-type=ACCESS_TYPE \
    --cluster-version=VERSION \
    --network=NETWORK_NAME \
    --create-subnetwork name=SUBNET_NAME,range=PRIMARY_RANGE \
    --region=COMPUTE_REGION

Reemplaza lo siguiente:

  • CLUSTER_NAME: Es el nombre del clúster nuevo que eliges.
  • ACCESS_TYPE: Es la enrutabilidad a la Internet pública. Usa INTERNAL para clústeres privados y EXTERNAL para clústeres públicos. Si no se especifica --ipv6-access-type, el tipo de acceso predeterminado es EXTERNAL.
  • VERSION: es la versión más reciente de GKE 1.24. Revisa las notas de la versión de GKE para conocer la versión más reciente actualizada. También puedes usar la opción --release-channel para seleccionar un canal de versiones.
  • NETWORK_NAME: El nombre de una red de VPC que contendrá la subred nueva. Esta red de VPC debe ser una red de modo personalizado Para obtener más información, consulta cómo cambiar una red de VPC del modo automático al modo personalizado.
  • SUBNET_NAME: Es el nombre de la subred nueva que eliges.
  • PRIMARY_RANGE: El rango de direcciones IPv4 principal de la subred nueva, en notación CIDR. Para obtener más información, consulta Rangos de subredes.
  • COMPUTE_REGION: Es la región de procesamiento para el clúster.

Verifica los rangos de direcciones IP del Pod y del Service

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 beta container clusters describe CLUSTER_NAME

El resultado tiene un bloque ipAllocationPolicy que es similar al siguiente:

 ipAllocationPolicy:
   ...
   createSubnetwork: true
   ipv6AccessType: INTERNAL 
   podCidrOverprovisionConfig: {}
   servicesIpv4Cidr: 10.5.160.0/20
   servicesIpv4CidrBlock: 10.5.160.0/20
   servicesIpv6CidrBlock: 2600:2d00:0:4:188f:ce54:5f00:0/112
   servicesSecondaryRangeName: gke-ipv6-2-services-ebc6a146
   stackType: ipv4-ipv6
   subnetIpv6CidrBlock: 2600:1900:4121:f8ae::/64
   useIpAliases: true
 ```

The following fields include network information:
  • Información de red IPv4:

    • clusterIpv4Cidr es el rango secundario para los pods
    • servicesIpv4Cidr es el rango secundario para los servicios
  • Información de red IPv6 (si un clúster tiene herramientas de redes de pila doble):

    • ipv6AccessType: La enrutabilidad a la Internet pública. Use INTERNAL para clústeres privados y EXTERNAL para clústeres públicos.
    • servicesIpv6CidrBlock: El rango de direcciones IPv6 principal
    • stackType: La definición de red de pila doble
    • subnetIpv6CidrBlock: El rango de direcciones IPv6 secundario para la subred nueva.

Consola

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

  1. Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.

    Ir a Google Kubernetes Engine

  2. En la lista de clústeres, haz clic en el nombre del clúster que quieres inspeccionar.

Los rangos secundarios se muestran en la sección Herramientas de redes:

  • 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. También puedes ver estadísticas del uso de las 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 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

El espacio no asignado en el rango de direcciones IP del Pod no es lo suficientemente grande para los nodos solicitados en el clúster. Por ejemplo, si el rango de direcciones IP del Pod de un 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 de 110, no puedes crear más de dos nodos Se asigna a cada nodo un rango de direcciones IP de alias con una máscara de red cuyo tamaño es /24.

Soluciones

Puedes agregar rangos de IP de Pod al clúster mediante CIDR de varios pods discontinuos.

Crea un clúster de reemplazo después de revisar y planificar rangos de direcciones 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.

Crea 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 te permite admitir más nodos en un rango de direcciones IP secundario fijo para Pods. Consulta Rango de direcciones IP secundario de la subred para Pods y Rangos de límite de nodos si deseas obtener más detalles sobre los cálculos pertinentes.

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. Revisa la configuración del 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 anulará 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.

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 un objeto Service (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.
  • Si usas todas las direcciones IP del Pod en una subred, no puedes reemplazar el rango de direcciones IP secundario de la subred sin poner el clúster en un estado inestable. Sin embargo, puedes crear rangos de direcciones IP del Pod adicionales mediante CIDR de varios Pods discontinuos.

¿Qué sigue?