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

Para obtener más información sobre los beneficios y los requisitos de los clústeres nativos de la VPC, consulta Clústeres nativos de la VPC.

Antes de comenzar

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

Establece la configuración de gcloud predeterminada mediante uno de los siguientes métodos:

  • Usa gcloud init si deseas ver una explicación sobre cómo configurar parámetros predeterminados.
  • Usa gcloud config para establecer el ID, la zona y la región del proyecto de manera individual.

Usa gcloud init

Si recibes el error One of [--zone, --region] must be supplied: Please specify location, completa esta sección.

  1. Ejecuta gcloud init y sigue las instrucciones:

    gcloud init

    Si usas SSH en un servidor remoto, usa la marca --console-only para evitar que el comando abra un navegador:

    gcloud init --console-only
  2. Sigue las instrucciones a fin de autorizar a gcloud para que use tu cuenta de Google Cloud.
  3. Crea una configuración nueva o selecciona una existente.
  4. Elige un proyecto de Google Cloud.
  5. Elige una zona predeterminada de Compute Engine.

Usa gcloud config

  • Establece tu ID del proyecto predeterminado:
    gcloud config set project project-id
  • Si trabajas con clústeres zonales, establece tu zona de procesamiento predeterminada:
    gcloud config set compute/zone compute-zone
  • Si trabajas con clústeres regionales, establece tu región de procesamiento predeterminada:
    gcloud config set compute/region compute-region
  • Actualiza gcloud a la versión más reciente:
    gcloud components update

Procedimientos

Usa los siguientes procedimientos para crear un clúster nativo de la VPC y verificar los rangos de 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 la 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=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=region \
      --enable-ip-alias \
      --subnetwork=subnet-name \
      --cluster-secondary-range-name=secondary-range-pods \
      --services-secondary-range-name=secondary-range-services
    

Reemplaza los marcadores de posición por valores válidos:

  • cluster-name es el nombre del clúster de GKE.
  • region es la región en la que se crea el clúster. Para crear un clúster zonal, reemplaza esta marca por --zone=zone, en la que zone es una zona de Google Cloud.
  • 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 es un rango de direcciones IP en una notación de CIDR (por ejemplo, 10.0.0.0/14) o el tamaño de la máscara de subred de un bloque de CIDR (por ejemplo, /14). Se usa con el fin de crear el rango de direcciones IP secundarias de la subred para los Pods.
    • services-ip-range es 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 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 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 servicios del clúster.

Console

  1. Visita el menú de Google Kubernetes Engine en Cloud Console.

    Ir al menú Google Kubernetes Engine

  2. Haz clic en el botón Crear clúster.

  3. En el panel de navegación, en Clúster, haz clic en Herramientas de 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 (ejemplo: 10.0.0.0/14).

  9. En el campo Rango de direcciones del servicio, ingresa un rango del servicio (ejemplo: 10.4.0.0/19).

  10. Configura tu clúster como desees.

  11. Haz 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,

  },
  ...
}

Donde:

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

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

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

  project_id        = "project-id"
  name              = "cluster-name"
  region            = "region"
  network           = "network-name"
  subnetwork        = "subnet-name"
  ip_range_pods     = "secondary-range-pods"
  ip_range_services = "secondary-range-services"
}

Reemplaza lo siguiente:

  • project-id es el ID del proyecto en el que se crea el clúster.
  • cluster-name es el nombre del clúster de GKE.
  • region es la región en la que se crea el clúster.
  • network-name es 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 secundarias 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 secundarias 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 en simultáneo

En las siguientes instrucciones, se muestra 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=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

En el ejemplo anterior, se ilustra lo siguiente:

  • cluster-name es el nombre del clúster de GKE.
  • region es la región en la que se crea el clúster. Para crear un clúster zonal, reemplaza esta marca por --zone=zone, en la que zone es una zona de GKE.
  • subnet-name es el nombre de la subred que deseas 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 de manera automática.
  • node-ip-range es un rango de direcciones IP en una notación de CIDR (por ejemplo, 10.5.0.0/20) o el tamaño de la máscara de subred de un bloque de CIDR (por ejemplo, /20). Se usa con el fin de crear el rango de direcciones IP principales de la subred para los nodos. Si se omite, GKE selecciona un rango de IP disponible en la VPC con un tamaño de /20.
  • pod-ip-range es un rango de direcciones IP en notación de CIDR (por ejemplo, 10.0.0.0/14) o el tamaño de la máscara de subred de un bloque CIDR (por ejemplo, /14). Se usa con el fin de crear el rango de direcciones IP secundario de la subred para los Pods. Si se omite, GKE usa /14, que es el tamaño predeterminado del rango de direcciones IP del Pod.
  • services-ip-range es un rango de direcciones IP en notación de CIDR (por ejemplo, 10.4.0.0/19) o el tamaño de la máscara de subred de un bloque CIDR (por ejemplo, /19). Se usa con el fin de crear el rango de direcciones IP secundario de la subred para los servicios. Si se omite, GKE usa /20, el tamaño predeterminado del rango de direcciones IP de los servicios.

Console

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

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 que usan la versión 1.14.2-gke.1 y posteriores 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 reutilizados de forma privada

Los clústeres de GKE que usan la versión 1.14.2-gke.1 y posteriores pueden reutilizar de forma privada determinados rangos de direcciones IP públicas como rangos de direcciones IP internos y de subred. Puedes reutilizar 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 privado para usar rangos de direcciones IP públicas reutilizados de forma privada. No se admiten clústeres nativos de la VPC que no sean privados y clústeres basados en rutas.

Los rangos públicos reutilizados de forma privada son rangos de subred; puedes usarlos de forma exclusiva o en conjunto 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 reutilizas un rango de direcciones IP públicas como un rango de subred, el 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 reutilizan 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 reutilizados de forma privada o dejar de usarlas a menos que reemplaces el clúster.

  • No se pueden cambiar las fuentes (SNAT) de los paquetes enviados desde Pods que usan un rango de direcciones IP públicas reutilizado de forma privada a direcciones de nodos. Por lo tanto, debes crear tu clúster con la marca --disable-default-snat. Para obtener más detalles sobre esta marca, consulta Enmascaramiento de IP en GKE.

  • Debido a que un clúster cuyos Pods reutilizan rangos de direcciones IP públicas de forma privada debe ser privado, tu clúster debe usar una solución NAT como Cloud NAT si los Pods necesitan enviar tráfico a destinos en Internet. Cuando uses Cloud NAT, debes configurar al menos una puerta de enlace NAT que se aplicará al rango de direcciones IP secundario para los Pods de la subred del clúster. De esta manera, Cloud NAT realiza una SNAT a partir de paquetes enviados desde direcciones IP de Pods, ya que la configuración de enmascaramiento de IP del clúster debe tener el comportamiento de SNAT predeterminado desactivado.

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

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

  • --enable-ip-alias: Esto crea un clúster nativo de la VPC, que es necesario para reutilizar rangos de direcciones IP públicas de forma privada.
  • --enable-private-nodes: Esto crea un clúster privado, que es necesario para reutilizar rangos de direcciones IP públicas de forma privada.
  • --disable-default-snat: Esta opción es obligatoria si reutilizas direcciones IP públicas de forma privada para tus Pods o nodos. Debes inhabilitar la SNAT para que las respuestas se puedan enrutar al Pod que originó el tráfico.

Con este comando, se crea un clúster privado nativo de la VPC que contiene lo siguiente:

  • Nodos que usan el rango de direcciones IP principal 10.0.0.0/24 de la subred
  • Pods que reutilizan 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 reutilizan 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
gcloud container clusters create cluster-name \
  --enable-ip-alias \
  --enable-private-nodes \
  --disable-default-snat \
  --zone=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=master-CIDR

Verifica los rangos del Pod y del objeto 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 container clusters describe cluster-name

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

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

Console

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

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

    Ir al menú Google Kubernetes Engine

  2. Selecciona el clúster que desees.

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

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

Soluciona problemas

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

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

Causas posibles
Hay operaciones paralelas en la misma subred. Por ejemplo, cuando se crea otro clúster nativo de la VPC o se agrega o borra un rango secundario en la subred.
Solución
Vuelve a ejecutar el comando.

Valor no válido para el campo 'resource.secondaryIpRanges [1].ipCidrRange': 'XXX'. IPCidrRange no válido: XXX entra en conflicto con el valor 'default' de la subred existente en la región 'XXX'.

Causas posibles

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

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

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

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.

Si no puedes reemplazar el clúster, podrías solucionar el problema si puedes crear un nuevo grupo de nodos con una cantidad máxima menor de pods por nodo. Si es posible, migra las cargas de trabajo a ese grupo de nodos y, luego, borra el grupo de nodos anterior. Reducir la cantidad máxima de Pods por nodo 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.

En la salida se incluirá un campo disableDefaultSnat como el siguiente:

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. Consulta la salida de iptables de ejemplo de enmascaramiento de IP para obtener una lista de las reglas iptables y conocer cuáles son las predeterminadas. 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.

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 objeto Service 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 TCP/UDP interno.

Próximos pasos