Crea y administra clústeres IPv6 de pila única

En este documento, se explica cómo crear, configurar y administrar clústeres IPv6 de pila única en Google Kubernetes Engine (GKE).

Puedes ejecutar cargas de trabajo en contenedores en un entorno de red solo IPv6 para evitar agotar el espacio de direcciones IPv4 privadas (RFC 1918). Cuando implementas un clúster de IPv6 de pila única, asignas solo direcciones IPv6 a tus Pods, nodos y Services, a la vez que mantienes la conectividad de entrada y salida a los recursos internos y externos.

Descripción general

A medida que tus cargas de trabajo escalan y aumenta la densidad del clúster, el espacio de direcciones IPv4 privadas puede agotarse con rapidez. En los clústeres de solo IPv4 y de pila doble, cada Pod requiere una dirección IPv4, lo que puede hacer que la asignación de bloques CIDR en tu red de VPC sea un cuello de botella importante para el escalamiento.

En los clústeres de IPv6 de pila única de GKE, asignas direcciones IPv6 exclusivamente en el plano de datos del clúster, lo que quita por completo las restricciones de direcciones IPv4. Los nodos trabajadores se ejecutan en instancias de VM de Compute Engine con IPv6 de pila única, y los Pods y Services se comunican a través de conexiones IPv6.

Asignación de direcciones IP (IPAM)

Los clústeres IPv6 de pila única asignan direcciones IPv6 en tu subred, nodos, Pods y Services con los siguientes tamaños de prefijo:

Recurso Prefijo del bloque CIDR Descripción
Subred /64 Se especifica como un bloque CIDR de subred solo IPv6.
Nodo /96 GKE lo asigna automáticamente desde el bloque CIDR de la subred, lo que proporciona alrededor de 4,290 millones de direcciones IPv6 únicas por nodo.
Pod /112 Se asigna desde un subconjunto del subrango /96 del nodo.
Servicio /64 GKE las asigna automáticamente para los objetos Service de ClusterIP desde el rango de direcciones IPv6 2600:2D00:0:4::0:0/64.

Tipos de acceso IPv6 externos e internos

Cuando configuras la subred del clúster, puedes elegir entre dos tipos de acceso IPv6 para controlar la capacidad de enrutamiento de Internet:

  • Interno (ULA): Las subredes con el tipo de acceso INTERNAL usan direcciones de unidifusión locales únicas (ULA) dentro del rango fd20::/20. La comunicación se limita a tu red de VPC, las redes de intercambio de tráfico y las conexiones híbridas. Los nodos y Pods no pueden acceder directamente a los recursos de Internet IPv6 públicos ni recibir entrada directa de Internet.
  • Externo (GUA): Las subredes con el tipo de acceso EXTERNAL usan direcciones de unidifusión global (GUA). A los nodos y Pods se les asignan direcciones IPv6 únicas a nivel global, y pueden comunicarse con recursos de Internet IPv6 públicos tanto de entrada como de salida, sujeto a las reglas de firewall de VPC y las tablas de enrutamiento.

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
  • Para usar Google Cloud CLI en esta tarea, instala y, luego, inicializa la gcloud CLI. Si ya instalaste gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos de este documento.

Requisitos y limitaciones

Para usar clústeres IPv6 de pila única, asegúrate de cumplir con los siguientes requisitos y limitaciones:

  • Tu clúster debe ejecutar la versión 1.37.1-gke.3020000 o posterior de GKE.
  • Tu clúster debe ser un clúster nativo de la VPC que use GKE Dataplane V2. Los clústeres IPv6 de pila única no admiten clústeres basados en rutas.
  • Los clústeres IPv6 de pila única solo admiten instancias de VM IPv6 de pila única como nodos trabajadores y no admiten grupos de nodos mixtos o de pila doble.
  • Debes usar Cloud DNS como proveedor de DNS del clúster (--cluster-dns=clouddns). Los clústeres IPv6 de pila única no admiten kube-dns.
  • El acceso al plano de control en clústeres IPv6 de pila única usa dos rutas de acceso distintas:
    • Clientes externos: Los clientes fuera del clúster (por ejemplo, con kubectl) acceden al plano de control a través de un extremo basado en un dominio en GKE Frontend (GKFE).
    • Cargas de trabajo internas: Los nodos y los Pods se conectan de forma segura al plano de control a través de Private Service Connect. Para admitir esta comunicación, debes proporcionar o crear una subred con un tipo de acceso IPv6 INTERNAL (--private-endpoint-subnetwork).
  • En las subredes IPv6 internas (INTERNAL), los nodos y los Pods pueden acceder a las APIs de Google y a Artifact Registry a través de IPv6 sin una puerta de enlace de Cloud NAT. Sin embargo, ten en cuenta lo siguiente:
    • Para llegar a extremos externos solo IPv4 (como registros de contenedores externos solo IPv4), debes configurar DNS64 y Cloud NAT (NAT64).
    • Los nodos y Pods en las subredes INTERNAL no pueden alcanzar extremos IPv6 públicos externos fuera de Google porque las direcciones locales únicas (ULA) no se pueden enrutar en la Internet IPv6 pública y Cloud NAT no admite la traducción de IPv6 a IPv6 (NAT66).
  • Los clústeres IPv6 de pila única no admiten las marcas de clúster --private-ipv6-google-access-type ni --enable-private-nodes. En su lugar, configura el Acceso privado a Google y los tipos de acceso IPv6 (INTERNAL o EXTERNAL) directamente en tu subred de VPC.
  • Los clústeres IPv6 de pila única no admiten parámetros de configuración de varias subredes.
  • Los clústeres IPv6 de pila única no admiten Ingress de GKE. Para configurar balanceadores de cargas de aplicaciones de capa 7, usa la API de Gateway.
  • La API de varias redes de GKE no admite redes de Pods IPv6; las redes de Pods secundarias deben ser solo IPv4. Para obtener más información, consulta Compatibilidad con varias redes para Pods.
  • Los clústeres solo IPv6 no admiten Cloud Service Mesh.
  • Puedes proporcionar tus propias direcciones IPv6 (BYOIPv6) con clústeres IPv6 de pila única. Para conocer los requisitos que se aplican a los prefijos BYOIPv6, consulta Crea y usa subprefijos IPv6.

Configuración del servidor de metadatos de la carga de trabajo

Debido a que las cargas de trabajo que se ejecutan en Pods solo IPv6 no pueden alcanzar la dirección del servidor de metadatos IPv4 estándar (169.254.169.254), aplica los siguientes ajustes:

  • Configura tus aplicaciones y bibliotecas cliente para acceder al servidor de metadatos con el nombre de dominio metadata.google.internal (recomendado) o la dirección IPv6 de ULA literal [fd20:ce::254].

  • Si usas bibliotecas cliente o aplicaciones con extremos de servidor de metadatos IPv4 codificados (por ejemplo, versiones anteriores de las bibliotecas cliente de la API de Google), establece la variable de entorno GCE_METADATA_HOST en tus imágenes de contenedor o especificaciones de Pod:

    env:
- name: GCE_METADATA_HOST
  value: "metadata.google.internal"

Crea un clúster IPv6 de pila única

Puedes crear un clúster IPv6 de pila única con Google Cloud CLI.

Crea un clúster y una subred de forma simultánea

Si no tienes subredes personalizadas preexistentes, puedes crear un clúster de IPv6 de pila única estándar y hacer que GKE aprovisione automáticamente la subred de nodo requerida y --private-endpoint-subnetwork en un solo comando.

Ejecuta el comando siguiente:

gcloud beta container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-dataplane-v2 \
    --cluster-dns=clouddns \
    --stack-type=ipv6 \
    --network=NETWORK_NAME \
    --create-subnetwork name=SUBNET_NAME \
    --ipv6-access-type=ACCESS_TYPE \
    --location=COMPUTE_LOCATION

Reemplaza lo siguiente:

  • CLUSTER_NAME: Nombre del clúster nuevo.
  • VERSION: GKE versión 1.37.1-gke.3020000 o posterior.
  • NETWORK_NAME: Es el nombre de una red de VPC de modo personalizado existente.
  • SUBNET_NAME: Es el nombre de la subred de nodos nueva que se creará.
  • ACCESS_TYPE: Es la enrutabilidad de Internet de la subred. Especifica INTERNAL para el direccionamiento de ULA privada o EXTERNAL para el direccionamiento de GUA pública. Si se omite, el valor predeterminado es EXTERNAL.
  • COMPUTE_LOCATION: Es la región o zona de procesamiento del clúster.

Crea un clúster de Standard en subredes personalizadas

Para usar subredes preexistentes o personalizadas, crea la red de VPC, la subred del plano de control de PSC y la subred de nodos antes de crear el clúster.

  1. Crea una red de VPC en modo personalizado con direcciones IPv6 internas de ULA habilitadas:

    gcloud compute networks create NETWORK_NAME \
    --subnet-mode=CUSTOM \
    --enable-ula-internal-ipv6

  2. Crea la subred del plano de control de PSC interno dedicada:

    gcloud compute networks subnets create PSC_SUBNET_NAME \
    --stack-type=ipv6_only \
    --ipv6-access-type=INTERNAL \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

    Reemplaza COMPUTE_REGION por la región en la que implementas tu clúster (por ejemplo, us-central1). También puedes especificar --stack-type=ipv4_ipv6 para la subred del plano de control de PSC.

  3. Crea la subred de nodos. Elige entre el acceso interno (INTERNAL) o el acceso externo (EXTERNAL):

    gcloud compute networks subnets create NODE_SUBNET_NAME \
    --stack-type=ipv6_only \
    --ipv6-access-type=ACCESS_TYPE \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

  4. Crea el clúster estándar IPv6 de pila única que haga referencia a ambas subredes:

    gcloud container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-dataplane-v2 \
    --cluster-dns=clouddns \
    --stack-type=ipv6 \
    --network=NETWORK_NAME \
    --subnetwork=NODE_SUBNET_NAME \
    --private-endpoint-subnetwork=PSC_SUBNET_NAME \
    --location=COMPUTE_LOCATION

Crea un clúster de Autopilot en subredes personalizadas

Los clústeres de Autopilot heredan automáticamente su tipo de pila de la subred de nodos que especifiques. Cuando seleccionas una subred de solo IPv6, GKE crea un clúster de Autopilot de IPv6 de pila única.

  1. Asegúrate de haber creado una red de VPC personalizada, una subred de PSC interna y una subred de nodos solo IPv6, como se describe en la sección anterior.

  2. Crea el clúster de Autopilot:

    gcloud container clusters create-auto CLUSTER_NAME \
    --cluster-version=VERSION \
    --network=NETWORK_NAME \
    --subnetwork=NODE_SUBNET_NAME \
    --private-endpoint-subnetwork=PSC_SUBNET_NAME \
    --location=COMPUTE_LOCATION

Crea un clúster de Standard con nodos administrados

También puedes crear un clúster de Standard IPv6 de pila única que use nodos administrados configurados a nivel de la carga de trabajo. Para obtener más información sobre cómo configurar las ComputeClasses administradas en clústeres de Standard, consulta Clases de Autopilot en clústeres de Standard.

Usa tus propias direcciones IPv6 para nodos y Pods

Puedes crear un clúster IPv6 de pila única cuyos nodos y Pods usen direcciones IPv6 propias (BYOIPv6) en lugar de las direcciones proporcionadas por Google. Para ello, crea la subred de nodos con un rango de direcciones IPv6 externo que provenga de un subprefijo IPv6 regional de tu prefijo delegado público (PDP). Luego, los nodos y los Pods reciben direcciones IPv6 de ese prefijo y se comunican con Internet y entre sí con esas direcciones.

  1. Crea un subprefijo IPv6 regional de tu prefijo delegado público en modo EXTERNAL_IPV6_SUBNETWORK_CREATION. Para obtener más información, consulta Crea subprefijos IPv6.

  2. Crea la subred del nodo con un tipo de acceso IPv6 EXTERNAL y haz referencia al subprefijo con la marca --ip-collection. Compute Engine asigna el rango de direcciones IPv6 /64 de la subred desde el subprefijo:

    gcloud compute networks subnets create NODE_SUBNET_NAME \
    --stack-type=ipv6_only \
    --ipv6-access-type=EXTERNAL \
    --ip-collection=SUB_PREFIX_NAME \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

    Reemplaza SUB_PREFIX_NAME por el nombre del subprefijo que creaste en el paso anterior. El prefijo secundario debe estar en la misma región que la subred. Para elegir un rango /64 específico del subprefijo en lugar de permitir que Compute Engine asigne uno, agrega la marca --external-ipv6-prefix.

  3. Crea el clúster en esta subred de nodos siguiendo los pasos que se indican en Crea un clúster de Standard en subredes personalizadas o Crea un clúster de Autopilot en subredes personalizadas. La subred del plano de control de PSC no necesita un rango de direcciones BYOIPv6.

  4. Después de que GKE cree el clúster, verifica que los nodos y los Pods tengan direcciones IPv6 de tu prefijo:

    kubectl get nodes -o wide
kubectl get pods --all-namespaces -o wide

Ten en cuenta lo siguiente:

  • En este procedimiento, se usa una subred de nodo con el tipo de acceso IPv6 EXTERNAL, por lo que los nodos y los Pods obtienen direcciones enrutables de forma global de tu prefijo. También puedes usar una subred de nodo con el tipo de acceso IPv6 INTERNAL haciendo referencia a un subprefijo en el modo INTERNAL_IPV6_SUBNETWORK_CREATION. En ese caso, los nodos y los Pods obtienen direcciones BYOIPv6 internas y se aplican las limitaciones de conectividad del tipo de acceso IPv6 interno. Para obtener más información, consulta Conéctate a recursos externos y privados.
  • Para exponer cargas de trabajo en direcciones BYOIPv6 con Services LoadBalancer, consulta Usa tus propias direcciones IPv6 (BYOIPv6), que no requiere una subred de nodos BYOIPv6.
  • Para conocer los requisitos que se aplican a los prefijos BYOIPv6, consulta Crea y usa subprefijos IPv6.

Verifica el tipo de pila del clúster

Una vez que se complete la creación del clúster, enumera tus clústeres para verificar que se ejecuten en el modo IPv6 de pila única:

gcloud beta container clusters list

El resultado confirma que la columna STACK_TYPE está configurada como IPV6:

NAME               LOCATION       MASTER_VERSION      MASTER_IP                                 MACHINE_TYPE  NODE_VERSION        NUM_NODES  STACK_TYPE  STATUS
v6-only-cluster-1  us-central1-c  1.37.0-gke.1000000  gke-3a3234-123456.us-central1-c.gke.goog  e2-medium     1.37.0-gke.1000000  1          IPV6        RUNNING

Balanceo de cargas en clústeres IPv6 de pila única

Puedes exponer aplicaciones que se ejecutan dentro de clústeres IPv6 de pila única con balanceadores de cargas de capa 7 y capa 4:

  • Balanceo de cargas de aplicaciones de capa 7 (API de Gateway): Usa la API de Gateway de Kubernetes para implementar balanceadores de cargas de aplicaciones de capa 7 (gke-l7-rilb, gke-l7-regional-external-managed o gke-l7-global-external-managed). Estas puertas de enlace pueden entregar clientes IPv4 e IPv6 internos y externos mientras enrutan el tráfico de forma transparente a extremos de Pods solo IPv6 internos. Ten en cuenta que Ingress de GKE no es compatible con los clústeres IPv6 de pila única. Cuando implementas puertas de enlace regionales (gke-l7-rilb y gke-l7-regional-external-managed) en clústeres IPv6 de pila única, ten en cuenta los siguientes requisitos de subred:

    • Subred de solo proxy: En los clústeres de IPv6 de pila única, la subred regional de solo proxy (--purpose=REGIONAL_MANAGED_PROXY) debe ser de pila doble (--stack-type=IPV4_IPV6). En los clústeres de solo IPv4 y de pila doble, la subred puede ser de solo IPv4 o de pila doble.
    • Subred de VIP de puerta de enlace: A diferencia de las puertas de enlace externas regionales IPv4 (que no asignan VIPs de una subred), las puertas de enlace externas regionales IPv6 (gke-l7-regional-external-managed) requieren una subred con acceso IPv6 EXTERNAL, y las puertas de enlace internas regionales (gke-l7-rilb) requieren una subred con acceso IPv6 INTERNAL (o un rango IPv4 para una VIP IPv4 interna). Para asignar una VIP de puerta de enlace regional efímera desde una subred personalizada en lugar de la subred del nodo del clúster, especifica el nombre de la subred en el campo spec.default.subnetwork de una GCPGatewayPolicy conectada a la puerta de enlace.

    Para obtener instrucciones de configuración, consulta Implementa puertas de enlace.

  • Balanceo de cargas de transferencia de capa 4 (API de Service): Puedes exponer cargas de trabajo a clientes IPv6 con Services de Kubernetes configurados con type: LoadBalancer. Según si los nodos del clúster se ejecutan en una subred INTERNAL (ULA) o EXTERNAL (GUA), es posible que debas aprovisionar una subred de balanceador de cargas dedicada y hacer referencia a ella con la anotación networking.gke.io/load-balancer-subnet:

Conéctate a recursos externos y privados

Las cargas de trabajo en tu clúster IPv6 de pila única a menudo necesitan comunicarse con servicios externos a través de Internet o servicios privados en Google Cloud.

Conéctate a recursos públicos de Internet IPv6

Si los nodos del clúster se ejecutan en una subred configurada con el tipo de acceso IPv6 EXTERNAL (--ipv6-access-type=EXTERNAL), la conectividad de salida y entrada a los extremos IPv6 públicos de Internet está habilitada de forma predeterminada. Verifica que las reglas de firewall de VPC permitan el tráfico IPv6 requerido. Para obtener más información, consulta Usa reglas de firewall de VPC.

Conéctate a recursos públicos de Internet IPv4 (DNS64 y NAT64)

Debido a que los Pods de un clúster IPv6 de pila única solo tienen direcciones IPv6, la conexión a extremos de Internet públicos solo IPv4 requiere traducción de red. Puedes configurar Cloud DNS y Cloud NAT en tu red de VPC para proporcionar traducción automática de DNS64 y NAT64:

  1. Crea una política del servidor DNS64:

    gcloud dns policies create POLICY_NAME \
    --description="DNS64 policy for single-stack IPv6 cluster" \
    --networks=NETWORK_NAME \
    --enable-dns64-all-queries

  2. Crea un Cloud Router en la región en la que se implementa tu clúster:

    gcloud compute routers create ROUTER_NAME \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

  3. Crea una puerta de enlace de Cloud NAT configurada para la traducción de NAT64:

    gcloud compute routers nats create NAT_NAME \
    --router=ROUTER_NAME \
    --region=COMPUTE_REGION \
    --auto-allocate-nat-external-ips \
    --nat64-all-v6-subnet-ip-ranges

    Para configurar NAT64 con subredes específicas o direcciones IP externas manuales, usa --nat64-custom-v6-subnet-ip-ranges y --nat-external-ip-pool.

Para obtener más información sobre la traducción de direcciones, consulta Configura DNS64 y NAT64 y DNS64 y NAT64 para la conectividad 6to4.

Conéctate a servicios privados con Private Service Connect

Private Service Connect (PSC) admite la traducción de direcciones IPv6 a IPv4 en extremos y reglas de reenvío. Puedes conectar las cargas de trabajo de tu clúster de IPv6 de pila única a los servicios administrados de Google Cloud (como las instancias de Cloud SQL) o a los servicios de productores de terceros:

  1. Reserva una dirección IPv6 interna estática desde la subred de PSC de tu clúster:

    gcloud compute addresses create ADDRESS_NAME \
    --ip-version=IPV6 \
    --subnet=PSC_SUBNET_NAME \
    --region=COMPUTE_REGION

  2. Crea una regla de reenvío de extremo de PSC orientada al adjunto de servicio:

    gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
    --address=ADDRESS_NAME \
    --region=COMPUTE_REGION \
    --network=NETWORK_NAME \
    --target-service-attachment=SERVICE_ATTACHMENT_URL \
    --allow-psc-global-access

  3. Recupera la dirección IPv6 asignada:

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME \
    --region=COMPUTE_REGION \
    --format='value(IPAddress)'

  4. Usa la dirección IPv6 recuperada dentro de las cadenas de conexión de tu aplicación. PSC traduce el tráfico para que tus Pods IPv6 puedan acceder de forma segura a los servicios de productor IPv4 o de pila doble.

Para obtener más información sobre cómo consumir servicios publicados, consulta Crea un extremo de Private Service Connect y Conéctate a Cloud SQL con Private Service Connect. Para publicar un Service LoadBalancer interno que se ejecuta en tu clúster para los consumidores en otras redes de VPC con un recurso ServiceAttachment, consulta Crea un balanceador de cargas interno con Private Service Connect.

Herramientas de redes y aceleradores avanzados

Puedes configurar clústeres IPv6 de pila única con interfaces de red secundarias para grupos de nodos aceleradores y Pods de varias redes.

Herramientas de redes de aceleradores con varias NIC

En los clústeres de IPv6 de pila única de Standard, puedes conectar redes de datos secundarias (RDMA o DIORITE) a grupos de nodos aceleradores (GPU y TPU) con redes automatizadas (--accelerator-network-profile=auto) o configuración manual de varias redes (--additional-node-network). Las interfaces secundarias pueden ejecutarse en subredes IPv4, subredes de pila doble o subredes solo IPv6.

Para obtener instrucciones paso a paso, consulta Configura redes de nodos con varias NIC en clústeres IPv6 de pila única.

Compatibilidad de varias redes para Pods

Los clústeres IPv6 de pila única admiten varias redes para Pods con las siguientes características:

  • La interfaz de red principal del Pod (eth0) usa redes IPv6 de pila única.
  • Las interfaces de red de Pod adicionales deben ser solo IPv4 (redes de VPC de capa 3). Los clústeres IPv6 de pila única no admiten redes de Pods IPv6 en interfaces de red adicionales.
  • La anotación del Pod networking.gke.io/default-interface configura la interfaz predeterminada solo para el tráfico IPv4. No se configura ninguna interfaz predeterminada para el tráfico IPv6.

Para aprender a configurar redes de Pods IPv4 secundarias respaldadas por subredes de VPC, consulta Configura la compatibilidad con varias redes para Pods en clústeres IPv6 de pila única.

Migra a clústeres IPv6 de pila única

No puedes convertir directamente ni actualizar in situ los clústeres IPv4 o de pila doble existentes en clústeres IPv6 de pila única. Para realizar la transición de las cargas de trabajo, usa una migración azul-verde:

  1. Audita las dependencias: Verifica que las configuraciones de la aplicación, las bibliotecas cliente y los agentes usen nombres de DNS (como metadata.google.internal) en lugar de direcciones IPv4 codificadas. Configura GCE_METADATA_HOST si es necesario.
  2. Aprovisiona el clúster verde: Implementa un nuevo clúster de IPv6 de pila única junto con el clúster existente dentro de la misma red de VPC o en una red de VPC con intercambio de tráfico. Verifica que Cloud DNS, DNS64, Cloud NAT (NAT64) y las reglas de reenvío de PSC estén configurados.
  3. Implementa cargas de trabajo: Aplica tus manifiestos de Kubernetes al clúster verde y verifica que los Pods se inicien y se comuniquen correctamente.
  4. Cambia el tráfico: Con tus balanceadores de cargas (API de Gateway o políticas de enrutamiento de Cloud DNS), cambia de forma gradual el tráfico del clúster heredado al nuevo clúster de IPv6 mientras supervisas las métricas y las tasas de error.
  5. Retira el clúster heredado: después de que se haya cambiado todo el tráfico y se verifique que el clúster verde es estable, vacía y borra el clúster anterior.

¿Qué sigue?