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 VNetSUBNET_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 ysubnet3
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
y192.168.0.0/16
: Direcciones IP privadas de RFC 1918100.64.0.0/10
: Espacio de direcciones compartidas de RFC 6598192.0.0.0/24
: Asignaciones de protocolo IETF de RFC 6890192.0.2.0/24
,198.51.100.0/24
y203.0.113.0/24
: Documentación de RFC 5737192.88.99.0/24
: Retransmisión de IPv6 a IPv4 (obsoleta) de RFC 7526198.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 FleetCLUSTER_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 compatibleADMIN_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ústerCLIENT_NAME
: es el nombre de AzureClient
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 VNetKEY_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 AzureGOOGLE_CLOUD_LOCATION
: es la ubicación de Google Cloud que administra tus clústeresVM_SIZE
: un tamaño de VM de Azure compatibleMIN_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 AzureGOOGLE_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
oRUNNING
.
¿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.