Crear un clúster

En esta página se explica cómo crear un clúster y un grupo de nodos en GKE on Azure con la versión 1.32.4-gke.200 de Kubernetes.

Antes de empezar

Para completar los pasos de esta página, haz lo siguiente:

  1. Sigue los pasos que se indican en la sección Configurar los requisitos previos.

  2. Elige si quieres ejecutar el plano de control en varias zonas o en una sola.

  3. Seleccione los intervalos de enrutamiento de interdominios sin clases (CIDR) que quiera proporcionar a su clúster.

Colocación zonal del plano de control

De forma predeterminada, GKE en Azure coloca réplicas del plano de control independientes en la misma subred de tres zonas de la región que hayas seleccionado. Puedes elegir estas zonas y subredes.

Si quieres usar la colocación predeterminada de réplicas del plano de control, ve a la sección Seleccionar intervalos CIDR para el clúster.

Pasarela NAT de Azure y planos de control de clústeres

Cada réplica del plano de control también requiere conectividad con el servicio de gestión alojado en Google para funcionar con normalidad.

Si usas la pasarela NAT de Azure para proporcionar conectividad saliente, debes tener en cuenta cómo afecta un fallo de zona al plano de control del clúster. Un endpoint de pasarela de NAT está aislado en una sola zona o es regional/no zonal, lo que supone un único punto de fallo.

Si quieres colocar réplicas del plano de control en una sola zona, usa una sola subred y zona. Si usas una pasarela NAT para la conectividad saliente, asegúrate de que el endpoint se encuentre en la misma zona.

Si quieres colocar réplicas en dos o tres zonas, puedes transferir una lista de subredes y zonas al crear un clúster. Cuando proporcionas dos subredes y zonas, GKE en Azure coloca dos réplicas en la primera zona proporcionada. Si proporcionas tres subredes y zonas, GKE en Azure colocará réplicas en cada subred. Para obtener más información, consulta Colocar réplicas en una subred específica.

Para obtener más información sobre cómo configurar subredes y zonas de Azure para lograr una alta disponibilidad, consulta el artículo Aislamiento de zonas con pilas zonales de la documentación de Azure.

Colocar réplicas en una subred específica

Esta sección es opcional.

Para controlar en qué zonas se colocan las réplicas del plano de control, usa la marca --replica-placements y proporciona una lista de IDs de subredes y zonas al crear el clúster. Puedes usar hasta tres subredes y zonas en las que colocar las réplicas del plano de control.

Para dar formato a la lista de subredes, sigue estos pasos.

  1. Recupera los IDs de tu subred de Azure con la herramienta de línea de comandos az:

    az network vnet subnet show \
  --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \
  --name SUBNET_NAME --query "id" -otsv

    Haz los cambios siguientes:

    • CLUSTER_RESOURCE_GROUP_NAME: el nombre de un grupo de recursos donde quieras ejecutar el clúster
    • VNET_RESOURCE_GROUP_NAME: el nombre del grupo de recursos que contiene tu red virtual
    • VNET_NAME: nombre de tu red virtual
    • SUBNET_NAME: el nombre de tu subred

    El resultado es el ID de la subred. Los IDs de subred de Azure tienen el siguiente formato:

    /subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/SUBNET_NAME

    Repite este comando en cada subred en la que quieras crear una réplica del plano de control. Copia los IDs de las subredes en un editor de texto para el siguiente paso.

  2. Crea una lista separada por comas de los IDs de subred y las zonas de disponibilidad de Azure, con dos puntos para separar la subred y la zona. Por ejemplo, para crear réplicas del plano de control en subnet1 en la zona 1, subnet2 en la zona 2 y subnet3 en la zona 3, usa la siguiente cadena:

    /subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/subnet1:1,/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/subnet2:2,/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/subnet3:3

    Copia esta cadena y úsala como valor de la marca --replica-placements cuando crees un clúster.

Seleccionar intervalos CIDR para el clúster

Cuando creas un clúster en GKE en Azure, debes proporcionar intervalos de direcciones IPv4 para usarlos en pods y servicios.

Estos intervalos de direcciones IP se especifican mediante la notación de enrutamiento entre dominios sin clases (CIDR). Por ejemplo, 100.64.0.0/16.

Te recomendamos los siguientes intervalos CIDR para los servicios y los pods:

  • Servicios: 100.64.0.0/16
  • Pods: 100.96.0.0/11

Estos intervalos son lo suficientemente grandes como para que puedas ampliar tu clúster sin problemas.

En las siguientes secciones se proporcionan más detalles al respecto.

Detalles sobre la selección de intervalos

GKE en Azure usa una red superpuesta para pods y servicios, por lo que no es necesario que los intervalos de IP de estas redes se puedan enrutar en la red virtual. Los intervalos de IP que utilices deben estar disponibles. Para obtener más información, consulta Dataplane V2.

  • Los intervalos de IPs de pods y servicios pueden solaparse con la red de la red virtual, siempre que no incluyan los intervalos de IPs de la subred del plano de control o del grupo de nodos.

  • El intervalo de IPs de pods y servicios debe estar dentro de uno de los siguientes intervalos de IPs privadas:

    • 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16: direcciones IP privadas (RFC 1918)
    • 100.64.0.0/10: espacio de direcciones compartidas (RFC 6598)
    • 192.0.0.0/24: asignaciones de protocolo IETF (RFC 6890)
    • 192.0.2.0/24, 198.51.100.0/24 y 203.0.113.0/24: documentación (RFC 5737)
    • 192.88.99.0/24: retransmisión de IPv6 a IPv4 (obsoleto) (RFC 7526)
    • 198.18.0.0/15: pruebas de comparativas (RFC 2544)

Te recomendamos que uses intervalos de IP dentro de 100.64.0.0/10 (RFC 6598). Este intervalo se reserva para NAT de nivel de operador, que probablemente no se use en tu red virtual.

Por ejemplo, la siguiente es una configuración válida en la que las redes de pods, servicios y nodos no se solapan (la red virtual usa direcciones IP privadas RFC 1918, mientras que las redes de pods y servicios se superponen a las IPs privadas RFC 6598).

  • Red VNet: 10.0.0.0/16, 172.16.1.0/24, 172.16.2.0/24
  • Red de pódcasts: 100.65.0.0/16
  • Red de servicio: 100.66.0.0/16

La siguiente configuración también es válida a pesar de que las redes de pods y de servicios se solapan con la red de la VNet, ya que no se solapan con las réplicas del plano de control.

  • Red VNet: 10.0.0.0/16
  • Red de pódcasts: 10.0.1.0/24
  • Red de servicio: 10.0.2.0/24
  • Subredes de réplica del plano de control: 10.0.3.0/24, 10.0.4.0/24 y 10.0.5.0/24

La siguiente configuración no es válida porque el intervalo de IPs del pod se solapa con la red del plano de control. Este solapamiento puede impedir que las cargas de trabajo se comuniquen con la réplica del plano de control en la red de la red virtual:

  • Red VNet: 10.0.0.0/16
  • Red de pódcasts: 10.0.1.0/24
  • Red de servicio: 10.1.0.0/24
  • Subredes de réplica del plano de control: 10.0.1.0/24, 10.0.2.0/24 y 10.0.3.0/24

Detalles sobre el intervalo de direcciones de los pods

Kubernetes asigna direcciones a objetos Pod del intervalo de direcciones de pods. El intervalo de pods de un clúster se divide en intervalos más pequeños para cada nodo. Cuando se programa un pod en un nodo concreto, Kubernetes le asigna una dirección IP del intervalo del nodo.

Para calcular el tamaño del intervalo de direcciones de pods, debes estimar el número de nodos que quieres que haya en tu clúster y el número de pods que quieres ejecutar en cada nodo.

En la siguiente tabla se ofrecen recomendaciones de tamaño para los intervalos de CIDR de pods en función del número de nodos y pods que quieras ejecutar.

Tabla de intervalos de direcciones de pods

Intervalo de direcciones de pods Número máximo de direcciones IP de Pod Número máximo de nodos Número máximo de pods
/24
Intervalo de direcciones de pod más pequeño posible		 256 direcciones 1 nodo 110 pods
/23 512 direcciones 2 nodos 220 cápsulas
/22 1024 direcciones 4 nodos 440 cápsulas
/21 2048 direcciones 8 nodos 880 Pods
/20 4096 direcciones 16 nodos 1760 Pods
/19 8192 direcciones 32 nodos 3520 Pods
/18 16.384 direcciones 64 nodos 7040 Pods
/17 32.768 direcciones 128 nodos 14.080 Pods
/16 65.536 direcciones 256 nodos 28.160 Pods
/15 131.072 direcciones 512 nodos 56.320 Pods
/14 262.144 direcciones 1024 nodos 112.640 Pods

Detalles sobre el intervalo de direcciones de servicio

Kubernetes asigna direcciones IP virtuales a los objetos Service, como los balanceadores de carga, de este intervalo de direcciones.

Para calcular el tamaño del intervalo de direcciones de servicio, debes estimar el número de servicios que quieres tener en tu clúster.

En la siguiente tabla se ofrecen recomendaciones de tamaño para los intervalos CIDR de los servicios en función del número de servicios que quieras ejecutar.

Tabla de intervalos de direcciones de servicio

Intervalo de direcciones de servicios Número máximo de servicios
/27
Intervalo de direcciones de servicio más pequeño posible		 32 servicios
/26 64 servicios
/25 128 Services
/24 256 Services
/23 512 Services
/22 1024 Services
/21 2048 Services
/20 4096 Servicios
/19 8192 servicios
/18 16.384 servicios
/17 32.768 servicios
/16
Intervalo de direcciones de servicio más grande posible		 65.536 servicios

Autenticarse en Azure

GKE en Azure ofrece dos métodos para autenticarse en Azure: la federación de identidades de carga de trabajo y la creación de un certificado de cliente. La autenticación mediante la federación de identidades de cargas de trabajo es el método recomendado, ya que es más sencillo y seguro.

Federación de identidades de cargas de trabajo

La federación de identidades de carga de trabajo permite que GKE en Azure se autentique en Azure mediante una cuenta de servicio de Google para gestionar posteriormente los recursos en la aplicación Azure AD. A diferencia de AzureClient, no es necesario que gestiones certificados ni que los subas a Azure AD manualmente.

Para configurar una credencial de identidad federada en tu aplicación de Azure AD, ejecuta los siguientes comandos. Ten en cuenta que puedes añadir hasta veinte credenciales a cada aplicación de Azure AD.

  1. Guarda el ID de aplicación de Azure en variables de entorno:

    APPLICATION_ID=$(az ad app list --all \
  --query "[?displayName=='APPLICATION_NAME'].appId" --output tsv)
PROJECT_ID="$(gcloud config get-value project)"
PROJECT_NUMBER=$(gcloud projects describe "$PROJECT_ID" \
--format "value(projectNumber)")

  2. Crea un archivo JSON llamado credential.json.

    {
  "name": "CREDENTIAL_NAME",
  "issuer": "https://accounts.google.com",
  "subject": "service-PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com",
  "audiences": ["api://AzureADTokenExchange"],
  "description": "Allow GKE on Azure to authenticate to the Azure AD application using a Google service account."
}
    • CREDENTIAL_NAME: el nombre de la credencial.
    • PROJECT_NUMBER: número del Google Cloud proyecto que aloja el clúster.

  3. Crea una credencial de identidad federada en la aplicación de Azure AD:

    az ad app federated-credential create --id "${APPLICATION_ID}" --parameters credential.json

Para obtener más información, consulta la documentación de Azure sobre la federación de identidades de carga de trabajo de Azure AD con Google Cloud.

También puedes aprovisionar la credencial de identidad federada de Azure con Terraform. Para obtener más información, consulta azuread_application_federated_identity_credential.

Después de configurar las credenciales, crea o selecciona un par de claves SSH para tu clúster.

Crear un par de claves SSH

Cuando creas un clúster, debes proporcionar un par de claves SSH. Si ya tienes un par de claves que quieres usar, puedes saltarte este paso.

  1. Para crear un nuevo par de claves, usa la herramienta de línea de comandos ssh-keygen:

    ssh-keygen -m PEM -t rsa -b 4096 -f KEY_PATH

    Sustituye KEY_PATH por la ruta a tu nueva clave privada.

  2. Almacena la clave en una variable de entorno:

    SSH_PUBLIC_KEY=$(cat KEY_PATH.pub)

    Por ejemplo, para crear un nuevo par de claves en ~/.ssh/anthos-multicloud-key.pub y almacenar la clave pública en una variable de entorno, ejecuta el siguiente comando:

    ssh-keygen -m PEM -t rsa -b 4096 -f ~/.ssh/anthos-multicloud-key
SSH_PUBLIC_KEY=$(cat ~/.ssh/anthos-multicloud-key.pub)

Una vez que hayas guardado la clave pública en una variable de entorno, podrás crear un clúster.

Selecciona tu proyecto host de la flota

Las flotas son un concepto deGoogle Cloud para organizar los clústeres en grupos más grandes. Con las flotas, puedes gestionar varios clústeres en diferentes nubes y aplicar políticas coherentes en todos ellos. La API GKE Multi-Cloud registra automáticamente tus clústeres en una flota cuando se crea el clúster.

Cuando creas un clúster, especificas un proyecto de host de flota desde el que se gestionará el clúster. Como GKE en Azure usa el nombre del clúster como nombre de miembro de la flota, debes asegurarte de que los nombres de los clústeres sean únicos en toda la flota.

Registro entre proyectos

Si quieres usar un proyecto host de flota que no sea el proyecto en el que se encuentra el clúster, debes aplicar un enlace de política de IAM adicional a la cuenta de servicio del agente de servicio multicloud. Google Cloud De esta forma, la cuenta de servicio puede gestionar flotas con el proyecto de host de la flota.

  1. Para añadir el agente de servicio a tu proyecto, ejecuta este comando:

    gcloud beta services identity create --service=gkemulticloud.googleapis.com \
  --project=CLUSTER_PROJECT_NUMBER

    Sustituye CLUSTER_PROJECT_NUMBER por el Google Cloud número de tu proyecto.

  2. Asigna este enlace con el siguiente comando:

    gcloud projects add-iam-policy-binding FLEET_PROJECT_ID \
  --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com" \
  --role="roles/gkemulticloud.serviceAgent"

    Haz los cambios siguientes:

    • FLEET_PROJECT_ID: proyecto host de tu flota Google Cloud
    • CLUSTER_PROJECT_NUMBER: tu Google Cloud proyecto number

El nombre de la cuenta del agente de servicio multicloud tiene el siguiente formato: service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com.

Puedes encontrar tus cuentas de servicio en la página Cuenta de servicio de la Google Cloud consola. Para obtener más información sobre cómo encontrar el número de tu proyecto, consulta Identificar proyectos.

Crear un clúster

Para crear un clúster, ejecuta los siguientes comandos:

  1. Guarda los IDs de tu grupo de recursos, VNet y subred de Azure en variables de entorno:

    SUBSCRIPTION_ID=$(az account show --query "id" --output tsv)
TENANT_ID=$(az account list \
  --query "[?id=='${SUBSCRIPTION_ID}'].{tenantId:tenantId}" --output tsv)
CLUSTER_RG_ID=$(az group show --resource-group=CLUSTER_RESOURCE_GROUP_NAME \
  --query "id" -otsv)
VNET_ID=$(az network vnet show --resource-group=VNET_RESOURCE_GROUP_NAME \
  --name=VNET_NAME --query "id" -otsv)
SUBNET_ID=$(az network vnet subnet show \
  --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \
  --name default --query "id" -otsv)

    Haz los cambios siguientes:

    • CLUSTER_RESOURCE_GROUP_NAME: el nombre de un grupo de recursos donde quieras ejecutar el clúster
    • VNET_RESOURCE_GROUP_NAME: el nombre del grupo de recursos que contiene tu red virtual
    • VNET_NAME: el nombre de tu VNet

  2. Crea un clúster con Google Cloud CLI:

    Federación de identidades de cargas de trabajo

    gcloud container azure clusters create CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --fleet-project FLEET_PROJECT \
    --azure-tenant-id "${TENANT_ID}" \
    --azure-application-id "${APPLICATION_ID}" \
    --azure-region AZURE_REGION \
    --pod-address-cidr-blocks POD_CIDR \
    --service-address-cidr-blocks SERVICE_CIDR \
    --vm-size VM_SIZE \
    --cluster-version 1.32.4-gke.200 \
    --ssh-public-key "$SSH_PUBLIC_KEY" \
    --resource-group-id "$CLUSTER_RG_ID" \
    --vnet-id "$VNET_ID" \
    --subnet-id "$SUBNET_ID" # Optional, see following note \
    --tags "control-plane=CLUSTER_NAME" \
    --admin-users ADMIN_USERS_LIST

    Cliente de Azure

    gcloud container azure clusters create CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --fleet-project FLEET_PROJECT \
    --client CLIENT_NAME \
    --azure-region AZURE_REGION \
    --pod-address-cidr-blocks POD_CIDR \
    --service-address-cidr-blocks SERVICE_CIDR \
    --vm-size VM_SIZE \
    --cluster-version 1.32.4-gke.200 \
    --ssh-public-key "$SSH_PUBLIC_KEY" \
    --resource-group-id "$CLUSTER_RG_ID" \
    --vnet-id "$VNET_ID" \
    --subnet-id "$SUBNET_ID" # Optional, see following note \
    --tags "control-plane=CLUSTER_NAME" \
    --admin-users ADMIN_USERS_LIST

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre de tu clúster
    • GOOGLE_CLOUD_LOCATION: la Google Cloud ubicación que gestiona tu clúster
    • FLEET_PROJECT con el proyecto host de la flota en el que se registrará el clúster. Si quieres gestionar este clúster desde otro proyecto, consulta Registro entre proyectos.Google Cloud
    • AZURE_REGION: una región de Azure admitida asociada a tu región de Google Cloud
    • POD_CIDR: el intervalo de direcciones de pods de tu clúster. Por ejemplo, 10.0.1.0/18.
    • SERVICE_CIDR: el intervalo de direcciones de servicio de tu clúster
    • VM_SIZE: a tamaño de máquina virtual de Azure compatible
    • ADMIN_USERS_LIST (opcional): lista separada por comas de las direcciones de correo electrónico de los usuarios a los que se les concederán privilegios de administrador. Por ejemplo, "kai@example.com,hao@example.com,kalani@example.com". El valor predeterminado es el usuario que crea el clúster.
    • CLIENT_NAME: el nombre de tu AzureClient

  3. Comprueba el estado de tu clúster:

    gcloud container azure clusters describe CLUSTER_NAME  --location GOOGLE_CLOUD_LOCATION

    Haz los cambios siguientes:

    • CLUSTER_NAME
    • GOOGLE_CLOUD_LOCATION

    El resultado incluye información sobre el estado y la configuración de tu clúster.

Autorizar Cloud Logging o Cloud Monitoring

Para que GKE en Azure pueda crear y subir registros y métricas del sistema aGoogle Cloud, debe tener autorización.

Para autorizar la identidad de carga de trabajo de Kubernetes gke-system/gke-telemetry-agent para escribir registros en Google Cloud Logging y métricas en Google Cloud Monitoring, ejecuta este comando:

gcloud projects add-iam-policy-binding GOOGLE_PROJECT_ID \
  --member="serviceAccount:GOOGLE_PROJECT_ID.svc.id.goog[gke-system/gke-telemetry-agent]" \
  --role=roles/gkemulticloud.telemetryWriter

Sustituye GOOGLE_PROJECT_ID por el ID del proyecto del clúster. Google Cloud

Este enlace de gestión de identidades y accesos concede acceso a todos los clústeres del proyecto Google Cloud project para subir registros y métricas. Solo tienes que ejecutarlo después de crear el primer clúster del proyecto.

No se podrá añadir este enlace de gestión de identidades y accesos a menos que se haya creado al menos un clúster en tu Google Cloud proyecto. Esto se debe a que el grupo de identidades de carga de trabajo al que hace referencia (GOOGLE_PROJECT_ID.svc.id.goog) no se aprovisiona hasta que se crea el clúster.

Crear un grupo de nodos

Antes de crear un pool de nodos, necesitas lo siguiente:

  • Permisos para usar la herramienta de línea de comandos az para obtener un ID de subred de Azure.
  • Acceso a la clave pública SSH del clúster.

Para crear un pool de nodos, ejecuta los siguientes comandos:

  1. Guarda el ID de la subred de la red virtual de Azure y la clave pública SSH en variables de entorno:

    SUBNET_ID=$(az network vnet subnet show \
  --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \
  --name default --query "id" -otsv)
SSH_PUBLIC_KEY=$(cat KEY_PATH.pub)

    Haz los cambios siguientes:

    • VNET_RESOURCE_GROUP_NAME: el nombre del grupo de recursos que contiene la red virtual
    • VNET_NAME: el nombre de tu VNet
    • KEY_PATH: la ruta a tu par de claves

  2. Crea un grupo de nodos con Google Cloud CLI:

    gcloud container azure node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --node-version 1.32.4-gke.200 \
    --vm-size VM_SIZE \
    --max-pods-per-node 110 \
    --min-nodes MIN_NODES \
    --max-nodes MAX_NODES \
    --ssh-public-key "${SSH_PUBLIC_KEY}" \
    --subnet-id "${SUBNET_ID}"

    Haz los cambios siguientes:

  3. Comprueba el estado de tu grupo de nodos:

    gcloud container azure node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION

    Haz los cambios siguientes:

    • NODE_POOL_NAME: un nombre único para tu grupo de nodos. Por ejemplo, node-pool-1.
    • CLUSTER_NAME: el nombre de tu clúster de GKE en Azure
    • GOOGLE_CLOUD_LOCATION: la Google Cloud ubicación que gestiona tu clúster

    El resultado incluye el estado de tu grupo de nodos, por ejemplo, si está PROVISIONING o RUNNING.

Siguientes pasos