Crea un clúster

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

Antes de comenzar

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

  1. Sigue los pasos de la página Configura los requisitos.

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

  3. Selecciona rangos de enrutamiento entre dominios sin clases (CIDR) para proporcionar a tu clúster.

Ubicación zonal del plano de control

De forma predeterminada, los clústeres de GKE en Azure colocan réplicas separadas del plano de control en la misma subred, en tres zonas de la región elegida. Puedes elegir estas zonas y subredes.

Si deseas usar la ubicación de réplica del plano de control predeterminada, ve a Selecciona rangos de CIDR para el clúster.

Puerta de enlace NAT de Azure y planos de control del clúster

Cada réplica del plano de control también requiere conectividad al servicio de administración alojado por Google para operar en un estado normal.

Si usas la puerta de enlace NAT de Azure para proporcionar conectividad saliente, debes considerar cómo una falla zonal afecta el plano de control del clúster. Un extremo de puerta de enlace NAT está aislado a una sola zona o es regional o no zonal, y esto presenta un punto único de fallo.

Si deseas colocar réplicas del plano de control en una sola zona, usa una sola subred y zona. Si usas la puerta de enlace NAT para la conectividad saliente, asegúrate de que el extremo esté ubicado en la misma zona.

Si deseas colocar réplicas en dos o tres zonas, puedes pasar una lista de subredes y zonas cuando crees un clúster. Cuando pasas dos subredes y zonas, GKE en Azure coloca dos réplicas en la primera zona proporcionada. Cuando pasas tres subredes y zonas, GKE en Azure coloca réplicas en cada subred. Para obtener más información, consulta Coloca réplicas en una subred específica.

Si deseas obtener más información para configurar subredes y zonas de Azure para alta disponibilidad, consulta Aislamiento de zonas con pilas zonales en la documentación de Azure.

Ubica réplicas en una subred específica

Esta sección es opcional.

Para controlar en qué zonas se ubican las réplicas del plano de control, usa la marca --replica-placements y pasa una lista de los ID y las zonas de la subred cuando crees tu clúster. Puedes usar hasta tres subredes y zonas para colocar las réplicas del plano de control.

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

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

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

    Reemplaza lo siguiente:

    • CLUSTER_RESOURCE_GROUP_NAME: Es un nombre de grupo de recursos existente en el que deseas ejecutar tu clúster.
    • VNET_RESOURCE_GROUP_NAME: Es el nombre del grupo de recursos que contiene tu VNet.
    • VNET_NAME: Es tu nombre de VNet
    • SUBNET_NAME: Es tu nombre de la subred

    El resultado es el ID de la subred. Los ID de subred de Azure se ven como el siguiente ejemplo:

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

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

  2. Crea una lista separada por comas de los ID de subred y las zonas de disponibilidad de Azure; usa 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 string:

    /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 string y úsala como el valor para la marca --replica-placements cuando crees un clúster.

Selecciona rangos CIDR para el clúster

Cuando creas un clúster en clústeres de GKE en Azure, debes proporcionar rangos de direcciones IPv4 para usar con Pods y Services.

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

Recomendamos los siguientes rangos de CIDR para servicios y pods:

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

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

En las siguientes secciones, se proporcionan más detalles.

Detalles sobre cómo elegir rangos

GKE en Azure usa una red de superposición para Pods y Services, por lo que los rangos de IP de estas redes no necesitan enrutarse dentro de la VNet. Todos los rangos de IP que usas deben estar disponibles. Para obtener más información, consulta Dataplane V2.

  • Los rangos de IP del Pod y del Service se pueden superponer con la red de VNet, siempre que no incluyan los rangos de IP de la subred del plano de control o el grupo de nodos.

  • El rango de IP del Pod y del Service debe estar dentro de uno de los siguientes rangos de IP privados:

    • 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16: Direcciones IP privadas de RFC 1918
    • 100.64.0.0/10: Espacio de direcciones compartidas de RFC 6598
    • 192.0.0.0/24: Asignaciones de protocolo IETF de RFC 6890
    • 192.0.2.0/24, 198.51.100.0/24 y 203.0.113.0/24: Documentación de RFC 5737
    • 192.88.99.0/24: Retransmisión de IPv6 a IPv4 (obsoleta) de RFC 7526
    • 198.18.0.0/15: Pruebas comparativas de RFC 2544

Recomendamos rangos de IP dentro de 100.64.0.0/10 (RFC 6598). Este rango se reserva para la NAT de nivel de proveedor, que es probable que no se use en tu VNet.

Por ejemplo, la siguiente es una configuración válida, ya que las redes de Pods, Services y nodos no se superponen (la VNet usa direcciones IP privadas RFC 1918, mientras que las redes de Pods y Services se superponen con las IP privadas RFC 6598).

  • Red de VNet: 10.0.0.0/16, 172.16.1.0/24, 172.16.2.0/24
  • Red del Pod: 100.65.0.0/16
  • Red del Service: 100.66.0.0/16

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

  • Red de VNet: 10.0.0.0/16
  • Red del Pod: 10.0.1.0/24
  • Red del Service: 10.0.2.0/24
  • Subredes de réplica del plano de control: 10.0.3.0/24, 10.0.4.0/2410.0.5.0/24

La siguiente configuración no es válida, ya que el rango de IP del Pod se superpone con la red del plano de control. Esta superposición puede evitar que las cargas de trabajo se comuniquen con la réplica del plano de control en la red de VNet:

  • Red de VNet: 10.0.0.0/16
  • Red del Pod: 10.0.1.0/24
  • Red del Service: 10.1.0.0/24
  • Subredes de réplica del plano de control: 10.0.1.0/24, 10.0.2.0/2410.0.3.0/24

Detalles sobre el rango de direcciones de Pods

Kubernetes asigna direcciones del rango de direcciones del Pod a los objetos Pod. El rango de Pods de un clúster se divide en rangos más pequeños para cada nodo. Cuando se programa un Pod en un nodo en particular, Kubernetes asigna una dirección IP de Pod desde el rango del nodo.

Para calcular el tamaño del rango de direcciones de Pods, debes estimar la cantidad de nodos que deseas ejecutar en tu clúster y la cantidad de Pods que deseas ejecutar en cada nodo.

En la siguiente tabla, se proporcionan recomendaciones de tamaño para los rangos de CIDR de Pod según la cantidad de nodos y Pods que quieres ejecutar.

Tabla de rangos de direcciones de Pods

Rango de direcciones de Pods Cantidad máx. de direcciones IP del pod Cant. máx. de nodos Cantidad máx. de pods
/24
El menor rango de direcciones de Pods posible
256 direcciones 1 nodo 110 pods
/23 512 direcciones 2 nodos 220 pods
/22 1,024 direcciones 4 nodos 440 pods
/21 2,048 direcciones 8 nodos 880 pods
/20 4,096 direcciones 16 nodos 1,760 pods
/19 8,192 direcciones 32 nodos 3,520 pods
/18 16,384 direcciones 64 nodos 7,040 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 1,024 nodos 112,640 pods

Detalles sobre el rango de direcciones del servicio

Kubernetes asigna direcciones IP virtuales a los objetos de servicio, por ejemplo, los balanceadores de cargas de este rango de direcciones.

Para calcular el tamaño del rango de direcciones de servicio, debes estimar la cantidad de servicios que deseas en el clúster.

En la siguiente tabla, se proporcionan recomendaciones de tamaño para los rangos de CIDR de servicio según la cantidad de servicios que quieras ejecutar.

Tabla de rangos de direcciones del servicio

Rango de direcciones de servicio Cantidad máxima de servicios
/27
El menor rango de direcciones del servicio posible
32 servicios
/26 64 servicios
/25 128 servicios
/24 256 servicios
/23 512 servicios
/22 1,024 servicios
/21 2,048 servicios
/20 4,096 servicios
/19 8,192 servicios
/18 16,384 servicios
/17 32,768 servicios
/16
El mayor rango de direcciones del servicio posible
65,536 servicios

Autentica en Azure

GKE en Azure proporciona dos métodos de autenticación en Azure: federación de identidades para cargas de trabajo y crea un certificado de cliente. La autenticación de la federación de identidades para cargas de trabajo es el método recomendado, porque es más simple y seguro.

Federación de identidades para cargas de trabajo

La federación de identidades de cargas de trabajo permite que GKE en Azure se autentique en Azure con una cuenta de servicio de Google para administrar recursos en la aplicación de Azure AD de forma posterior. En comparación con AzureClient, no es necesario administrar los certificados ni subirlos a Azure AD de forma manual.

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

  1. Guarda el ID de aplicación de Azure en las 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: Es el nombre de la credencial.
    • PROJECT_NUMBER: Es la cantidad del proyecto de Google Cloud 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
    

Si deseas obtener más detalles, consulta en la documentación de Azure la Federación de identidades para cargas 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 elige un par de claves SSH para tu clúster.

Crea 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 usar, omite este paso.

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

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

    Reemplaza 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 par de claves nuevo en ~/.ssh/anthos-multicloud-key.pub y almacenar la clave pública en una variable de entorno, ejecuta los siguientes comandos:

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

Después de guardar la clave pública en una variable de entorno, podrás crear un clúster.

Selecciona el proyecto host de la flota

Las flotas son un concepto de Google Cloud para organizar clústeres en grupos más grandes. Con las flotas, puedes administrar varios clústeres en varias nubes y aplicar políticas coherentes en ellos. La API de GKE Multi-cloud registra automáticamente tus clústeres en una flota cuando se crean.

Cuando creas un clúster, especificas un proyecto host de flota desde el que se administrará el clúster. Debido a que GKE en Azure usa el nombre del clúster como el nombre de la membresía de la flota, debes asegurarte de que estos sean únicos en tu flota.

Registro entre proyectos

Si deseas usar un proyecto host de flota distinto del proyecto de Google Cloud en el que se encuentra el clúster, debes aplicar una vinculación de política de IAM adicional a la cuenta de servicio del agente de servicio de múltiples nubes. Esto permite que la cuenta de servicio administre las flotas con el proyecto host de la flota.

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

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

    Reemplaza CLUSTER_PROJECT_NUMBER por el número de proyecto de Google Cloud.

  2. Asigna esta vinculación 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"
    

    Reemplaza lo siguiente:

    • FLEET_PROJECT_ID: El proyecto de Google Cloud de tu proyecto host de Fleet
    • CLUSTER_PROJECT_NUMBER: Es el número de tu proyecto de Google Cloud.

El nombre de la cuenta del agente de servicios de múltiples nubes 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 consola de Google Cloud. Para obtener más información sobre cómo encontrar el número de tu proyecto, consulta Identifica proyectos.

Crea un clúster

Para crear un clúster, ejecuta el siguiente comando:

  1. Guarda los ID de los grupos de recursos de Azure, VNet y las subredes en las 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)
    

    Reemplaza lo siguiente:

    • CLUSTER_RESOURCE_GROUP_NAME: Es un nombre de grupo de recursos existente en el que deseas ejecutar tu clúster.
    • VNET_RESOURCE_GROUP_NAME: Es el nombre del grupo de recursos que contiene tu VNet.
    • VNET_NAME: nombre de tu VNet
  2. Crea un clúster con la CLI de Google Cloud:

    Federación de identidades para 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.29.3-gke.600 \
        --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.29.3-gke.600 \
        --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
    

    Reemplaza lo siguiente:

    • CLUSTER_NAME: Es el nombre de tu clúster.
    • GOOGLE_CLOUD_LOCATION: Es la ubicación de Google Cloud que administra tus clústeres.
    • FLEET_PROJECT por el proyecto host fleet en el que se registrará el clúster. Si deseas administrar este clúster desde otro proyecto de Google Cloud, consulta Registro entre proyectos.
    • AZURE_REGION: Es una región de Azure compatible asociada a tu región de Google Cloud.
    • POD_CIDR: Es el rango de direcciones de Pods del clúster, por ejemplo, 10.0.1.0/18.
    • SERVICE_CIDR: Es el rango de direcciones de servicio del clúster.
    • VM_SIZE: un tamaño de VM de Azure compatible
    • ADMIN_USERS_LIST (opcional): Es una lista separada por comas de direcciones de correo electrónico de los usuarios a los que se les otorgan privilegios administrativos, por ejemplo, "kai@example.com,hao@example.com,kalani@example.com". La configuración predeterminada es el usuario que crea el clúster
    • CLIENT_NAME: es el nombre de AzureClient
  3. Verifica el estado de tu clúster:

    gcloud container azure clusters describe CLUSTER_NAME  --location GOOGLE_CLOUD_LOCATION
    

    Reemplaza lo siguiente:

    • CLUSTER_NAME
    • GOOGLE_CLOUD_LOCATION

    En el resultado, se incluye información sobre el estado y la configuración del clúster.

Autoriza Cloud Logging/Cloud Monitoring

Para que GKE en Azure cree y suba registros y métricas del sistema a Google Cloud, debe tener autorización.

Para autorizar la identidad de carga de trabajo de Kubernetes gke-system/gke-telemetry-agent a fin de 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

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

Esta vinculación de IAM otorga acceso a todos los clústeres del proyecto de Google Cloud para subir registros y métricas. Solo necesitas ejecutarlo después de crear tu primer clúster para el proyecto.

Nota: Agregar esta vinculación de IAM fallará, salvo que se cree al menos un clúster en tu proyecto de Google Cloud. Esto se debe a que el grupo de identidades para cargas 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 grupo de nodos, necesitas lo siguiente:

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

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

  1. Guarda tu ID de subred de Azure VNet y la clave pública SSH en las 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)
    

    Reemplaza lo siguiente:

    • VNET_RESOURCE_GROUP_NAME: nombre del grupo de recursos que contiene VNet.
    • VNET_NAME: nombre de tu VNet
    • KEY_PATH: ruta de acceso 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.29.3-gke.600 \
        --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}"
    

    Reemplaza lo siguiente:

    • NODE_POOL_NAME: un nombre único para el grupo de nodos, por ejemplo, node-pool-1.
    • CLUSTER_NAME: es el nombre de tu clúster de GKE en Azure
    • GOOGLE_CLOUD_LOCATION: es la ubicación de Google Cloud que administra tus clústeres
    • VM_SIZE: un tamaño de VM de Azure compatible
    • MIN_NODES: Es la cantidad mínima de nodos en el grupo de nodos. Para obtener más información, consulta Escalador automático de clúster.
    • MAX_NODES: cantidad máxima de nodos en el grupo de nodos
  3. Verifica el estado del grupo de nodos:

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

    Reemplaza lo siguiente:

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

    El resultado incluye el estado del grupo de nodos, incluso si es PROVISIONING o RUNNING.

¿Qué sigue?