Crea un cluster utente utilizzando i client API GKE On-Prem

Questa pagina descrive come creare un cluster utente utilizzando la console Google Cloud, Google Cloud CLI (gcloud CLI) o Terraform.

Che cos'è l'API GKE On-Prem?

L'API GKE On-Prem è ospitata da Google Cloud e consente di gestire il ciclo di vita dei cluster on-premise utilizzando Terraform e le applicazioni Google Cloud standard. L'API GKE On-Prem viene eseguita nell'infrastruttura di Google Cloud. Terraform, la console e gcloud CLI sono client dell'API e utilizzano l'API per creare cluster nel tuo data center.

Per gestire il ciclo di vita dei cluster, l'API GKE On-Prem deve archiviare i metadati relativi allo stato del cluster in Google Cloud, utilizzando la regione Google Cloud specificata durante la creazione del cluster. Questi metadati consentono all'API di gestire il ciclo di vita del cluster e non includono dati specifici per i carichi di lavoro.

Quando crei un cluster utilizzando un client API GKE On-Prem, specifichi un progetto Google Cloud. Dopo la creazione, il cluster viene automaticamente registrato nel parco risorse del progetto specificato. Questo progetto è definito progetto host del parco risorse. Il progetto host del parco risorse non può essere modificato dopo la creazione del cluster.

Se preferisci, puoi creare un cluster utente creando un file di configurazione del cluster utente e utilizzando gkectl, come descritto in Creazione di un cluster utente mediante gkectl.

Se vuoi utilizzare Terraform, la console o l'gcloud CLI per gestire il ciclo di vita dei cluster creati utilizzando gkectl, consulta Configurare un cluster utente che sia gestito dall'API GKE On-Prem.

Prima di iniziare

Questa sezione descrive i requisiti per la creazione di un cluster utente utilizzando i client API GKE On-Prem.

Concedi autorizzazioni IAM

Se non sei un proprietario del progetto, devi ricevere i privilegi roles/gkeonprem.admin.

Se vuoi accedere alle pagine GKE Enterprise e Google Kubernetes Engine nella console, devi disporre anche dei ruoli seguenti:

Dopo la creazione del cluster, se non sei un proprietario del progetto e vuoi utilizzare il gateway di Connect per connetterti al cluster utente tramite la riga di comando, sono richiesti i ruoli seguenti:

  • roles/gkehub.gatewayAdmin: questo ruolo ti consente di accedere all'API Connect Gateway. Se hai bisogno solo dell'accesso di sola lettura al cluster, roles/gkehub.gatewayReader è sufficiente.

  • roles/gkehub.viewer: questo ruolo consente di recuperare le credenziali del cluster.

Per informazioni sulla concessione dei ruoli, consulta Gestire l'accesso a progetti, cartelle e organizzazioni

Registra il cluster di amministrazione

Devi disporre di un cluster di amministrazione, che deve essere registrato in un parco risorse prima di poter creare cluster utente utilizzando i client API GKE On-Prem.

Abilita gli audit log dell'attività di amministrazione per il cluster di amministrazione

Il logging delle attività di amministrazione per Audit log di Cloud deve essere abilitato nel cluster di amministrazione.

Abilita il logging e il monitoraggio a livello di sistema per il cluster di amministrazione

Cloud Logging e Cloud Monitoring devono essere abilitati nel cluster di amministrazione.

API di Google obbligatorie

Assicurati che tutte le API di Google richieste siano abilitate nel progetto host del parco risorse.

Inoltre, devi abilitare l'API GKE On-Prem:

gcloud services enable --project FLEET_HOST_PROJECT_ID \
    gkeonprem.googleapis.com

Accesso da riga di comando

Dopo la creazione del cluster, se vuoi utilizzare il gateway di connessione per connetterti al cluster utente tramite la riga di comando:

Assicurati di aver installato i seguenti strumenti a riga di comando:

  • La versione più recente di gcloud CLI.
  • kubectl per eseguire comandi sui cluster Kubernetes. Se devi installare kubectl, segui queste instructions.

Se utilizzi Cloud Shell come ambiente shell per interagire con Google Cloud, questi strumenti sono installati automaticamente.

Versioni disponibili per le nuove installazioni

Quando crei un cluster utente, in genere installi la versione di GKE su VMware corrispondente al cluster di amministrazione. Puoi però installare una versione patch successiva o una versione secondaria successiva. Ad esempio, potresti voler installare la release più recente della patch quando crei un cluster utente per ricevere correzioni di bug. Occorrono circa 7-10 giorni dopo una release di GKE su VMware perché la versione sia disponibile nell'API GKE On-Prem.

Se vuoi creare un cluster utente in una versione successiva rispetto al cluster di amministrazione, scarica prima un bundle specifico della versione dei componenti necessari al cluster di amministrazione per gestire i cluster utente in quella versione, quindi esegui il deployment dei componenti. Per maggiori informazioni, consulta Installare una versione successiva rispetto a quella del cluster di amministrazione.

Scegli uno strumento per creare il cluster

Puoi utilizzare Terraform, la console Google Cloud o Google Cloud CLI (gcloud CLI) per creare un cluster gestito dall'API GKE On-Prem. Se è la prima volta che installi GKE su VMware, potresti trovare la console lo strumento più facile da utilizzare.

Quando avrai acquisito maggiore familiarità con le informazioni necessarie per creare i cluster, potresti trovare che Terraform o gcloud CLI sia più pratico, in particolare se intendi creare più di un cluster. Terraform è uno strumento Infrastructure as Code standard di settore. Se la tua organizzazione usa già Terraform, ti consigliamo di usarlo per creare cluster e gestire il ciclo di vita del cluster.

Con gcloud CLI, puoi salvare il comando con i suoi argomenti in un file di testo e apportare le modifiche necessarie per creare cluster aggiuntivi. Se usi uno strumento CI/CD come Cloud Build, puoi utilizzare i comandi gcloud per creare un cluster e un pool di nodi e specificare il flag --impersonate-service-account per automatizzare la creazione.

Creazione di un cluster utente

Console

La maggior parte dei campi nella console Google Cloud corrisponde ai campi nel file di configurazione del cluster utente.

  1. Nella console Google Cloud, vai alla pagina Crea un cluster GKE su VMware.

    Vai a Crea un cluster GKE su VMware

  2. Seleziona il progetto Google Cloud in cui vuoi creare il cluster. Il progetto selezionato viene utilizzato anche come progetto host del parco risorse. Deve essere lo stesso progetto in cui è registrato il cluster di amministrazione. Dopo la creazione, il cluster utente viene registrato automaticamente nel parco risorse del progetto selezionato.

Le sezioni seguenti illustrano la procedura per configurare il cluster utente.

Impostazioni di base del cluster

Inserisci le informazioni di base sul cluster.

  1. Inserisci un nome per il cluster utente.

  2. In Cluster di amministrazione, seleziona il cluster di amministrazione dall'elenco. Se non hai specificato un nome per il cluster di amministrazione quando lo hai creato, il nome viene generato nel formato gke-admin-[HASH]. Se non riconosci il nome del cluster di amministrazione, esegui il comando seguente sulla workstation di amministrazione:

    KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
kubectl get OnPremAdminCluster -n kube-system -o=jsonpath='{.items[0].metadata.name}'

    Se il cluster di amministrazione che vuoi utilizzare non è visualizzato, consulta la sezione relativa alla risoluzione dei problemi Il cluster di amministrazione non viene visualizzato nell'elenco a discesa Impostazioni di base del cluster.

  3. Nel campo Posizione API Google Cloud, seleziona la regione Google Cloud dall'elenco. Questa impostazione specifica la regione in cui viene eseguita l'API GKE On-Prem e la regione in cui sono archiviate:

    • I metadati del cluster utente necessari all'API GKE On-Prem per gestire il ciclo di vita
    • I dati di Cloud Logging e Cloud Monitoring dei componenti di sistema
    • L'audit log di amministrazione creato da Cloud Audit Logs

    Il nome, il progetto e la località del cluster identificano in modo univoco Google Cloud.

  4. Seleziona la versione di GKE su VMware per il tuo cluster utente.

  5. In qualità di creatore del cluster, ti vengono concessi i privilegi di amministratore del cluster. Se vuoi, inserisci l'indirizzo email di un altro utente che gestirà il cluster nel campo Utente amministratore del cluster nella sezione Autorizzazione.

    Una volta creato il cluster, l'API GKE On-Prem applica al cluster i criteri di controllo dell'accesso dell'accesso basato sui ruoli (RBAC) di Kubernetes per concedere a te e ad altri utenti amministratori il ruolo clusterrole/cluster-admin di Kubernetes, che fornisce l'accesso completo a tutte le risorse del cluster in tutti gli spazi dei nomi.

  6. Fai clic su Avanti per andare alla sezione Piano di controllo.

Piano di controllo

Tutti i campi della sezione Piano di controllo sono impostati con valori predefiniti. Rivedi i valori predefiniti e, se necessario, modificali in base alle tue esigenze.

  1. Nel campo vCPU del nodo del piano di controllo, inserisci il numero di vCPU (minimo 4) per ciascun nodo del piano di controllo per il cluster utente.
  2. Nel campo Memoria del nodo del piano di controllo, inserisci la dimensione della memoria in MiB (minimo 8192 e deve essere un multiplo di 4) per ogni piano di controllo per il tuo cluster utente.
  3. In Nodi del piano di controllo, seleziona il numero di nodi del piano di controllo per il cluster utente. Ad esempio, puoi selezionare un nodo del piano di controllo per un ambiente di sviluppo e tre nodi del piano di controllo per gli ambienti di produzione ad alta disponibilità.
  4. (Facoltativo) Seleziona Ridimensionamento automatico dei nodi. Il ridimensionamento significa che le risorse vCPU e di memoria assegnate a un nodo vengono regolate automaticamente. Se questa opzione è abilitata, i nodi del piano di controllo per il cluster utente vengono ridimensionati in base al numero di nodi worker nel cluster utente. Di conseguenza, man mano che aggiungi altri nodi worker al cluster utente, aumentano le dimensioni dei nodi del piano di controllo.

  5. (Facoltativo) Seleziona Abilita piano di controllo v2. L'abilitazione del piano di controllo V2 significa che il piano di controllo per un cluster utente viene eseguito su uno o più nodi nel cluster utente stesso, anziché nel cluster di amministrazione (definito modello kubeception).

    Quando selezioni Abilita piano di controllo v2, viene visualizzata la sezione IP del nodo del piano di controllo. Inserisci l'indirizzo IP per il gateway, la subnet mask e gli indirizzi IP per i nodi del piano di controllo.

    Se è abilitato Controlplane V2, i campi vCPU e memoria si applicano ai nodi del piano di controllo nel cluster utente. Il numero di nodi è determinato dal numero di indirizzi IP che inserisci. Quando Controlplane V2 non è abilitato, i campi per vCPU, memoria e numero di nodi del piano di controllo si applicano ai nodi nel cluster di amministrazione. Assicurati di mettere da parte un numero sufficiente di indirizzi IP per il cluster di amministrazione.

  6. Fai clic su Avanti per andare alla sezione Networking.

Networking

In questa sezione devi specificare gli indirizzi IP per i nodi, i pod e i servizi del cluster. Un cluster utente deve avere un indirizzo IP per ogni nodo e un indirizzo IP aggiuntivo per un nodo temporaneo, necessario durante gli upgrade, gli aggiornamenti e la riparazione automatica del cluster. Per maggiori informazioni, consulta Quanti indirizzi IP ha bisogno un cluster utente?.

  1. Nella sezione IP nodo, seleziona la modalità IP per il cluster utente. Seleziona una delle seguenti opzioni:

    • DHCP: scegli DHCP se vuoi che i nodi del cluster ricevano l'indirizzo IP da un server DHCP.

    • Statici: scegli Statici se vuoi fornire indirizzi IP statici per i nodi del cluster o se vuoi configurare il bilanciamento del carico manuale.

  2. Se hai selezionato DHCP, vai al passaggio successivo per specificare i CIDR di servizi e pod. Per la modalità IP statico, fornisci le seguenti informazioni:

    1. Inserisci l'indirizzo IP del gateway per il cluster utente.

    2. Inserisci la Subnet mask per i nodi del cluster utente.

    3. Nella sezione Indirizzi IP, inserisci gli indirizzi IP e, facoltativamente, i nomi host per i nodi nel cluster utente. Puoi inserire un singolo indirizzo IP v4 (ad esempio 192.0.2.1) o un blocco CIDR di indirizzi IPv4 (ad esempio 192.0.2.0/24).

      • Se inserisci un blocco CIDR, non inserire un nome host.
      • Se inserisci un singolo indirizzo IP, puoi facoltativamente inserire un host. Se non inserisci un nome host, GKE su VMware utilizza il nome della VM proveniente da vSphere come nome host.

    4. Fai clic su + Aggiungi indirizzo IP come necessario per inserire altri indirizzi IP.

  3. Nella sezione CIDR servizi e pod, la console fornisce i seguenti intervalli di indirizzi per i servizi e i pod Kubernetes:

    • CIDR servizio: 10.96.0.0/20
    • CIDR pod: 192.168.0.0/16

    Se preferisci inserire intervalli di indirizzi personalizzati, consulta Indirizzi IP per pod e servizi per le best practice.

  4. Se hai selezionato Modalità IP statico o Abilita piano di controllo v2, specifica le seguenti informazioni nella sezione Configurazione host:

    1. Inserisci gli indirizzi IP dei server DNS.
    2. Inserisci gli indirizzi IP dei server NTP.
    3. Facoltativamente, inserisci i domini di ricerca DNS.

  5. Fai clic su Avanti per andare alla sezione Bilanciatore del carico.

Bilanciatore del carico

Scegli il bilanciatore del carico da configurare per il cluster. Per ulteriori informazioni, consulta Panoramica del bilanciatore del carico.

Seleziona il Tipo di bilanciatore del carico dall'elenco.

Abbinato a MetalLB

Configura il bilanciamento del carico in bundle con MetalLB. Puoi utilizzare MetalLB per il cluster utente solo se il cluster di amministrazione utilizza SeeSaw o MetalLB. Questa opzione richiede una configurazione minima. MetalLB viene eseguito direttamente sui nodi del cluster e non richiede VM aggiuntive. Per ulteriori informazioni sui vantaggi dell'utilizzo di MetalLB e sulle differenze con le altre opzioni di bilanciamento del carico, consulta Bilanciamento del carico in bundle con MetalLB.

  1. Nella sezione Pool di indirizzi, configura almeno un pool di indirizzi, come segue:

    1. Inserisci un nome per il pool di indirizzi.

    2. Inserisci un intervallo di indirizzi IP contenente il VIP in entrata in una delle due notazioni CIDR (ad es. 192.0.2.0/26) o notazione intervallo (ad es. 192.0.2.64-192.0.2.72). Per specificare un singolo indirizzo IP in un pool, utilizza /32 nella notazione CIDR (ad es. 192.0.2.1/32).

    3. Se gli indirizzi IP dei tuoi servizi di tipo LoadBalancer non si trovano nello stesso intervallo di indirizzi IP del VIP in entrata, fai clic su + Aggiungi intervallo di indirizzi IP e inserisci un altro intervallo di indirizzi.

      Gli indirizzi IP in ogni pool non possono sovrapporsi e devono trovarsi nella stessa subnet dei nodi del cluster.

    4. In Assegnazione di indirizzi IP, seleziona una delle seguenti opzioni:

      • Automatico: scegli questa opzione se vuoi che il controller MetalLB assegni automaticamente gli indirizzi IP dal pool di indirizzi ai servizi di tipo LoadBalancer
      • Manuale: scegli questa opzione se intendi utilizzare gli indirizzi del pool per specificare manualmente gli indirizzi per i servizi di tipo LoadBalancer

    5. Fai clic su Evita indirizzi IP con errori se vuoi che il controller MetalLB non utilizzi indirizzi del pool che terminano con .0 o .255. In questo modo eviterai il problema dei dispositivi consumer con errori che causano erroneamente l'interruzione del traffico inviato a questi indirizzi IP speciali.

    6. Al termine, fai clic su Fine.

  2. Se necessario, fai clic su Aggiungi pool di indirizzi.

  3. Nella sezione IP virtuali, inserisci quanto segue:

    • VIP del piano di controllo: l'indirizzo IP di destinazione da utilizzare per il traffico inviato al server API Kubernetes del cluster utente. Il server API Kubernetes per il cluster utente viene eseguito su un nodo nel cluster di amministrazione. Questo indirizzo IP deve trovarsi nello stesso dominio L2 dei nodi del cluster di amministrazione. Non aggiungere questo indirizzo nella sezione Pool di indirizzi.

    • VIP in entrata: l'indirizzo IP da configurare sul bilanciatore del carico per il proxy in entrata. Devi aggiungerlo a un pool di indirizzi nella sezione Pool di indirizzi.

  4. Fai clic su Continua.

Bilanciatore del carico Big-IP F5

Puoi utilizzare F5 per il cluster utente solo se il cluster di amministrazione utilizza F5. Assicurati di installare e configurare l'ADC BIG-IP di F5 prima di integrarlo con GKE su VMware.

  1. Nella sezione IP virtuali, inserisci quanto segue:

    • Vip del piano di controllo: l'indirizzo IP di destinazione da utilizzare per il traffico inviato al server API Kubernetes.

    • VIP in entrata: l'indirizzo IP da configurare sul bilanciatore del carico per il proxy in entrata.

  2. Nel campo Indirizzo, inserisci l'indirizzo del bilanciatore del carico BIG-IP di F5.

  3. Nel campo Partition, inserisci il nome di una partizione BIG-IP che hai creato per il cluster utente.

  4. Nel campo Nome pool SNAT, inserisci il nome del pool SNAT, se applicabile.

  5. Fai clic su Continua.

Bilanciatore del carico manuale

Configura il bilanciamento del carico manuale. Puoi utilizzare un bilanciatore del carico manuale per il cluster utente solo se il cluster di amministrazione utilizza un bilanciatore del carico manuale. In GKE su VMware, il server API, il proxy in entrata e il servizio aggiuntivo per l'aggregazione dei log di Kubernetes sono esposti ciascuno da un servizio Kubernetes di tipo LoadBalancer. Scegli i tuoi valori nodePort nell'intervallo 30.000-32767 per questi servizi. Per il proxy in entrata, scegli un valore nodePort sia per il traffico HTTP che per quello HTTPS. Per ulteriori informazioni, consulta Attivazione della modalità di bilanciamento del carico manuale.

  1. Nella sezione IP virtuali, inserisci quanto segue:

    • Vip del piano di controllo: l'indirizzo IP di destinazione da utilizzare per il traffico inviato al server API Kubernetes.

    • VIP in entrata: l'indirizzo IP da configurare sul bilanciatore del carico per il proxy in entrata.

  2. Nel campo Porta del nodo del piano di controllo, inserisci un valore nodePort per il server API Kubernetes. Il server API Kubernetes di un cluster utente viene eseguito sul cluster di amministrazione.

  3. Nel campo Porta nodo HTTP in entrata, inserisci un valore nodePort per il traffico HTTP verso il proxy in entrata.

  4. Nel campo Porta del nodo HTTPS in entrata, inserisci un valore nodePort per il traffico HTTPS verso il proxy in entrata.

  5. Nel campo Porta nodo server Konnectivity, inserisci un valore nodePort per il server Konnectivity.

  6. Fai clic su Continua.

Funzionalità

Questa sezione mostra le funzionalità e le operazioni abilitate sul cluster.

Le funzionalità seguenti sono attivate automaticamente e non possono essere disattivate:

  1. Le funzionalità seguenti sono attive per impostazione predefinita, ma puoi disabilitarle:

    • Abilita il driver CSI vSphere: chiamato anche plug-in vSphere Container Storage. Il driver Container Storage Interface (CSI) viene eseguito in un cluster Kubernetes nativo di cui è stato eseguito il deployment in vSphere per il provisioning di volumi permanenti nello spazio di archiviazione vSphere. Per maggiori informazioni, consulta Utilizzo del driver vSphere Container Storage Interface.
    • Abilita i gruppi anti-affinità: le regole di anti-affinità Distributed Resource Scheduler (DRS) VMware vengono create automaticamente per i nodi del cluster utente e vengono così distribuite in almeno tre host fisici nel data center. Assicurati che il tuo ambiente vSphere soddisfi i requisiti.

  2. Fai clic su Avanti per configurare un pool di nodi

Pool di nodi

Il cluster verrà creato con almeno un pool di nodi. Un pool di nodi è un modello per i gruppi di nodi creati in questo cluster. Per saperne di più, consulta Creazione e gestione dei pool di nodi .

  1. Nella sezione Valori predefiniti del pool di nodi, completa quanto segue:

    1. Inserisci il Nome del pool di nodi o accetta "default-pool" come nome.
    2. Inserisci il numero di vCPUs per ciascun nodo nel pool (minimo 4 per worker del cluster utente).
    3. Inserisci la dimensione della memoria in mebibyte (MiB) per ciascun nodo nel pool (minimo 8192 MiB per nodo worker del cluster utente, che deve essere un multiplo di 4).
    4. Nel campo Nodi, inserisci il numero di nodi che compongono il pool (minimo 3). Se hai inserito indirizzi IP statici per gli IP nodi nella sezione Networking, assicurati di aver inserito un numero sufficiente di indirizzi IP per contenere questi nodi dei cluster utente.
    5. Seleziona il tipo di immagine del sistema operativo: Ubuntu, Ubuntu Containerd o COS.
    6. Inserisci le Dimensioni del disco di avvio in gigabyte (GiB) (minimo 40 GiB).
    7. Se utilizzi MetalLB come bilanciatore del carico, MetalLB deve essere abilitato in almeno un pool di nodi. Lascia selezionata l'opzione Utilizza questo pool di nodi per il bilanciamento del carico MetalLB o aggiungi un altro pool di nodi da utilizzare per MetalLB.

  2. Nella sezione Metadati del pool di nodi (facoltativo), se vuoi aggiungere etichette e incompatibilità di Kubernetes:

    1. Fai clic su + Aggiungi etichette Kubernetes. Inserisci la chiave e il valore per l'etichetta. Ripeti queste operazioni in base alle necessità.
    2. Fai clic su + Aggiungi incompatibilità. Inserisci la Chiave, il Valore e l'Effetto per l'incompatibilità. Ripeti queste operazioni in base alle necessità.

  3. Fai clic su Verifica e completa per creare il cluster utente. La creazione del cluster utente richiede almeno 15 minuti. La console visualizza messaggi di stato durante la verifica delle impostazioni e la creazione del cluster nel data center.

    Se si verifica un errore durante la verifica delle impostazioni, nella console viene visualizzato un messaggio di errore sufficientemente chiaro da permetterti di risolvere il problema di configurazione e riprovare a creare il cluster.

    Per saperne di più sui possibili errori e su come correggerli, vedi Risolvere i problemi di creazione dei cluster utente nella console Google Cloud.

Interfaccia a riga di comando gcloud

Per creare un cluster utente, devi utilizzare il seguente comando:

gcloud container vmware clusters create

Dopo aver creato il cluster, devi creare almeno un pool di nodi utilizzando questo comando:

gcloud container vmware node-pools create

La maggior parte dei flag per la creazione del cluster e del pool di nodi corrisponde ai campi nel file di configurazione del cluster utente. Per iniziare, puoi testare un comando completo nella sezione examples.

Prima di iniziare

  1. Accedi con il tuo Account Google.

    gcloud auth login

  2. Assicurati di aggiornare i componenti:

    gcloud components update

  3. Visualizza un elenco delle versioni disponibili:

    gcloud container vmware clusters query-version-config \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --location=REGION

    Sostituisci quanto segue:

    • ADMIN_CLUSTER_NAME: il nome del cluster di amministrazione.

    • FLEET_HOST_PROJECT_ID: l'ID del progetto in cui è registrato il cluster di amministrazione.

    • REGION: la regione Google Cloud che hai specificato quando hai registrato il cluster nell'API GKE On-Prem.

    L'output del comando è simile al seguente:

    versions:
- isInstalled: true
  version: 1.14.3-gke.25
- version: 1.14.4-gke.54
- version: 1.15.0-gke.581

Le versioni che puoi utilizzare per creare un cluster utente sono annotate con isInstalled=true, il che significa che il cluster di amministrazione dispone dei componenti specifici della versione necessari per gestire i cluster utente di quella versione. Se vuoi creare un cluster utente con un'altra versione disponibile, consulta Installare una versione successiva rispetto a quella del cluster di amministrazione.

Esempi

Gli esempi seguenti mostrano come creare un cluster utente con bilanciatori del carico diversi. Per informazioni sulle opzioni di bilanciamento del carico disponibili, consulta Panoramica del bilanciatore del carico per ulteriori informazioni.

Gli esempi utilizzano i valori predefiniti per configurare i nodi del piano di controllo. Se vuoi modificare i valori predefiniti, includi i flag descritti nella sezione Flag del piano di controllo. Se necessario, puoi anche modificare alcune impostazioni di vSphere.

Quando il cluster è in esecuzione, devi aggiungere un pool di nodi prima di eseguire il deployment dei carichi di lavoro, come descritto nella sezione Creare un pool di nodi.

MetalLB e DHCP

Questo esempio mostra come creare un cluster utente con il bilanciatore del carico MetalLB in bundle e utilizzare il server DHCP per ottenere gli indirizzi IP per i nodi del cluster.

Puoi utilizzare MetalLB per il cluster utente solo se il tuo cluster di amministrazione utilizza SeeSaw o MetalLB. Questa opzione di bilanciamento del carico richiede una configurazione minima. MetalLB viene eseguito direttamente sui nodi del cluster e non richiede VM aggiuntive. Per ulteriori informazioni sui vantaggi dell'utilizzo di MetalLB e sul confronto con le altre opzioni di bilanciamento del carico, consulta Bilanciamento del carico in bundle con MetalLB.

Assicurati di scorrere, se necessario, per compilare il segnaposto ADMIN_CLUSTER_NAME per il flag --admin-cluster-membership. Questo esempio utilizza il nome del cluster di amministrazione completamente specificato, quindi non è necessario includere --admin-cluster-membership-location e --admin-cluster-membership-project.

gcloud container vmware clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --ingress-vip=INGRESS_VIP \
  --enable-dhcp
  • USER_CLUSTER_NAME: un nome a tua scelta per il cluster utente. Il nome non può essere modificato dopo la creazione del cluster. Il nome deve avere le seguenti caratteristiche:
    • Deve contenere al massimo 40 caratteri
    • Deve contenere solo caratteri alfanumerici minuscoli o un trattino (-)
    • iniziano con un carattere alfabetico
    • terminano con un carattere alfanumerico
  • FLEET_HOST_PROJECT_ID: l'ID del progetto in cui vuoi creare il cluster. Il progetto specificato viene utilizzato anche come progetto host del parco risorse. Deve essere lo stesso progetto in cui è registrato il cluster di amministrazione. Dopo la creazione, il cluster utente viene automaticamente registrato nel parco risorse del progetto selezionato. Il progetto host del parco risorse non può essere modificato dopo la creazione del cluster.
  • ADMIN_CLUSTER_NAME: il nome del cluster di amministrazione che gestisce il cluster utente. Nel flag --admin-cluster-membership puoi utilizzare il nome del cluster completamente specificato, che ha il formato seguente: 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    In alternativa, puoi impostare --admin-cluster-membership sul nome del cluster di amministrazione, come nel comando di esempio. Quando utilizzi solo il nome del cluster di amministrazione, imposta l'ID progetto del cluster di amministrazione con --admin-cluster-membership-project e la località con --admin-cluster-membership-location. La località del cluster di amministrazione è global o una regione Google Cloud. Se devi trovare la regione, esegui gcloud container fleet memberships list.

  • REGION: la regione Google Cloud in cui vengono eseguiti l'API GKE On-Prem (gkeonprem.googleapis.com), il servizio parco risorse (gkehub.googleapis.com) e il servizio Connect (gkeconnect.googleapis.com). Specifica us-west1 o un'altra regione supportata. La regione non può essere modificata dopo la creazione del cluster. Questa impostazione specifica la regione in cui sono archiviati:
    • I metadati del cluster utente necessari all'API GKE On-Prem per gestire il ciclo di vita del cluster
    • I dati di Cloud Logging e Cloud Monitoring dei componenti di sistema
    • L'audit log di amministrazione creato da Cloud Audit Logs

    Il nome, il progetto e la località del cluster identificano in modo univoco il cluster in Google Cloud.

  • VERSION: la versione di GKE su VMware per il cluster utente.
  • YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: se non includi il flag --admin-users, in qualità di creatore del cluster, per impostazione predefinita ti vengono concessi i privilegi di amministratore del cluster. Tuttavia, se includi --admin-users per designare un altro utente come amministratore, esegui l'override dell'impostazione predefinita e devi includere sia il tuo indirizzo email sia l'indirizzo email dell'altro amministratore. Ad esempio, per aggiungere due amministratori: 
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    Una volta creato il cluster, l'API GKE On-Prem applica al cluster i criteri di controllo dell'accesso dell'accesso basato sui ruoli (RBAC) di Kubernetes per concedere a te e agli altri utenti amministratore il ruolo clusterrole/cluster-admin di Kubernetes, che fornisce l'accesso completo a tutte le risorse del cluster in tutti gli spazi dei nomi.

  • SERVICE_CIDR_BLOCK: un intervallo di indirizzi IP, in formato CIDR, da utilizzare per i servizi nel cluster. Deve essere almeno un intervallo /24.

    Esempio: --service-address-cidr-blocks=10.96.0.0/20

  • POD_CIDR_BLOCK: un intervallo di indirizzi IP, in formato CIDR, da utilizzare per i pod nel cluster. Deve essere un intervallo di almeno /18.

    Esempio: --pod-address-cidr-blocks=192.168.0.0/16

  • --metal-lb-config-address-pools: includi questo flag per specificare la configurazione dei pool di indirizzi che devono essere utilizzati dal bilanciatore del carico MetalLB. Il valore del flag ha il seguente formato: 
    --metal-lb-config-address-pool 'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

    Il valore contiene segmenti che iniziano con le parole chiave pool, avoid-buggy-ip, manual-assign e addresses. Separa ogni segmento con una virgola.

    • pool: un nome a tua scelta per il pool.
    • avoid-buggy-ips1: se la imposti su True, il controller MetalLB non assegnerà indirizzi IP che terminano con .0 o .255 ai servizi. In questo modo si evita il problema dei dispositivi consumer con problemi di interruzione del traffico inviato a questi indirizzi IP speciali per errore. Se non specificato, il valore predefinito è False.
    • manual-assign: se non vuoi che il controller MetalLB assegni automaticamente gli indirizzi IP di questo pool ai servizi, imposta questo valore su True. Quindi uno sviluppatore può creare un servizio di tipo LoadBalancer e specificare manualmente uno degli indirizzi dal pool. Se non specificato, manual-assign è impostato su False.
    • Nell'elenco addresses: ogni indirizzo deve essere un intervallo in formato notazione CIDR o intervallo con trattino. Per specificare un singolo indirizzo IP in un pool (ad esempio per il VIP in entrata), utilizza /32 nella notazione CIDR, ad esempio: 192.0.2.1/32.

    Tieni presente quanto segue:

    • Racchiudi l'intero valore tra virgolette singole.
    • Lo spazio vuoto non è consentito.
    • Separa ogni intervallo di indirizzi IP con un punto e virgola.

    Ad esempio:

    --metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'
  • CONTROL_PLANE_VIP: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il server API Kubernetes del cluster utente.

    Esempio: --control-plane-vip=203.0.113.3

  • INGRESS_VIP: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il proxy in entrata.

    Esempio: --ingress-vip=10.251.134.80

    L'indirizzo IP per il VIP in entrata deve essere in uno dei pool di indirizzi MetalLB.

  • --enable-dhcp: includi --enable-dhcp se vuoi che i nodi del cluster ricevano l'indirizzo IP da un server DHCP che fornisci. Non includere questo flag se vuoi fornire indirizzi IP statici per i nodi del cluster o se vuoi configurare il bilanciamento del carico manuale.

MetalLB e IP statici

Questo esempio mostra come creare un cluster utente con il bilanciatore del carico MetalLB in bundle e assegnando indirizzi IP statici ai nodi del cluster.

Puoi utilizzare MetalLB per il cluster utente solo se il tuo cluster di amministrazione utilizza SeeSaw o MetalLB. Questa opzione di bilanciamento del carico richiede una configurazione minima. MetalLB viene eseguito direttamente sui nodi del cluster e non richiede VM aggiuntive. Per ulteriori informazioni sui vantaggi dell'utilizzo di MetalLB e sul confronto con le altre opzioni di bilanciamento del carico, consulta Bilanciamento del carico in bundle con MetalLB.

Assicurati di scorrere, se necessario, per compilare il segnaposto ADMIN_CLUSTER_NAME per il flag --admin-cluster-membership. Questo esempio utilizza il nome del cluster di amministrazione completamente specificato, quindi non è necessario includere --admin-cluster-membership-location e --admin-cluster-membership-project.

gcloud container vmware clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --ingress-vip=INGRESS_VIP \
  --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...' \
  --dns-servers=DNS_SERVER,... \
  --dns-search-domains=DNS_SEARCH_DOMAIN,... \
  --ntp-servers=NTP_SERVER,...

Sostituisci quanto segue:

  • USER_CLUSTER_NAME: un nome a tua scelta per il cluster utente. Il nome non può essere modificato dopo la creazione del cluster. Il nome deve avere le seguenti caratteristiche:
    • Deve contenere al massimo 40 caratteri
    • Deve contenere solo caratteri alfanumerici minuscoli o un trattino (-)
    • iniziano con un carattere alfabetico
    • terminano con un carattere alfanumerico
  • FLEET_HOST_PROJECT_ID: l'ID del progetto in cui vuoi creare il cluster. Il progetto specificato viene utilizzato anche come progetto host del parco risorse. Deve essere lo stesso progetto in cui è registrato il cluster di amministrazione. Dopo la creazione, il cluster utente viene automaticamente registrato nel parco risorse del progetto selezionato. Il progetto host del parco risorse non può essere modificato dopo la creazione del cluster.
  • ADMIN_CLUSTER_NAME: il nome del cluster di amministrazione che gestisce il cluster utente. Nel flag --admin-cluster-membership puoi utilizzare il nome del cluster completamente specificato, che ha il formato seguente: 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    In alternativa, puoi impostare --admin-cluster-membership sul nome del cluster di amministrazione, come nel comando di esempio. Quando utilizzi solo il nome del cluster di amministrazione, imposta l'ID progetto del cluster di amministrazione con --admin-cluster-membership-project e la località con --admin-cluster-membership-location. La località del cluster di amministrazione è global o una regione Google Cloud. Se devi trovare la regione, esegui gcloud container fleet memberships list.

  • REGION: la regione Google Cloud in cui vengono eseguiti l'API GKE On-Prem (gkeonprem.googleapis.com), il servizio parco risorse (gkehub.googleapis.com) e il servizio Connect (gkeconnect.googleapis.com). Specifica us-west1 o un'altra regione supportata. La regione non può essere modificata dopo la creazione del cluster. Questa impostazione specifica la regione in cui sono archiviati:
    • I metadati del cluster utente necessari all'API GKE On-Prem per gestire il ciclo di vita del cluster
    • I dati di Cloud Logging e Cloud Monitoring dei componenti di sistema
    • L'audit log di amministrazione creato da Cloud Audit Logs

    Il nome, il progetto e la località del cluster identificano in modo univoco il cluster in Google Cloud.

  • VERSION: la versione di GKE su VMware per il cluster utente.
  • YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: se non includi il flag --admin-users, in qualità di creatore del cluster, per impostazione predefinita ti vengono concessi i privilegi di amministratore del cluster. Tuttavia, se includi --admin-users per designare un altro utente come amministratore, esegui l'override dell'impostazione predefinita e devi includere sia il tuo indirizzo email sia l'indirizzo email dell'altro amministratore. Ad esempio, per aggiungere due amministratori: 
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    Una volta creato il cluster, l'API GKE On-Prem applica al cluster i criteri di controllo dell'accesso dell'accesso basato sui ruoli (RBAC) di Kubernetes per concedere a te e agli altri utenti amministratore il ruolo clusterrole/cluster-admin di Kubernetes, che fornisce l'accesso completo a tutte le risorse del cluster in tutti gli spazi dei nomi.

  • SERVICE_CIDR_BLOCK: un intervallo di indirizzi IP, in formato CIDR, da utilizzare per i servizi nel cluster. Deve essere almeno un intervallo /24.

    Esempio: --service-address-cidr-blocks=10.96.0.0/20

  • POD_CIDR_BLOCK: un intervallo di indirizzi IP, in formato CIDR, da utilizzare per i pod nel cluster. Deve essere un intervallo di almeno /18.

    Esempio: --pod-address-cidr-blocks=192.168.0.0/16

  • --metal-lb-config-address-pools: includi questo flag per specificare la configurazione dei pool di indirizzi che devono essere utilizzati dal bilanciatore del carico MetalLB. Il valore del flag ha il seguente formato: 
    --metal-lb-config-address-pool 'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

    Il valore contiene segmenti che iniziano con le parole chiave pool, avoid-buggy-ip, manual-assign e addresses. Separa ogni segmento con una virgola.

    • pool: un nome a tua scelta per il pool.
    • avoid-buggy-ips1: se la imposti su True, il controller MetalLB non assegnerà indirizzi IP che terminano con .0 o .255 ai servizi. In questo modo si evita il problema dei dispositivi consumer con problemi di interruzione del traffico inviato a questi indirizzi IP speciali per errore. Se non specificato, il valore predefinito è False.
    • manual-assign: se non vuoi che il controller MetalLB assegni automaticamente gli indirizzi IP di questo pool ai servizi, imposta questo valore su True. Quindi uno sviluppatore può creare un servizio di tipo LoadBalancer e specificare manualmente uno degli indirizzi dal pool. Se non specificato, manual-assign è impostato su False.
    • Nell'elenco addresses: ogni indirizzo deve essere un intervallo in formato notazione CIDR o intervallo con trattino. Per specificare un singolo indirizzo IP in un pool (ad esempio per il VIP in entrata), utilizza /32 nella notazione CIDR, ad esempio: 192.0.2.1/32.

    Tieni presente quanto segue:

    • Racchiudi l'intero valore tra virgolette singole.
    • Lo spazio vuoto non è consentito.
    • Separa ogni intervallo di indirizzi IP con un punto e virgola.

    Ad esempio:

    --metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'
  • CONTROL_PLANE_VIP: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il server API Kubernetes del cluster utente.

    Esempio: --control-plane-vip=203.0.113.3

  • INGRESS_VIP: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il proxy in entrata.

    Esempio: --ingress-vip=10.251.134.80

    L'indirizzo IP per il VIP in entrata deve essere in uno dei pool di indirizzi MetalLB.

  • --static-ip-config-ip-blocks: specifica il gateway predefinito, la subnet mask e un elenco di indirizzi IP statici per i nodi worker nel cluster utente. Il valore del flag ha il seguente formato: 
    --static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'

    Il valore contiene segmenti che iniziano con le parole chiave gateway, netmask e ips. Separa i segmenti con una virgola.

    Tieni presente quanto segue:

    • Racchiudi l'intero valore tra virgolette singole.
    • Lo spazio vuoto non è consentito, se non tra un indirizzo IP e un nome host.

    Nell'elenco degli indirizzi IP:

    • Puoi specificare un singolo indirizzo IP o un blocco CIDR di indirizzi IP.
    • Separa ogni indirizzo IP o blocco CIDR con un punto e virgola.
    • Per un singolo indirizzo IP, facoltativamente puoi specificare un nome host dopo l'indirizzo IP. Separa l'indirizzo IP e il nome host con uno spazio. Se non specifichi un nome host, GKE su VMware utilizza il nome della VM proveniente da vSphere come nome host.
    • Se specifichi un blocco CIDR, non specificare un valore per il nome host.

    Ad esempio:

    --static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'
  • DNS_SERVER: un elenco separato da virgole degli indirizzi IP dei server DNS per le VM.
  • DNS_SEARCH_DOMAIN: un elenco separato da virgole dei domini di ricerca DNS utilizzati dagli host. Questi domini vengono utilizzati come parte di un elenco di ricerca di domini.

    Ad esempio:

    --dns-search-domains example.com,examplepetstore.com
  • NTP_SERVER: un elenco separato da virgole degli indirizzi IP dei server orari che le VM possono utilizzare.

F5 BIG-IP e DHCP

Questo esempio mostra come creare un cluster utente con il bilanciatore del carico BIG-IP di F5 e utilizzare il server DHCP per ottenere gli indirizzi IP per i nodi del cluster.

Puoi utilizzare F5 per il cluster utente solo se il cluster di amministrazione utilizza F5. Assicurati di installare e configurare l'ADC BIG-IP di F5 prima di integrarlo con GKE su VMware. Per ulteriori informazioni, consulta la guida all'installazione dell'ADC BIG-IP di F5. Il nome utente e la password F5 vengono ereditati dal cluster di amministrazione.

Assicurati di scorrere, se necessario, per compilare il segnaposto ADMIN_CLUSTER_NAME per il flag --admin-cluster-membership. Questo esempio utilizza il nome del cluster di amministrazione completamente specificato, quindi non è necessario includere --admin-cluster-membership-location e --admin-cluster-membership-project.

gcloud container vmware clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --f5-config-address=F5_CONFIG_ADDRESS \
  --f5-config-partition=F5_CONFIG_PARTITION \
  --f5-config-snat-pool=F5_CONFIG_SNAT_POOL \
  --control-plane-vipCONTROL_PLANE_VIP \
  --ingress-vip=INGRESS_VIP \
  --enable-dhcp
  • USER_CLUSTER_NAME: un nome a tua scelta per il cluster utente. Il nome non può essere modificato dopo la creazione del cluster. Il nome deve avere le seguenti caratteristiche:
    • Deve contenere al massimo 40 caratteri
    • Deve contenere solo caratteri alfanumerici minuscoli o un trattino (-)
    • iniziano con un carattere alfabetico
    • terminano con un carattere alfanumerico
  • FLEET_HOST_PROJECT_ID: l'ID del progetto in cui vuoi creare il cluster. Il progetto specificato viene utilizzato anche come progetto host del parco risorse. Deve essere lo stesso progetto in cui è registrato il cluster di amministrazione. Dopo la creazione, il cluster utente viene automaticamente registrato nel parco risorse del progetto selezionato. Il progetto host del parco risorse non può essere modificato dopo la creazione del cluster.
  • ADMIN_CLUSTER_NAME: il nome del cluster di amministrazione che gestisce il cluster utente. Nel flag --admin-cluster-membership puoi utilizzare il nome del cluster completamente specificato, che ha il formato seguente: 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    In alternativa, puoi impostare --admin-cluster-membership sul nome del cluster di amministrazione, come nel comando di esempio. Quando utilizzi solo il nome del cluster di amministrazione, imposta l'ID progetto del cluster di amministrazione con --admin-cluster-membership-project e la località con --admin-cluster-membership-location. La località del cluster di amministrazione è global o una regione Google Cloud. Se devi trovare la regione, esegui gcloud container fleet memberships list.

  • REGION: la regione Google Cloud in cui vengono eseguiti l'API GKE On-Prem (gkeonprem.googleapis.com), il servizio parco risorse (gkehub.googleapis.com) e il servizio Connect (gkeconnect.googleapis.com). Specifica us-west1 o un'altra regione supportata. La regione non può essere modificata dopo la creazione del cluster. Questa impostazione specifica la regione in cui sono archiviati:
    • I metadati del cluster utente necessari all'API GKE On-Prem per gestire il ciclo di vita del cluster
    • I dati di Cloud Logging e Cloud Monitoring dei componenti di sistema
    • L'audit log di amministrazione creato da Cloud Audit Logs

    Il nome, il progetto e la località del cluster identificano in modo univoco il cluster in Google Cloud.

  • VERSION: la versione di GKE su VMware per il cluster utente.
  • YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: se non includi il flag --admin-users, in qualità di creatore del cluster, per impostazione predefinita ti vengono concessi i privilegi di amministratore del cluster. Tuttavia, se includi --admin-users per designare un altro utente come amministratore, esegui l'override dell'impostazione predefinita e devi includere sia il tuo indirizzo email sia l'indirizzo email dell'altro amministratore. Ad esempio, per aggiungere due amministratori: 
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    Una volta creato il cluster, l'API GKE On-Prem applica al cluster i criteri di controllo dell'accesso dell'accesso basato sui ruoli (RBAC) di Kubernetes per concedere a te e agli altri utenti amministratore il ruolo clusterrole/cluster-admin di Kubernetes, che fornisce l'accesso completo a tutte le risorse del cluster in tutti gli spazi dei nomi.

  • SERVICE_CIDR_BLOCK: un intervallo di indirizzi IP, in formato CIDR, da utilizzare per i servizi nel cluster. Deve essere almeno un intervallo /24.

    Esempio: --service-address-cidr-blocks=10.96.0.0/20

  • POD_CIDR_BLOCK: un intervallo di indirizzi IP, in formato CIDR, da utilizzare per i pod nel cluster. Deve essere un intervallo di almeno /18.

    Esempio: --pod-address-cidr-blocks=192.168.0.0/16

  • F5_CONFIG_ADDRESS: l'indirizzo del bilanciatore del carico BIG-IP di F5.

  • F5_CONFIG_PARTITION:il nome di una partizione BIG-IP che hai creato per il cluster utente.

  • F5_CONFIG_SNAT_POOL: il nome del pool SNAT, se applicabile.

  • CONTROL_PLANE_VIP: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il server API Kubernetes del cluster utente.

    Esempio: --control-plane-vip=203.0.113.3

  • INGRESS_VIP: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il proxy in entrata.

    Esempio: --ingress-vip=10.251.134.80

    L'indirizzo IP per il VIP in entrata deve essere in uno dei pool di indirizzi MetalLB.

  • --enable-dhcp: includi --enable-dhcp se vuoi che i nodi del cluster ricevano l'indirizzo IP da un server DHCP che fornisci. Non includere questo flag se vuoi fornire indirizzi IP statici per i nodi del cluster o se vuoi configurare il bilanciamento del carico manuale.

Bilanciatore del carico manuale e IP statici

Questo esempio mostra come creare un cluster utente con un bilanciatore del carico manuale e assegnare indirizzi IP statici ai nodi del cluster.

Puoi utilizzare un bilanciatore del carico manuale per il cluster utente solo se il tuo cluster di amministrazione utilizza un bilanciatore del carico manuale. In GKE su VMware, il server API, il proxy in entrata e il servizio aggiuntivo per l'aggregazione dei log di Kubernetes sono esposti ciascuno da un servizio Kubernetes di tipo LoadBalancer. Scegli i tuoi valori nodePort nell'intervallo 30.000-32767 per questi servizi. Per il proxy in entrata, scegli un valore nodePort per il traffico HTTP e HTTPS. Per ulteriori informazioni, consulta Attivazione della modalità di bilanciamento del carico manuale.

Assicurati di scorrere, se necessario, per compilare il segnaposto ADMIN_CLUSTER_NAME per il flag --admin-cluster-membership. Questo esempio utilizza il nome del cluster di amministrazione completamente specificato, quindi non è necessario includere --admin-cluster-membership-location e --admin-cluster-membership-project.

gcloud container vmware clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-node-port=CONTROL_PLANE_NODE_PORT \
  --ingress-vip=INGRESS_VIP \
  --ingress-http-node-port=INGRESS_HTTP_NODE_PORT \
  --ingress-https-node-port=INGRESS_HTTPS_NODE_PORT \
  --konnectivity-server-node-port=KONNECTIVITY_SERVER_NODE_PORT

Sostituisci quanto segue:

  • USER_CLUSTER_NAME: un nome a tua scelta per il cluster utente. Il nome non può essere modificato dopo la creazione del cluster. Il nome deve avere le seguenti caratteristiche:
    • Deve contenere al massimo 40 caratteri
    • Deve contenere solo caratteri alfanumerici minuscoli o un trattino (-)
    • iniziano con un carattere alfabetico
    • terminano con un carattere alfanumerico
  • FLEET_HOST_PROJECT_ID: l'ID del progetto in cui vuoi creare il cluster. Il progetto specificato viene utilizzato anche come progetto host del parco risorse. Deve essere lo stesso progetto in cui è registrato il cluster di amministrazione. Dopo la creazione, il cluster utente viene automaticamente registrato nel parco risorse del progetto selezionato. Il progetto host del parco risorse non può essere modificato dopo la creazione del cluster.
  • ADMIN_CLUSTER_NAME: il nome del cluster di amministrazione che gestisce il cluster utente. Nel flag --admin-cluster-membership puoi utilizzare il nome del cluster completamente specificato, che ha il formato seguente: 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    In alternativa, puoi impostare --admin-cluster-membership sul nome del cluster di amministrazione, come nel comando di esempio. Quando utilizzi solo il nome del cluster di amministrazione, imposta l'ID progetto del cluster di amministrazione con --admin-cluster-membership-project e la località con --admin-cluster-membership-location. La località del cluster di amministrazione è global o una regione Google Cloud. Se devi trovare la regione, esegui gcloud container fleet memberships list.

  • REGION: la regione Google Cloud in cui vengono eseguiti l'API GKE On-Prem (gkeonprem.googleapis.com), il servizio parco risorse (gkehub.googleapis.com) e il servizio Connect (gkeconnect.googleapis.com). Specifica us-west1 o un'altra regione supportata. La regione non può essere modificata dopo la creazione del cluster. Questa impostazione specifica la regione in cui sono archiviati:
    • I metadati del cluster utente necessari all'API GKE On-Prem per gestire il ciclo di vita del cluster
    • I dati di Cloud Logging e Cloud Monitoring dei componenti di sistema
    • L'audit log di amministrazione creato da Cloud Audit Logs

    Il nome, il progetto e la località del cluster identificano in modo univoco il cluster in Google Cloud.

  • VERSION: la versione di GKE su VMware per il cluster utente.
  • YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: se non includi il flag --admin-users, in qualità di creatore del cluster, per impostazione predefinita ti vengono concessi i privilegi di amministratore del cluster. Tuttavia, se includi --admin-users per designare un altro utente come amministratore, esegui l'override dell'impostazione predefinita e devi includere sia il tuo indirizzo email sia l'indirizzo email dell'altro amministratore. Ad esempio, per aggiungere due amministratori: 
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    Una volta creato il cluster, l'API GKE On-Prem applica al cluster i criteri di controllo dell'accesso dell'accesso basato sui ruoli (RBAC) di Kubernetes per concedere a te e agli altri utenti amministratore il ruolo clusterrole/cluster-admin di Kubernetes, che fornisce l'accesso completo a tutte le risorse del cluster in tutti gli spazi dei nomi.

  • SERVICE_CIDR_BLOCK: un intervallo di indirizzi IP, in formato CIDR, da utilizzare per i servizi nel cluster. Deve essere almeno un intervallo /24.

    Esempio: --service-address-cidr-blocks=10.96.0.0/20

  • POD_CIDR_BLOCK: un intervallo di indirizzi IP, in formato CIDR, da utilizzare per i pod nel cluster. Deve essere un intervallo di almeno /18.

    Esempio: --pod-address-cidr-blocks=192.168.0.0/16

  • CONTROL_PLANE_VIP: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico del server API Kubernetes del cluster utente.

    Esempio: --control-plane-vip=203.0.113.3

  • CONTROL_PLANE_NODE_PORT: un valore nodePort per il server API Kubernetes.

  • INGRESS_VIP: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il proxy in entrata.

    Esempio: --ingress-vip=203.0.113.4

  • INGRESS_HTTP_NODE_PORT: un valore nodePort per il traffico HTTP verso il proxy in entrata.

  • INGRESS_HTTPS_NODE_PORT: un valore nodePort per il traffico HTTPS verso il proxy in entrata.

  • KONNECTIVITY_SERVER_NODE_PORT: un valore nodePort per il server Konnectivity.

  • --static-ip-config-ip-blocks: specifica il gateway predefinito, la subnet mask e un elenco di indirizzi IP statici per i nodi worker nel cluster utente. Il valore del flag ha il seguente formato: 
    --static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'

    Il valore contiene segmenti che iniziano con le parole chiave gateway, netmask e ips. Separa i segmenti con una virgola.

    Tieni presente quanto segue:

    • Racchiudi l'intero valore tra virgolette singole.
    • Lo spazio vuoto non è consentito, se non tra un indirizzo IP e un nome host.

    Nell'elenco degli indirizzi IP:

    • Puoi specificare un singolo indirizzo IP o un blocco CIDR di indirizzi IP.
    • Separa ogni indirizzo IP o blocco CIDR con un punto e virgola.
    • Per un singolo indirizzo IP, facoltativamente puoi specificare un nome host dopo l'indirizzo IP. Separa l'indirizzo IP e il nome host con uno spazio. Se non specifichi un nome host, GKE su VMware utilizza il nome della VM proveniente da vSphere come nome host.
    • Se specifichi un blocco CIDR, non specificare un valore per il nome host.

    Ad esempio:

    --static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'
  • DNS_SERVER: un elenco separato da virgole degli indirizzi IP dei server DNS per le VM.
  • DNS_SEARCH_DOMAIN: un elenco separato da virgole dei domini di ricerca DNS utilizzati dagli host. Questi domini vengono utilizzati come parte di un elenco di ricerca di domini.

    Ad esempio:

    --dns-search-domains example.com,examplepetstore.com
  • NTP_SERVER: un elenco separato da virgole degli indirizzi IP dei server orari che le VM possono utilizzare.

Per un elenco completo dei flag e delle relative descrizioni, consulta il riferimento di gcloud CLI.

Flag del piano di controllo

Se vuoi utilizzare valori non predefiniti per la configurazione del piano di controllo, includi uno o più dei seguenti flag:

  • --cpus=vCPUS: il numero di vCPU (minimo 4) per ciascun nodo del piano di controllo per il cluster utente. Se non specificato, il valore predefinito è 4 vCPU.

  • --memory=MEMORY: la dimensione della memoria in mebibyte (MiB) per ogni piano di controllo per il tuo cluster utente. Il valore minimo è 8192 e deve essere un multiplo di 4. Se non specificato, il valore predefinito è 8192.

  • --replicas=NODES: il numero di nodi del piano di controllo per il cluster utente. Ad esempio, puoi selezionare un nodo del piano di controllo per un ambiente di sviluppo e tre nodi del piano di controllo per ambienti di produzione ad alta disponibilità.

  • --enable-auto-resize: se vuoi abilitare il ridimensionamento automatico dei nodi del piano di controllo per il cluster utente, includi --enable-auto-resize. Per ridimensionamento le risorse vCPU e di memoria assegnate a un nodo vengono regolate automaticamente. Se questa opzione è abilitata, i nodi del piano di controllo per il cluster utente vengono ridimensionati in base al numero di nodi worker nel cluster utente. Di conseguenza, man mano che aggiungi altri nodi worker al cluster utente, le dimensioni dei nodi del piano di controllo aumentano.

  • --enable-control-plane-v2: se vuoi abilitare il piano di controllo V2, includi --enable-control-plane-v2. Se il piano di controllo V2 è abilitato, il piano di controllo per un cluster utente viene eseguito su uno o più nodi nel cluster utente stesso. Per impostazione predefinita, il piano di controllo per un cluster utente viene eseguito su uno o più nodi nel cluster di amministrazione (definito modello kubeception). Se il piano di controllo V2 è abilitato, i valori di --cpus e --memory si applicano ai nodi del piano di controllo nel cluster utente. Il numero di nodi è determinato dal numero di indirizzi IP inseriti in --control-plane-ip-block. Se il piano di controllo V2 non è abilitato, i valori di --cpus, --memory e --replicas si applicano ai nodi del piano di controllo nel cluster di amministrazione. Assicurati di mettere da parte un numero sufficiente di indirizzi IP per il cluster di amministrazione.

    Se abiliti Controlplane V2, devi specificare anche i flag seguenti:

    • --dns-servers=DNS_SERVER_1,...: un elenco separato da virgole degli indirizzi IP dei server DNS per le VM.

    • --ntp-servers=NTP_SERVER_1,...: un elenco separato da virgole degli indirizzi IP dei server orari che le VM possono utilizzare.

    • --control-plane-ip-block, che ha il seguente formato:

      --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1;CP_IP_ADDRESS_2 CP_HOST_2'

      Il valore contiene segmenti che iniziano con le parole chiave gateway, netmask e ips. Separa i segmenti con una virgola.

      Tieni presente quanto segue:

      • Racchiudi l'intero valore tra virgolette singole.
      • Lo spazio vuoto non è consentito, se non tra un indirizzo IP e un host.

      Nell'elenco degli indirizzi IP:

      • Puoi specificare un singolo indirizzo IP o un blocco CIDR di indirizzi IP.

      • Separa ogni indirizzo IP o blocco CIDR con un punto e virgola.

      • Per un singolo indirizzo IP, puoi facoltativamente specificare un nome host dopo l'indirizzo IP. Separa l'indirizzo IP e il nome host con uno spazio.

      • Se specifichi un blocco CIDR, non specificare un valore per il nome host.

      Ad esempio:

      --control-plane-ip-block 'gateway=192.168.0.1,netmask=255.0.0.0,ips=192.168.1.1;192.168.1.2 hostname-2;192.168.2.2/28`

    • (Facoltativo) --dns-search-domains=DNS_SEARCH_DOMAIN_1,...: un elenco separato da virgole dei domini di ricerca DNS che gli host possono utilizzare. Questi domini vengono utilizzati come parte di un elenco di ricerca di domini.

      Ad esempio:

      --dns-search-domains example.com,examplepetstore.com

Per un elenco completo dei flag e delle relative descrizioni, consulta il riferimento di gcloud CLI.

Flag vSphere

Specifica i seguenti flag facoltativi, se necessario:

  • --disable-aag-config: se non includi questo flag, le regole di anti-affinità Distributed Resource Scheduler (DRS) di VMware vengono create automaticamente per i nodi del cluster utente e, di conseguenza, sono distribuiti in almeno tre host fisici nel tuo data center. Assicurati che il tuo ambiente vSphere soddisfi i requisiti. Se il cluster non soddisfa i requisiti, includi questo flag.

  • --disable-vsphere-csi: se non includi questo flag, viene eseguito il deployment dei componenti CSI (Container Storage Interface) di vSphere nel cluster utente. Il driver CSI viene eseguito in un cluster Kubernetes nativo di cui è stato eseguito il deployment in vSphere per il provisioning di volumi permanenti. Per maggiori informazioni, consulta Utilizzo del driver vSphere Container Storage Interface. Se non vuoi eseguire il deployment dei componenti CSI, includi questo flag.

Per un elenco completo dei flag e delle relative descrizioni, consulta il riferimento di gcloud CLI

Prima di eseguire il comando gcloud per creare il cluster, potresti voler includere --validate-only per convalidare la configurazione specificata nei flag del comando gcloud. Quando vuoi creare il cluster, rimuovi questo flag ed esegui il comando.

L'output del comando è simile al seguente:

Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.

Nell'output di esempio, la stringa operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 è la stringa OPERATION_ID dell'operazione a lunga esecuzione. Puoi trovare lo stato dell'operazione con il seguente comando:

gcloud container vmware operations describe OPERATION_ID \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION

Per maggiori informazioni, consulta la pagina relativa alle operazioni di gcloud container vmware.

La creazione del cluster utente richiede almeno 15 minuti. Puoi visualizzare il cluster nella console Google Cloud nella pagina dei cluster Anthos.

Crea un pool di nodi

Dopo aver creato il cluster, devi creare almeno un pool di nodi prima di eseguire il deployment dei carichi di lavoro.

gcloud container vmware node-pools create NODE_POOL_NAME \
--cluster=USER_CLUSTER_NAME  \
--project=FLEET_HOST_PROJECT_ID \
--location=REGION \
--image-type=IMAGE_TYPE  \
--boot-disk-size=BOOT_DISK_SIZE \
--cpus=vCPUS \
--memory=MEMORY \
--replicas=NODES \
--enable-load-balancer

Sostituisci quanto segue:

  • NODE_POOL_NAME: un nome a tua scelta per il pool di nodi. Il nome deve rispettare i seguenti requisiti:

    • Deve contenere al massimo 40 caratteri
    • Deve contenere solo caratteri alfanumerici minuscoli o un trattino (-)
    • iniziano con un carattere alfabetico
    • terminano con un carattere alfanumerico

  • USER_CLUSTER_NAME: il nome del cluster utente appena creato.

  • FLEET_HOST_PROJECT_ID: l'ID del progetto in cui è registrato il cluster.

  • REGION: la località Google Cloud specificata quando hai creato il cluster.

  • IMAGE_TYPE: il tipo di immagine del sistema operativo da eseguire sulle VM nel pool di nodi. Imposta uno dei seguenti valori: ubuntu_containerd o cos.

  • BOOT_DISK_SIZE: la dimensione del disco di avvio in gigabyte (GiB) per ogni nodo nel pool. Il minimo è 40 GiB.

  • vCPUs: il numero di vCPU per ciascun nodo nel pool di nodi. Il numero minimo è 4.

  • MEMORY: la dimensione della memoria in mebibyte (MiB) per ogni nodo nel pool. Il minimo è 8192 MiB per nodo worker del cluster utente e il valore deve essere un multiplo di 4.

  • NODES: il numero di nodi nel pool di nodi. Il numero minimo è 3.

  • Se utilizzi MetalLB come bilanciatore del carico, facoltativamente includi --enable-load-balancer se vuoi consentire l'esecuzione dell'altoparlante MetalLB sui nodi nel pool. MetalLB deve essere abilitato in almeno un pool di nodi. Se non includi questo flag, devi creare un altro pool di nodi da utilizzare per MetalLB.

Per informazioni sui flag facoltativi, consulta Aggiungere un pool di nodi e Riferimento per l'interfaccia a riga di comando gcloud.

Terraform

Puoi utilizzare il seguente esempio di configurazione di base per creare un cluster utente con il bilanciatore del carico MetalLB in bundle e un pool di nodi.

Per ulteriori informazioni e altri esempi, consulta la documentazione di riferimento di google_gkeonprem_vmware_cluster.

  1. Clona il repository anthos-samples e passa alla directory in cui si trova l'esempio Terraform:

    git clone https://github.com/GoogleCloudPlatform/anthos-samples
cd anthos-samples/anthos-onprem-terraform/avmw_user_cluster_metallb

Imposta le variabili in terraform.tfvars

L'esempio fornisce un file di variabili di esempio da passare a main.tf, che mostra come configurare il bilanciatore del carico MetalLB in bundle e abilitare i nodi del cluster per ottenere gli indirizzi IP da un server DHCP fornito da te.

  1. Crea una copia del file terraform.tfvars.sample:

    cp terraform.tfvars.sample terraform.tfvars

  2. Modifica i valori dei parametri in terraform.tfvars.

    project_id                  = "FLEET_HOST_PROJECT_ID"
region                      = "REGION"
admin_cluster_name          = "ADMIN_CLUSTER_NAME"
on_prem_version             = "VERSION"
admin_user_emails           = ["YOUR_EMAIL_ADDRESS", "ADMIN_2_EMAIL_ADDRESS"]
cluster_name                = "avmw-user-cluster-metallb"
control_plane_node_cpus     = 4
control_plane_node_memory   = 8192
control_plane_node_replicas = 3
control_plane_vip           = "CONTROL_PLANE_VIP"
ingress_vip                 = "INGRESS_VIP"
lb_address_pools            = [
    { name = "lbpool_1", addresses = ["10.200.0.51-10.200.0.70"] }
]

    Nell'elenco seguente vengono descritte le variabili:

    • project_id: l'ID del progetto in cui vuoi creare il cluster. Il progetto specificato viene utilizzato anche come progetto host del parco risorse. Deve essere lo stesso progetto in cui è registrato il cluster di amministrazione. Dopo la creazione, il cluster utente viene automaticamente registrato nel parco risorse del progetto selezionato. Il progetto host del parco risorse non può essere modificato dopo la creazione del cluster.

    • region: la regione Google Cloud in cui viene eseguita l'API GKE On-Prem. Specifica us-west1 o un'altra regione supportata.

    • admin_cluster_name: il nome del cluster di amministrazione che gestisce il cluster utente.

    • on_prem_version: la versione di GKE su VMware per il tuo cluster utente. In genere, la versione specificata viene specificata per il cluster di amministrazione. Per specificare una versione successiva, Installa una versione successiva rispetto a quella del cluster di amministrazione. Se non conosci la versione del cluster di amministrazione, esegui gcloud container vmware clusters query-version-config, che è il primo passaggio in Installare una versione successiva rispetto a quella del cluster di amministrazione.

    • admin_user_emails: un elenco degli indirizzi email degli utenti a cui vengono concessi i privilegi amministrativi per il cluster. Assicurati di aggiungere il tuo indirizzo email se intendi amministrare il cluster.

      Quando il cluster viene creato, l'API GKE On-Prem applica al cluster i criteri di controllo dell'accesso basato su ruoli (RBAC) di Kubernetes per concedere agli utenti amministratori il ruolo clusterrole/cluster-admin di Kubernetes, che fornisce l'accesso completo a tutte le risorse del cluster in tutti gli spazi dei nomi. Ciò consente inoltre agli utenti di accedere alla console utilizzando la propria identità Google.

    • cluster_name: un nome a tua scelta per il cluster utente. Il nome non può essere modificato dopo la creazione del cluster. Il nome deve rispettare i seguenti requisiti:

      • Deve contenere al massimo 40 caratteri
      • Deve contenere solo caratteri alfanumerici minuscoli o un trattino (-)
      • iniziano con un carattere alfabetico
      • terminano con un carattere alfanumerico

    • control_plane_node_cpus: il numero di vCPU per ciascun nodo del piano di controllo per il cluster utente. Il numero minimo è 4 vCPU.

    • control_plane_node_memory: la dimensione della memoria in mebibyte (MiB) per ciascun piano di controllo per il cluster utente. Il valore minimo è 8192 e deve essere un multiplo di 4.

    • control_plane_node_replicas: il numero di nodi del piano di controllo per il cluster utente. Ad esempio, puoi inserire un nodo del piano di controllo per un ambiente di sviluppo e tre nodi del piano di controllo per ambienti di produzione ad alta disponibilità.

    • control_plane_vip: l'indirizzo IP virtuale (VIP) che hai scelto di configurare sul bilanciatore del carico per il server API Kubernetes del cluster utente.

    • ingress_vip: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il proxy in entrata.

    • lb_address_pools: un elenco di mappe che definiscono i pool di indirizzi che devono essere utilizzati dal bilanciatore del carico MetalLB. Il VIP in entrata deve trovarsi in uno di questi pool. Specifica quanto segue:

      • name: il nome del pool.
      • addresses: un intervallo di indirizzi in formato CIDR o intervallo con trattino. Per specificare un singolo indirizzo IP in un pool (ad esempio per il VIP in entrata), utilizza /32 nella notazione CIDR, ad esempio 192.0.2.1/32.

      Sostituisci gli indirizzi IP di esempio con i tuoi valori e, se necessario, aggiungi altri pool di indirizzi.

  3. Salva le modifiche in terraform.tfvars. Se non vuoi apportare modifiche facoltative a main.tf, passa alla sezione che segue, Creare il cluster e un pool di nodi.

(Facoltativo) Configura le impostazioni del cluster in main.tf

Questa sezione illustra alcune modifiche facoltative alla configurazione che puoi apportare in main.tf. Prima di apportare modifiche, esegui il backup di main.tf:

cp main.tf main.tf.bak

Modalità di indirizzamento IP del nodo worker

Per impostazione predefinita, main.tf configura il cluster in modo che utilizzi un server DHCP da te fornito per assegnare indirizzi IP ai nodi worker del cluster. DHCP viene configurato includendo la mappa dhcp_config all'interno del blocco network_config. Se vuoi fornire indirizzi IP statici per i nodi worker, apporta le seguenti modifiche a main.tf:

  1. Sostituisci il blocco network_config e includi un blocco static_ip_config. Ad esempio:

    network_config {
  service_address_cidr_blocks = ["10.96.0.0/12"]
  pod_address_cidr_blocks = ["192.168.0.0/16"]
  host_config {
    dns_servers = ["10.254.41.1"]
    ntp_servers = ["216.239.35.8"]
  }
  static_ip_config {
    ip_blocks {
      netmask = "255.255.252.0"
      gateway = "10.251.31.254"
      ips {
        ip = "10.251.30.153"
        hostname = "vm-1"
      }
      ips {
        ip = "10.251.31.206"
        hostname = "vm-2"
      }
      ips {
        ip = "10.251.31.193"
        hostname = "vm-3"
      }
      ips {
        ip = "10.251.30.230"
        hostname = "vm-4"
      }
    }
  }
}

  2. Sostituisci quanto segue con i tuoi valori:

    • service_address_cidr_blocks: un intervallo di indirizzi IP, in formato CIDR, da utilizzare per i servizi nel cluster. Deve essere almeno un intervallo /24.

    • pod_address_cidr_blocks: un intervallo di indirizzi IP, in formato CIDR, da utilizzare per i pod nel cluster. Deve essere un intervallo di almeno /18.

    • dns_servers: un elenco degli indirizzi IP dei server DNS delle VM.

    • ntp_servers: un elenco degli indirizzi IP dei server orari per le VM utilizzate.

    • Nel blocco static_ip_config, sostituisci i valori per netmask e gateway con gli indirizzi della tua rete. Sostituisciip e hostname con gli indirizzi IP e i nomi host dei nodi worker.

Configura piano di controllo V2

Per impostazione predefinita, main.tf configura il piano di controllo per l'esecuzione del cluster utente su uno o più nodi nel cluster di amministrazione (definito modello kubeception). Se preferisci, puoi abilitare il piano di controllo V2. Se è abilitato il piano di controllo V2, il piano di controllo per un cluster utente viene eseguito su uno o più nodi nel cluster utente stesso. Per configurare il piano di controllo V2, apporta le seguenti modifiche a main.tf:

  1. Aggiungi la seguente riga dopo la riga con admin_cluster_membership:

    enable_control_plane_v2 = "true"

  2. Aggiungi una mappa control_plane_v2_config al blocco network_config, ad esempio:

    control_plane_v2_config {
  control_plane_ip_block {
    netmask = "255.255.252.0"
    gateway = "10.250.71.254"
    ips {
      ip = "10.250.68.54"
      hostname = "cpv2-vm1"
    }
    ips {
      ip = "10.250.68.128"
      hostname = "cpv2-vm2"
    }
    ips {
      ip = "10.250.71.50"
      hostname = "cpv2-vm3"
    }
  }
}

  3. Sostituisci i valori per netmask e gateway con gli indirizzi IP della tua rete. Sostituisci ip e hostname con gli indirizzi IP dei nodi del piano di controllo.

Crea il cluster e un pool di nodi

  1. Inizializza e crea il piano Terraform:

    terraform init

    Terraform installa tutte le librerie necessarie, ad esempio il provider Google Cloud.

  2. Rivedi la configurazione e apporta modifiche, se necessario:

    terraform plan

  3. Applica il piano Terraform per creare il cluster utente:

    terraform apply

    La creazione del cluster utente richiede circa 15 minuti o più, altri 15 minuti per creare il pool di nodi. Puoi visualizzare il cluster nella console Google Cloud nella pagina dei cluster Anthos.

Connettiti al cluster utente

Quando crei un cluster utente utilizzando un client API GKE On-Prem, puoi aggiungere te e altri utenti come amministratori del cluster specificando gli indirizzi email degli account Google Cloud:

  • Nella console, il tuo indirizzo email viene aggiunto automaticamente nella pagina Impostazioni di base del cluster nella sezione Autorizzazione e hai la possibilità di aggiungere altri utenti amministratori del cluster.

  • Con gcloud CLI, includi il flag --admin-users impostato sul tuo indirizzo email. Il flag non accetta elenchi. Aggiungi il flag --admin-users per ogni utente amministratore del cluster.

  • Con l'esempio di Terraform, puoi specificare te e altri utenti amministratore nella variabile admin_user_emails nel file terraform.tvars.sample.

Il cluster è configurato con criteri di controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes che concedono agli utenti amministratori il ruolo cluster-admin e consentono loro di accedere al cluster dalla console utilizzando la loro identità Google Cloud. Per maggiori informazioni, consulta Configurare l'autenticazione dell'identità Google.

Tutti i cluster hanno un endpoint canonico. L'endpoint espone il server API Kubernetes utilizzato da kubectl e da altri servizi per comunicare con il piano di controllo del cluster sulla porta TCP 443. Questo endpoint non è accessibile sulla rete internet pubblica. Se hai accesso all'endpoint privato del cluster tramite la rete VPC, puoi connetterti direttamente all'endpoint privato e generare direttamente un file kubeconfig. In caso contrario, puoi utilizzare il gateway di connessione. In questo caso, kubectl utilizza Connect, che inoltra in modo sicuro il traffico all'endpoint privato per tuo conto.

Per accedere al cluster utente dalla riga di comando, è necessario un file kubeconfig. Esistono due modi per ottenere un file kubeconfig:

  • Utilizza il gateway di Connect per accedere al cluster da un computer su cui è installato Google Cloud CLI. Il gateway Connect consente di gestire i cluster in modo semplice e sicuro. Per maggiori informazioni, consulta Connessione ai cluster registrati con il gateway Connect.

  • Per l'accesso diretto agli endpoint privati, crea un file kubeconfig sulla workstation di amministrazione e gestisci il cluster dalla workstation di amministrazione.

Assicurati di attendere fino a quando la console indica che lo stato del cluster utente è integro.

Connetti gateway

  1. initialize gcloud CLI per utilizzarlo con il progetto host del parco risorse oppure esegui i comandi seguenti per accedere con il tuo Account Google, imposta il progetto host del parco risorse come predefinito e aggiorna i componenti:

    gcloud auth login
gcloud config set project PROJECT_ID
gcloud components update

  2. Recupera le credenziali del cluster utilizzate per interagire con Connect Gateway. Nel comando seguente, sostituisci MEMBERSHIP_NAME con il nome del cluster. In GKE su VMware, il nome dell'appartenenza è uguale a quello del cluster.

    gcloud container fleet memberships get-credentials MEMBERSHIP_NAME

    Questo comando restituisce un comando Connetti un elemento kubeconfig specifico per il gateway che ti consente di connetterti al cluster tramite il gateway.

    Dopo aver ottenuto le credenziali necessarie, puoi eseguire i comandi utilizzando kubectl come faresti normalmente per qualsiasi cluster Kubernetes, senza dover specificare il nome del file kubeconfig, ad esempio:

    kubectl get namespaces

Workstation di amministrazione

Per creare il file kubeconfig del cluster utente sulla workstation di amministrazione, esegui questo comando per salvare in locale un nuovo file kubeconfig per il cluster utente. Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del cluster utente appena creato
  • ADMIN_CLUSTER_KUBECONFIG: percorso del file kubeconfig del cluster di amministrazione
  • USER_CLUSTER_KUBECONFIG: il nome del file kubeconfig del cluster utente che il comando restituisce
kubectl get secret admin \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  -n CLUSTER_NAME \
  -o=jsonpath='{.data.admin\.conf}' | base64 -d > USER_CLUSTER_KUBECONFIG

Dopo aver salvato il file, puoi iniziare ad accedere al cluster utente utilizzando kubectl sulla workstation di amministrazione, ad esempio:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get namespaces

Installa una versione successiva rispetto a quella del cluster di amministrazione

Un cluster di amministrazione può gestire i cluster utente in versioni diverse. Se vuoi creare un cluster utente di una versione successiva rispetto al cluster di amministrazione, devi scaricare ed eseguire il deployment dei componenti necessari al cluster di amministrazione per gestire i cluster utente di quella versione, come segue:

  1. Visualizza un elenco delle versioni disponibili:

    gcloud container vmware clusters query-version-config \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --location=REGION

    Sostituisci quanto segue:

    • ADMIN_CLUSTER_NAME: il nome del cluster di amministrazione.

    • FLEET_HOST_PROJECT_ID: l'ID del progetto in cui è registrato il cluster di amministrazione.

    • REGION: la regione Google Cloud in cui viene eseguita l'API GKE On-Prem. Questa è la regione che specificherai quando crei il cluster utente. Specifica us-west1 o un'altra regione supportata.

    L'output del comando è simile al seguente:

    versions:
- isInstalled: true
  version: 1.14.3-gke.25
- version: 1.14.4-gke.54
- version: 1.15.0-gke.581

    Le versioni installate sul cluster di amministrazione sono annotate con isInstalled=true.

  2. Se non lo hai già fatto, registra il cluster di amministrazione nell'API GKE On-Prem. Dopo aver registrato il cluster nell'API GKE On-Prem, non devi eseguire di nuovo questo passaggio.

  3. Scarica la nuova versione dei componenti e implementali nel cluster di amministrazione:

    gcloud beta vmware admin-clusters update ADMIN_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --required-platform-version=VERSION

    Questo comando scarica la versione dei componenti specificati in --required-platform-version nel cluster di amministrazione, quindi esegue il deployment dei componenti. Ora puoi creare un cluster utente con la versione specificata.

Passaggi successivi