Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Creazione di un cluster utente

In Google Distributed Cloud, i workload vengono eseguiti su uno o più cluster utente. Questo documento mostra come creare un cluster utente. Se vuoi utilizzare i domini di topologia, consulta Crea un cluster utente da utilizzare con i domini di topologia.

Questa pagina è rivolta ad amministratori, architetti e operatori che configurano, monitorano e gestiscono l'infrastruttura tecnologica. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Nella versione 1.33 e successive, tutti i nuovi cluster vengono creati come cluster avanzati. Assicurati di esaminare le differenze durante l'esecuzione di cluster avanzati.

Esistono diversi strumenti che puoi utilizzare per creare un cluster utente:

gkectl
ConsoleGoogle Cloud
Google Cloud CLI
Terraform

Tre di questi strumenti (la console, gcloud CLI e Terraform) sono client dell'API GKE On-Prem.

Per indicazioni sullo strumento che potresti voler utilizzare, consulta Scegli uno strumento per gestire il ciclo di vita del cluster.

Prima di iniziare

Se prevedi di utilizzare gkectl per creare il cluster utente, assicurati di aver configurato e di poter accedere alla tua workstation di amministrazione come descritto in Crea una workstation di amministrazione.
Assicurati che la tua workstation di amministrazione abbia la versione richiesta di gkectl. In genere, utilizzi la stessa versione di gkectl che verrà utilizzata quando crei il cluster. Specifica la versione del cluster nel campo gkeOnPremVersion nel file di configurazione del cluster. Durante la creazione del cluster vengono applicate le seguenti regole relative alle versioni:
- La versione secondaria gkectl non può essere precedente alla versione secondaria del cluster. Ad esempio, non è consentito creare un cluster 1.30 utilizzando la versione 1.29 di gkectl. Le versioni patch non sono importanti. Ad esempio, puoi utilizzare gkectl versione 1.29.0-gke.1456 per creare un cluster con una versione patch più recente, ad esempio 1.29.1000-gke.94.
- La versione secondaria gkectl non può essere superiore di più di due versioni secondarie rispetto alla versione del cluster. Ad esempio, se stai creando un cluster 1.28, la versione gkectl può essere 1.29 o 1.30. Tuttavia, non puoi utilizzare gkectl versione 1.31 perché è di tre versioni secondarie superiore alla versione del cluster.
Se necessario, consulta Scarica gkectl per ottenere una versione supportata di gkectl.
Se non l'hai ancora fatto, configura le risorse Google Cloud come descritto in questi documenti:
Quando configuri il progetto host del parco risorse, tieni presente lo strumento che hai scelto, perché se hai scelto uno dei client API GKE on-prem, devi abilitare altre API. Per l'elenco delle API, consulta Abilita le API nel progetto host del parco risorse.
Prima di creare un cluster utente, devi avere un cluster di amministrazione per gestirlo. Se non l'hai ancora fatto, crea una workstation di amministrazione e un cluster di amministrazione.
Determina la versione del cluster utente che vuoi installare. Quando crei un cluster utente, in genere installi la versione corrispondente a quella del cluster di amministrazione. Se vuoi installare una versione diversa su un cluster utente, consulta Regole per le versioni.
Se prevedi di installare la versione 1.30 o una versione successiva, è necessario Controlplane V2. Anche se installi la versione 1.29 o precedente, ti consigliamo di attivare Controlplane V2. Quando il control plane v2 è abilitato, il control plane per il cluster utente viene eseguito su uno o più nodi nel cluster utente stesso. L'alternativa è creare un cluster utente che utilizzi kubeception. Nel caso di kubeception, il control plane per il cluster utente viene eseguito su uno o più nodi nel cluster di amministrazione.
Consulta il documento di pianificazione degli indirizzi IP e assicurati di avere un numero sufficiente di indirizzi IP disponibili.
Consulta la panoramica del bilanciamento del carico e rivedi la tua decisione sul tipo di bilanciatore del carico che vuoi utilizzare. Puoi utilizzare il bilanciatore del carico MetalLB in bundle o configurare manualmente un bilanciatore del carico a tua scelta. Per il bilanciamento manuale del carico, devi configurare il bilanciatore del carico prima di creare il cluster utente.
Pensa a quanti node pool ti servono e quale sistema operativo vuoi eseguire in ciascuno dei tuoi pool.
Valuta se vuoi utilizzare cluster vSphere separati per il cluster di amministrazione e i cluster utente e se vuoi utilizzare data center separati. Valuta anche se vuoi utilizzare istanze separate di vCenter Server.
Nella versione 1.29 e successive, i controlli preflight lato server sono abilitati per impostazione predefinita. I controlli preflight lato server richiedono regole firewall aggiuntive. In Regole firewall per i cluster di amministrazione, cerca "Controlli preflight" e assicurati che tutte le regole firewall richieste siano configurate.

Con i controlli preflight lato server, quando crei un cluster utente utilizzando gkectl, i controlli preflight vengono eseguiti sul cluster di amministrazione anziché localmente sulla workstation di amministrazione. I controlli preflight lato server vengono eseguiti anche se utilizzi la console Google Cloud , Google Cloud CLI o Terraform per creare un cluster utente.

Crea un cluster utente con lo strumento che preferisci

Questa sezione illustra i passaggi per creare un cluster utente utilizzando gkectl, la console, gcloud CLI e Terraform.

gkectl

Panoramica della procedura

Questi sono i passaggi principali per utilizzare gkectl per creare un cluster utente:

Compila i file di configurazione

Specifica i dettagli del nuovo cluster compilando un file di configurazione del cluster utente, un file di configurazione delle credenziali ed eventualmente un file di blocco IP.
(Facoltativo) Importa le immagini sistema operativo in vSphere ed esegui il push delle immagini container nel registry privato, se applicabile.

Esegui gkectl prepare.
Creazione di un cluster utente

Esegui gkectl create cluster per creare un cluster come specificato nel file di configurazione.
Verifica che il cluster utente sia in esecuzione

Utilizza kubectl per visualizzare i nodi del cluster.

Al termine di questa procedura, avrai un cluster utente in esecuzione in cui potrai eseguire il deployment dei tuoi workload.

Se utilizzi i Controlli di servizio VPC, potresti visualizzare errori quando esegui alcuni comandi gkectl, ad esempio "Validation Category: GCP - [UNKNOWN] GCP service: [Stackdriver] could not get GCP services". Per evitare questi errori, aggiungi il parametro --skip-validation-gcp ai comandi.

Compila i file di configurazione

Se hai utilizzato gkeadm per creare la workstation di amministrazione, gkeadm ha generato un template per il file di configurazione del cluster utente denominato user-cluster.yaml. Inoltre, gkeadm ha compilato alcuni campi per te.

Se non hai utilizzato gkeadm per creare la tua workstation di amministrazione, puoi utilizzare gkectl per generare un template per il file di configurazione del cluster utente.

Per generare un template per il file di configurazione del cluster utente:

gkectl create-config cluster --config=OUTPUT_FILENAME --gke-on-prem-version=VERSION

Sostituisci quanto segue:

OUTPUT_FILENAME: un percorso di tua scelta per il template generato. Se ometti questo flag, gkectl assegna al file il nome user-cluster.yaml e lo inserisce nella directory corrente.

VERSION: il numero di versione desiderato. Ad esempio: gkectl create-config cluster --gke-on-prem-version=1.36.200-gke.118.

Acquisisci familiarità con il file di configurazione esaminando il documento File di configurazione del cluster utente. Ti consigliamo di tenere aperto questo documento in una scheda o finestra separata, perché dovrai consultarlo durante il completamento dei passaggi seguenti.

`name`

Imposta il campo name su un nome a tua scelta per il cluster utente.

`gkeOnPremVersion`

Questo campo è già compilato. Specifica la versione di Google Distributed Cloud. Ad esempio, 1.36.200-gke.118.

`enableAdvancedCluster`

Nella versione 1.31, se vuoi attivare la funzionalità cluster avanzata, imposta enableAdvancedCluster su true. Questo campo deve essere impostato su true se il cluster di amministrazione ha il cluster avanzato abilitato.

Tieni presente le seguenti differenze tra le versioni:

Nella versione 1.31, la funzionalità dei cluster avanzati è in anteprima:
- Puoi attivare il cluster avanzato al momento della creazione del cluster solo per i nuovi cluster 1.31.
- Dopo aver attivato il cluster avanzato, non potrai eseguire l'upgrade del cluster alla versione 1.32. Attiva il cluster avanzato solo in un ambiente di test.
Nella versione 1.32, la funzionalità cluster avanzato è in disponibilità generale.
- Per impostazione predefinita, i cluster utente vengono creati come cluster avanzati. Devi impostare esplicitamente enableAdvancedCluster su false se vuoi creare un cluster non avanzato.
- Per i cluster in cui è abilitata la funzionalità dei cluster avanzati, gli upgrade dei cluster sono supportati.
Nella versione 1.33 e successive, tutti i cluster vengono creati come cluster avanzati. Se imposti enableAdvancedCluster su false, la creazione del cluster non va a buon fine.

`enableControlplaneV2`

Per creare un cluster utente con Controlplane V2 abilitato, imposta enableControlplaneV2 su true.

Se attivi il cluster avanzato, devi impostare enableControlplaneV2 su true.

Quando il control plane v2 è abilitato, il control plane del cluster utente viene eseguito sui nodi nel cluster utente stesso. Ti consigliamo vivamente di attivare Controlplane V2.

kubeception

Se imposti questo campo su false, il cluster utilizzerà kubeception. Con kubeception, il control plane del cluster utente viene eseguito sui nodi del cluster di amministrazione.

Per un cluster kubeception:

Imposta enableControlplaneV2 su false.
Non compilare la sezione controlPlaneIPBlock.
Specifica gli indirizzi IP per i nodi del control plane del cluster utente nel file del blocco IP del cluster di amministrazione.

`enableDataplaneV2`

Imposta enableDataplaneV2 su true.

`vCenter`

I valori impostati nella sezione vCenter del file di configurazione del cluster di amministrazione sono globali. ovvero si applicano al cluster di amministrazione e ai cluster utente associati.

Per ogni cluster utente che crei, hai la possibilità di eseguire l'override di alcuni dei valori vCenter globali.

Per eseguire l'override di uno qualsiasi dei valori vCenter globali, compila i campi pertinenti nella sezione vCenter del file di configurazione del cluster utente.

In particolare, potresti voler utilizzare cluster vSphere separati per il cluster di amministrazione e i cluster utente e potresti voler utilizzare data center separati per il cluster di amministrazione e i cluster utente.

Utilizzo di un data center e un cluster vSphere

L'opzione predefinita prevede l'utilizzo di un data center e di un cluster vSphere per il cluster di amministrazione e il cluster utente. Per questa opzione, non impostare valori vCenter nel file di configurazione del cluster utente. I valori vCenter verranno ereditati dal cluster di amministrazione.

Utilizzo di cluster vSphere separati

Se vuoi creare un cluster utente che si trova nel proprio cluster vSphere, specifica un valore per vCenter.cluster nel file di configurazione del cluster utente.

Se il cluster di amministrazione e il cluster utente si trovano in cluster vSphere separati, possono trovarsi nello stesso data center o in data center diversi.

Utilizzo di data center vSphere separati

Il cluster utente e il cluster di amministrazione possono trovarsi in data center diversi. In questo caso, si trovano anche in cluster vSphere separati.

Se specifichi vCenter.datacenter nel file di configurazione del cluster utente, devi specificare anche:

vCenter.networkName
vCenter.datastore o vCenter.storagePolicyName
vCenter.cluster o vCenter.resourcePool

Utilizzo di account vCenter separati

Un cluster utente può utilizzare un account vCenter diverso, con un vCenter.credentials diverso, rispetto al cluster di amministrazione. L'account vCenter per il cluster di amministrazione deve accedere al data center del cluster di amministrazione, mentre l'account vCenter per il cluster utente deve accedere solo al data center del cluster utente.

Utilizzo di istanze separate di vCenter Server

In determinate situazioni, è opportuno creare un cluster utente che utilizzi la propria istanza di vCenter Server. In altre parole, il cluster di amministrazione e un cluster utente associato utilizzano istanze diverse di vCenter Server.

Ad esempio, in una località perimetrale, potresti voler avere una macchina fisica che esegue vCenter Server e una o più macchine fisiche che eseguono ESXi. Puoi quindi utilizzare l'istanza locale di vCenter Server per creare una gerarchia di oggetti vSphere, tra cui data center, cluster, pool di risorse, datastore e cartelle.

Compila l'intera sezione vCenter del file di configurazione del cluster utente. In particolare, specifica un valore per vCenter.address diverso dall'indirizzo del server vCenter specificato nel file di configurazione del cluster di amministrazione. Ad esempio:

vCenter:
  address: "vc-edge.example"
  datacenter: "vc-edge"
  cluster: "vc-edge-workloads"
  resourcePool: "vc-edge-pool
  datastore: "vc-edge-datastore
  caCertPath: "/usr/local/google/home/me/certs/edge-cacert.pem"
  credentials:
    fileRef:
      path: "credential.yaml"
      entry: "vCenter-edge"
  folder: "edge-vm-folder"

Compila anche il campo network.vCenter.networkName.

`network`

Decidi in che modo i nodi worker devono ottenere i propri indirizzi IP. Le opzioni sono:

Da un server DHCP configurato in precedenza. Imposta network.ipMode.type su "dhcp".
Da un elenco di indirizzi IP statici che fornisci. Imposta network.ipMode.type su "static" e crea un file di blocco IP che fornisca gli indirizzi IP statici. Per un esempio di file di blocco IP, consulta Esempio di file di configurazione compilati.

Se hai deciso di utilizzare indirizzi IP statici per i nodi worker, compila il campo network.ipMode.ipBlockFilePath.

I nodi del control plane per il cluster utente devono ottenere i propri indirizzi IP da un elenco di indirizzi statici forniti da te. Questo vale anche se i nodi worker ricevono i propri indirizzi da un server DHCP. Per specificare gli indirizzi IP statici per i nodi del control plane, compila la sezione network.controlPlaneIPBlock. Se vuoi un cluster utente ad alta affidabilità (HA), specifica tre indirizzi IP. In caso contrario, specifica un indirizzo IP.

Specifica i server DNS e NTP compilando la sezione hostConfig. Questi server DNS e NTP sono destinati ai nodi del control plane. Se utilizzi indirizzi IP statici per i nodi worker, questi server DNS e server NTP sono anche per i nodi worker.

network.podCIDR e network.serviceCIDR hanno valori precompilati che puoi lasciare invariati, a meno che non siano in conflitto con gli indirizzi già in uso nella tua rete. Kubernetes utilizza questi intervalli per assegnare indirizzi IP ai pod e ai servizi nel tuo cluster.

Che tu utilizzi un server DHCP o specifichi un elenco di indirizzi IP statici, devi avere un numero sufficiente di indirizzi IP disponibili per il cluster utente. Per una spiegazione del numero di indirizzi IP necessari, consulta Pianifica gli indirizzi IP.

`loadBalancer`

Riserva un VIP per il server API Kubernetes del cluster utente. Riserva un altro VIP per il servizio in entrata del cluster utente. Fornisci i tuoi VIP come valori per loadBalancer.vips.controlPlaneVIP e loadBalancer.vips.ingressVIP.

Decidi il tipo di bilanciamento del carico che vuoi utilizzare. Le opzioni sono:

Bilanciamento del carico in bundle MetalLB. Imposta loadBalancer.kind su "MetalLB". Compila anche la sezione loadBalancer.metalLB.addressPools e imposta enableLoadBalancer su true per almeno uno dei tuoi node pool. Per saperne di più, consulta Bilanciamento del carico in bundle con MetalLB.
Bilanciamento manuale del carico. Imposta loadBalancer.kind su "ManualLB" e compila la sezione manualLB. Per saperne di più, consulta Bilanciamento manuale del carico.

Per saperne di più sulle opzioni di bilanciamento del carico, consulta Panoramica del bilanciamento del carico.

`advancedNetworking`

Se prevedi di creare un gateway NAT in uscita, imposta advancedNetworking su true.

`multipleNetworkInterfaces`

Decidi se vuoi configurare più interfacce di rete per i pod e imposta multipleNetworkInterfaces di conseguenza.

`storage`

Se vuoi disattivare il deployment dei componenti CSI vSphere, imposta storage.vSphereCSIDisabled su true.

`masterNode`

Nella sezione masterNode, puoi specificare il numero di nodi del control plane che vuoi per il tuo cluster utente: specifica 3 per un cluster ad alta affidabilità (HA) o 1 per un cluster non HA. Puoi anche specificare un datastore per i nodi del control plane e se vuoi attivare il ridimensionamento automatico per i nodi del control plane.

Se il campo enableAdvancedCluster è true, devi impostare il campo replicas su 3. Solo i cluster utente ad alta disponibilità sono supportati sui cluster avanzati.

Ricorda che hai specificato gli indirizzi IP per i nodi del control plane nella sezione network.controlPlaneIPBlock.

`nodePools`

Un pool di nodi è un gruppo di nodi all'interno di un cluster che condividono la stessa configurazione. Ad esempio, i nodi di un pool potrebbero eseguire Windows e i nodi di un altro pool potrebbero eseguire Linux.

Devi specificare almeno un pool di nodi compilando la sezione nodePools.

Se attivi il cluster avanzato, imposta nodePools[i].osImageType su ubuntu_cgv2.

Per saperne di più, consulta Pool di nodi e Creazione e gestione dei pool di nodi.

`antiAffinityGroups`

Imposta antiAffinityGroups.enabled su true o false.

Questo campo specifica se Google Distributed Cloud crea regole anti-affinità Distributed Resource Scheduler (DRS) per i nodi worker, in modo da distribuirle in almeno tre host fisici del data center.

`stackdriver`

Se vuoi attivare Cloud Logging e Cloud Monitoring per il tuo cluster, compila la sezione stackdriver.

Questa sezione è obbligatoria per impostazione predefinita. In altre parole, se non compili questa sezione, devi includere il flag --skip-validation-stackdriver quando esegui gkectl create cluster.

Tieni presente i seguenti requisiti per i nuovi cluster:

L'ID in stackdriver.projectID deve essere lo stesso dell'ID in gkeConnect.projectID e cloudAuditLogging.projectID.
La regione Google Cloud impostata in stackdriver.clusterLocation deve essere la stessa della regione impostata in cloudAuditLogging.clusterLocation e gkeConnect.location. Inoltre, se gkeOnPremAPI.enabled è true, la stessa regione deve essere impostata in gkeOnPremAPI.location.

Se gli ID progetto e le regioni non sono gli stessi, la creazione del cluster non va a buon fine.

`gkeConnect`

Il cluster utente deve essere registrato in un parco risorse Google Cloud .

Compila la sezione gkeConnect per specificare un progetto host del parco risorse e un account di servizio associato. L'ID in gkeConnect.projectID deve essere lo stesso ID impostato in stackdriver.projectID e cloudAuditLogging.projectID. Se gli ID progetto non sono gli stessi, la creazione del cluster non va a buon fine.

In 1.28 e versioni successive, puoi facoltativamente specificare una regione in cui vengono eseguiti i servizi Fleet e Connect in gkeConnect.location. Se non includi questo campo, il cluster utilizza le istanze globali di questi servizi.

Se includi gkeConnect.location nel file di configurazione, la regione specificata deve essere la stessa configurata in cloudAuditLogging.clusterLocation, stackdriver.clusterLocation e gkeOnPremAPI.location. Se le regioni non sono le stesse, la creazione del cluster non va a buon fine.

`gkeOnPremAPI`

Nella versione 1.16 e successive, se l'API GKE on-prem è abilitata nel tuo progettoGoogle Cloud , tutti i cluster del progetto vengono registrati automaticamente nell'API GKE on-prem nella regione configurata in stackdriver.clusterLocation. La regione gkeOnPremAPI.location deve essere la stessa specificata in cloudAuditLogging.clusterLocation, gkeConnect.location (se il campo è incluso nel file di configurazione) e stackdriver.clusterLocation.

Se vuoi registrare tutti i cluster del progetto nell'API GKE On-Prem, assicurati di seguire i passaggi descritti in Prima di iniziare per attivare e utilizzare l'API GKE On-Prem nel progetto.
Se non vuoi registrare il cluster nell'API GKE On-Prem, includi questa sezione e imposta gkeOnPremAPI.enabled su false. Se non vuoi registrare cluster nel progetto, disabilita gkeonprem.googleapis.com (il nome del servizio per l'API GKE On-Prem) nel progetto. Per istruzioni, vedi Disabilitare i servizi.

`cloudAuditLogging`

Se vuoi integrare gli audit log del server API Kubernetes del tuo cluster con Cloud Audit Logs, compila la sezione cloudAuditLogging.

Tieni presente i seguenti requisiti:

Se attivi il cluster avanzato, imposta cloudAuditLogging.serviceAccountKeyPath sullo stesso percorso di stackdriver.serviceAccountKeyPath.
L'ID in cloudAuditLogging.projectID deve essere lo stesso dell'ID in gkeConnect.projectID e stackdriver.projectID.
La regione in cloudAuditLogging.clusterLocation deve essere la stessa di quella impostata in gkeConnect.location e stackdriver.clusterLocation. Inoltre, se gkeOnPremAPI.enabled è true, la stessa regione deve essere impostata in gkeOnPremAPI.location.

Se gli ID progetto e le regioni non sono gli stessi, la creazione del cluster non va a buon fine.

Esempio di file di configurazione compilati

Ecco un esempio di file di blocco IP e di file di configurazione del cluster utente:

user-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
      hostname: worker-vm-1
    - ip: 172.16.21.3
      hostname: worker-vm-2
    - ip: 172.16.21.4
      hostname: worker-vm-3
    - ip: 172.16.21.5
      hostname: worker-vm-4

user-cluster.yaml

apiVersion: v1
kind: UserCluster
name: "my-user-cluster"
gkeOnPremVersion: 1.36.200-gke.118
enableControlplaneV2: true
enableAdvancedCluster: true
network:
  hostConfig:
    dnsServers:
    - "203.0.113.2"
    - "198.51.100.2"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  serviceCIDR: 10.96.0.0/20
  podCIDR: 192.168.0.0/16
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.21.1"
    ips:
    - ip: "172.16.21.6"
      hostname: "cp-vm-1"
    - ip: "172.16.21.7"
      hostname: "cp-vm-2"
    - ip: "172.16.21.8"
      hostname: "cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    ingressVIP: "172.16.21.30"
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.21.30-172.16.21.39"
enableDataplaneV2: true
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  osImageType: "ubuntu_cgv2"
  enableLoadBalancer: true
antiAffinityGroups:
  enabled: true
gkeConnect:
  projectID: "my-project-123"
  location: "us-central1"
  registerServiceAccountKeyPath: "connect-register-sa-2203040617.json"
stackdriver:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  serviceAccountKeyPath: "log-mon-sa-2203040617.json"
  disableVsphereResourceMetrics: false
cloudAuditLogging:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  serviceAccountKeyPath: "log-mon-sa-2203040617.json"
autoRepair:
  enabled: true

Ecco i punti importanti da comprendere nell'esempio precedente:

Il campo nodePools.replicas è impostato su 3, il che significa che sono presenti tre nodi worker in "worker-node-pool". Tutti i nodi worker utilizzano indirizzi IP statici perché network.ipMode.type è impostato su "static".
Gli indirizzi IP statici per i nodi worker sono specificati in un file di blocco IP. Il file del blocco IP contiene quattro indirizzi, anche se sono presenti solo tre nodi worker. L'indirizzo IP aggiuntivo è necessario durante l'upgrade, l'aggiornamento e la riparazione automatica del cluster.
I server DNS e NTP sono specificati nella sezione hostConfig. In questo esempio, questi server DNS e server NTP sono destinati ai nodi del control plane e ai nodi worker. Questo perché i nodi worker hanno indirizzi IP statici. Se i nodi worker dovessero ottenere i propri indirizzi IP da un server DHCP, questi server DNS e server NTP sarebbero solo per i nodi del control plane.
Gli indirizzi IP statici per i tre nodi del control plane sono specificati nella sezione network.controlPlaneIPBlock del file di configurazione del cluster utente. Non è necessario un indirizzo IP aggiuntivo in questo blocco.
Controlplane V2 è abilitato.
Il campo masterNode.replicas è impostato su 3, quindi il cluster avrà un control plane ad alta affidabilità.
Il VIP del control plane e il VIP Ingress si trovano entrambi nella stessa VLAN dei nodi worker e dei nodi del control plane.
I VIP riservati ai servizi di tipo LoadBalancer sono specificati nella sezione loadBalancer.metalLB.addressPools del file di configurazione del cluster utente. Questi VIP si trovano nella stessa VLAN dei nodi worker e dei nodi del control plane. L'insieme di VIP specificato in questa sezione deve includere il VIP Ingress e non deve includere il VIP del control plane.
Il file di configurazione del cluster utente non include una sezione vCenter. Pertanto, il cluster utente utilizza le stesse risorse vSphere del cluster di amministrazione.

Convalida il file di configurazione

Dopo aver compilato il file di configurazione del cluster utente, esegui il comando gkectl check-config per verificare che il file sia valido. Il supporto del comando gkectl check-config sui cluster utente avanzati è stato aggiunto nelle seguenti versioni: 1.32.700+, 1.33.300+ e 1.34.0 e successive. Se installi una versione precedente su un cluster Advanced, il comando non andrà a buon fine.

gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Sostituisci quanto segue:

ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig per il tuo cluster di amministrazione
USER_CLUSTER_CONFIG: il percorso del file di configurazione del cluster utente

Se il comando restituisce messaggi di errore, risolvi i problemi e convalida nuovamente il file.

Se vuoi saltare le convalide che richiedono più tempo, passa il flag --fast. Per saltare singole convalide, utilizza i flag --skip-validation-xxx. Per scoprire di più sul comando check-config, consulta Esecuzione dei controlli preflight.

(Facoltativo) Importa le immagini sistema operativo in vSphere ed esegui il push delle immagini container in un registry privato

Esegui gkectl prepare se una delle seguenti condizioni è vera:

Il cluster utente si trova in un data center vSphere diverso da quello del cluster di amministrazione.
Il cluster utente ha un vCenter Server diverso da quello del cluster di amministrazione.
Il cluster utente ha una cartella vCenter diversa da quella del cluster di amministrazione.
Il cluster utente utilizza un Container Registry privato diverso dal registry privato utilizzato dal cluster di amministrazione.

gkectl prepare --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --bundle-path BUNDLE \
    --user-cluster-config USER_CLUSTER_CONFIG

Sostituisci quanto segue:

ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione
BUNDLE: il percorso del file del bundle. Questo file si trova sulla tua workstation di amministrazione in /var/lib/gke/bundles/. Ad esempio:
```
/var/lib/gke/bundles/gke-onprem-vsphere-1.36.200-gke.118-full.tgz
```
USER_CLUSTER_CONFIG: il percorso del file di configurazione del cluster utente

Creazione di un cluster utente

Esegui questo comando per creare un cluster utente:

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Individua il file kubeconfig del cluster utente

Il comando gkectl create cluster crea un file kubeconfig denominato USER_CLUSTER_NAME-kubeconfig nella directory attuale. Questo file kubeconfig ti servirà in un secondo momento per interagire con il cluster utente.

Il file kubeconfig contiene il nome del cluster utente. Per visualizzare il nome del cluster, puoi eseguire:

kubectl config get-clusters --kubeconfig USER_CLUSTER_KUBECONFIG

L'output mostra il nome del cluster. Ad esempio:

NAME
my-user-cluster

Se vuoi, puoi modificare il nome e la posizione del file kubeconfig.

Verifica che il cluster utente sia in esecuzione

Verifica che il cluster utente sia in esecuzione:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster utente.

L'output mostra i nodi del cluster utente. Ad esempio:

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

Console

Inizia

Nella console Google Cloud , vai alla pagina Crea cluster di VM.

Vai a Crea cluster di VM
Seleziona il progetto Google Cloud in cui vuoi creare il cluster. Il progetto selezionato viene utilizzato 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.
Nella sezione Scegli il tipo di cluster, seleziona Crea un cluster utente per un cluster di amministrazione esistente.

Impostazioni di base del cluster

Inserisci le informazioni di base sul cluster.

Inserisci un nome per il cluster utente.
In Cluster di amministrazione, seleziona il cluster di amministrazione dall'elenco. Se non hai specificato un nome per il cluster di amministrazione durante la creazione, il nome viene generato nel formato gke-admin-[HASH]. Se non riconosci il nome del cluster di amministrazione, esegui questo comando 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 viene visualizzato, consulta la sezione sulla risoluzione dei problemi Il cluster di amministrazione non viene visualizzato nell'elenco a discesa Cluster basics.
Nel campo Località API GCP, seleziona la regione Google Cloud dall'elenco. Questa impostazione specifica la regione in cui vengono eseguiti i seguenti servizi e API:
- API GKE On-Prem (gkeonprem.googleapis.com)
- Servizio per flotte (gkehub.googleapis.com)
- Collega il servizio (gkeconnect.googleapis.com)
Questa impostazione controlla anche la regione in cui vengono archiviati i seguenti elementi:
- 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 amministrativo creato da Cloud Audit Logs
Il nome, il progetto e la località del cluster identificano in modo univoco il cluster in Google Cloud.
Seleziona la versione di Google Distributed Cloud per il tuo cluster utente.
In qualità di creatore del cluster, ti vengono concessi i privilegi amministrativi del cluster. Se vuoi, inserisci l'indirizzo email di un altro utente che amministrerà il cluster nel campo Utente amministratore del cluster nella sezione Autorizzazione.

Quando il cluster viene creato, l'API GKE On-Prem applica al cluster i criteri di controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes per concedere a te e ad altri utenti amministratori il ruolo Kubernetes clusterrole/cluster-admin, che fornisce l'accesso completo a ogni risorsa del cluster in tutti i namespace.

Nota: oltre alle policy RBAC di Kubernetes, devi concedere alcuni ruoli Identity and Access Management (IAM) agli utenti che non sono Project Owner. Per maggiori dettagli sulla concessione dei ruoli IAM, consulta Concedi i ruoli richiesti.
Fai clic su Avanti per andare alla sezione Control plane.

Control plane

Tutti i campi della sezione Control plane sono impostati con valori predefiniti. Esamina i valori predefiniti e, se necessario, modificali.

Nel campo vCPU del nodo del control plane, inserisci il numero di vCPU (minimo 4) per ciascun nodo del control plane del cluster utente.
Nel campo Memoria del nodo del control plane, inserisci la dimensione della memoria in MiB (minimo 8192; il valore deve essere un multiplo di 4) per ciascun control plane del tuo cluster utente.
In Nodi del control plane, seleziona il numero di nodi del control plane per il cluster utente. Ad esempio, puoi selezionare 1 nodo del control plane per un ambiente di sviluppo e 3 nodi del control plane per ambienti di produzione ad alta affidabilità (HA).
Facoltativamente, seleziona Ridimensionamento automatico dei nodi. Il ridimensionamento indica che le risorse di vCPU e memoria assegnate a un nodo vengono regolate automaticamente. Se questa opzione è abilitata, i nodi del control plane per il cluster utente vengono ridimensionati in base al numero di nodi worker nel cluster utente. Man mano che aggiungi altri nodi worker al cluster utente, le dimensioni dei nodi del control plane aumentano.
Nella sezione IP dei nodi del control plane, inserisci gli indirizzi IP del gateway, della subnet mask e dei nodi del control plane.
Fai clic su Avanti per andare alla sezione Networking.

Networking

In questa sezione, specifichi gli indirizzi IP dei nodi, dei pod e dei servizi del tuo 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 saperne di più, consulta Quanti indirizzi IP sono necessari per un cluster utente?.

Nella sezione IP dei nodi, 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.
- Statico: scegli Statico se vuoi fornire indirizzi IP statici per i nodi del cluster o se vuoi configurare il bilanciamento del carico manuale.
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 dei nodi nel cluster utente. Puoi inserire un singolo indirizzo IPv4 (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 nome host. Se non inserisci un nome host, Google Distributed Cloud utilizza il nome della VM di vSphere come nome host.
4. Fai clic su + Aggiungi indirizzo IP per inserire altri indirizzi IP, se necessario.
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 i tuoi intervalli di indirizzi, consulta Indirizzi IP per pod e servizi per le best practice.
Se hai selezionato Modalità IP statico o Abilita control plane 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. Se vuoi, inserisci i domini di ricerca DNS.
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 saperne di più, consulta la panoramica del bilanciatore del carico.

Seleziona il tipo di bilanciatore del carico dall'elenco.

Abbinato a MetalLB

Configura il bilanciamento del carico integrato 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 sul confronto con le altre opzioni di bilanciamento del carico, consulta Bilanciamento del carico integrato con MetalLB.

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 che contenga il VIP Ingress nella notazione CIDR (ad es. 192.0.2.0/26) o la notazione dell'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 rientrano 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 degli indirizzi IP, seleziona una delle seguenti opzioni:
  - Automatico: scegli questa opzione se vuoi che il controller MetalLB assegni automaticamente gli indirizzi IP del 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 che presentano bug se vuoi che il controller MetalLB non utilizzi indirizzi del pool che terminano con .0 o .255. In questo modo si evita il problema dei dispositivi consumer con bug che eliminano erroneamente il traffico inviato a questi indirizzi IP speciali.
6. Al termine, fai clic su Fine.
Se necessario, fai clic su Add Address Pool (Aggiungi pool di indirizzi).
Nella sezione IP virtuali, inserisci quanto segue:
- VIP del control plane: 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 Ingress: l'indirizzo IP da configurare sul bilanciatore del carico per il proxy Ingress. Devi aggiungerlo a un pool di indirizzi nella sezione Pool di indirizzi.
Fai clic su Continua.

BIG-IP di F5

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

Il nome utente e la password di F5 vengono ereditati dal cluster di amministrazione.

Nella sezione IP virtuali, inserisci quanto segue:
- VIP del control plane: l'indirizzo IP di destinazione da utilizzare per il traffico inviato al server API Kubernetes.
- VIP Ingress: l'indirizzo IP da configurare sul bilanciatore del carico per il proxy Ingress.
Nel campo Indirizzo, inserisci l'indirizzo del bilanciatore del carico BIG-IP di F5.
Nel campo Partizione, inserisci il nome di una partizione BIG-IP che hai creato per il cluster utente.
Nel campo Nome pool sNAT, inserisci il nome del pool SNAT, se applicabile.
Fai clic su Continua.

Manuale

Puoi utilizzare un bilanciamento manuale del carico per il cluster utente solo se il cluster di amministrazione utilizza un bilanciamento manuale del carico. In Google Distributed Cloud, il server API Kubernetes e il proxy in entrata sono esposti ciascuno da un servizio Kubernetes di tipo LoadBalancer. Scegli i tuoi valori nodePort nell'intervallo 30000-32767 per questi servizi. Per il proxy in entrata, scegli un valore nodePort sia per il traffico HTTP che per quello HTTPS. Per saperne di più, consulta Attivazione della modalità di bilanciamento manuale del carico.

Nella sezione IP virtuali, inserisci quanto segue:
- VIP del control plane: l'indirizzo IP di destinazione da utilizzare per il traffico inviato al server API Kubernetes.
- VIP Ingress: l'indirizzo IP da configurare sul bilanciatore del carico per il proxy Ingress.
Nel campo Porta nodo control plane, inserisci un valore nodePort per il server API Kubernetes.
Nel campo Porta nodo HTTP Ingress, inserisci un valore nodePort per il traffico HTTP verso il proxy in entrata.
Nel campo Porta nodo HTTPS Ingress, inserisci un valore nodePort per il traffico HTTPS verso il proxy in entrata.
Nel campo Porta del nodo server Konnectivity, inserisci un valore nodePort per il server Konnectivity.
Fai clic su Continua.

Funzionalità

In questa sezione vengono visualizzate le funzionalità e le operazioni attivate sul cluster.

Le seguenti funzionalità vengono attivate automaticamente e non possono essere disattivate:
- Cloud Logging dei servizi di sistema
- Cloud Monitoring dei servizi di sistema
- L'audit log delle attività di amministrazione
Le seguenti funzionalità sono attive per impostazione predefinita, ma puoi disattivarle:
- Attiva driver CSI vSphere: chiamato anche plug-in vSphere Container Storage. Il driver Container Storage Interface (CSI) viene eseguito in un cluster Kubernetes di cui è stato eseguito il deployment in vSphere per il provisioning di volumi permanenti nell'archiviazione di vSphere. Per saperne di più, consulta Utilizzo del driver vSphere Container Storage Interface.
- Abilita gruppi anti-affinità: le regole anti-affinità Distributed Resource Scheduler (DRS) di VMware vengono create automaticamente per i nodi del cluster utente, in modo da distribuirle in almeno tre host fisici del data center. Assicurati che l'ambiente vSphere soddisfi i requisiti.
Nota: se hai seguito la procedura Configura un'infrastruttura minima, hai un solo host ESXi, quindi assicurati di deselezionare Abilita gruppi anti-affinità.
Fai clic su Avanti per configurare un pool di nodi

Node pool

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

Nella sezione Valori predefiniti del node pool, completa quanto segue:
1. Inserisci il Nome del node pool o accetta "default-pool" come nome.
2. Inserisci il numero di vCPUs per ogni nodo nel pool (minimo 4 per worker 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; il valore deve essere un multiplo di 4).
4. Nel campo Nodi, inserisci il numero di nodi nel pool (minimo 3). Se hai inserito indirizzi IP statici per gli IP dei nodi nella sezione Networking, assicurati di aver inserito un numero sufficiente di indirizzi IP per ospitare questi nodi del cluster utente.
5. Seleziona il tipo di immagine sistema operativo: Ubuntu, Ubuntu Containerd o COS.
6. Inserisci la dimensione del disco di avvio in gibibyte (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.
Nella sezione Metadati del node pool (facoltativo), se vuoi aggiungere etichette e taint di Kubernetes, segui questi passaggi:
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 taint. Inserisci Chiave, Valore ed Effetto per l'effetto taint. Ripeti queste operazioni in base alle necessità.
Fai clic su Verifica e completa per creare il cluster utente. La creazione del cluster utente richiede almeno 15 minuti. La console visualizza i messaggi di stato mentre verifica le impostazioni e crea il cluster nel tuo data center.

Se si verifica un errore durante la verifica delle impostazioni, la console visualizza un messaggio di errore che dovrebbe essere sufficientemente chiaro da consentirti di risolvere il problema di configurazione e riprovare a creare il cluster.

Per saperne di più sui possibili errori e su come risolvere il problema, consulta Risolvi i problemi di creazione dei cluster utente nella console Google Cloud .

gcloud CLI

Per creare un cluster utente, utilizza il seguente comando:

gcloud container vmware clusters create

Dopo aver creato il cluster, devi creare almeno un pool di nodi utilizzando il seguente 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 del file di configurazione del cluster utente. Per aiutarti a iniziare, puoi testare un comando completo nella sezione degli esempi.

Raccogliere informazioni

Raccogli alcune informazioni necessarie per creare il cluster.

Recupera il nome e la località di appartenenza al parco risorse del cluster di amministrazione:
```
gcloud container fleet memberships list \
    --project=FLEET_HOST_PROJECT_ID
```
Sostituisci FLEET_HOST_PROJECT_ID con l'ID del progetto in cui è registrato il cluster di amministrazione.

L'output è simile al seguente:
```
NAME             EXTERNAL_ID                           LOCATION
admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1
```
La località specifica dove vengono eseguiti i servizi Fleet e Connect. I cluster di amministrazione creati prima della versione 1.28 sono gestiti dai servizi globali Fleet e Connect. Nella versione 1.28 e successive, puoi specificare global o una regione Google Cloud quando crei il cluster di amministrazione. Specifica la regione nel flag --admin-cluster-membership-location nei comandi di esempio riportati di seguito.
Ottieni 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 \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --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.
- ADMIN_CLUSTER_REGION: la regione di appartenenza al parco risorse del cluster di amministrazione. Può essere globale o una regione Google Cloud. Utilizza la località del cluster di amministrazione dall'output di gcloud container fleet memberships list.
- REGION: la regione Google Cloud che utilizzerai quando crei il cluster utente. Questa è la regione in cui l'API GKE On-Prem viene eseguita e archivia i suoi metadati.
  - Se il cluster di amministrazione è registrato nell'API GKE On-Prem, utilizza la stessa regione del cluster di amministrazione. Per scoprire la regione del cluster di amministrazione, esegui questo comando:
```
gcloud container vmware admin-clusters list \
  --project=FLEET_HOST_PROJECT_ID \
  --location=-
```
  - Se il cluster di amministrazione non è registrato nell'API GKE On-Prem, specifica us-west1 o un'altra regione supportata. Se in un secondo momento registri il cluster di amministrazione nell'API GKE On-Prem, utilizza la stessa regione in cui si trova il cluster utente.
L'output del comando gcloud container vmware clusters query-version-config è simile al seguente:
```
versions:
- isInstalled: true
  version: 1.28.800-gke.109
- version: 1.29.0-gke.1456
- version: 1.29.100-gke.248
- version: 1.29.200-gke.245
- version: 1.29.300-gke.184
```
Il comando restituisce anche una spiegazione delle versioni che puoi utilizzare per la creazione o l'upgrade del cluster utente. Le versioni consentite 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 utilizzare una versione installata sul cluster di amministrazione, vai alla sezione Esempi per creare il cluster utente.

Installa un'altra versione

Un cluster di amministrazione può gestire cluster utente di versioni diverse. L'output del comando query-version-config elenca altre versioni che puoi utilizzare quando crei il cluster. Se vuoi creare un cluster utente con una versione diversa da quella del 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:

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

Sostituisci VERSION con una delle versioni elencate nell'output del comando query-version-config.

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

Se esegui nuovamente gcloud container vmware clusters query-version-config, la versione specificata viene annotata con isInstalled: true.

Esempi

Gli esempi seguenti mostrano come creare un cluster utente con diversi bilanciatori del carico con Controlplane V2 abilitato. Con Controlplane V2, il control plane per un cluster utente viene eseguito su uno o più nodi nel cluster utente stesso. Ti consigliamo di abilitare Controlplane V2. Nella versione 1.30 e successive, i nuovi cluster utente devono avere Controlplane V2 abilitato. Per informazioni sulle opzioni di bilanciamento del carico disponibili, consulta la panoramica del bilanciatore del carico.

La maggior parte degli esempi utilizza i valori predefiniti per la configurazione dei nodi del control plane. Se vuoi modificare una delle impostazioni predefinite, includi i flag descritti nella sezione Flag del control plane. Se necessario, puoi anche modificare alcune impostazioni di vSphere.

Prima di eseguire il comando gcloud per creare il cluster, puoi includere --validate-only per convalidare la configurazione specificata nei flag del comando gcloud. Quando è tutto pronto per creare il cluster, rimuovi questo flag ed esegui il comando.

Se ricevi un errore dopo che il comando gcloud container vmware clusters create è stato eseguito per circa un minuto o più, controlla se il cluster è stato creato parzialmente eseguendo il seguente comando:

gcloud container vmware clusters list \
    --project=FLEET_HOST_PROJECT_ID \
    --location=-

Se il cluster non è elencato nell'output, correggi l'errore ed esegui nuovamente gcloud container vmware clusters create.

Se il cluster è elencato nell'output, eliminalo utilizzando il seguente comando:

gcloud container vmware clusters delete USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --force \
    --allow-missing

Quindi correggi l'errore ed esegui di nuovo gcloud container vmware clusters create.

Dopo che il cluster è in esecuzione, devi aggiungere un pool di nodi prima di eseguire il deployment dei workload, come descritto nella sezione Crea un node pool.

MetalLB e DHCP

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

Puoi utilizzare MetalLB per il cluster utente solo se il cluster di amministrazione utilizza 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 integrato con MetalLB.

Il comando di esempio crea un cluster utente con le seguenti caratteristiche, che puoi modificare in base alle esigenze del tuo ambiente.

Flag	Descrizione
`--admin-users`	Concede a te e a un altro utente i diritti amministrativi completi sul cluster.
`--enable-control-plane-v2`	Abilita Controlplane V2, che è consigliato e richiesto nella versione 1.30 e successive.
`--control-plane-ip-block`	Un indirizzo IP per il nodo del control plane. Per creare un cluster utente ad alta affidabilità (HA), specifica tre indirizzi IP e aggiungi il flag `--replicas=3`.
`--metal-lb-config-address-pools`	Due pool di indirizzi per il bilanciatore del carico MetalLB. Devi avere almeno un pool di indirizzi e puoi specificarne altri, se necessario. Per comodità, l'esempio contiene un pool di indirizzi con il nome "ingress-vip-pool" per ricordare che l'indirizzo IP del VIP Ingress deve trovarsi in uno dei pool di indirizzi. Puoi specificare il CIDR per un singolo indirizzo IP aggiungendo `/32` all'indirizzo IP.

gcloud container vmware clusters create USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --location=REGION \
    --version=VERSION \
    --admin-users=YOUR_EMAIL_ADDRESS \
    --admin-users=ANOTHER_EMAIL_ADDRESS \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=AVOID_BUGGY_IPS,manual-assign=MANUAL_ASSIGN,addresses=IP_ADDRESS_RANGE_1' \
    --metal-lb-config-address-pools='pool=ingress-vip-pool,avoid-buggy-ips=False,manual-assign=True,addresses=INGRESS_VIP/32' \
    --enable-control-plane-v2 \
    --dns-servers=DNS_SERVER_1 \
    --ntp-servers=NTP_SERVER_1 \
    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1 CP_HOST_1' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --enable-dhcp

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:
- contenere al massimo 40 caratteri
- contenere solo caratteri alfanumerici minuscoli o un trattino (-)
- iniziare con un carattere alfabetico
- terminare 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 registrato automaticamente 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 seguente formato:
```
    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 Fleet (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 vengono archiviati i seguenti elementi:
- 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 amministrativo creato da Cloud Audit Logs
Il nome, il progetto e la località del cluster identificano in modo univoco il cluster in Google Cloud.

Importante Se prevedi di installare Cloud Service Mesh, devi installare la versione 1.19.3 o successive. Questo è necessario perché i servizi Fleet e Connect vengono eseguiti in una regione.
VERSION: la versione di Google Distributed Cloud per il tuo 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 amministrativi 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 quello dell'altro amministratore. Ad esempio, per aggiungere due amministratori:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
Quando il cluster viene creato, l'API GKE On-Prem applica al cluster i criteri di controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes per concedere a te e ad altri utenti amministratori il ruolo Kubernetes clusterrole/cluster-admin, che fornisce l'accesso completo a ogni risorsa del cluster in tutti i namespace.

Nota: oltre alle policy RBAC di Kubernetes, devi concedere alcuni ruoli Identity and Access Management (IAM) agli utenti che non sono Project Owner. Per informazioni dettagliate sulla concessione dei ruoli IAM, consulta Concedi i ruoli richiesti.

SERVICE_CIDR_BLOCK: un intervallo di indirizzi IP, in formato CIDR, da utilizzare per i servizi nel cluster. Deve essere un intervallo di almeno /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: Includere questo flag per specificare la configurazione dei pool di indirizzi da utilizzare 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 imposti questo valore su True, il controller MetalLB non assegnerà ai servizi indirizzi IP che terminano con .0 o .255. In questo modo si evita il problema dei dispositivi consumer con bug che eliminano erroneamente il traffico inviato a questi indirizzi IP speciali. 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. In seguito, uno sviluppatore può creare un servizio di tipo LoadBalancer e specificare manualmente uno degli indirizzi del pool. Se non specificato, manual-assign è impostato su False.
- Nell'elenco di addresses: ogni indirizzo deve essere un intervallo nella notazione CIDR o nel formato di 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 del VIP Ingress deve trovarsi in uno dei pool di indirizzi MetalLB.

--enable-dhcp: includi --enable-dhcp se vuoi che i nodi del cluster ricevano il proprio 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 manuale del carico.

MetalLB e IP statici

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

Il comando di esempio crea un cluster utente con le seguenti caratteristiche, che puoi modificare in base alle esigenze del tuo ambiente.

Flag	Descrizione
`--admin-users`	Concede a te e a un altro utente i diritti amministrativi completi sul cluster.
`--enable-control-plane-v2`	Abilita Controlplane V2, che è consigliato e richiesto nella versione 1.30 e successive.
`--control-plane-ip-block`	Un indirizzo IP per il nodo del control plane. Per creare un cluster utente ad alta affidabilità (HA), specifica tre indirizzi IP e aggiungi il flag `--replicas=3`.
`--metal-lb-config-address-pools`	Due pool di indirizzi per il bilanciatore del carico MetalLB. Devi avere almeno un pool di indirizzi e puoi specificarne altri, se necessario. Per comodità, l'esempio contiene un pool di indirizzi con il nome "ingress-vip-pool" per ricordare che l'indirizzo IP del VIP Ingress deve trovarsi in uno dei pool di indirizzi. Puoi specificare il CIDR per un singolo indirizzo IP aggiungendo `/32` all'indirizzo IP.
`--static-ip-config-ip-blocks`	Quattro indirizzi IP per i nodi worker nei cluster. È incluso un indirizzo per un nodo aggiuntivo che può essere utilizzato durante l'upgrade e l'aggiornamento. Se necessario, puoi specificare più indirizzi IP. Il nome host è facoltativo.

gcloud container vmware clusters create USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --location=REGION \
    --version=VERSION \
    --admin-users=YOUR_EMAIL_ADDRESS \
    --admin-users=ANOTHER_EMAIL_ADDRESS \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=AVOID_BUGGY_IPS,manual-assign=MANUAL_ASSIGN,addresses=IP_ADDRESS_RANGE_1' \
    --metal-lb-config-address-pools='pool=ingress-vip-pool,avoid-buggy-ips=False,manual-assign=True,addresses=INGRESS_VIP/32' \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1 CP_HOST_1' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1 HOST_1;IP_ADDRESS_2 HOST_2;IP_ADDRESS_3 HOST_3;IP_ADDRESS_4 HOST_4' \
    --dns-servers=DNS_SERVER_1 \
    --ntp-servers=NTP_SERVER_1

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:
- contenere al massimo 40 caratteri
- contenere solo caratteri alfanumerici minuscoli o un trattino (-)
- iniziare con un carattere alfabetico
- terminare 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 registrato automaticamente 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 seguente formato:
```
    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 Fleet (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 vengono archiviati i seguenti elementi:
- 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 amministrativo creato da Cloud Audit Logs
Il nome, il progetto e la località del cluster identificano in modo univoco il cluster in Google Cloud.

Importante Se prevedi di installare Cloud Service Mesh, devi installare la versione 1.19.3 o successive. Questo è necessario perché i servizi Fleet e Connect vengono eseguiti in una regione.
VERSION: la versione di Google Distributed Cloud per il tuo 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 amministrativi 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 quello dell'altro amministratore. Ad esempio, per aggiungere due amministratori:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
Quando il cluster viene creato, l'API GKE On-Prem applica al cluster i criteri di controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes per concedere a te e ad altri utenti amministratori il ruolo Kubernetes clusterrole/cluster-admin, che fornisce l'accesso completo a ogni risorsa del cluster in tutti i namespace.

Nota: oltre alle policy RBAC di Kubernetes, devi concedere alcuni ruoli Identity and Access Management (IAM) agli utenti che non sono Project Owner. Per informazioni dettagliate sulla concessione dei ruoli IAM, consulta Concedi i ruoli richiesti.

SERVICE_CIDR_BLOCK: un intervallo di indirizzi IP, in formato CIDR, da utilizzare per i servizi nel cluster. Deve essere un intervallo di almeno /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: Includere questo flag per specificare la configurazione dei pool di indirizzi da utilizzare 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 imposti questo valore su True, il controller MetalLB non assegnerà ai servizi indirizzi IP che terminano con .0 o .255. In questo modo si evita il problema dei dispositivi consumer con bug che eliminano erroneamente il traffico inviato a questi indirizzi IP speciali. 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. In seguito, uno sviluppatore può creare un servizio di tipo LoadBalancer e specificare manualmente uno degli indirizzi del pool. Se non specificato, manual-assign è impostato su False.
- Nell'elenco di addresses: ogni indirizzo deve essere un intervallo nella notazione CIDR o nel formato di 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 del VIP Ingress deve trovarsi in uno dei pool di indirizzi MetalLB.

--static-ip-config-ip-blocks: specifica il gateway predefinito, la subnet mask e un elenco degli 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.
- Non sono consentiti spazi vuoti, tranne tra un indirizzo IP e un nome host.
Nell'elenco degli indirizzi IP:
- Puoi specificare un singolo indirizzo IP o un blocco di indirizzi IP CIDR.
- 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 non specifichi un nome host, Google Distributed Cloud utilizza il nome della VM di 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 utilizzabili 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 di riferimento temporale che le VM devono utilizzare.

LB 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 worker del cluster.

Puoi utilizzare un bilanciatore del carico manuale per il cluster utente solo se il cluster di amministrazione utilizza un bilanciatore del carico manuale. In Google Distributed Cloud, il server API, il proxy in entrata e il servizio componente 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 30000-32767 per questi servizi. Per il proxy in entrata, scegli un valore nodePort sia per il traffico HTTP che per quello HTTPS. Per saperne di più, consulta Attivazione della modalità di bilanciamento manuale del carico.

Il comando di esempio crea un cluster utente con le seguenti caratteristiche, che puoi modificare in base alle esigenze del tuo ambiente.

Flag	Descrizione
`--admin-users`	Concede a te e a un altro utente i diritti amministrativi completi sul cluster.
`--enable-control-plane-v2`	Abilita Controlplane V2, che è consigliato e richiesto nella versione 1.30 e successive.
`--control-plane-ip-block`	Un indirizzo IP per il nodo del control plane. Per creare un cluster utente ad alta affidabilità (HA), specifica tre indirizzi IP e aggiungi il flag `--replicas=3`.
`--static-ip-config-ip-blocks`	Quattro indirizzi IP per i nodi worker nei cluster. È incluso un indirizzo per un nodo aggiuntivo che può essere utilizzato durante l'upgrade e l'aggiornamento. Se necessario, puoi specificare più indirizzi IP. Il nome host è facoltativo.

gcloud container vmware clusters create USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --location=REGION \
    --version=VERSION \
    --admin-users=YOUR_EMAIL_ADDRESS \
    --admin-users=ANOTHER_EMAIL_ADDRESS \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1 CP_HOST_1' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --ingress-http-node-port=INGRESS_HTTP_NODE_PORT \
    --ingress-https-node-port=INGRESS_HTTPS_NODE_PORT \
    --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1 HOST_1;IP_ADDRESS_2 HOST_2;IP_ADDRESS_3 HOST_3;IP_ADDRESS_4 HOST_4' \
    --dns-servers=DNS_SERVER_1 \
    --ntp-servers=NTP_SERVER_1

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:
- contenere al massimo 40 caratteri
- contenere solo caratteri alfanumerici minuscoli o un trattino (-)
- iniziare con un carattere alfabetico
- terminare 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 registrato automaticamente 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 seguente formato:
```
    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 Fleet (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 vengono archiviati i seguenti elementi:
- 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 amministrativo creato da Cloud Audit Logs
Il nome, il progetto e la località del cluster identificano in modo univoco il cluster in Google Cloud.

Importante Se prevedi di installare Cloud Service Mesh, devi installare la versione 1.19.3 o successive. Questo è necessario perché i servizi Fleet e Connect vengono eseguiti in una regione.
VERSION: la versione di Google Distributed Cloud per il tuo 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 amministrativi 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 quello dell'altro amministratore. Ad esempio, per aggiungere due amministratori:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
Quando il cluster viene creato, l'API GKE On-Prem applica al cluster i criteri di controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes per concedere a te e ad altri utenti amministratori il ruolo Kubernetes clusterrole/cluster-admin, che fornisce l'accesso completo a ogni risorsa del cluster in tutti i namespace.

Nota: oltre alle policy RBAC di Kubernetes, devi concedere alcuni ruoli Identity and Access Management (IAM) agli utenti che non sono Project Owner. Per informazioni dettagliate sulla concessione dei ruoli IAM, consulta Concedi i ruoli richiesti.

SERVICE_CIDR_BLOCK: un intervallo di indirizzi IP, in formato CIDR, da utilizzare per i servizi nel cluster. Deve essere un intervallo di almeno /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 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 Ingress.

Esempio: --ingress-vip=203.0.113.4
INGRESS_HTTP_NODE_PORT: un valore nodePort per il traffico HTTP verso il proxy in entrata (ad esempio 30243).
INGRESS_HTTPS_NODE_PORT: un valore nodePort per il traffico HTTPS verso il proxy in entrata (ad esempio 30879).

--static-ip-config-ip-blocks: specifica il gateway predefinito, la subnet mask e un elenco degli 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.
- Non sono consentiti spazi vuoti, tranne tra un indirizzo IP e un nome host.
Nell'elenco degli indirizzi IP:
- Puoi specificare un singolo indirizzo IP o un blocco di indirizzi IP CIDR.
- 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 non specifichi un nome host, Google Distributed Cloud utilizza il nome della VM di 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 utilizzabili 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 di riferimento temporale che le VM devono utilizzare.

Flag del control plane

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

--cpus=vCPUS: il numero di vCPU (minimo 4) per ciascun nodo del control plane per il tuo cluster utente. Se non specificato, il valore predefinito è 4 vCPU.
--memory=MEMORY: la dimensione della memoria in mebibyte (MiB) per ciascun nodo del control plane per il 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 control plane per il tuo cluster utente. Ad esempio, puoi selezionare 1 nodo del control plane per un ambiente di sviluppo e 3 nodi del control plane per ambienti di produzione ad alta affidabilità (HA).
--enable-auto-resize: se vuoi attivare il ridimensionamento automatico dei nodi del control plane per il cluster utente, includi --enable-auto-resize. Il ridimensionamento significa che le risorse vCPU e di memoria assegnate a un nodo vengono regolate automaticamente. Se questa opzione è abilitata, i nodi del control plane per il cluster utente vengono ridimensionati in base al numero di nodi worker nel cluster utente. Man mano che aggiungi altri nodi worker al cluster utente, le dimensioni dei nodi del control plane aumentano.
--enable-control-plane-v2: per abilitare Controlplane V2, che consigliamo, includi questo flag. Quando il control plane v2 è abilitato, il control plane per un cluster utente viene eseguito su uno o più nodi nel cluster utente stesso. Nella versione 1.30 e successive, è richiesto Controlplane V2.

Quando attivi Controlplane V2, devi anche specificare i seguenti flag:
- --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 di riferimento ora che le VM devono 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.
  - Gli spazi vuoti non sono consentiti, tranne tra un indirizzo IP e un nome host.
    
    Nell'elenco degli indirizzi IP:
  - Puoi specificare un singolo indirizzo IP o un blocco di indirizzi IP CIDR.
  - 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 utilizzabili dagli host. 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

Se necessario, specifica i seguenti flag facoltativi:
--disable-aag-config: se non includi questo flag, le regole anti-affinità Distributed Resource Scheduler (DRS) di VMware vengono create automaticamente per i nodi del cluster utente, in modo da distribuirle in almeno tre host fisici del data center. Assicurati che il tuo ambiente vSphere soddisfi i requisiti. Se il tuo cluster non soddisfa i requisiti, includi questo flag.

Nota: se hai seguito la procedura Configura un'infrastruttura minima, hai un solo host ESXi, quindi assicurati di includere questo flag.
--disable-vsphere-csi: se non includi questo flag, i componenti vSphere Container Storage Interface (CSI) vengono distribuiti 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 nell'archiviazione di vSphere. Per saperne di più, 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

Monitora l'avanzamento della creazione del cluster

L'output del comando di creazione del cluster è 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 è il OPERATION_ID dell'operazione a lunga esecuzione. Puoi scoprire lo stato dell'operazione con il seguente comando:
```
gcloud container vmware operations describe OPERATION_ID \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION
```
Per saperne di più, consulta gcloud container vmware operations.

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

Crea un node pool

Dopo aver creato il cluster, devi creare almeno un pool di nodi prima di eseguire il deployment dei workload.
```
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 scelto da te per il node pool. Il nome deve:
- contenere al massimo 40 caratteri
- contenere solo caratteri alfanumerici minuscoli o un trattino (-)
- iniziare con un carattere alfabetico
- terminare 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 regione Google Cloud che hai specificato quando hai creato il cluster.
IMAGE_TYPE: il tipo di immagine sistema operativo da eseguire sulle VM nel pool di nodi. Imposta uno dei seguenti valori: ubuntu_cgv2 o cos_cgv2.
BOOT_DISK_SIZE: le dimensioni del disco di avvio in gibibyte (GiB) per ogni nodo nel pool. Il valore minimo è 40 GiB.
vCPUs: il numero di vCPU per ogni nodo nel pool di nodi. Il numero minimo è 4.
MEMORY: la dimensione della memoria in mebibyte (MiB) per ciascun nodo nel pool. Il valore minimo è 8192 MiB per nodo worker del cluster utente e 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, includi facoltativamente --enable-load-balancer se vuoi consentire l'esecuzione dello speaker MetalLB sui nodi del 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 Aggiungi un node pool e il riferimento di gcloud CLI.

Esempi di comandi gcloud

MetalLB e DHCP

gcloud container vmware clusters create user-cluster-1 \
    --project=example-project-12345 \
    --location=us-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/us-west1/memberships/admin-cluster-1 \
    --version=1.36.200-gke.118 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --enable-dhcp \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=lb-pool-1,manual-assign=False,avoid-buggy-ips=True,addresses=192.0.2.0/26;pool=lb-ingress-vip-pool,manual-assign=True,addresses=198.51.100.1/32' \
    --enable-control-plane-v2 \
    --control-plane-vip=203.0.113.1 \
    --ingress-vip=198.51.100.1

MetalLB e IP statici

gcloud container vmware clusters create user-cluster-3 \
    --project=example-project-12345 \
    --location=europe-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/global/memberships/admin-cluster-1 \
    --version=1.36.200-gke.118 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.10 user-vm-1;192.0.2.11 user-vm-2' \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.12 user-vm-3;192.0.2.13 extra-vm' \
    --dns-servers=203.0.113.1,203.0.113.2  \
    --dns-search-domains=example.com,altostrat.com \
    --ntp-servers=203.0.113.3,203.0.113.4 \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=192.0.2.254,netmask=255.255.255.0,ips=198.51.100.1 cp-vm-1;198.51.100.2 cp-vm-2;198.51.100.3 cp-vm-3' \
    --replicas=3 \
    --metal-lb-config-address-pools='pool=lb-pool-1,manual-assign=False,avoid-buggy-ips=True,addresses=192.0.2.0/26;lb-ingress-vip-pool,manual-assign=True,addresses=198.51.100.1/32' \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

LB manuale e IP statici

gcloud container vmware clusters create user-cluster-4 \
    --project=example-project-12345 \
    --location=asia-east1 \
    --admin-cluster-membership=projects/example-project-12345/locations/asia-east1/memberships/admin-cluster-1 \
    --version=1.36.200-gke.118 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.10 user-vm-1;192.0.2.11 user-vm-2';ips=192.0.2.12 user-vm-3;192.0.2.13 extra-vm'\
    --dns-servers=203.0.113.1,203.0.113.2  \
    --ntp-servers=203.0.113.3,203.0.113.4 \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=192.0.2.254,netmask=255.255.255.0,ips=198.51.100.1 cp-vm-1;198.51.100.2 cp-vm-2;198.51.100.3 cp-vm-3' \
    --replicas=3 \
    --control-plane-vip=192.0.2.60 \
    --ingress-vip=192.0.2.50 \
    --ingress-http-node-port=30243 \
    --ingress-https-node-port=30879

Terraform

Prima di iniziare

Recupera il nome e la località di appartenenza al parco risorse del cluster di amministrazione:
```
gcloud container fleet memberships list \
    --project=FLEET_HOST_PROJECT_ID
```
Sostituisci FLEET_HOST_PROJECT_ID con l'ID del progetto in cui è registrato il cluster di amministrazione.

L'output è simile al seguente:
```
NAME             EXTERNAL_ID                           LOCATION
admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1
```
La località specifica dove vengono eseguiti i servizi Fleet e Connect. I cluster di amministrazione creati prima della versione 1.28 sono gestiti dai servizi globali Fleet e Connect. Nella versione 1.28 e successive, puoi specificare global o una regione Google Cloud quando crei il cluster.
Ottieni 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 \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --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.
- ADMIN_CLUSTER_REGION: la regione di appartenenza al parco risorse del cluster di amministrazione. Può essere globale o una regione Google Cloud. Utilizza la località del cluster di amministrazione dall'output di gcloud container fleet memberships list.
- REGION: la regione Google Cloud che utilizzerai quando crei il cluster. Questa è la regione in cui vengono eseguiti l'API GKE On-Prem e i servizi Fleet e Connect. Specifica us-west1 o un'altra regione supportata.
L'output di questo 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
```
Il comando restituisce anche una spiegazione delle versioni che puoi utilizzare per la creazione o l'upgrade dei cluster utente. Le versioni consentite 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 utilizzare una versione installata nel cluster di amministrazione, vai alla sezione Esempio per creare il cluster utente.

Installa un'altra versione

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

Sostituisci VERSION con una delle versioni elencate nell'output del comando query-version-config.

Se esegui nuovamente gcloud container vmware clusters query-version-config, la versione specificata viene annotata con isInstalled: true.

Esempio

Puoi utilizzare il seguente esempio di configurazione di base per creare un cluster utente con il bilanciatore del carico MetalLB integrato e un pool di nodi utilizzando il provider Google per Terraform.

Quando crei un cluster utente, il file di configurazione Terraform deve contenere almeno una risorsa google_gkeonprem_vmware_node_pool per creare un pool di nodi. Tuttavia, Terraform non può creare la risorsa del pool di nodi finché non ha completato tutte le operazioni sulla risorsa del cluster utente google_gkeonprem_vmware_cluster upstream. Per applicare questa dipendenza, includi un'istruzione depends_on nella risorsa google_gkeonprem_vmware_node_pool, come mostrato nel seguente file main.tf di esempio. Per saperne di più sull'utilizzo di depends_on per specificare le dipendenze delle risorse, consulta la documentazione delle risorse Terraform.

Per saperne di più sull'esempio, fai clic sul seguente link:

`main.tf` per creare un cluster utente

L'esempio main.tf contiene i seguenti moduli e risorse:

enable_google_apis_primary: abilita le API di Google richieste nel progetto. Devi abilitare le API in un progetto una sola volta. Se le API sono già state abilitate nel tuo progetto, non è necessario includerle in un file di configurazione Terraform.
google_project_service: abilita l'API GKE On-Prem nel progetto. Come per le altre API di Google richieste, devi abilitare l'API GKE On-Prem una sola volta.
gcloud_update_admin_cluster_platform_controller: aggiorna il controller della piattaforma nel cluster di amministrazione. Questo è necessario per gli upgrade dei cluster utente. Se il cluster di amministrazione è già nella versione corretta, questo modulo non apporta modifiche. Sebbene questo modulo sia facoltativo, la creazione del cluster utente non va a buon fine se esiste una mancata corrispondenza tra la versione del controller della piattaforma sul cluster di amministrazione e la versione specificata per il cluster utente.
google_gkeonprem_vmware_cluster: crea il cluster utente. Questa risorsa è obbligatoria. Il cluster utente è registrato nell'API GKE On-Prem e nello stesso parco risorse del cluster di amministrazione. L'esempio crea il cluster utilizzando MetalLB integrato. La documentazione di riferimento di google_gkeonprem_vmware_cluster fornisce un esempio di configurazione di un bilanciatore del carico manuale.
google_gkeonprem_vmware_node_pool: crea un pool di nodi. Questa risorsa è obbligatoria nel file di configurazione Terraform. Un cluster utente appena creato deve avere almeno un pool di nodi per passare a uno stato integro.

module "enable_google_apis_primary" {
  source     = "terraform-google-modules/project-factory/google//modules/project_services"
  version    = "~> 18.0"
  project_id = var.project_id
  activate_apis = [
    "cloudresourcemanager.googleapis.com",
    "anthos.googleapis.com",
    "anthosgke.googleapis.com",
    "container.googleapis.com",
    "gkeconnect.googleapis.com",
    "gkehub.googleapis.com",
    "serviceusage.googleapis.com",
    "stackdriver.googleapis.com",
    "monitoring.googleapis.com",
    "logging.googleapis.com",
    "iam.googleapis.com",
    "compute.googleapis.com",
    "anthosaudit.googleapis.com",
    "opsconfigmonitoring.googleapis.com",
    "file.googleapis.com",
    "connectgateway.googleapis.com"
  ]
  disable_services_on_destroy = false
}

# Enable GKE OnPrem API
resource "google_project_service" "default" {
  project            = var.project_id
  service            = "gkeonprem.googleapis.com"
  disable_on_destroy = false
}

# This module is used to update the platform controller on your admin cluster. This
# is a necessary step for the user cluster version update. If the admin cluster is
# already on the correct version, then this module does not change anything
module "gcloud_update_admin_cluster_platform_controller" {
  source                = "terraform-google-modules/gcloud/google"
  version               = "~> 3.0"
  platform              = "linux"
  create_cmd_entrypoint = "gcloud"
  create_cmd_body       = <<EOT
    beta container vmware admin-clusters               \
    update ${var.admin_cluster_name}                   \
    --required-platform-version=${var.on_prem_version} \
    --project ${var.project_id}                        \
    --location ${var.region}
  EOT
}

# Create an anthos vmware user cluster and enroll it with the gkeonprem API
resource "google_gkeonprem_vmware_cluster" "default" {
  name        = var.cluster_name
  description = "Anthos VMware user cluster with MetalLB"
  provider    = google-beta
  depends_on = [
    google_project_service.default,
    module.gcloud_update_admin_cluster_platform_controller
  ]
  location                 = var.region
  on_prem_version          = var.on_prem_version
  admin_cluster_membership = "projects/${var.project_id}/locations/global/memberships/${var.admin_cluster_name}"
  network_config {
    service_address_cidr_blocks = ["10.96.0.0/12"]
    pod_address_cidr_blocks     = ["192.168.0.0/16"]
    dhcp_ip_config {
      enabled = true
    }
  }
  control_plane_node {
    cpus     = var.control_plane_node_cpus
    memory   = var.control_plane_node_memory
    replicas = var.control_plane_node_replicas
  }
  load_balancer {
    vip_config {
      control_plane_vip = var.control_plane_vip
      ingress_vip       = var.ingress_vip
    }
    metal_lb_config {
      dynamic "address_pools" {
        for_each = var.lb_address_pools
        content {
          pool      = address_pools.value.name
          addresses = address_pools.value.addresses
        }
      }
    }
  }
  authorization {
    dynamic "admin_users" {
      for_each = var.admin_user_emails
      content {
        username = admin_users.value
      }
    }
  }
}

# Create a node pool for the anthos vmware user cluster
resource "google_gkeonprem_vmware_node_pool" "default" {
  name           = "${var.cluster_name}-nodepool"
  display_name   = "Nodepool for ${var.cluster_name}"
  provider       = google-beta
  vmware_cluster = google_gkeonprem_vmware_cluster.default.name
  location       = var.region
  config {
    replicas             = 3
    image_type           = "ubuntu_containerd"
    enable_load_balancer = true
  }
  depends_on = [
    google_gkeonprem_vmware_cluster.default
  ]
}

Per saperne di più e per altri esempi, consulta la documentazione di riferimento di google_gkeonprem_vmware_cluster.

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 consentire ai nodi del cluster di ottenere i propri indirizzi IP da un server DHCP che fornisci.

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

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

Crea una copia del file terraform.tfvars.sample:

cp terraform.tfvars.sample terraform.tfvars

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"] }
]
```
Il seguente elenco descrive 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 registrato automaticamente 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 vengono eseguite l'API GKE On-Prem (gkeonprem.googleapis.com), il servizio Fleet (gkehub.googleapis.com) e il servizio Connect (gkeconnect.googleapis.com). Specifica us-west1 o un'altra regione supportata.
- admin_cluster_name: il nome del cluster di amministrazione che gestisce il cluster utente. L'esempio presuppone che il cluster di amministrazione utilizzi global come regione. Se hai un cluster di amministrazione regionale:
  1. Apri main.tf in un editor di testo.
  2. Cerca admin_cluster_membership, che ha il seguente aspetto:
```
admin_cluster_membership = "projects/${var.project_id}/locations/global/memberships/${var.admin_cluster_name}"
```
  1. Sostituisci global con la regione utilizzata dal cluster di amministrazione e salva il file.
- on_prem_version: la versione di Google Distributed Cloud per il tuo cluster utente.
- admin_user_emails: un elenco di indirizzi email degli utenti a cui concedere i privilegi amministrativi sul 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 ogni risorsa del cluster in tutti i namespace. In questo modo, gli utenti possono anche accedere alla console utilizzando la propria Google Identity.
- 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:
  - contenere al massimo 40 caratteri
  - contenere solo caratteri alfanumerici minuscoli o un trattino (-)
  - iniziare con un carattere alfabetico
  - terminare con un carattere alfanumerico
- control_plane_node_cpus: il numero di vCPU per ogni nodo del control plane per il cluster utente. Il numero minimo è 4 vCPU.
- control_plane_node_memory: la dimensione della memoria in mebibyte (MiB) per ogni control plane del cluster utente. Il valore minimo è 8192 e deve essere un multiplo di 4.
- control_plane_node_replicas: il numero di nodi del control plane per il cluster utente. Ad esempio, puoi inserire 1 nodo del control plane per un ambiente di sviluppo e 3 nodi del control plane per ambienti di produzione ad alta affidabilità (HA).
- 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 verranno utilizzati dal bilanciatore del carico MetalLB. Il VIP Ingress deve trovarsi in uno di questi pool. Specifica quanto segue:
  - name: un nome per il pool.
  - addresses: un intervallo di indirizzi in notazione CIDR o in formato di 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 aggiungi altri pool di indirizzi, se necessario.
Salva le modifiche in terraform.tfvars. Se non vuoi apportare modifiche facoltative a main.tf, vai alla sezione successiva, Crea il cluster e un node pool.

Configura Controlplane V2

Nella versione 1.30 e successive, devi attivare Controlplane V2. Il file main.tf nell'esempio non abilita Controlplane V2. Devi modificare main.tf per abilitare Controlplane V2 e aggiungere gli indirizzi IP per il gateway, la subnet mask e i nodi del control plane. Prima di apportare modifiche, esegui il backup di main.tf:

  cp main.tf main.tf.bak

Per configurare Controlplane V2, apporta le seguenti modifiche a main.tf:

Aggiungi la seguente riga al blocco resource:
```
  enable_control_plane_v2 = "true"
```

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"
      }
    }
  }

Sostituisci i valori di netmask e gateway con gli indirizzi IP della tua rete. Sostituisci ip e hostname con gli indirizzi IP dei nodi del control plane.

(Facoltativo) Abilita il cluster avanzato

Per impostazione predefinita, nella versione 1.32 e successive, i cluster utente creati utilizzando Terraform non hanno il cluster avanzato abilitato. Se vuoi attivare il cluster avanzato, aggiungi il seguente campo di primo livello a main.tf:

enable_advanced_cluster = true

Assicurati di esaminare le differenze durante l'esecuzione di cluster avanzati prima di attivare il cluster avanzato.

(Facoltativo) Modalità di indirizzamento IP dei nodi worker

Questa sezione spiega alcune modifiche di configurazione facoltative che puoi apportare in main.tf. Prima di apportare modifiche, esegui un backup di main.tf:

cp main.tf main.tf.bak

Per impostazione predefinita, main.tf configura il cluster in modo che utilizzi un server DHCP fornito da te per assegnare gli indirizzi IP ai nodi worker del cluster. DHCP è 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:

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"
        }
      }
    }
  }

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 un intervallo di almeno /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 per le VM.
- ntp_servers: un elenco degli indirizzi IP dei server di riferimento ora che le VM devono utilizzare.
- Nel blocco static_ip_config, sostituisci i valori di netmask e gateway con gli indirizzi della tua rete. Sostituisci ip e hostname con gli indirizzi IP e i nomi host dei tuoi nodi worker.

Crea il cluster e un pool di nodi

Inizializza e crea il piano Terraform:
```
terraform init
```
Terraform installa tutte le librerie necessarie, come il provider Google Cloud .
Esamina la configurazione e apporta le modifiche necessarie:
```
terraform plan
```
Applica il piano Terraform per creare il cluster utente:
```
terraform apply
```
La creazione del cluster utente richiede circa 15 minuti o più, mentre la creazione del pool di nodi richiede altri 15 minuti. Puoi visualizzare il cluster nella console Google Cloud nella pagina Cluster GKE.

(Facoltativo) Esegui gli strumenti a riga di comando prima della creazione delle risorse

Se necessario, puoi eseguire strumenti a riga di comando come gcloud CLI e gkectl per eseguire attività di configurazione prima della creazione delle risorse. Puoi definire le righe di comando da eseguire all'interno del file di configurazione Terraform utilizzando il provisioner local-exec, che ti consente di riutilizzare le variabili Terraform definite.

L'esempio seguente mostra come modificare main.tf per eseguire il comando gkectl prepare prima della creazione del cluster:

resource "null_resource" "gkectl_prepare" {
  provisioner "local-exec" {
    command = "gkectl prepare --kubeconfig=${var.kubeconfig} --cluster-name=${var.cluster_name} --vcenter-username=${var.vcenter_username} --vcenter-password=${var.vcenter_password} --vcenter-address=${var.vcenter_address} --datacenter=${var.datacenter} --datastore=${var.datastore} --network=${var.network} --os-image=${var.os_image} --service-account-key-file=${var.service_account_key_file} --location=${var.location}"
    working_dir = path.module  # Important: Set working directory
    environment = {
        # Optional: set environment variables if needed.
        # Example: GOOGLE_APPLICATION_CREDENTIALS = "/path/to/your/credentials.json"
    }
  }
}

resource "google_gkeonprem_vmware_cluster" "cluster" {
  # ... your cluster configuration ...
  # Ensure this depends on the null_resource
  depends_on = [null_resource.gkectl_prepare]

  # ... rest of your cluster configuration ...
  location = var.location
  name = var.cluster_name
  # ... other required fields ...
}

Risoluzione dei problemi

Consulta la sezione Risoluzione dei problemi di creazione e upgrade dei cluster.

Creazione di un cluster utente Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Prima di iniziare

Crea un cluster utente con lo strumento che preferisci

gkectl

Panoramica della procedura

Compila i file di configurazione

name

gkeOnPremVersion

enableAdvancedCluster

enableControlplaneV2

kubeception

enableDataplaneV2

vCenter

Utilizzo di un data center e un cluster vSphere

Utilizzo di cluster vSphere separati

Utilizzo di data center vSphere separati

Utilizzo di account vCenter separati

Utilizzo di istanze separate di vCenter Server

network

loadBalancer

advancedNetworking

multipleNetworkInterfaces

storage

masterNode

nodePools

antiAffinityGroups

stackdriver

gkeConnect

gkeOnPremAPI

cloudAuditLogging

Esempio di file di configurazione compilati

user-ipblock.yaml

user-cluster.yaml

Convalida il file di configurazione

(Facoltativo) Importa le immagini sistema operativo in vSphere ed esegui il push delle immagini container in un registry privato

Creazione di un cluster utente

Individua il file kubeconfig del cluster utente

Verifica che il cluster utente sia in esecuzione

Console

Inizia

Impostazioni di base del cluster

Control plane

Networking

Bilanciatore del carico

Abbinato a MetalLB

BIG-IP di F5

Manuale

Funzionalità

Node pool

gcloud CLI

Raccogliere informazioni

Installa un'altra versione

Esempi

MetalLB e DHCP

MetalLB e IP statici

LB manuale e IP statici

Flag del control plane

Flag vSphere

Monitora l'avanzamento della creazione del cluster

Crea un node pool

Esempi di comandi gcloud

MetalLB e DHCP

MetalLB e IP statici

LB manuale e IP statici

Terraform

Prima di iniziare

Installa un'altra versione

Esempio

main.tf per creare un cluster utente

Imposta le variabili in terraform.tfvars

Configura Controlplane V2

(Facoltativo) Abilita il cluster avanzato

(Facoltativo) Modalità di indirizzamento IP dei nodi worker

Crea il cluster e un pool di nodi

(Facoltativo) Esegui gli strumenti a riga di comando prima della creazione delle risorse

Risoluzione dei problemi

Passaggi successivi

Creazione di un cluster utente

`name`

`gkeOnPremVersion`

`enableAdvancedCluster`

`enableControlplaneV2`

`enableDataplaneV2`

`vCenter`

`network`

`loadBalancer`

`advancedNetworking`

`multipleNetworkInterfaces`

`storage`

`masterNode`

`nodePools`

`antiAffinityGroups`

`stackdriver`

`gkeConnect`

`gkeOnPremAPI`

`cloudAuditLogging`

`main.tf` per creare un cluster utente

Imposta le variabili in `terraform.tfvars`