Questa pagina descrive come creare un cluster GKE su AWS. Puoi anche creare un VPC e un cluster con Terraform.
Questa pagina è rivolta ad amministratori, architetti e operatori che vogliono configurare, monitorare e gestire l'infrastruttura cloud. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta Ruoli utente e attività comuni di GKE. Google Cloud
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 control plane. Ciascuna deve trovarsi in una zona di disponibilità AWS diversa.
- Il ruolo AWS IAM che GKE su AWS assume durante la gestione del cluster. Per farlo, è necessario un insieme specifico di autorizzazioni IAM.
- Chiavi CMK simmetriche KMS per la crittografia at-rest dei dati del cluster (etcd) e della configurazione.
- Il profilo istanza AWS IAM per ogni replica del control plane. Per farlo, è necessario 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 control plane.
È tua responsabilità creare e gestire queste risorse, che possono essere condivise tra tutti i tuoi cluster GKE. Tutte le altre risorse AWS sottostanti con ambito cluster 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 sono specificati utilizzando la notazione Classless Inter-Domain Routing
(CIDR),
ad esempio 100.64.0.0/16
.
Intervalli consigliati
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 AWS utilizza una rete di overlay per pod e servizi, quindi gli intervalli IP per queste reti non devono essere instradabili all'interno del VPC. 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 VPC, a condizione che non includano gli intervalli IP della subnet del control plane o delpool di nodil.
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 nel tuo
VPC.
Ad esempio, la seguente è una configurazione valida in cui le reti Pod, Service e Node non si sovrappongono (il VPC utilizza indirizzi IP privati RFC 1918, mentre le reti Pod e Service 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 pod:
100.65.0.0/16
- Rete di servizio:
100.66.0.0/16
La seguente è anche una configurazione valida nonostante la sovrapposizione delle reti di pod e servizi con la rete VPC, poiché non vi è alcuna sovrapposizione con le repliche del control plane.
- Rete VPC:
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 VPC:
- Rete VPC:
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 tabella seguente 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 |
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 AWS utilizza il nome del cluster come nome di 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 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.
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 .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 progettoGoogle Cloud del progetto host del parco risorseCLUSTER_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 maggiori informazioni su come trovare il numero di progetto, vedi Identificazione dei progetti.
Crea il cluster
Utilizza il seguente comando per creare il cluster in GKE su AWS. Per saperne di più su questo comando, inclusi i parametri facoltativi, consulta la pagina di riferimento di 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
: il nome del cluster che hai sceltoAWS_REGION
: la regione AWS in cui creare il clusterGOOGLE_CLOUD_LOCATION
: il nome della località Google Cloud da cui verrà gestito questo cluster, come definito nelle regioni di gestione.Google CloudCLUSTER_VERSION
: la versione di Kubernetes da installare sul tuo clusterFLEET_PROJECT
: il progetto host del parco risorse in cui verrà registrato il cluster. Se vuoi gestire questo cluster da un altro Google Cloud progetto, consulta la sezione Registrazione tra progetti.VPC_ID
: l'ID della VPC AWS per questo clusterCONTROL_PLANE_SUBNET_1
,CONTROL_PLANE_SUBNET_2
,CONTROL_PLANE_SUBNET_3
: gli ID subnet per le tre istanze del control plane del clusterPOD_ADDRESS_CIDR_BLOCKS
: l'intervallo di indirizzi CIDR per i pod del clusterSERVICE_ADDRESS_CIDR_BLOCKS
: l'intervallo di indirizzi CIDR per i servizi del clusterAPI_ROLE_ARN
: l'ARN del ruolo API GKE Multi-cloudCONTROL_PLANE_PROFILE
: il profilo dell'istanza IAM associata al cluster. Per informazioni dettagliate su come aggiornare un profilo istanza IAM, consulta Aggiornare il profilo istanza AWS IAM.DB_KMS_KEY_ARN
: l'Amazon Resource Name (ARN) della chiave KMS di AWS per criptare i secret del clusterCONFIG_KMS_KEY_ARN
: l'Amazon Resource Name (ARN) della chiave AWS KMS per criptare i dati utenteADMIN_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
Se presente, il parametro --tags
applica il tag AWS specificato a tutte le risorse
AWS sottostanti gestite da GKE su AWS. Questo esempio tagga i nodi del control plane
con il nome del cluster a cui appartengono.
Non potrai accedere tramite SSH a questi nodi del piano di controllo a meno che tu 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 Google Cloud posizione, esegui il seguente comando.
gcloud container aws get-server-config --location GCP_LOCATION
Autorizza Cloud Logging / Cloud Monitoring
Affinché GKE su AWS 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.
Passaggi successivi
- Crea un node pool.
- Configura l'accesso ai cluster per kubectl.
- Prova la guida rapida per avviare 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.