Crea un cluster

Questa pagina spiega come creare un cluster e un pool di nodi in GKE su Azure su Kubernetes versione 1.31.4-gke.500.

Prima di iniziare

Per completare i passaggi in questa pagina, svolgi i seguenti passaggi:

1. Segui i passaggi descritti in Configurare i prerequisiti.

2. Scegli se eseguire il piano di controllo in più zone o in una sola zona.

3. Seleziona gli intervalli CIDR (Classless Inter-Domain Routing) da fornire al tuo cluster.

Posizionamento zonale del piano di controllo

Per impostazione predefinita, GKE on Azure posiziona repliche del piano di controllo separate nella stessa subnet in tre zone della regione selezionata. Puoi scegliere queste zone e subnet.

Se vuoi utilizzare il posizionamento predefinito delle repliche del piano di controllo, vai a Selezionare gli intervalli CIDR per il cluster.

Gateway NAT di Azure e control plane del cluster

Per funzionare in uno stato normale, ogni replica del control plane richiede anche la connettività al servizio di gestione ospitato da Google.

Se utilizzi il gateway Azure NAT per fornire connettività in uscita, devi considerare come un errore zonale influisce sul piano di controllo del cluster. Un endpoint del gateway NAT è isolato in una singola zona o è regionale/non zonale e rappresenta un single point of failure.

Se vuoi posizionare le repliche del piano di controllo in una singola zona, utilizza una singola subnet e una singola zona. Se utilizzi il gateway NAT per la connettività in uscita, assicurati che l'endpoint si trovi nella stessa zona.

Se vuoi posizionare le repliche in due o tre zone, puoi passare un elenco di subnet e zone quando crei un cluster. Quando passi due subnet e zone, GKE su Azure inserisce due repliche nella prima zona fornita. Quando specifichi tre subnet e zone, GKE on Azure inserisce le repliche in ogni subnet. Per ulteriori informazioni, consulta Posizionare le repliche in una sottorete specifica.

Per ulteriori informazioni sulla configurazione di subnet e zone di Azure per l'alta disponibilità, consulta Isolamento delle zone con gli stack zonali nella documentazione di Azure.

Posiziona le repliche in una subnet specifica

Questa sezione è facoltativa.

Per controllare le zone in cui vengono posizionate le repliche del piano di controllo, utilizza il flag --replica-placements e passa un elenco di ID subnet e zone quando crei il cluster. Puoi utilizzare fino a tre sottoreti e zone in cui posizionare le repliche del piano di controllo.

Per formattare l'elenco delle sottoreti, svolgi i seguenti passaggi.

1. Recupera gli ID subnet di Azure con lo strumento a riga di comando az:

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

   Sostituisci quanto segue:

   • CLUSTER_RESOURCE_GROUP_NAME: il nome di un gruppo di risorse esistente in cui vuoi eseguire il cluster
   • VNET_RESOURCE_GROUP_NAME: il nome del gruppo di risorse che contiene la tua VNet
   • VNET_NAME: il nome della VNet
   • SUBNET_NAME: il nome della subnet

   L'output è l'ID della subnet. Gli ID subnet di Azure sono simili al seguente:

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

   Ripeti questo comando per ogni subnet in cui vuoi creare una replica del piano di controllo. Copia gli ID sottorete in un editor di testo per il passaggio successivo.

2. Crea un elenco separato da virgole di ID subnet e zone di disponibilità di Azure, con due punti che separano la subnet e la zona. Ad esempio, per creare repliche del piano di controllo in subnet1 nella zona 1, subnet2 nella zona 2 e subnet3 nella zona 3, utilizza la seguente stringa:

   /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 questa stringa e utilizzala come valore per il flag --replica-placements quando crei un cluster.

Seleziona gli intervalli CIDR per il cluster

Quando crei un cluster in GKE su Azure, devi fornire gli intervalli di indirizzi IPv4 da utilizzare per i pod e i servizi.

Questi intervalli IP vengono specificati utilizzando la notazione Classless Inter-Domain Routing (CIDR), ad esempio 100.64.0.0/16.

Fasce consigliate

Ti consigliamo i seguenti intervalli CIDR per i servizi e i pod:

• Servizi: 100.64.0.0/16
• Pod: 100.96.0.0/11

Questi intervalli sono sufficientemente ampi per consentirti di far crescere il cluster senza problemi.

Le seguenti sezioni forniscono ulteriori dettagli.

Dettagli sulla selezione degli intervalli

GKE on Azure utilizza una rete overlay per i pod e i servizi, pertanto gli intervalli IP di queste reti non devono essere instradabili all'interno della VNet. Gli eventuali intervalli IP utilizzati devono essere garantiti disponibili. Per ulteriori informazioni, consulta Dataplane V2.

• Gli intervalli IP dei pod e dei servizi possono sovrapporsi alla rete della VNet, a condizione che non includano gli intervalli IP del piano di controllo o della sottorete del pool di nodi.

• L'intervallo IP del pod e del servizio deve rientrare in uno dei seguenti intervalli IP privati:

  • 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16: indirizzi IP privati (RFC 1918)
  • 100.64.0.0/10 - Spazio di indirizzi condiviso (RFC 6598)
  • 192.0.0.0/24 - Assegnazioni di protocollo IETF (RFC 6890)
  • 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 - Documentazione (RFC 5737)
  • 192.88.99.0/24 - Relay da IPv6 a IPv4 (non più supportato) (RFC 7526)
  • 198.18.0.0/15 - Test di benchmark (RFC 2544)

Consigliamo intervalli IP compresi tra 100.64.0.0/10 (RFC 6598). Questo intervallo è riservato per il NAT di livello operatore, che probabilmente non viene utilizzato nella tua VNet.

Ad esempio, la seguente è una configurazione valida in cui le reti di pod, servizio e nodi non si sovrappongono (la VNet utilizza indirizzi IP privati RFC 1918, mentre le reti di pod e servizio sono sovrapposte agli IP privati RFC 6598).

• Rete VNet: 10.0.0.0/16, 172.16.1.0/24, 172.16.2.0/24
• Rete pod: 100.65.0.0/16
• Rete di servizio: 100.66.0.0/16

Anche la seguente è una configurazione valida, nonostante le reti di pod e servizi si sovrappongano alla rete VNet, poiché non vi è sovrapposizione con le repliche del control plane.

• Rete VNet: 10.0.0.0/16
• Rete pod: 10.0.1.0/24
• Rete di servizio: 10.0.2.0/24
• Subnet di replica del piano di controllo: 10.0.3.0/24, 10.0.4.0/24, 10.0.5.0/24

La seguente configurazione è non valida, perché l'intervallo IP del pod si sovrappone alla rete del control plane. Questa sovrapposizione potrebbe impedire ai carichi di lavoro di comunicare con la replica del control plane nella rete della VNet:

• Rete VNet: 10.0.0.0/16
• Rete pod: 10.0.1.0/24
• Rete di servizio: 10.1.0.0/24
• Subnet di replica del piano di controllo: 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24

Dettagli sull'intervallo di indirizzi del pod

Kubernetes assegna gli indirizzi agli oggetti Pod dall'intervallo di indirizzi dei pod. L'intervallo di pod di un cluster è suddiviso in intervalli più piccoli per ciascun nodo. Quando un pod viene pianificato su un determinato nodo, Kubernetes assegna un indirizzo IP del pod dall'intervallo del nodo.

Per calcolare le dimensioni dell'intervallo di indirizzi dei pod, devi stimare il numero di nodi che vuoi nel cluster e il numero di pod che vuoi eseguire su ciascun nodo.

La tabella seguente fornisce consigli sulle dimensioni per gli intervalli CIDR dei pod in base al numero di nodi e pod che intendi eseguire.

Dettagli sull'intervallo di indirizzi dei servizi

Kubernetes alloca indirizzi IP virtuali per gli oggetti Service, ad esempio i bilanciatori del carico, da questo intervallo di indirizzi.

Per calcolare le dimensioni dell'intervallo di indirizzi di servizio, devi stimare il numero di servizi che vuoi nel cluster.

La tabella seguente fornisce consigli sulle dimensioni per gli intervalli CIDR dei servizi in base al numero di servizi che intendi eseguire.

Esegui l'autenticazione in Azure

GKE on Azure offre due metodi per l'autenticazione in Azure: la federazione delle identità per i carichi di lavoro e la creazione di un certificato client. L'autenticazione tramite federazione delle identità per i workload è il metodo consigliato, perché è più semplice e sicuro.

Federazione delle identità per i workload

La federazione delle identità per i carichi di lavoro consente a GKE su Azure di autenticarsi su Azure utilizzando un account di servizio Google, in modo da gestire successivamente le risorse nell'applicazione Azure AD. Rispetto ad AzureClient, non è necessario gestire i certificati e caricarli manualmente in Azure AD.

Per configurare una credenziale di identità federata nell'applicazione Azure AD, esegui i comandi seguenti. Tieni presente che puoi aggiungere fino a 20 credenziali a ogni applicazione Azure AD.

1. Salva l'ID applicazione Azure nelle variabili di ambiente:

   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: il nome dell'applicazione Azure AD che hai utilizzato per creare un'applicazione Azure Active Directory.

2. Crea un file JSON denominato 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: il nome della credenziale.
   • PROJECT_NUMBER: il numero del Google Cloud progetto che ospita il cluster.

3. Crea una credenziale di identità federata nell'applicazione Azure AD:

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

Per maggiori dettagli, consulta la documentazione di Azure sulla federazione delle identità per i workload di Azure AD con Google Cloud.

Puoi anche eseguire il provisioning della credenziale dell'identità federata di Azure utilizzando Terraform. Per maggiori dettagli, vedi azuread_application_federated_identity_credential.

Dopo aver configurato le credenziali, crea o seleziona una coppia di chiavi SSH per il cluster.

Crea una coppia di chiavi SSH

Quando crei un cluster, devi fornire una coppia di chiavi SSH. Se hai già una coppia di chiavi da utilizzare, salta questo passaggio.

1. Per creare una nuova coppia di chiavi, utilizza lo strumento a riga di comando ssh-keygen:

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

   Sostituisci KEY_PATH con il percorso della nuova chiave privata.

2. Memorizza la chiave in una variabile di ambiente:

   SSH_PUBLIC_KEY=$(cat KEY_PATH.pub)
   

   Ad esempio, per creare una nuova coppia di chiavi in ~/.ssh/anthos-multicloud-key.pub e memorizzare la chiave pubblica in una variabile di ambiente, esegui il seguente comando:

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

Dopo aver salvato la chiave pubblica in una variabile di ambiente, puoi creare un cluster.

Seleziona il progetto host del parco risorse

I parchi risorse sono un Google Cloud concetto per organizzare i cluster in gruppi più grandi. Con i parchi risorse, puoi gestire più cluster su diversi cloud e applicare criteri coerenti a tutti. L'API GKE Multi-Cloud registra automaticamente i cluster in un parco risorse al momento della creazione.

Quando crei un cluster, specifichi un progetto host del parco risorse da cui verrà gestito il cluster. Poiché GKE on Azure utilizza il nome del cluster come nome dell'appartenenza al parco risorse, devi assicurarti che i nomi dei cluster siano univoci nel parco risorse.

Registrazione tra progetti

Se vuoi utilizzare un progetto host di Fleet diverso dal Google Cloud progetto in cui si trova il cluster, devi applicare un'associazione di criteri IAM aggiuntiva all'account di servizio Multi-Cloud Service Agent. In questo modo, l'account di servizio può gestire i parchi risorse con il progetto host del parco risorse.

1. Per aggiungere Service Agent al progetto, esegui questo comando:

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

   Sostituisci CLUSTER_PROJECT_NUMBER con il numero Google Cloud del tuo progetto.

2. Assegna questa associazione con il seguente 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"
   

   Sostituisci quanto segue:

   • FLEET_PROJECT_ID: il progettoGoogle Cloud del tuo progetto host del parco risorse
   • CLUSTER_PROJECT_NUMBER: il numero del Google Cloud progetto

Il nome dell'account agente di servizio multicloud ha il seguente formato: service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com.

Puoi trovare i tuoi account di servizio nella pagina Account di servizio della Google Cloud console. Per scoprire di più su come trovare il numero di progetto, consulta la sezione Identificazione dei progetti.

Crea un cluster

Per creare un cluster, esegui i seguenti comandi:

1. Salva gli ID gruppo di risorse, VNet e sottorete di Azure nelle variabili di ambiente:

   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)
   

   Sostituisci quanto segue:

   • CLUSTER_RESOURCE_GROUP_NAME: il nome di un gruppo di risorse esistente in cui vuoi eseguire il cluster
   • VNET_RESOURCE_GROUP_NAME: il nome del gruppo di risorse che contiene la tua VNet
   • VNET_NAME: il nome della VNet

2. Crea un cluster con Google Cloud CLI:

   Federazione delle identità per i workload

   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
   

   Client 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
   

   Sostituisci quanto segue:

   • CLUSTER_NAME: il nome del cluster
   • GOOGLE_CLOUD_LOCATION: la Google Cloud posizione che gestisce il tuo cluster
   • FLEET_PROJECT con il progetto host del parco risorse in cui verrà registrato il cluster. Se vuoi gestire questo cluster da un altroGoogle Cloud progetto, consulta la sezione Registrazione tra progetti.
   • AZURE_REGION: una regione Azure supportata associata alla tua Google Cloud regione
   • POD_CIDR: l'intervallo di indirizzi dei pod del tuo cluster, ad esempio 10.0.1.0/18
   • SERVICE_CIDR: Intervallo di indirizzi dei servizi del tuo cluster
   • VM_SIZE: una dimensione VM Azure supportata
   • ADMIN_USERS_LIST (facoltativo): un elenco separato da virgole degli indirizzi email degli utenti a cui concedere i privilegi amministrativi, ad esempio "kai@example.com,hao@example.com,kalani@example.com". Valore predefinito: l'utente che crea il cluster
   • CLIENT_NAME: il nome del tuo AzureClient

3. Controlla lo stato del cluster:

   gcloud container azure clusters describe CLUSTER_NAME  --location GOOGLE_CLOUD_LOCATION
   

   Sostituisci quanto segue:

   • CLUSTER_NAME
   • GOOGLE_CLOUD_LOCATION

   L'output include informazioni sullo stato e sulla configurazione del cluster.

Autorizza Cloud Logging / Cloud Monitoring

Affinché GKE on Azure possa creare e caricare log e metriche di sistema suGoogle Cloud, deve essere autorizzato.

Per autorizzare l'identità del carico di lavoro Kubernetes gke-system/gke-telemetry-agent a scrivere log in Google Cloud Logging e metriche in Google Cloud Monitoring, esegui questo 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

Sostituisci GOOGLE_PROJECT_ID con l'ID Google Cloud del progetto del cluster.

Questa associazione IAM concede l'accesso a tutti i cluster del progetto Google Cloud per caricare log e metriche. Devi eseguirlo solo dopo aver creato il primo cluster per il progetto.

L'aggiunta di questa associazione IAM non andrà a buon fine a meno che non sia stato creato almeno un cluster nel tuo Google Cloud progetto. Questo perché il pool di identità per i carichi di lavoro a cui fa riferimento (GOOGLE_PROJECT_ID.svc.id.goog) non viene eseguito fino alla creazione del cluster.

Crea un node pool

Prima di creare un pool di nodi, devi disporre di quanto segue:

• Autorizzazioni per utilizzare lo strumento a riga di comando az per recuperare un ID subnet di Azure.
• Accesso alla chiave pubblica SSH del cluster.

Per creare un pool di nodi, esegui i seguenti comandi:

1. Salva l'ID sottorete della VNet di Azure e la chiave pubblica SSH nelle variabili di ambiente:

   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)
   

   Sostituisci quanto segue:

   • VNET_RESOURCE_GROUP_NAME: il nome del gruppo di risorse che contiene la VNet
   • VNET_NAME: il nome della VNet
   • KEY_PATH: il percorso della coppia di chiavi

2. Crea un pool di nodi con Google Cloud CLI:

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

   Sostituisci quanto segue:

   • NODE_POOL_NAME: un nome univoco per il pool di nodi, ad esempio node-pool-1
   • CLUSTER_NAME: il nome del cluster GKE su Azure
   • GOOGLE_CLOUD_LOCATION: la Google Cloud location che gestisce il tuo cluster
   • VM_SIZE: una dimensione VM Azure supportata
   • MIN_NODES: il numero minimo di nodi nel node pool. Per ulteriori informazioni, consulta Cluster Autoscaler
   • MAX_NODES: il numero massimo di nodi nel pool di nodi

3. Controlla lo stato del pool di nodi:

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

   Sostituisci quanto segue:

   • NODE_POOL_NAME: un nome univoco per il pool di nodi, ad esempio node-pool-1
   • CLUSTER_NAME: il nome del cluster GKE su Azure
   • GOOGLE_CLOUD_LOCATION: la Google Cloud location che gestisce il tuo cluster

   L'output include lo stato del tuo pool di nodi, ad esempio se è PROVISIONING o RUNNING.

Passaggi successivi

• Configura l'accesso ai cluster per kubectl.
• Crea un pool di nodi.
• Prova la guida rapida per lanciare il tuo primo carico di lavoro.
• Leggi la documentazione di riferimento per gcloud container clusters create.
• Hai riscontrato un problema durante la creazione di un cluster? Per ulteriori informazioni, consulta la sezione Risoluzione dei problemi.