Crea un cluster

Questa pagina descrive come creare un cluster GKE su AWS. Puoi anche creare un VPC e un cluster con Terraform.

Prima di iniziare

Prima di creare un cluster, devi completare i prerequisiti. In particolare, devi fornire le seguenti risorse:

  • Un VPC AWS in cui verrà eseguito il cluster.
  • Fino a tre subnet AWS per le tre repliche del piano di controllo. Ciascuno deve trovarsi in una zona di disponibilità AWS diversa.
  • Il ruolo AWS IAM che GKE su AWS assume durante la gestione del cluster. Ciò richiede un set specifico di autorizzazioni IAM.
  • Chiavi CMK simmetriche KMS per la crittografia at-rest dei dati del cluster (etcd) e della configurazione.
  • Il profilo dell'istanza AWS IAM per ogni replica del piano di controllo. Ciò richiede un insieme specifico di autorizzazioni IAM.
  • Una coppia di chiavi SSH EC2 (facoltativa) se hai bisogno dell'accesso SSH alle istanze EC2 che eseguono ogni replica del piano di controllo.

È tua responsabilità creare e gestire queste risorse, che possono essere condivise tra tutti i tuoi cluster GKE. Tutte le altre risorse AWS con ambito cluster sottostanti sono gestite da GKE su AWS.

Seleziona gli intervalli CIDR per il cluster

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

Questi intervalli IP vengono specificati utilizzando la notazione 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 abbastanza grandi da consentirti di far crescere il tuo cluster senza problemi.

Le seguenti sezioni forniscono ulteriori dettagli.

Dettagli sulla selezione degli intervalli

GKE su AWS utilizza una rete overlay per pod e servizi, quindi non è necessario che gli intervalli IP per queste reti siano instradabili all'interno del VPC. Qualsiasi intervallo IP che utilizzi deve essere garantito e disponibile. Per maggiori informazioni, consulta Dataplane V2.

  • Gli intervalli IP di pod e servizi possono sovrapporsi alla rete VPC, a condizione che non includano gli intervalli IP di 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 condiviso (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 usare intervalli IP compresi all'interno del valore 100.64.0.0/10 (RFC 6598). Questo intervallo è riservato per NAT di livello operatore, che probabilmente non è utilizzato nel tuo VPC.

Ad esempio, di seguito è riportata una configurazione valida in cui le reti di pod, servizi e nodi non si sovrappongono (il VPC utilizza indirizzi IP privati RFC 1918, mentre le reti di pod e servizi sono sovrapposte agli IP privati RFC 6598).

  • Rete VPC: 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

Quella seguente è anche una configurazione valida nonostante le reti di pod e servizi si sovrappongano alla rete VPC, poiché non esiste una sovrapposizione con le repliche del piano di controllo.

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

  • Rete VPC: 10.0.0.0/16
  • Rete di pod: 10.0.1.0/24
  • Rete di servizi: 10.1.0.0/24
  • Subnet della 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 ogni nodo. Quando un pod viene pianificato su un determinato nodo, Kubernetes assegna un indirizzo IP 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 del servizio

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

Per calcolare la dimensione dell'intervallo di indirizzi dei servizi, devi stimare il numero di servizi che vuoi nel tuo cluster.

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

Tabella degli intervalli di indirizzi di servizio

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 1.024 servizi
/21 2.048 servizi
/20 4.096 servizi
/19 8.192 servizi
/18 16.384 servizi
/17 32.768 servizi
/16
Il più grande intervallo di indirizzi di servizio possibile		 65.536 Servizi

Seleziona il progetto host del parco risorse

I parchi risorse sono un concetto di Google Cloud per organizzare i cluster in gruppi più grandi. Con i parchi risorse, puoi gestire più cluster su diversi cloud e applicare criteri coerenti tra loro. L'API GKE Multi-Cloud registra automaticamente i cluster con un parco risorse quando viene creato.

Quando crei un cluster, specifichi un progetto host del parco risorse da cui verrà gestito il cluster. Poiché GKE su AWS utilizza il nome del cluster come nome dell'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 da quello in cui si trova il cluster, devi applicare un'associazione di criteri IAM aggiuntiva all'account di servizio dell'agente di servizio multi-cloud. In questo modo l'account di servizio può gestire i parchi risorse con il progetto host del parco risorse.

  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 tuo 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 saperne di più su come trovare il numero di progetto, consulta Identificazione dei progetti.

Crea il cluster

Utilizza il comando seguente per creare il cluster in GKE su AWS. Per ulteriori informazioni su questo comando, inclusi i parametri facoltativi, consulta la pagina di riferimento gcloud container aws.

gcloud container aws clusters create CLUSTER_NAME \
  --aws-region AWS_REGION \
  --location GOOGLE_CLOUD_LOCATION \
  --cluster-version CLUSTER_VERSION \
  --fleet-project FLEET_PROJECT \
  --vpc-id VPC_ID \
  --subnet-ids CONTROL_PLANE_SUBNET_1,CONTROL_PLANE_SUBNET_2,CONTROL_PLANE_SUBNET_3 \
  --pod-address-cidr-blocks POD_ADDRESS_CIDR_BLOCKS \
  --service-address-cidr-blocks SERVICE_ADDRESS_CIDR_BLOCKS \
  --role-arn API_ROLE_ARN \
  --database-encryption-kms-key-arn DB_KMS_KEY_ARN \
  --admin-users ADMIN_USERS_LIST \
  --config-encryption-kms-key-arn CONFIG_KMS_KEY_ARN \
  --iam-instance-profile CONTROL_PLANE_PROFILE \
  --tags "Name=CLUSTER_NAME-cp"

Sostituisci quanto segue:

  • CLUSTER_NAME: nome del cluster che hai scelto
  • AWS_REGION: la regione AWS in cui creare il cluster
  • GOOGLE_CLOUD_LOCATION: il nome della località Google Cloud da cui verrà gestito il cluster, come definito nelle regioni di gestione di Google Cloud.
  • CLUSTER_VERSION: la versione di Kubernetes da installare sul cluster
  • FLEET_PROJECT: il progetto host del parco risorse in cui verrà registrato il cluster. Se vuoi gestire questo cluster da un altro progetto Google Cloud, consulta Registrazione tra progetti.
  • VPC_ID: l'ID del VPC AWS per questo cluster
  • CONTROL_PLANE_SUBNET_1, CONTROL_PLANE_SUBNET_2, CONTROL_PLANE_SUBNET_3: gli ID subnet per le tre istanze del piano di controllo del cluster
  • POD_ADDRESS_CIDR_BLOCKS: l'intervallo di indirizzi CIDR per i pod del cluster
  • SERVICE_ADDRESS_CIDR_BLOCKS: l'intervallo di indirizzi CIDR per i servizi del cluster
  • API_ROLE_ARN: l'ARN del ruolo API GKE Multi-Cloud
  • CONTROL_PLANE_PROFILE: il profilo dell'istanza IAM associata al cluster. Per maggiori dettagli su come aggiornare un profilo di istanza IAM, consulta Aggiornare il profilo di un'istanza AWS IAM.
  • DB_KMS_KEY_ARN: l'Amazon Resource Name (ARN) della chiave AWS KMS per criptare i secret del cluster
  • CONFIG_KMS_KEY_ARN: l'Amazon Resource Name (ARN) della chiave AWS KMS per criptare i dati utente
  • 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

Se presente, il parametro --tags applica il tag AWS specificato a tutte le risorse AWS sottostanti gestite da GKE su AWS. Questo esempio contrassegna i nodi del piano di controllo con il nome del cluster a cui appartengono.

Non potrai accedere tramite SSH a questi nodi del piano di controllo, a meno che non specifichi una coppia di chiavi SSH con il flag --ssh-ec2-key-pair.

Per visualizzare tutte le versioni di Kubernetes supportate in una determinata località di Google Cloud, esegui questo comando.

gcloud container aws get-server-config --location GCP_LOCATION

Autorizza Cloud Logging / Cloud Monitoring

Per poter creare e caricare log di sistema e metriche in Google Cloud, GKE su AWS 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 progetto Google Cloud del cluster.

Questa associazione IAM concede a tutti i cluster nel progetto del progetto Google Cloud l'accesso 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é non viene eseguito il provisioning del pool di identità per i carichi di lavoro a cui fa riferimento (GOOGLE_PROJECT_ID.svc.id.goog) fino alla creazione del cluster.

Passaggi successivi