Crea un clúster nativo de la VPC

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 gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.
Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar las propiedades compute/region y compute/zone. Cuando configuras las ubicaciones predeterminadas, puedes evitar errores en la CLI de gcloud como el siguiente: One of [--zone, --region] must be supplied: Please specify location.

Limitaciones

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. No se admiten las redes heredadas.

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 de red de transferencia 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.

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 \
    --location=COMPUTE_LOCATION \
    --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 \
    --location=COMPUTE_LOCATION \
    --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_LOCATION: la ubicación de Compute Engine para el clúster.
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 (2¹⁸ direcciones) de forma automática. Este rango se selecciona de forma aleatoria a partir de 10.0.0.0/8 (un rango de 2²⁴ direcciones) y no incluirá los rangos de direcciones IP asignados a las VMs, 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 es el nombre de un rango de direcciones IP secundario existente en el especificado.

Console

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

Ir a Google Kubernetes Engine
Haz clic en Crear y, luego, en la sección Standard o Autopilot, haz clic en Configurar.
En el panel de navegación, en Clúster, haz clic en Herramientas de redes.
En la lista desplegable Red, selecciona una VPC.
En la lista desplegable Subred del nodo, selecciona una subred para el clúster.
Asegúrate de que la casilla de verificación Habilitar enrutamiento de tráfico nativo de la VPC (con alias de IP) esté seleccionada.
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.
En el campo Rango de direcciones de pods, ingresa un rango de pods, como 10.0.0.0/14.
En el campo Rango de direcciones del servicio, ingresa un rango del servicio, como 10.4.0.0/19.
Configura tu clúster.
Haz clic en Crear.

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_LOCATION"
  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_LOCATION: la ubicación de Compute Engine para el clúster. Para Terraform, la región de Compute Engine.
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 especificado.
SECONDARY_RANGE_SERVICES es el nombre de un rango de direcciones IP secundario existente en el especificado.

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,

  },
  ...
}

Este comando incluye los siguientes valores:

"clusterIpv4CidrBlock": Es el rango de CIDR para Pods. Esto determina el tamaño del rango secundario para pods, que puede estar en notación CIDR, como 10.0.0.0/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 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.
"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.

Crea un clúster y selecciona el rango de direcciones IP del plano de control

De forma predeterminada, los clústeres con Private Service Connect usan el rango de subred principal para aprovisionar la dirección IP interna asignada al extremo del plano de control. Puedes anular esta configuración predeterminada si seleccionas un rango de subred diferente solo durante la creación del clúster. En las siguientes secciones, se muestra cómo crear un clúster con Private Service Connect y anular el rango de subred.

gcloud

Crea un clúster con Private Service Connect definido como público

gcloud container clusters create CLUSTER_NAME \
    --private-endpoint-subnetwork=SUBNET_NAME \
    --location=COMPUTE_LOCATION

Agrega la marca --enable-private-nodes para crear el clúster de Private Service Connect como privado.

Reemplaza lo siguiente:

CLUSTER_NAME: el nombre del clúster de GKE.
SUBNET_NAME: Es el nombre de una subred existente.
COMPUTE_LOCATION: la ubicación de Compute Engine para el clúster.

GKE crea un clúster con Private Service Connect.

Crea un clúster definido como privado:

En la versión 1.29 de GKE y versiones posteriores, puedes crear un clúster con Private Service Connect:

gcloud container clusters create CLUSTER_NAME --enable-ip-alias \
    --enable-private-nodes  \
    --private-endpoint-subnetwork=SUBNET_NAME \
    --region=COMPUTE_REGION

Reemplaza lo siguiente:

CLUSTER_NAME es el nombre del clúster de GKE.
SUBNET_NAME: Es el nombre de una subred existente. Si no proporcionas un valor para la marca private-endpoint-subnetwork, pero usas master-ipv4-cidr, GKE crea una nueva subred que usa los valores que definiste en master-ipv4-cidr. GKE usa la subred nueva para aprovisionar la dirección IP interna del plano de control.
COMPUTE_LOCATION: la ubicación de Compute Engine para el clúster.

Console

Crea un clúster definido como público:

Para asignar una subred al plano de control de un clúster nuevo, primero debes agregar una subred. Luego, completa los siguientes pasos:

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

Ir a Google Kubernetes Engine
Haz clic en Crear.
En la sección Standard o Autopilot, haz clic en Configurar.
En Nombre, ingresa el nombre de tu clúster.
Para los clústeres estándar, en el panel de navegación, en Clúster, haz clic en Herramientas de redes.
En la sección Acceso a la red IPv4, haz lo siguiente:
1. Para crear un clúster de GKE como público, selecciona Clúster público.
2. Para crear un clúster de GKE como privado, selecciona Clúster privado.
En ambos casos, puedes cambiar el modo de aislamiento del clúster cuando edites la configuración del clúster.
En la sección Opciones avanzadas de redes, selecciona la casilla de verificación Anular la subred predeterminada del extremo privado del plano de control.
En la lista Subred del extremo privado, selecciona la subred que creaste.
Haz clic en Listo. Agrega redes autorizadas adicionales según sea necesario.

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 \
    --location=COMPUTE_LOCATION \
    --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_LOCATION: la ubicación de Compute Engine para el clúster.
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 2¹⁸ direcciones. Este rango se selecciona de forma aleatoria a partir de 10.0.0.0/8 (un rango de 2²⁴ 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 que no sean RFC 1918

Los clústeres de GKE pueden usar rangos de direcciones IP fuera de los rangos RFC 1918 para nodos, Pods y objetos Service. Consulta los rangos válidos en la documentación de red de VPC para 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 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 red de transferencia internos solo usan direcciones IP del rango de direcciones IP principal de la subred. Para crear un balanceador de cargas de red de transferencia 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 lo siguiente:

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 externas 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. Si configuraste el CIDR del Pod para usar direcciones IP externas, las reglas de SNAT se aplican al tráfico de Pod a Pod. Para evitar que esto suceda, tienes 2 opciones:

Crea tu clúster con la marca --disable-default-snat. Para obtener más detalles sobre esta marca, consulta Enmascaramiento de IP en GKE.
Configura el configMap ip-masq-agent, que se incluye en la lista nonMasqueradeCIDRs, al menos el CIDR del pod, el CIDR de Service y la subred de los nodos.

Usa una red IPv4 o IPv6 de pila doble para crear un clúster de pila doble

Puedes crear un clúster con herramientas de redes de pila doble IPv4/IPv6 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 (disponible en los clústeres de Autopilot versión 1.25 o posterior y en los clústeres Standard versión 1.24 o posterior).
Actualiza una subred existente a una subred de pila doble (disponible en la versión 1.25 o posterior de los clústeres de Autopilot y en la versión 1.24 o posterior de los clústeres Standard).
Crea un clúster con herramientas de redes de pila doble (disponibles en los clústeres de Autopilot versión 1.25 o posterior y en los clústeres Standard versión 1.24 o posterior). Los clústeres de Autopilot de GKE se establecen de forma predeterminada en un clúster de pila doble cuando usas una subred de pila doble. Después de la creación del clúster, puedes actualizar el clúster de Autopilot para que sea solo IPv4.
Crea un clúster de pila doble y una subred de pila doble de forma simultánea (disponible en la versión 1.25 o posterior de los clústeres de Autopilot y en la versión 1.24 o posterior de los clústeres Standard).

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 la red que contendrá la subred nueva. Esta red debe cumplir con los siguientes requisitos:
- Debe ser una red de VPC en modo personalizado. Para obtener más información, consulta cómo cambiar una red de VPC del modo automático al modo personalizado.
- Si reemplazas ACCESS_TYPE por INTERNAL, la red debe usar direcciones IPv6 de unidifusión (ULA) únicas.
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 con herramientas de redes de pila doble

Para crear un clúster con una subred de pila doble existente, puedes usar gcloud CLI o la consola de Google Cloud:

gcloud

Para los clústeres Autopilot, ejecuta el siguiente comando:
```
  gcloud container clusters create-auto CLUSTER_NAME \
      --location=COMPUTE_LOCATION \
      --network=NETWORK_NAME \
      --subnetwork=SUBNET_NAME
```
Reemplaza lo siguiente:
- CLUSTER_NAME: Es el nombre del clúster nuevo de Autopilot.
- COMPUTE_LOCATION: la ubicación de Compute Engine para el clúster.
- NETWORK_NAME: El nombre de la red de VPC que contiene la subred Esta red de VPC debe ser una red de VPC 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 de pila doble. Para obtener más información, consulta cómo crear una subred de pila doble.
  
  Los clústeres de Autopilot de GKE se establecen de forma predeterminada en un clúster de pila doble cuando usas una subred de pila doble. Después de la creación del clúster, puedes actualizar el clúster de Autopilot para que sea solo IPv4.

Para los clústeres estándar, ejecuta el siguiente comando:
```
gcloud container clusters create CLUSTER_NAME \
    --enable-ip-alias \
    --enable-dataplane-v2 \
    --stack-type=ipv4-ipv6 \
    --network=NETWORK_NAME \
    --subnetwork=SUBNET_NAME \
    --location=COMPUTE_LOCATION
```
Reemplaza lo siguiente:
- CLUSTER_NAME el nombre del clúster nuevo.
- NETWORK_NAME: El nombre de la red de VPC que contiene la subred Esta red de VPC debe ser una red de VPC de modo personalizado que use direcciones IPv6 de unidifusión (ULA) únicas. 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_LOCATION: la ubicación de Compute Engine para el clúster.

Console

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

Ir a Google Kubernetes Engine
Haz clic en Crear.
En la sección Standard o Autopilot, haz clic en Configurar.
Configura tu clúster según sea necesario.
En el panel de navegación, en Clúster, haz clic en Herramientas de redes.
En la lista Red, selecciona el nombre de tu red.
En la lista Subred del nodo, selecciona el nombre de tu subred de pila doble.
Para los clústeres estándar, selecciona el botón de selección IPv4 e IPv6 (pila doble). Esta opción solo está disponible si seleccionaste una subred de pila doble.

Los clústeres de Autopilot se configuran de forma predeterminada para un clúster de pila doble cuando usas una subred de pila doble.
Haz clic en Crear.

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.

Para los clústeres Autopilot, ejecuta el siguiente comando:
```
gcloud container clusters create-auto CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --network=NETWORK_NAME \
    --create-subnetwork name=SUBNET_NAME
```
Reemplaza lo siguiente:
- CLUSTER_NAME: Es el nombre del clúster nuevo de Autopilot.
- COMPUTE_LOCATION: la ubicación de Compute Engine para el clúster.
- NETWORK_NAME: El nombre de la red de VPC que contiene la subred Esta red de VPC debe ser una red de VPC de modo personalizado que use direcciones IPv6 de unidifusión (ULA) únicas. 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. GKE puede crear la subred según las políticas de tu organización:
  - Si las políticas de tu organización permiten la pila doble, y la red es el modo personalizado, GKE crea una subred de pila doble y asigna un rango principal IPv6 externo a la subred .
  - Si las políticas de la organización no permiten la pila doble o si la red está en modo automático, GKE crea una subred de pila única (IPv4).

Para los clústeres estándar, ejecuta el siguiente comando:
```
gcloud container clusters create CLUSTER_NAME \
    --enable-ip-alias \
    --stack-type=ipv4-ipv6 \
    --ipv6-access-type=ACCESS_TYPE \
    --network=NETWORK_NAME \
    --create-subnetwork name=SUBNET_NAME,range=PRIMARY_RANGE \
    --location=COMPUTE_LOCATION
```
Reemplaza lo siguiente:
- CLUSTER_NAME: Es el nombre del clúster nuevo que eliges.
- ACCESS_TYPE: 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 la red que contendrá la subred nueva. Esta red debe cumplir con los siguientes requisitos:
  - Debe ser una red de VPC en modo personalizado. Para obtener más información, consulta cómo cambiar una red de VPC del modo automático al modo personalizado.
  - Si reemplazas ACCESS_TYPE por INTERNAL, la red debe usar direcciones IPv6 de unidifusión (ULA) únicas.
- 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_LOCATION: la ubicación de Compute Engine para el clúster.

Actualiza el tipo de pila en un clúster existente

Puedes cambiar el tipo de pila de un clúster existente. Antes de cambiar el tipo de pila en un clúster existente, ten en cuenta las siguientes limitaciones:

El cambio del tipo de pila es compatible con los clústeres de GKE nuevos que ejecutan la versión 1.25 o posterior. Los clústeres de GKE que se actualizaron de las versiones 1.24 a las 1.25 o 1.26 pueden obtener errores de validación cuando se habilita la red de pila doble. En caso de error, comunícate con el equipo de asistencia al cliente de Google Cloud.
Cambiar el tipo de pila es una operación perjudicial porque GKE reinicia los componentes en el plano de control y en los nodos.
GKE respeta los períodos de mantenimiento configurados cuando se vuelven a crear los nodos. Esto significa que el tipo de pila del clúster no funcionará en el clúster hasta que se produzca el siguiente período de mantenimiento. Si no quieres esperar, puedes actualizar de forma manual el grupo de nodos si configuras la marca --cluster-version en la misma versión de GKE que ya ejecuta el plano de control. Si usas esta solución alternativa, debes usar la CLI de gcloud. Si deseas obtener más información, consulta Advertencias para los períodos de mantenimiento.
El cambio del tipo de pila no cambia automáticamente la familia de IP de los objetos Service existentes. Se aplican las siguientes condiciones:
- Si cambias una sola pila por pila doble, los servicios existentes seguirán siendo una sola pila.
- Si cambias una pila doble a una sola, los servicios existentes con direcciones IPv6 entrarán en un estado de error. Borra el Service y crea uno con el ipFamilies correcto. Para obtener más información, consulta un ejemplo de configuración de un Deployment.

Para actualizar un clúster nativo de la VPC existente, puedes usar gcloud CLI o la consola de Google Cloud:

gcloud

Ejecuta el siguiente comando:

  gcloud container clusters update CLUSTER_NAME \
      --stack-type=STACK_TYPE \
      --location=COMPUTE_LOCATION

Reemplaza lo siguiente:

CLUSTER_NAME: Es el nombre del clúster que deseas actualizar.
STACK_TYPE: Es el tipo de pila. Reemplaza
- ipv4: para actualizar un clúster de pila doble a un clúster solo IPv4. GKE usa el rango de direcciones IPv4 principal de la subred del clúster.
- ipv4-ipv6: para actualizar un clúster de IPv4 existente a pila doble. Solo puedes cambiar un clúster a pila doble si la subred subyacente es compatible con pila doble. Para obtener más información, consulta Actualiza una subred existente a una subred de pila doble.
COMPUTE_LOCATION: la ubicación de Compute Engine para el clúster.

Console

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

Ir a Google Kubernetes Engine
Junto al clúster que deseas editar, haz clic en Acciones y, luego, en Editar.
En la sección Herramientas de redes, junto a Tipo de pila, haz clic en Editar.
En el cuadro de diálogo Editar tipo de pila, selecciona la casilla de verificación para el tipo de pila del clúster que necesitas.
Haz clic en Guardar cambios.

Crea un objeto Service de pila doble IPv4/IPv6

Puedes crear un objeto Service de pila doble IPv4/IPv6 de tipo ClusterIP o NodePort. Los clústeres de GKE nuevos que ejecutan la versión 1.29 o una posterior admiten los Services de pila doble de tipo LoadBalancer. Para obtener más información, consulta objeto Service LoadBalancer de pila doble IPv4/IPv6.

Para cada uno de estos tipos de servicios, puedes definir los campos ipFamilies y ipFamilyPolicy como IPv4, IPv6 o una pila doble. Para obtener más información, consulta Services de pila doble de IPv4/IPv6.

Verifica el tipo de pila, el pod y los rangos de direcciones IP del 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

El resultado tiene un bloque ipAllocationPolicy. El campo stackType describe el tipo de definición de red. Para cada tipo, puedes ver la siguiente información de red:

Información de red IPv4:
- clusterIpv4Cidr es el rango secundario para los pods.
- servicesIpv4Cidr es el rango secundario para Services.
Información de red IPv6 (si un clúster tiene herramientas de redes de pila doble):
- ipv6AccessType: La enrutabilidad a la Internet pública. INTERNAL para direcciones IPv6 privadas y EXTERNAL para direcciones IPv6 públicas.
- subnetIpv6CidrBlock: El rango de direcciones IPv6 secundario para la subred nueva.
- servicesIpv6CidrBlock: El rango de direcciones asignado para los Services IPv6 en el clúster de pila doble.

Console

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

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

Ir a Google Kubernetes Engine
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 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 de GKE: nombre, versión del plano de control, modo (estándar o Autopilot), 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.

Nota: GKE trunca las cadenas largas que se usan en el nombre de la subred y el nombre del rango de direcciones IPv4 secundario para Pods a 15 caracteres.

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:

Crea un nuevo grupo de nodos con una cantidad máxima menor de pods por nodo.
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.

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.

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:

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.

Crea un clúster nativo de la VPC

Antes de comenzar

Limitaciones

Crea un clúster en una subred existente

gcloud

Console

Terraform

API

Crea un clúster y selecciona el rango de direcciones IP del plano de control

gcloud

Crea un clúster con Private Service Connect definido como público

Crea un clúster definido como privado:

Console

Crea un clúster definido como público:

Crea un clúster y una subred simultáneamente

gcloud

Console

API

Usa rangos de direcciones IP que no sean RFC 1918

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

Usa una red IPv4 o IPv6 de pila doble para crear un clúster de pila doble

Crea una subred de pila doble.

Actualiza una subred existente a una subred de pila doble

Crea un clúster con herramientas de redes de pila doble

gcloud

Console

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

Actualiza el tipo de pila en un clúster existente

gcloud

Console

Crea un objeto Service de pila doble IPv4/IPv6

Verifica el tipo de pila, el pod y los rangos de direcciones IP del servicio

gcloud

Console

Soluciona problemas

El recurso de red predeterminado no está listo

Valor incorrecto para IPCidrRange

No hay espacio suficiente de dirección IP para Pods

Confirma si la SNAT predeterminada está inhabilitada

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

Depura Cloud NAT con sNAT predeterminada inhabilitada

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

¿Qué sigue?

Valor incorrecto para `IPCidrRange`

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