Crea un cluster

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

Prima di iniziare

Per completare i passaggi in questa pagina, procedi nel seguente modo:

  1. Segui i passaggi descritti in Configurare i prerequisiti.

  2. Scegli se eseguire il control plane 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 control plane

Per impostazione predefinita, GKE su Azure inserisce repliche del control plane 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 control plane, vai a Seleziona gli intervalli CIDR per il cluster.

Gateway NAT Azure e control plane del cluster

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

Se utilizzi il gateway NAT di Azure per fornire connettività in uscita, devi considerare in che modo un errore di zona influisce sul control plane del cluster. Un endpoint gateway NAT è isolato in una singola zona o è regionale/non zonale e questo rappresenta un singolo punto di errore.

Se vuoi posizionare le repliche del control plane in una singola zona, utilizza una singola subnet e zona. Se utilizzi NAT Gateway 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 passi tre subnet e zone, GKE su Azure inserisce le repliche in ogni subnet. Per saperne di più, consulta Inserire repliche in una subnet specifica.

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

Posizionare le repliche in una subnet specifica

Questa sezione è facoltativa.

Per controllare in quali zone vengono inserite le repliche del control plane, utilizza il flag --replica-placements e passa 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 control plane.

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

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

    L'output è l'ID della subnet. Gli ID subnet Azure sono simili ai seguenti:

    /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 control plane. Copia gli ID subnet 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 i due elementi separati da due punti. Ad esempio, per creare repliche del control plane 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 intervalli di indirizzi IPv4 da utilizzare per pod e servizi.

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

Ti consigliamo i seguenti intervalli CIDR per servizi e pod:

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

Questi intervalli sono abbastanza grandi da consentirti di espandere 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 VNet. Tutti gli intervalli IP che utilizzi devono essere garantiti disponibili. Per ulteriori informazioni, consulta Dataplane V2.

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

  • L'intervallo IP di pod e servizi 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 - Relè da IPv6 a IPv4 (ritirato) (RFC 7526)
    • 198.18.0.0/15: test di benchmark (RFC 2544)

Consigliamo intervalli IP all'interno di 100.64.0.0/10 (RFC 6598). Questo intervallo è riservato a NAT di livello operatore, che probabilmente non viene utilizzato nella tua VNet.

Ad esempio, la seguente è una configurazione valida in cui le reti Pod, Service e Node non si sovrappongono (la VNet utilizza indirizzi IP privati RFC 1918, mentre le reti Pod e Service 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 si sovrappongono alle 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 delle repliche del control plane: 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 VNet:

  • Rete VNet: 10.0.0.0/16
  • Rete pod: 10.0.1.0/24
  • Rete di servizio: 10.1.0.0/24
  • Subnet delle repliche del control plane: 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24

Dettagli sull'intervallo di indirizzi del 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 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 da eseguire su ogni nodo.

La seguente tabella fornisce consigli sulle dimensioni degli 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 del pod Numero massimo di nodi Numero massimo di pod
/24
Intervallo di indirizzi del pod più piccolo possibile		 256 indirizzi 1 nodo 110 pod
/23 512 indirizzi 2 nodi 220 Pods
/22 1024 indirizzi 4 nodi 440 Pods
/21 2048 indirizzi 8 nodi 880 Pods
/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 emergenza

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 del servizio, devi stimare il numero di servizi che vuoi nel cluster.

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

Tabella degli intervalli di indirizzi di emergenza

Intervallo di indirizzi dei servizi Numero massimo di servizi
/27
Intervallo di indirizzi dei servizi 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 dei servizi più grande possibile		 65.536 servizi

Esegui l'autenticazione in Azure

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

Federazione delle identità per i workload

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

Per configurare una credenziale federata di identità nell'applicazione Azure AD, esegui i seguenti comandi. 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)")

  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 maggiori dettagli, consulta la documentazione di Azure Federazione delle identità per i workload 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. 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 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 Google Cloud concetto per organizzare i cluster in gruppi più grandi. Con i parchi risorse, puoi gestire più cluster su più cloud e applicare criteri coerenti. L'API GKE Multi-Cloud registra automaticamente i cluster in un parco risorse quando viene creato il 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 di appartenenza al 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 binding dei criteri IAM aggiuntivo al account di servizio dell'agente di servizio multicloud. In questo modo, il account di servizio può gestire i parchi risorse con il progetto host del parco risorse.

  1. Per aggiungere l'agente di servizio al tuo 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 questo binding 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 progetto Google Cloud host del parco risorse
    • CLUSTER_PROJECT_NUMBER: il numero del tuo progetto Google Cloud

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

Puoi trovare i tuoi service account nella console Google Cloud nella pagina Service account. Per ulteriori informazioni su come trovare il numero di progetto, vedi Identificazione dei progetti.

Crea un cluster

Per creare un cluster, esegui questi comandi:

  1. Salva l'ID del gruppo di risorse Azure, della VNet e della subnet 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 tua 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.32.4-gke.200 \
    --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.32.4-gke.200 \
    --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 tuo cluster
    • GOOGLE_CLOUD_LOCATION: la Google Cloud posizione che gestisce il cluster
    • FLEET_PROJECT con il progetto host del parco risorse in cui verrà registrato il cluster. Se vuoi gestire questo cluster da un altro progettoGoogle Cloud , consulta la sezione Registrazione tra progetti.
    • AZURE_REGION: a supported Azure region associated to your Google Cloud region
    • POD_CIDR: l'intervallo di indirizzi dei pod del cluster, ad esempio 10.0.1.0/18
    • SERVICE_CIDR: l'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 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 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 su Azure possa creare e caricare log e metriche di sistema su Google Cloud, deve essere autorizzato.

Per autorizzare l'identità del workload 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 progetto Google Cloud del cluster.

Questo binding IAM concede l'accesso a tutti i cluster nel 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 tuo 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 provisionato 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 Azure.
  • Accesso alla chiave pubblica SSH del cluster.

Per creare un pool di nodi, esegui questi comandi:

  1. Salva l'ID subnet 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 tua 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.32.4-gke.200 \
    --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 cluster GKE su Azure
    • GOOGLE_CLOUD_LOCATION: la Google Cloud posizione che gestisce il tuo cluster

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

Passaggi successivi