Crear un clúster

Esta página explica cómo crear un clúster y un grupo de nodos en GKE en Azure en Kubernetes versión 1.31.4-gke.500.

Antes de empezar

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

1. Siga los pasos que se indican en Configurar requisitos previos .

2. Elija si desea ejecutar el plano de control en varias zonas o en una sola.

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

Ubicación zonal del plano de control

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

Si desea utilizar la ubicación de réplica del plano de control predeterminada, salte a Seleccionar rangos de CIDR para su clúster .

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

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

Si usa una puerta de enlace NAT de Azure para proporcionar conectividad saliente, debe considerar cómo un fallo zonal afecta el plano de control del clúster. Un punto de conexión de la puerta de enlace NAT está aislado en una sola zona o es regional/no zonal, lo que representa un único punto de fallo.

Si desea colocar réplicas del plano de control en una sola zona, utilice una sola subred y zona. Si utiliza una puerta de enlace NAT para la conectividad saliente, asegúrese de que el punto final esté ubicado en la misma zona.

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

Para obtener más información sobre cómo configurar subredes y zonas de Azure para alta disponibilidad, consulte Aislamiento de zona con pilas zonales en la documentación de Azure.

Coloque réplicas en una subred específica

Esta sección es opcional.

Para controlar las zonas donde se ubican las réplicas del plano de control, utilice el indicador --replica-placements y pase una lista de ID de subred y zonas al crear el clúster. Puede usar hasta tres subredes y zonas para ubicar las réplicas del plano de control.

Para formatear la lista de subredes, realice los siguientes pasos.

1. Recupere sus identificadores de 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
   

   Reemplace lo siguiente:

   • CLUSTER_RESOURCE_GROUP_NAME : un nombre de grupo de recursos existente donde desea ejecutar su clúster
   • VNET_RESOURCE_GROUP_NAME : el nombre del grupo de recursos que contiene su VNet
   • VNET_NAME : el nombre de su VNet
   • SUBNET_NAME : su nombre de subred

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

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

   Repita este comando para cada subred donde desee crear una réplica del plano de control. Copie los ID de subred en un editor de texto para el siguiente paso.

2. Cree una lista separada por comas de los ID de subred y las zonas de disponibilidad de Azure, con dos puntos separando la subred y la zona. Por ejemplo, para crear réplicas del plano de control en subnet1 de la zona 1, subnet2 de la zona 2 y subnet3 de la zona 3, use 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
   

   Copie esta cadena y utilícela como valor para el indicador --replica-placements cuando cree un clúster .

Seleccione rangos CIDR para su clúster

Cuando crea un clúster en GKE en Azure, debe proporcionar rangos de direcciones IPv4 para usar en pods y servicios.

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

Rangos recomendados

Recomendamos los siguientes rangos de CIDR para servicios y pods:

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

Estos rangos son lo suficientemente amplios para permitirle hacer crecer su clúster sin ningún problema.

Las siguientes secciones proporcionan más detalles.

Detalles sobre la selección de rangos

GKE en Azure usa una red superpuesta para pods y servicios, por lo que no es necesario enrutar los rangos de IP de estas redes dentro de la red virtual. Debe garantizarse la disponibilidad de todos los rangos de IP que use. Para obtener más información, consulte Dataplane V2 .

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

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

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

Recomendamos rangos de IP dentro de 100.64.0.0/10 (RFC 6598). Este rango está reservado para NAT de nivel de operador, que probablemente no se utilice en su red virtual.

Por ejemplo, la siguiente es una configuración válida donde las redes Pod, Service y Node no se superponen (la VNet usa direcciones IP privadas RFC 1918, mientras que las redes Pod y Service se superponen en IP privadas RFC 6598).

• Red virtual: 10.0.0.0/16 , 172.16.1.0/24 , 172.16.2.0/24
• Red de pods: 100.65.0.0/16
• Red de servicio: 100.66.0.0/16

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

• Red VNet: 10.0.0.0/16
• Red de pods: 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 , 10.0.5.0/24

La siguiente configuración no es válida porque el rango de IP del pod se superpone con la red del plano de control. Esta superposición podría impedir que las cargas de trabajo se comuniquen con la réplica del plano de control en la red virtual.

• Red VNet: 10.0.0.0/16
• Red de pods: 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 , 10.0.3.0/24

Detalles sobre el rango de direcciones del Pod

Kubernetes asigna direcciones a los objetos Pod dentro de su rango de direcciones. 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 específico, Kubernetes le asigna una dirección IP del rango de ese nodo.

Para calcular el tamaño del rango de direcciones de Pod, debe estimar la cantidad de nodos que desea en su clúster y la cantidad de Pods que desea ejecutar en cada nodo.

La siguiente tabla proporciona recomendaciones de tamaño para los rangos de CIDR de Pod en función de la cantidad de nodos y Pods que desea ejecutar.

Detalles sobre el rango de direcciones del servicio

Kubernetes asigna direcciones IP virtuales para objetos de servicio (por ejemplo, balanceadores de carga de este rango de direcciones).

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

La siguiente tabla proporciona recomendaciones de tamaño para los rangos de CIDR de servicio en función de la cantidad de servicios que desea ejecutar.

Autenticarse en Azure

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

Federación de identidades de carga de trabajo

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

Para configurar una credencial de identidad federada en su aplicación de Azure AD, ejecute los siguientes comandos. Tenga en cuenta que puede agregar hasta veinte credenciales a cada aplicación de Azure AD.

1. Guarde el ID de su 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)")
   

   • APPLICATION_NAME : el nombre de la aplicación de Azure AD que utilizó al crear una aplicación de Azure Active Directory .

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 : el número del Google Cloud proyecto que aloja el cluster.

3. Cree 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 detalles, consulte la documentación de Azure Federación de identidades de carga de trabajo de Azure AD con Google Cloud .

También puede aprovisionar la credencial de identidad federada de Azure mediante Terraform. Para obtener más información, consulte azuread_application_federated_identity_credential .

Después de configurar las credenciales, cree o seleccione un par de claves SSH para su clúster.

Crear un par de claves ssh

Al crear un clúster, debe proporcionar un par de claves SSH. Si ya tiene un par de claves para usar, omita este paso.

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

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

   Reemplace KEY_PATH con la ruta a su nueva clave privada.

2. Almacene 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, ejecute 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)
   

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

Seleccione su proyecto anfitrión de Fleet

Las flotas son unaGoogle Cloud Concepto para organizar clústeres en grupos más grandes. Con las flotas, puede administrar varios clústeres en varias nubes y aplicar políticas coherentes entre ellos. La API Multi-Cloud de GKE registra automáticamente sus clústeres con una flota al crearlos.

Al crear un clúster, se especifica un proyecto de host de Fleet desde el que se administrará. Dado que GKE en Azure usa el nombre del clúster como nombre de pertenencia de Fleet, debe asegurarse de que los nombres de los clústeres sean únicos en toda la Fleet.

Registro entre proyectos

Si desea utilizar un proyecto de Fleet Host distinto del Google Cloud En el proyecto donde se ubica el clúster, debe aplicar una política de IAM adicional a la cuenta de servicio del Agente de Servicio Multi-Cloud. Esto permite que la cuenta de servicio administre flotas con el proyecto host de flotas.

1. Para agregar el Agente de Servicio a su proyecto, ejecute este comando:

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

   Reemplace CLUSTER_PROJECT_NUMBER con su Google Cloud número de proyecto.

2. Asigne 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"
   

   Reemplace lo siguiente:

   • FLEET_PROJECT_ID : el proyecto host de su flotaGoogle Cloud proyecto
   • CLUSTER_PROJECT_NUMBER : su Google Cloud número de proyecto

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

Puede encontrar sus cuentas de servicio en la Google Cloud Página de la cuenta de servicio de la consola. Para obtener más información sobre cómo encontrar el número de proyecto, consulte Identificación de proyectos .

Crear un clúster

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

1. Guarde los identificadores de subred, red virtual y grupo de recursos 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)
   

   Reemplace lo siguiente:

   • CLUSTER_RESOURCE_GROUP_NAME : un nombre de grupo de recursos existente donde desea ejecutar su clúster
   • VNET_RESOURCE_GROUP_NAME : el nombre del grupo de recursos que contiene su VNet
   • VNET_NAME : el nombre de su VNet

2. Cree un clúster con la CLI de Google Cloud:

   Federación de identidades de carga 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.31.4-gke.500 \
       --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.31.4-gke.500 \
       --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
   

   Reemplace lo siguiente:

   • CLUSTER_NAME : el nombre de su clúster
   • GOOGLE_CLOUD_LOCATION : la Google Cloud ubicación que administra su clúster
   • FLEET_PROJECT con el proyecto host de la flota donde se registrará el clúster. Si desea administrar este clúster desde otro...Google Cloud proyecto, véase Registro entre proyectos .
   • AZURE_REGION : una región de Azure compatible asociada a su Google Cloud región
   • POD_CIDR : rango de direcciones de pod de su clúster; por ejemplo, 10.0.1.0/18
   • SERVICE_CIDR : rango de direcciones de servicio de su clúster
   • VM_SIZE : un tamaño de máquina virtual de Azure compatible
   • ADMIN_USERS_LIST (opcional): una lista separada por comas de las direcciones de correo electrónico de los usuarios a los que se otorgarán privilegios administrativos; por ejemplo, "kai@example.com,hao@example.com,kalani@example.com". El valor predeterminado es el usuario que creó el clúster.
   • CLIENT_NAME : su nombre de cliente de Azure

3. Comprueba el estado de tu clúster:

   gcloud container azure clusters describe CLUSTER_NAME  --location GOOGLE_CLOUD_LOCATION
   

   Reemplace lo siguiente:

   • CLUSTER_NAME
   • GOOGLE_CLOUD_LOCATION

   La salida incluye información sobre el estado y la configuración de su clúster.

Autorizar el registro en la nube/monitoreo en la nube

Para que GKE en Azure pueda crear y cargar registros y métricas del sistema enGoogle Cloud, debe estar autorizado.

Para autorizar la identidad de carga de trabajo de Kubernetes gke-system/gke-telemetry-agent a escribir registros en Google Cloud Registro y métricas para Google Cloud Para monitorear, ejecute 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

Reemplace GOOGLE_PROJECT_ID con el clúster Google Cloud Identificación del proyecto.

Este enlace de IAM otorga acceso a todos los clústeres en el Google Cloud Proyecto para cargar registros y métricas. Solo necesitas ejecutarlo después de crear el primer clúster del proyecto.

Agregar este enlace de IAM fallará a menos que se haya creado al menos un clúster en su 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 la creación del clúster.

Crear un grupo de nodos

Antes de crear un grupo de nodos, necesita lo siguiente:

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

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

1. Guarde el identificador 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)
   

   Reemplace lo siguiente:

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

2. Cree un grupo de nodos con la CLI de Google Cloud:

   gcloud container azure node-pools create NODE_POOL_NAME \
       --cluster CLUSTER_NAME \
       --location GOOGLE_CLOUD_LOCATION \
       --node-version 1.31.4-gke.500 \
       --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}"
   

   Reemplace lo siguiente:

   • NODE_POOL_NAME : un nombre único para su grupo de nodos, por ejemplo, node-pool-1
   • CLUSTER_NAME : el nombre de su clúster de GKE en Azure
   • GOOGLE_CLOUD_LOCATION : la Google Cloud ubicación que administra su clúster
   • VM_SIZE : un tamaño de máquina virtual de Azure compatible
   • MIN_NODES : el número mínimo de nodos en el grupo de nodos; para obtener más información, consulte Escalador automático de clúster
   • MAX_NODES : el número máximo de nodos en el grupo de nodos

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
   

   Reemplace lo siguiente:

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

   La salida incluye el estado de su grupo de nodos, incluso si está en PROVISIONING o RUNNING .

¿Qué sigue?

• Configurar el acceso al clúster para kubectl .
• Crear un grupo de nodos .
• Pruebe el inicio rápido para iniciar su primera carga de trabajo.
• Lea la documentación de referencia para gcloud container clusters create .
• ¿Tuviste algún problema al crear un clúster? Consulta la sección "Solución de problemas" para obtener más información.