Esta documentación es para la versión más reciente de GKE en Azure, que se lanzó en noviembre de 2021. Consulta las notas de la versión para obtener más información.

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:

Sigue los pasos de la página Configura los requisitos.
Elige si ejecutarás el plano de control en varias zonas o en una sola.
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.

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.

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.

Rangos recomendados

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/24, 10.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/24, 10.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.

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

APPLICATION_NAME: Es el nombre de la aplicación de Azure AD que usaste cuando creaste una aplicación de Azure Active Directory.

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.

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.

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

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

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

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
Nota: Cuando creas un clúster, puedes pasar los siguientes tres campos opcionales en lugar del campo “--subnet-id” :
- --endpoint-subnet-id: la subred en la que GKE en Azure implementa el extremo del balanceador de cargas del plano de control. Si no especificas un valor, el valor predeterminado es “subnet-id”.
- --service-load-balancer-subnet-id: Es la subred en la que se implementan los balanceadores de cargas de tipo de servicio privados de Kubernetes. Si no especificas un valor, el valor predeterminado es “subnet-id”.
- --replica-placements
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:

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

Debes configura el acceso de kubectl al clúster.
Crea un grupo de nodos.
Prueba la Guía de inicio rápido para iniciar tu primera carga de trabajo.
Lee la documentación de referencia de gcloud container clusters create.
¿Tuviste problemas para crear un clúster? Consulta Solución de problemas para obtener más información.

Crea un clúster

Antes de comenzar

Ubicación zonal del plano de control

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

Ubica réplicas en una subred específica

Selecciona rangos CIDR para el clúster

Rangos recomendados

Detalles sobre cómo elegir rangos

Detalles sobre el rango de direcciones de Pods

Detalles sobre el rango de direcciones del servicio

Autentica en Azure

Federación de identidades para cargas de trabajo

Crea un par de claves SSH.

Selecciona el proyecto host de la flota

Registro entre proyectos

Crea un clúster

Federación de identidades para cargas de trabajo

Cliente de Azure

Autoriza Cloud Logging/Cloud Monitoring

Crear un grupo de nodos

¿Qué sigue?