Agrega subredes a los clústeres

En esta página, se muestra cómo asignar subredes adicionales a un clúster nativo de la VPC. Las subredes adicionales asignadas a un clúster te permiten crear grupos de nodos nuevos en los que las direcciones IPv4 para los nodos y los Pods provienen de los rangos de subredes adicionales.

Esta página está dirigida a especialistas en herramientas de redes que diseñan la red para su organización. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en Google Cloud el contenido, consulta Roles y tareas comunes del usuario de GKE.

Descripción general

Cuando creas un clúster de GKE nativo de la VPC nuevo, seleccionas una subred predeterminada para el clúster. La subred predeterminada del clúster proporciona direcciones IPv4 para nodos, Pods y servicios, como se describe en Rangos de direcciones IP para clústeres nativos de la VPC.

Puedes asignar hasta ocho subredes adicionales a un clúster nativo de la VPC, lo que permite un crecimiento significativo del clúster. Cada subred adicional recién asignada se denomina subred no predeterminada.

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

En esta sección, se describen los requisitos y las limitaciones que se aplican cuando asignas y usas subredes adicionales a un clúster. Debes cumplir con todos los requisitos antes de asignar subredes adicionales.

  • Asegúrate de que tu clúster de GKE sea un clúster nativo de la VPC que ejecute la versión 1.30.3-gke.1211000 de GKE o posterior. Los clústeres basados en rutas y los clústeres en redes heredadas no admiten subredes adicionales.
  • Puedes asignar hasta ocho subredes adicionales por clúster.
  • Las subredes adicionales solo proporcionan direcciones IPv4 para nodos y Pods. Las subredes adicionales no se pueden usar para proporcionar direcciones IPv6 para nodos o Pods.
  • Solo los grupos de nodos nuevos pueden usar las subredes adicionales, no los grupos de nodos existentes. De forma predeterminada, GKE selecciona automáticamente una subred adecuada para el grupo de nodos. De manera opcional, puedes especificar una subred de forma manual cuando creas un grupo de nodos.
  • Los rangos de direcciones IPv4 secundarios de la subred en una subred no predeterminada solo pueden usarse en un solo clúster.
  • Es posible que las subredes adicionales no se usen con puertas de enlace de varios clústeres.
  • Si usas la compatibilidad con varias redes para Pods, los rangos de direcciones IPv4 principales y de Pod de una subred adicional no deben superponerse con ningún rango de CIDR configurado en tu configuración de varias redes Las subredes adicionales que configures solo se aplican a la red predeterminada. Esta limitación significa que las interfaces de red adicionales en tus nodos y Pods no pueden usar las direcciones IP que proporcionan estas subredes adicionales.
  • Cuando agregas una subred a clústeres que tienen habilitado Cloud Service Mesh, la malla no puede enrutar el tráfico a los Pods en la subred no predeterminada.

Requisitos del balanceador de cargas para clústeres con subredes adicionales

En esta sección, se describen los requisitos del balanceador de cargas que se aplican cuando usas subredes adicionales en tu clúster. Estos requisitos se aplican cada vez que creas un Ingress externo, una puerta de enlace externa o un objeto Service LoadBalancer externo.

  • Para usar un Ingress externo, una puerta de enlace o un objeto Service LoadBalancer en un clúster con subredes adicionales, tu clúster debe ejecutar la versión 1.33.2-gke.4780000 de GKE o posterior.
  • Los objetos Ingress externos que usan el controlador de Ingress de GKE deben usar el balanceo de cargas nativo del contenedor.
  • Habilita la subdivisión de GKE para los objetos Service LoadBalancer internos. La subdivisión de GKE solo afecta a los objetos Service LoadBalancer internos nuevos. Por lo tanto, debes borrar y volver a crear los servicios existentes en tu clúster después de habilitar la subdivisión de GKE.

  • Para crear un balanceador de cargas de red de transferencia externo basado en servicios de backend, los objetos Service LoadBalancer externos nuevos deben incluir el campo spec.loadBalancerClass establecido en networking.gke.io/l4-regional-external. Este campo solo afecta a los objetos Service LoadBalancer externos nuevos y no se aplica a los objetos Service LoadBalancer externos existentes. Borra y vuelve a crear todos los objetos Service LoadBalancer externos que se crearon sin el campo spec.loadBalancerClass. Este campo requiere la versión 1.33.1-gke.1779000 de GKE o posterior.

    El tipo de backend que se usa (backends de NEG GCE_VM_IP o backends de grupos de instancias) depende de la versión de GKE cuando creas el objeto Service LoadBalancer externo. Para obtener más información, consulta Agrupación de nodos.

Agrega una subred nueva con un rango de direcciones IPv4 de Pod

  1. Crea una subred nueva y agrega un nuevo rango de direcciones IPv4 secundario de la subred. La subred debe estar en la misma región y red de VPC que el clúster:

       gcloud compute networks subnets create SUBNET_NAME \
     --network=NETWORK \
     --region=REGION \
     --range=PRIMARY_RANGE \
     --secondary-range=POD_RANGE_NAME=SECONDARY_RANGE \
     --enable-private-ip-google-access

    Reemplaza lo siguiente:

    • SUBNET_NAME: es el nombre de la subred nueva.
    • NETWORK: Es el nombre de la red de VPC que contiene la subred nueva.
    • REGION: Es la región en la que se encuentra la subred.
    • PRIMARY_RANGE: Es el rango IPv4 principal para la subred nueva, en notación CIDR. Para obtener más información, consulta Rangos de subredes IPv4.
    • POD_RANGE_NAME: Es un nombre para el rango secundario.
    • SECONDARY_RANGE: Es el rango IPv4 secundario en notación CIDR. Para conocer los rangos válidos, consulta Rangos de subredes IPv4.

    Para obtener más información, consulta Trabaja con subredes.

  2. Actualiza el clúster para usar la subred adicional con gcloud CLI:

       gcloud container clusters update CLUSTER_NAME \
     --additional-ip-ranges=subnetwork=SUBNET_NAME,pod-ipv4-range=POD_RANGE_NAME

    Reemplaza lo siguiente:

    • CLUSTER_NAME: Es el nombre del clúster existente.
    • SUBNET_NAME: Es el nombre de la subred nueva que creaste.
    • POD_RANGE_NAME: Es el nombre del rango de direcciones IPv4 secundario de la subred que deseas usar para el rango de direcciones IPv4 de Pod.

Agrega una subred nueva con varios rangos de direcciones IPv4 de Pod

  1. Crea una subred nueva en la misma región y red de VPC que el clúster. Establece el rango de direcciones IPv4 principal de la subred en un rango de direcciones IPv4 adicional para los nodos.

  2. Para cada rango de direcciones IPv4 de Pod adicional que necesites, agrega un nuevo rango de direcciones IPv4 secundario de la subred a la subred que creaste en el paso anterior.

  3. Actualiza el clúster para usar la subred adicional con gcloud CLI. En el siguiente ejemplo, se agrega una subred que tiene dos rangos de direcciones IPv4 secundarios de la subred para los Pods.

       gcloud container clusters update CLUSTER_NAME \
     --additional-ip-ranges=subnetwork=SUBNET_NAME,pod-ipv4-range=POD_RANGE_NAME_1 \
     --additional-ip-ranges=subnetwork=SUBNET_NAME,pod-ipv4-range=POD_RANGE_NAME_2

    Reemplaza lo siguiente:

    • CLUSTER_NAME: Es el nombre del clúster existente.
    • SUBNET_NAME: Es el nombre de la subred nueva que creaste.
    • POD_RANGE_NAME_1 y POD_RANGE_NAME_2: Son los nombres de los rangos de direcciones IPv4 secundarios de la subred que deseas usar para los rangos de direcciones IPv4 de Pod.

Verifica las subredes

Por clúster: Para ver los detalles de todas las subredes asociadas con un clúster, ejecuta el siguiente comando:

   gcloud container clusters describe CLUSTER_NAME

Reemplaza CLUSTER_NAME por el nombre del clúster.

El resultado es similar a este:

ipAllocationPolicy:
  additionalIPRangesConfig:
  - podIpv4RangeNames:
    - pod-range-1
    subnetwork: projects/user-gke-dev-2/regions/us-central1/subnetworks/shared-msc-subnets

Por grupo de nodos: Para ver los detalles de todas las subredes asociadas con un grupo de nodos, ejecuta el siguiente comando:

gcloud container node-pools describe POOL_NAME \
    --cluster=CLUSTER_NAME \

Reemplaza lo siguiente:

  • POOL_NAME: el nombre del grupo de nodos
  • CLUSTER_NAME: el nombre del clúster

El resultado es similar a este:

name: pool-1
networkConfig:
  podRange: pod-range-1
  subnetwork: projects/user-gke-dev-2/regions/us-central1/subnetworks/shared-msc-subnets

Cómo los grupos de nodos seleccionan una subred

De forma predeterminada, cuando creas un grupo de nodos nuevo y hay varias subredes disponibles, GKE selecciona automáticamente una subred adecuada para el grupo de nodos según los requisitos de las direcciones IP y la disponibilidad de direcciones IP en todas las subredes del clúster.

Especifica una subred de forma manual durante la creación del grupo de nodos

Para especificar una subred cuando creas un grupo de nodos, usa la marca --subnetwork con el comando gcloud container node-pools create. La subred que especifiques ya debe estar asignada al clúster (ya sea como la subred predeterminada o como una subred adicional). Si no especificas un rango IPv4 de Pod, GKE selecciona automáticamente un rango secundario disponible de la subred especificada. Si la subred o el rango de Pod especificados no tienen suficientes direcciones IP disponibles para el grupo de nodos, GKE muestra un error.

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --subnetwork=SUBNET_NAME

Especifica el rango de direcciones IPv4 de Pod junto con la subred

Si la subred especificada tiene varios rangos de direcciones IPv4 secundarios, puedes usar la marca --pod-ipv4-range y la marca --subnetwork para especificar qué rango usar para los Pods en el grupo de nodos. 

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --subnetwork=SUBNET_NAME \
    --pod-ipv4-range=POD_RANGE_NAME

Reemplaza lo siguiente:

  • POOL_NAME: Un nombre para el grupo de nodos nuevo.
  • CLUSTER_NAME: el nombre del clúster
  • LOCATION: la región o zona del clúster
  • SUBNET_NAME: el nombre o la ruta de acceso completa del recurso de la subred que deseas usar
  • POD_RANGE_NAME: el nombre del rango secundario de la subred que se usará para los Pods en este grupo de nodos

Quita una subred no predeterminada

Quitar una subred no predeterminada de un clúster le indica al clúster que ya no use los rangos de la subred en ninguno de los grupos de nodos del clúster. La eliminación tiene los siguientes efectos:

  • El rango de direcciones IPv4 principal de la subred no predeterminada no se puede usar para los rangos de direcciones IPv4 de nodos.
  • Los rangos IPv4 secundarios de la subred en la subred no predeterminada no se pueden usar para los rangos IPv4 de Pod.

Antes de quitar una subred no predeterminada, debes borrar todos los grupos de nodos que usen esta subred. El primer paso recomendado es establecer la subred en el estado de drenaje. Las subredes en el estado de drenaje no se considerarán para su uso en grupos de nodos recién creados. Esto evita que las operaciones del escalador automático de clústeres (como el escalamiento vertical del grupo de nodos) seleccionen la subred que deseas quitar, sin necesidad de inhabilitar el ajuste de escala automático para todo el clúster.

Estos son los pasos para quitar una subred:

  1. Establece la subred no predeterminada en el estado de drenaje. Esto evita que los grupos de nodos nuevos seleccionen esta subred, lo que es útil cuando habilitas el ajuste de escala automático en el clúster.
  2. Borra todos los grupos de nodos que usan esta subred.
  3. Quita la subred del clúster.

Para quitar una subred no predeterminada del clúster, ejecuta el siguiente comando:

   gcloud container clusters update CLUSTER_NAME \
     --remove-additional-ip-ranges=subnetwork=SUBNET_NAME

Reemplaza lo siguiente:

  • CLUSTER_NAME: El nombre de tu clúster.
  • SUBNET_NAME: El nombre de la subred que deseas quitar del clúster.

Para establecer el estado de una subred no predeterminada en drenaje, ejecuta el siguiente comando:

   gcloud container clusters update CLUSTER_NAME \
     --drain-additional-ip-ranges=subnetwork=SUBNET_NAME

Reemplaza lo siguiente:

  • CLUSTER_NAME: El nombre de tu clúster.
  • SUBNET_NAME: El nombre de la subred que deseas establecer en el estado de drenaje.

Para anular el drenaje de una subred no predeterminada, ejecuta el siguiente comando:

   gcloud container clusters update CLUSTER_NAME \
     --undrain-additional-ip-ranges=subnetwork=SUBNET_NAME

Reemplaza lo siguiente:

  • CLUSTER_NAME: El nombre de tu clúster.
  • SUBNET_NAME: El nombre de la subred que deseas anular el drenaje.

Después de quitar una subred no predeterminada del clúster, puedes borrar la subred no predeterminada.

Quita un rango IPv4 secundario de una subred no predeterminada

Cuando quitas un rango IPv4 secundario de una subred no predeterminada de un clúster, GKE le indica al clúster que no use ese rango para los rangos IPv4 de Pod en ningún grupo de nodos. Si el rango IPv4 secundario de la subred no predeterminada que quitas es el único rango de la subred no predeterminada que usa este clúster, GKE también le indica al clúster que deje de usar la dirección IPv4 principal de esta subred para las direcciones IPv4 de nodos.

Antes de quitar un rango IPv4 secundario de una subred no predeterminada, debes borrar todos los grupos de nodos que usen el rango para las direcciones IPv4 de Pod.

Para quitar un rango IPv4 secundario de una subred no predeterminada del clúster, ejecuta el siguiente comando:

   gcloud container clusters update CLUSTER_NAME \
     --remove-additional-ip-ranges=\
       subnetwork=SUBNET_NAME,pod-ipv4-range=POD_RANGE_NAME

Reemplaza lo siguiente:

  • CLUSTER_NAME: el nombre del clúster
  • SUBNET_NAME: el nombre de la subred no predeterminada
  • POD_RANGE_NAME: el nombre del rango IPv4 secundario de la subred no predeterminada que deseas quitar del clúster

Después de quitar un rango IPv4 secundario de una subred no predeterminada del clúster, puedes borrarlo.

Usa subredes adicionales en la VPC compartida

Antes de continuar, asegúrate de tener lo siguiente:

  • Un entorno de VPC compartida funcional en el que se adjuntan los proyectos host y de servicio. Para obtener instrucciones, consulta Configura un clúster con una VPC compartida.
  • Un clúster de GKE en ejecución ubicado en el proyecto de servicio.
  • Todas las APIs necesarias están habilitadas en los proyectos host y de servicio.

  1. Crea una subred adicional en el proyecto host en la misma red del clúster de GKE:

    gcloud compute networks subnets create ADDITIONAL_SUBNET_NAME \
  --project HOST_PROJECT_ID \
  --network shared-net \
  --range 172.16.4.0/22 \
  --region COMPUTE_REGION \
  --secondary-range ADDITIONAL_SUBNET_NAME-services=172.16.16.0/20,ADDITIONAL_SUBNET_NAME-pods=172.20.0.0/14

  2. Obtén la política de IAM. Para permitir que el clúster de GKE en el proyecto de servicio acceda a subredes adicionales dentro de la VPC compartida del proyecto host, debes configurar los permisos de IAM necesarios. Si los permisos aún no están configurados, continúa con los siguientes pasos. No es necesario realizar ninguna acción si los permisos ya existen.

    gcloud compute networks subnets get-iam-policy ADDITIONAL_SUBNET_NAME \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

    El resultado contiene un campo etag. Toma nota del valor de etag.

  3. Crea un archivo llamado ADDITIONAL_SUBNET_NAME-policy.yaml que tenga el siguiente contenido:

      bindings:
  - members:
    - serviceAccount:SERVICE_PROJECT_NUM@cloudservices.gserviceaccount.com
    - serviceAccount:service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com
    role: roles/compute.networkUser
  etag: ETAG_STRING

    Reemplaza ETAG_STRING por el valor etag que anotaste antes.

  4. Establece la política de IAM para la subred ADDITIONAL_SUBNET_NAME:

      gcloud compute networks subnets set-iam-policy ADDITIONAL_SUBNET_NAME \
      ADDITIONAL_SUBNET_NAME-policy.yaml \
      --project HOST_PROJECT_ID \
      --region COMPUTE_REGION

  5. Verifica los rangos de direcciones IP secundarios y las subredes que se pueden usar, como se describe en shared vpc verify usable subnets.

  6. Actualiza el clúster de VPC compartida de las subredes adicionales:

    gcloud container clusters update CLUSTER_NAME \
        --project=SERVICE_PROJECT_ID \
        --location=CONTROL_PLANE_LOCATION \
        --additional-ip-ranges=subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/ADDITIONAL_SUBNET_NAME,pod-ipv4-range=ADDITIONAL_SUBNET_NAME-pods

Reemplaza lo siguiente:

  • CLUSTER_NAME: el nombre de tu clúster de GKE en el proyecto de servicio
  • ADDITIONAL_SUBNET_NAME: el nombre de la subred adicional que creaste en el proyecto host (p. ej., nivel-2)
  • HOST_PROJECT_ID: el ID del proyecto host
  • SERVICE_PROJECT_NUM: el nombre del proyecto de servicio
  • COMPUTE_REGION: la región en la que se encuentra la subred

Esto te permite usar las subredes adicionales en un entorno de VPC compartida.

¿Qué sigue?