crea un cluster

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

Prima di iniziare

Per completare la procedura indicata in questa pagina:

  1. Segui i passaggi in Configurare i prerequisiti.

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

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

Posizionamento a livello di zona del piano di controllo

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

Se vuoi utilizzare il posizionamento predefinito della replica del piano di controllo, vai a Selezionare intervalli CIDR per il cluster.

Piani di controllo del gateway e del cluster Azure NAT

Ogni replica del piano di controllo richiede anche la connettività al servizio di gestione ospitato da Google per funzionare in uno stato normale.

Se utilizzi il gateway Azure NAT per fornire la connettività in uscita, devi considerare l'impatto di un errore a livello di zona sul piano di controllo del cluster. Un endpoint gateway NAT è isolato in una singola zona o è a livello di regione/non zona e questo rappresenta un single point of failure.

Se vuoi collocare le repliche del piano di controllo in una singola zona, utilizza una subnet e una zona singole. Se utilizzi il gateway NAT per la connettività in uscita, assicurati che l'endpoint sia posizionato 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 posiziona due repliche nella prima zona fornita. Quando passi in tre subnet e zone, GKE su Azure posiziona le repliche in ogni subnet. Per maggiori informazioni, consulta Posizionare le repliche in una subnet specifica.

Per saperne di più sulla configurazione dell'alta disponibilità per subnet e zone Azure, consulta Isolamento delle zone con stack a livello di zona nella documentazione di Azure.

Posiziona le repliche in una subnet specifica

Questa sezione è facoltativa.

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

Per formattare l'elenco delle subnet, segui questi passaggi.

  1. Recupera i tuoi ID subnet 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 rete VNet
    • VNET_NAME: il nome della tua rete VNet
    • SUBNET_NAME: il nome della subnet

    L'output è l'ID della subnet. Gli ID subnet 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 la replica del piano di controllo. Copia gli ID subnet in un editor di testo per il passaggio seguente.

  2. Crea un elenco separato da virgole di ID subnet e zone di disponibilità 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 intervalli CIDR per il cluster

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

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

Consigliamo i seguenti intervalli CIDR per servizi e pod:

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

Questi intervalli sono sufficientemente grandi da consentirti di far crescere il cluster senza problemi.

Le seguenti sezioni forniscono ulteriori dettagli.

Dettagli sulla selezione degli intervalli

GKE su Azure utilizza una rete di overlay per pod e servizi, quindi gli intervalli IP per queste reti non devono essere instradabili all'interno della rete virtuale. La disponibilità di tutti gli intervalli IP utilizzati deve essere garantita. Per maggiori informazioni, consulta Dataplane V2.

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

  • L'intervallo IP di pod e 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 condivisi (RFC 6598)
    • 192.0.0.0/24: assegnazioni del 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: inoltro da IPv6 a IPv4 (deprecato) (RFC 7526)
    • 198.18.0.0/15 - Test di benchmark (RFC 2544)

Consigliamo di utilizzare intervalli IP compresi all'interno di 100.64.0.0/10 (RFC 6598). Questo intervallo è riservato al NAT di livello operatore, che probabilmente non è utilizzato nella tua rete VPC.

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

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

Anche quella seguente è una configurazione valida nonostante le reti di pod e servizi si sovrappongano alla rete VNet poiché non c'è sovrapposizione con le repliche del piano di controllo.

  • Rete VNet: 10.0.0.0/16
  • Rete di pod: 10.0.1.0/24
  • Rete di servizi: 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 dei pod si sovrappone alla rete del piano di controllo. Questa sovrapposizione potrebbe impedire ai carichi di lavoro di comunicare con la replica del piano di controllo nella rete VNet:

  • Rete VNet: 10.0.0.0/16
  • Rete di pod: 10.0.1.0/24
  • Rete di servizi: 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 dei pod

Kubernetes alloca 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 nodo specifico, Kubernetes assegna l'indirizzo IP di un 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 suggerimenti sulle dimensioni per gli intervalli CIDR dei pod in base al numero di nodi e pod che intendi eseguire.

Tabella degli intervalli di indirizzi dei pod

Intervallo di indirizzi del pod Numero massimo di indirizzi IP di pod Numero massimo di nodi Numero massimo di pod
/24
Intervallo di indirizzi dei pod più piccolo possibile		 256 indirizzi 1 nodo 110 pod
/23 512 indirizzi 2 nodi 220 pod
/22 1024 indirizzi 4 nodi 440 pod
/21 2048 indirizzi 8 nodi 880 pod
/20 4096 indirizzi 16 nodi 1760 pod
/19 8192 indirizzi 32 nodi 3520 pod
/18 16.384 indirizzi 64 nodi 7040 pod
/17 32.768 indirizzi 128 nodi 14.080 pod
/16 65.536 indirizzi 256 nodi 28.160 pod
/15 131.072 indirizzi 512 nodi 56.320 pod
/14 262.144 indirizzi 1024 nodi 112.640 pod

Dettagli sull'intervallo di indirizzi di servizio

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

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

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

Tabella degli intervalli di indirizzi dei servizi

Intervallo di indirizzi dei servizi Numero massimo di servizi
/27
Intervallo di indirizzi del servizio più piccolo possibile		 32 Servizi
/26 64 Servizi
/25 128 Servizi
/24 256 Servizi
/23 512 Servizi
/22 1024 servizi
/21 2048 servizi
/20 4096 servizi
/19 8192 Servizi
/18 16.384 servizi
/17 32.768 Servizi
/16
Intervallo di indirizzi di servizio più ampio possibile		 65.536 Servizi

Autenticazione in Azure

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

Federazione delle identità per i carichi di lavoro

La federazione di Workload Identity consente a GKE su Azure di eseguire l'autenticazione in Azure utilizzando un account di servizio Google per gestire successivamente le risorse nell'applicazione Azure AD. Rispetto ad AzureClient, non è necessario gestire i certificati e caricarli manualmente su Azure AD.

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

  1. Salva il tuo 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)")

  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 progetto Google Cloud 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 ulteriori dettagli, consulta la documentazione di Azure sulla Federazione delle identità dei carichi di lavoro di Azure AD con Google Cloud.

Puoi anche eseguire il provisioning della credenziale di 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. Archivia 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 archiviare la chiave pubblica in una variabile di ambiente, esegui questo 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 concetto di Google Cloud per organizzare i cluster in gruppi più grandi. I parchi risorse consentono di gestire più cluster su più cloud e applicare criteri coerenti tra di essi. L'API GKE Multi-Cloud registra automaticamente i cluster con un parco risorse al momento della creazione del cluster.

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

Registrazione tra progetti

Se vuoi utilizzare un progetto host del parco risorse diverso dal progetto Google Cloud in cui si trova il cluster, devi applicare un'associazione di criteri IAM aggiuntiva all'account di servizio dell'agente di servizio multi-cloud. Ciò consente all'account di servizio di gestire i parchi risorse con il progetto Fleet Host.

  1. Per aggiungere l'agente di servizio 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 del tuo progetto Google Cloud.

  2. Assegna questa associazione con il comando seguente:

    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 progetto Google Cloud del progetto host del parco risorse
    • CLUSTER_PROJECT_NUMBER: il numero del tuo progetto Google Cloud

Il nome dell'account dell'agente di servizio multi-cloud 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 console Google Cloud. Per scoprire di più su come trovare il numero del progetto, consulta Identificazione dei progetti.

crea un cluster

Per creare un cluster, esegui questi comandi:

  1. Salva gli ID gruppo di risorse, VNet e subnet 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 rete VNet
    • VNET_NAME: il nome della tua rete multicanale

  2. Crea un cluster con Google Cloud CLI:

    Federazione delle identità per i carichi di lavoro

    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

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

    Sostituisci quanto segue:

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

  3. Controlla lo stato del tuo 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

Per consentire a GKE su Azure di creare e caricare log di sistema e metriche su Google Cloud, è necessario che sia autorizzato.

Per autorizzare l'identità dei carichi di lavoro Kubernetes gke-system/gke-telemetry-agent a scrivere i log in Google Cloud Logging e le 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 progetto Google Cloud del cluster.

Questa associazione IAM concede l'accesso a tutti i cluster nel progetto di 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 riuscirà, a meno che non sia stato creato almeno un cluster nel progetto Google Cloud. 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 pool di nodi

Prima di creare un pool di nodi, è necessario quanto segue:

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

Per creare un pool di nodi, esegui questi comandi:

  1. Salva l'ID subnet Azure VNet 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 VNet
    • VNET_NAME: il nome della tua rete multicanale
    • 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.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}"

    Sostituisci quanto segue:

  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 tuo cluster GKE su Azure
    • GOOGLE_CLOUD_LOCATION: la località Google Cloud che gestisce il tuo cluster

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

Passaggi successivi