Questa pagina è stata tradotta dall'API Cloud Translation.

Creazione di un cluster utente

In Google Distributed Cloud, i tuoi carichi di lavoro vengono eseguiti su uno o più cluster utente. Questo documento mostra come creare un cluster utente.

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

gkectl
Console Google Cloud
Google Cloud CLI
Terraform

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

Per indicazioni sullo strumento che potresti utilizzare, vedi Scegliere uno strumento per gestire il ciclo di vita dei cluster.

Prima di iniziare

Se non lo hai già fatto, configura le tue risorse Google Cloud come descritto in questi documenti:
Durante la configurazione del progetto host del parco risorse, tieni presente lo strumento che preferisci, perché se hai scelto uno dei client dell'API GKE On-Prem, devi abilitare altre API.
Prima di creare un cluster utente, devi disporre di un cluster di amministrazione per gestire il cluster utente. Se non lo hai già fatto, crea una workstation di amministrazione e un cluster di amministrazione.

Se hai scelto di utilizzare uno dei client dell'API GKE On-Prem, devi abilitare l'audit logging e Cloud Logging per il cluster di amministrazione.
Determina la versione del cluster utente da installare. Quando crei un cluster utente, in genere installi la versione che corrisponde a quella del cluster di amministrazione. ma puoi installare una versione patch successiva o una versione secondaria successiva. Per maggiori informazioni, consulta Installare una versione successiva rispetto alla versione del cluster di amministrazione.
Valuta se vuoi che il cluster utente abiliti il piano di controllo V2. Quando il piano di controllo V2 è abilitato, il piano di controllo per il cluster utente viene eseguito su uno o più nodi nel cluster utente stesso. Ti consigliamo vivamente di abilitare il piano di controllo V2. L'alternativa è creare un cluster utente che utilizzi kubeception. Nel caso kubeception, il piano di controllo per il cluster utente viene eseguito su uno o più nodi nel cluster di amministrazione.
Consulta il documento sulla pianificazione degli indirizzi IP e assicurati di disporre di un numero sufficiente di indirizzi IP.
Consulta la panoramica del bilanciamento del carico e rivedi la decisione sul tipo di bilanciatore del carico da utilizzare. Puoi utilizzare il bilanciatore del carico MetalLB in bundle oppure puoi configurare manualmente un bilanciatore del carico a tua scelta. Per il bilanciamento del carico manuale, devi configurare il bilanciatore del carico prima di creare il cluster utente.
Pensa a quanti pool di nodi ti servono e al sistema operativo che vuoi eseguire in ciascuno dei tuoi pool.
Valuta se utilizzare cluster vSphere separati per il cluster di amministrazione e i cluster utente e se usare data center separati. Valuta inoltre se utilizzare istanze separate di vCenter Server.
Dalla versione 1.29 in poi, 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. Vengono eseguiti anche i controlli preflight lato server se utilizzi la console Google Cloud, Google Cloud CLI o Terraform per creare un cluster utente.

Creazione di un cluster utente

Gkectl

Panoramica della procedura

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

Connettiti alla workstation di amministrazione

La workstation di amministrazione è una macchina che dispone degli strumenti necessari per creare un cluster utente.
Compila i file di configurazione

Specifica i dettagli per il nuovo cluster completando un file di configurazione del cluster utente, un file di configurazione delle credenziali ed eventualmente un file di blocco IP.
(Facoltativo) Importa immagini del sistema operativo in vSphere ed esegui il push delle immagini container al registro 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 puoi eseguire il deployment dei carichi di lavoro.

Se utilizzi Controlli di servizio VPC, potresti riscontrare 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

Esegui questi passaggi sulla workstation di amministrazione.

Quando gkeadm ha creato la tua workstation di amministrazione, ha generato un file di configurazione denominato user-cluster.yaml. Questo file di configurazione consente di creare il cluster utente.

Acquisisci familiarità con il file di configurazione analizzando il documento sul file di configurazione del cluster utente. Ti consigliamo di tenere questo documento aperto in una scheda o finestra separata, perché lo userai man mano che completi i passaggi seguenti.

`name`

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

`gkeOnPremVersion`

Questo campo è già stato compilato. Specifica la versione di Google Distributed Cloud. Ad esempio, 1.29.100-gke.248.

`enableControlplaneV2`

Per creare un cluster utente con il piano di controllo V2 abilitato, imposta enableControlplaneV2 su true.

Quando il piano di controllo V2 è abilitato, il piano di controllo per il cluster utente viene eseguito sui nodi nel cluster utente stesso. Ti consigliamo vivamente di abilitare Controlplane V2.

Kubernetes

Se imposti questo campo su false, il cluster utilizzerà kubecetption. Con kubeception, il piano di controllo per il cluster utente viene eseguito sui nodi nel cluster di amministrazione.

Per un cluster kubeception:

Imposta enableControlplaneV2 su false.
Non compilare la sezione controlPlaneIPBlock.
Specifica gli indirizzi IP per i nodi del piano di controllo del cluster utente nel file dei blocchi 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. Vale a dire che 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 valori vCenter globali.

Per eseguire l'override di qualsiasi valore globale di vCenter, 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 utilizzare data center separati per il cluster di amministrazione e i cluster utente.

Utilizzo di un data center e di un cluster vSphere

L'opzione predefinita prevede l'utilizzo di un data center e un cluster vSphere per il cluster di amministrazione e il cluster utente. Per questa opzione, non impostare alcun valore 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 all'interno del 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 vCenter.credentials diverso, dal 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, ha senso creare un cluster utente che utilizzi una propria istanza di vCenter Server. Ciò significa che il cluster di amministrazione e un cluster utente associato utilizzano istanze diverse di vCenter Server.

Ad esempio, in una località perimetrale, potresti voler disporre di una macchina fisica che esegue vCenter Server e di una o più macchine fisiche che eseguono ESXi. Puoi quindi utilizzare l'istanza locale di vCenter Server per creare una gerarchia di oggetti vSphere, che include 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 come vuoi che i nodi worker ricevano i propri indirizzi IP. Le opzioni sono:

Da un server DHCP configurato in anticipo. Imposta network.ipMode.type su "dhcp".
Da un elenco di indirizzi IP statici forniti da te. Imposta network.ipMode.type su "static" e crea un file dei blocchi IP che fornisce gli indirizzi IP statici. Per un esempio di file di blocco IP, vedi 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 piano di controllo per il cluster utente devono recuperare i relativi indirizzi IP da un elenco di indirizzi statici forniti da te. anche se i nodi worker ricevono gli indirizzi da un server DHCP. Per specificare gli indirizzi IP statici per i nodi del piano di controllo, compila la sezione network.controlPlaneIPBlock. Se vuoi un cluster utente ad alta disponibilità, 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 piano di controllo. Se utilizzi indirizzi IP statici per i nodi worker, questi server DNS e NTP sono validi 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 indirizzi già utilizzati nella tua rete. Kubernetes utilizza questi intervalli per assegnare indirizzi IP a pod e servizi nel tuo cluster.

Indipendentemente dal fatto che tu ti affidi a un server DHCP o specifichi un elenco di indirizzi IP statici, devi disporre di un numero sufficiente di indirizzi IP per il cluster utente. Per una spiegazione del numero di indirizzi IP necessari, vedi Pianificare gli indirizzi IP.

`loadBalancer`

Riserva un VIP per il server API Kubernetes del tuo 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 da utilizzare. Le opzioni sono:

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

Per ulteriori informazioni 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 configurare più interfacce di rete per i pod e imposta multipleNetworkInterfaces di conseguenza.

`storage`

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

`masterNode`

Nella sezione masterNode, puoi specificare quanti nodi del piano di controllo vuoi per il cluster utente: uno o tre. Puoi anche specificare un datastore per i nodi del piano di controllo e se vuoi abilitare il ridimensionamento automatico per i nodi del piano di controllo.

Ricorda che hai specificato gli indirizzi IP per i nodi del piano di controllo nella sezione network.controlPlaneIPBlock.

`nodePools`

Un pool di nodi è un gruppo di nodi in un cluster che hanno tutti la stessa configurazione. Ad esempio, i nodi in un pool potrebbero eseguire Windows, mentre i nodi in un altro pool potrebbero eseguire Linux.

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

Per ulteriori informazioni, 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 di anti-affinità del Distributed Resource Scheduler (DRS) per i nodi worker, in modo da distribuirle su almeno tre host fisici nel tuo data center.

`stackdriver`

Se vuoi abilitare 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 uguale all'ID in gkeConnect.projectID e cloudAuditLogging.projectID.
La regione Google Cloud impostata in stackdriver.clusterLocation deve corrispondere a quella impostata in cloudAuditLogging.clusterLocation e gkeConnect.location (se il campo è incluso nel file di configurazione). Inoltre, se gkeOnPremAPI.enabled è true, è necessario impostare la stessa regione in gkeOnPremAPI.location.

Se gli ID progetto e le regioni non sono uguali, la creazione del cluster non riesce.

`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 uguale all'ID impostato in stackdriver.projectID e cloudAuditLogging.projectID. Se gli ID progetto non sono uguali, la creazione del cluster non va a buon fine.

Nella versione 1.28 e 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 usa le istanze globali dei servizi.

Se includi gkeConnect.location nel file di configurazione, la regione specificata deve corrispondere a quella configurata in cloudAuditLogging.clusterLocation, stackdriver.clusterLocation e gkeOnPremAPI.location. Se le regioni non corrispondono, la creazione del cluster non riesce.

`gkeOnPremAPI`

Nella versione 1.16 e successive, se l'API GKE On-Prem è abilitata nel tuo progetto Google Cloud, tutti i cluster nel progetto vengono registrati automaticamente nell'API GKE On-Prem nella regione configurata in stackdriver.clusterLocation. La regione gkeOnPremAPI.location deve essere uguale a quella 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 eseguire 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 alcun cluster nel progetto, disabilita gkeonprem.googleapis.com (il nome del servizio per l'API GKE On-Prem) nel progetto. Per le istruzioni, vedi Disabilitare i servizi.

`usageMetering`

Se vuoi abilitare la misurazione dell'utilizzo per il tuo cluster, compila la sezione usageMetering.

`cloudAuditLogging`

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

Tieni presente i seguenti requisiti per i nuovi cluster:

L'ID in cloudAuditLogging.projectID deve essere uguale all'ID in gkeConnect.projectID e stackdriver.projectID.
La regione in cloudAuditLogging.clusterLocation deve corrispondere a quella impostata in gkeConnect.location (se il campo è incluso nel file di configurazione) e in stackdriver.clusterLocation. Inoltre, se gkeOnPremAPI.enabled è true, è necessario impostare la stessa regione in gkeOnPremAPI.location.

Se gli ID progetto e le regioni non sono uguali, la creazione del cluster non riesce.

Esempio di file di configurazione compilati

Ecco un esempio di un file di blocco IP e di un 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

cat user-cluster.yaml
apiVersion: v1
kind: UserCluster
name: "my-user-cluster"
gkeOnPremVersion: 1.29.100-gke.248
enableControlplaneV2: true
enableDataplaneV2: 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"
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  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"
  enableVPC: false
  serviceAccountKeyPath: "log-mon-sa-2203040617.json"
autoRepair:
  enabled: true

Questi sono i punti importanti da comprendere nell'esempio precedente:

Gli indirizzi IP statici per i nodi worker sono specificati in un file di blocchi IP. Il file dei blocchi IP ha quattro indirizzi anche se ci sono solo tre nodi worker. È necessario un indirizzo IP aggiuntivo durante l'upgrade e la riparazione automatica del cluster.
I server DNS e NTP sono specificati nella sezione hostConfig. In questo esempio, questi server DNS e NTP sono destinati ai nodi del piano di controllo e ai nodi worker. Questo perché i nodi worker hanno indirizzi IP statici. Se i nodi worker dovessero ricevere i loro indirizzi IP da un server DHCP, questi server DNS e NTP sarebbero solo per i nodi del piano di controllo.
Gli indirizzi IP statici per i tre nodi del piano di controllo sono specificati nella sezione network.controlPlaneIPBlock del file di configurazione del cluster utente. Non è necessario un indirizzo IP aggiuntivo in questo blocco.
Il piano di controllo V2 è abilitato.
Il campo masterNode.replicas è impostato su 3, quindi il cluster avrà un piano di controllo ad alta disponibilità.
Il VIP del piano di controllo e il VIP in entrata si trovano entrambi nella stessa VLAN dei nodi worker e dei nodi del piano di controllo.
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 piano di controllo. L'insieme di VIP specificato in questa sezione deve includere il VIP in entrata e non deve includere il VIP del piano di controllo.
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.

Convalidare il file di configurazione

Dopo aver compilato il file di configurazione del cluster utente, esegui gkectl check-config per verificare che il file sia valido:

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 le singole convalide, utilizza i flag --skip-validation-xxx. Per scoprire di più sul comando check-config, consulta Esecuzione dei controlli preflight.

3. (Facoltativo) Importa immagini del sistema operativo in vSphere ed esegui il push delle immagini container a un registro privato

Esegui gkectl prepare se una delle seguenti condizioni è vera:

Il cluster utente si trova in un data center vSphere diverso dal cluster di amministrazione.
Il cluster utente ha un server vCenter diverso da quello del cluster di amministrazione.
Il cluster utente utilizza un registro dei container privato diverso dal registro 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.29.100-gke.248-full.tgz
```
USER_CLUSTER_CONFIG: il percorso del file di configurazione del cluster utente

4. Creazione di un cluster utente

Crea un cluster utente:

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Individuare il file kubeconfig del cluster utente

Il comando gkectl create cluster crea un file kubeconfig denominato USER_CLUSTER_NAME-kubeconfig nella directory attuale. In seguito, avrai bisogno di questo file kubeconfig 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.

5. 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 un cluster GKE on VMware.

Vai a Creare un cluster GKE on VMware
Seleziona il progetto Google Cloud in cui vuoi creare il cluster. Il progetto selezionato viene utilizzato anche come progetto host del parco risorse. Deve essere lo stesso progetto in cui è registrato il cluster di amministrazione. Una volta creato, il cluster utente viene registrato automaticamente nel parco risorse del progetto selezionato.

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 al momento della 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 è visualizzato, consulta la sezione relativa alla risoluzione dei problemi Il cluster di amministrazione non viene visualizzato nell'elenco a discesa Impostazioni di base del cluster.
Nel campo Posizione API Google Cloud, seleziona dall'elenco la regione Google Cloud. Questa impostazione specifica la regione in cui vengono eseguiti i seguenti servizi e API:
- API GKE On-Prem (gkeonprem.googleapis.com)
- Servizio parco risorse (gkehub.googleapis.com)
- Connetti servizio (gkeconnect.googleapis.com)
Questa impostazione controlla anche la regione in cui sono 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
- Il log di controllo Admin creato da Cloud Audit Logs
Il nome del cluster, il progetto e la località identificano insieme 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 di amministratore del cluster. Facoltativamente, inserisci l'indirizzo email di un altro utente che gestirà il cluster nel campo Utente amministratore del cluster nella sezione Autorizzazione.

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

Nota: oltre ai criteri RBAC di Kubernetes, devi concedere alcuni ruoli IAM (Identity and Access Management) agli utenti che non sono proprietari del progetto. Per maggiori dettagli sulla concessione dei ruoli IAM, consulta Concedere i ruoli richiesti.
Fai clic su Avanti per andare alla sezione Piano di controllo.

Piano di controllo

Tutti i campi della sezione Piano di controllo sono impostati con valori predefiniti. Rivedi le impostazioni predefinite e, se necessario, modificale.

Nel campo vCPU del nodo del piano di controllo, inserisci il numero di vCPU (minimo 4) per ciascun nodo del piano di controllo per il tuo cluster utente.
Nel campo Memoria del nodo del piano di controllo, inserisci la dimensione della memoria in MiB (minimo 8192; deve essere un multiplo di 4) per ogni piano di controllo per il tuo cluster utente.
In Nodi del piano di controllo, seleziona il numero di nodi del piano di controllo per il cluster utente. Ad esempio, puoi selezionare 1 nodo del piano di controllo per un ambiente di sviluppo e 3 nodi del piano di controllo per gli ambienti di produzione ad alta disponibilità.
(Facoltativo) Seleziona Ridimensionamento automatico dei nodi. Il ridimensionamento implica che le risorse di vCPU e memoria assegnate a un nodo vengono regolate automaticamente. Se questa opzione è abilitata, i nodi del piano di controllo per il cluster utente vengono ridimensionati in base al numero di nodi worker nel cluster utente. Man mano che aggiungi altri nodi worker al cluster utente, le dimensioni dei nodi del piano di controllo aumentano.
(Facoltativo) Seleziona Abilita piano di controllo v2. L'abilitazione del piano di controllo V2 significa che il piano di controllo per un cluster utente viene eseguito su uno o più nodi nel cluster utente stesso anziché nel cluster di amministrazione (denominato kubeception).

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

Quando il piano di controllo V2 è abilitato, i campi per vCPU e memoria si applicano ai nodi del piano di controllo nel cluster utente. Il numero di nodi è determinato dal numero di indirizzi IP inseriti. Se il piano di controllo V2 non è abilitato, i campi per vCPU, memoria e numero di nodi del piano di controllo si applicano ai nodi nel cluster di amministrazione. Assicurati di tenere da parte un numero sufficiente di indirizzi IP per il cluster di amministrazione.
Fai clic su Avanti per andare alla sezione Networking.

Networking

In questa sezione specifichi gli indirizzi IP per nodi, pod e servizi del tuo cluster. Un cluster utente deve avere un indirizzo IP per ogni nodo e un indirizzo IP aggiuntivo per un nodo temporaneo che è necessario durante gli upgrade, gli aggiornamenti e la riparazione automatica del cluster. Per ulteriori informazioni, vedi Quanti indirizzi IP servono a un cluster utente?.

Nella sezione IP del nodo, seleziona la modalità IP per il cluster utente. Seleziona una delle seguenti opzioni:
- DHCP: scegli DHCP se vuoi che i nodi del cluster ricevano l'indirizzo IP da un server DHCP.
- 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 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 IP v4 (ad esempio 192.0.2.1) o un blocco CIDR di indirizzi IPv4 (ad esempio 192.0.2.0/24).
  - Se inserisci un blocco CIDR, non inserire un nome host.
  - Se inserisci un singolo indirizzo IP, puoi inserire un nome host facoltativamente. Se non inserisci un nome host, Google Distributed Cloud utilizza il nome della VM da vSphere come nome host.
4. Fai clic su + Aggiungi indirizzo IP se necessario per inserire altri indirizzi IP.
Nella sezione CIDR di servizi e pod, la console fornisce i seguenti intervalli di indirizzi per i servizi e i pod Kubernetes:
- CIDR del servizio: 10.96.0.0/20
- CIDR pod: 192.168.0.0/16
Se preferisci inserire intervalli di indirizzi personalizzati, vedi Indirizzi IP per pod e servizi per le best practice.
Se hai selezionato Modalità IP statico o Abilita piano di controllo v2, specifica le seguenti informazioni nella sezione Configurazione host:
1. Inserisci gli indirizzi IP dei server DNS.
2. Inserisci gli indirizzi IP dei server NTP.
3. (Facoltativo) 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 dei bilanciatori del carico.

Seleziona il Tipo di bilanciatore del carico dall'elenco.

Abbinato a MetalLB

Configura il bilanciamento del carico in bundle con MetalLB. Puoi utilizzare MetalLB per il cluster utente solo se il cluster di amministrazione utilizza SeeSaw o MetalLB. Questa opzione richiede una configurazione minima. MetalLB viene eseguito direttamente sui nodi cluster e non richiede VM aggiuntive. Per ulteriori informazioni sui vantaggi dell'utilizzo di MetalLB e sulle differenze rispetto alle altre opzioni di bilanciamento del carico, consulta Bilanciamento del carico in bundle 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 in entrata in una 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 servizi di tipo LoadBalancer non si trovano nello stesso intervallo di indirizzi IP del VIP in entrata, fai clic su + Aggiungi intervallo di indirizzi IP e inserisci un altro intervallo di indirizzi.
  
  Gli indirizzi IP in ogni pool non possono sovrapporsi e devono trovarsi nella stessa subnet dei nodi del cluster.
4. In Assegnazione di indirizzi IP, seleziona una delle seguenti opzioni:
  - Automatico: scegli questa opzione se vuoi che il controller MetalLB assegni automaticamente gli indirizzi IP del pool di indirizzi a 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 errori di indirizzi IP 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 dei consumatori con errori che rilasciano erroneamente il traffico inviato a quegli indirizzi IP speciali.
6. Al termine, fai clic su Fine.
Se necessario, fai clic su Aggiungi pool di indirizzi.
Nella sezione IP virtuali, inserisci quanto segue:
- VIP piano di controllo: l'indirizzo IP di destinazione da utilizzare per il traffico inviato al server API Kubernetes del cluster utente. Il server API Kubernetes per il cluster utente viene eseguito su un nodo nel cluster di amministrazione. Questo indirizzo IP deve trovarsi nello stesso dominio L2 dei nodi del cluster di amministrazione. Non aggiungere questo indirizzo nella sezione Pool di indirizzi.
- VIP in entrata: l'indirizzo IP da configurare sul bilanciatore del carico per il proxy in entrata. Devi aggiungerlo a un pool di indirizzi nella sezione Pool di indirizzi.
Fai clic su Continua.

F5 BIG-IP

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 F5 vengono ereditati dal cluster di amministrazione.

Nella sezione IP virtuali, inserisci quanto segue:
- VIP piano di controllo: l'indirizzo IP di destinazione da utilizzare per il traffico inviato al server API Kubernetes.
- VIP in entrata: l'indirizzo IP da configurare sul bilanciatore del carico per il proxy in entrata.
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 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 Kubernetes e il proxy in entrata sono entrambi esposti 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 per il traffico HTTP e HTTPS. Per ulteriori informazioni, consulta Attivazione della modalità di bilanciamento del carico manuale.

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

Funzionalità

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

I seguenti elementi sono attivati automaticamente e non possono essere disattivati:
- Cloud Logging dei servizi di sistema
- Cloud Monitoring dei servizi di sistema
- Il log di controllo dell'attività di amministrazione
Le seguenti opzioni sono abilitate per impostazione predefinita, ma puoi disabilitarle:
- Abilita 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 nello spazio di archiviazione vSphere. Per ulteriori informazioni, consulta Utilizzo del driver vSphere Container Storage Interface.
- Abilita i gruppi di anti-affinità: le regole di anti-affinità di VMware Distributed Resource Scheduler (DRS) vengono create automaticamente per i nodi del cluster utente, in modo che vengano distribuiti su almeno tre host fisici nel tuo data center. Assicurati che il tuo ambiente vSphere soddisfi i requisiti.
Nota: se hai seguito Configura minima infrastruttura, hai un solo host ESXi, quindi assicurati di deselezionare l'opzione Attiva gruppi anti-affinità.
Fai clic su Avanti per configurare un pool di nodi

Pool di nodi

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

Nella sezione Valori predefiniti del pool di nodi, completa quanto segue:
1. Inserisci il Nome del pool di nodi o accetta "default-pool" come nome.
2. Inserisci il numero di vCPUs per ciascun nodo nel pool (minimo 4 per worker del cluster utente).
3. Inserisci la dimensione della memoria in mebibyte (MiB) per ciascun nodo nel pool (minimo 8192 MiB per nodo worker del cluster utente e 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 pool di nodi (facoltativo), se vuoi aggiungere etichette e incompatibilità 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 incompatibilità. Inserisci Chiave, Valore ed Effetto per l'incompatibilità. 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 data center.

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

Per maggiori informazioni sui possibili errori e su come correggerli, consulta Risolvere i problemi di creazione dei cluster utente nella console Google Cloud.

Interfaccia a riga di comando gcloud

Utilizza il comando seguente per creare un cluster utente:

gcloud container vmware clusters create

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

gcloud container vmware node-pools create

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

Prima di iniziare

Ottieni il nome e la località di appartenenza del parco risorse del tuo 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 Fleet e Connect globali. 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 che seguono.
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 del parco risorse del cluster di amministrazione. Questa è una regione globale o di Google Cloud. Utilizza la posizione 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 and Connect. Specifica us-west1 o un'altra regione supportata.
L'output del comando è simile al seguente:
```
versions:
- isInstalled: true
  version: 1.14.3-gke.25
- version: 1.14.4-gke.54
- version: 1.15.0-gke.581
```
Le versioni che puoi utilizzare per creare un cluster utente sono annotate con isInstalled=true, il che significa che il cluster di amministrazione ha i componenti specifici della versione necessari per gestire i cluster utente di quella versione. Se vuoi creare un cluster utente con un'altra versione disponibile, consulta Installare una versione successiva rispetto a quella del cluster di amministrazione.

Esempi

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

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

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

MetalLB e DHCP

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

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

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=SERVICE_CIDR_BLOCK \
    --pod-address-cidr-blocks=POD_CIDR_BLOCK \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --enable-dhcp

Sostituisci quanto segue:

USER_CLUSTER_NAME: un nome a tua scelta per il cluster utente. Non è possibile modificare il nome dopo la creazione del cluster. Il nome deve avere le seguenti caratteristiche:
- Deve contenere al massimo 40 caratteri
- Contenere solo caratteri alfanumerici minuscoli o un trattino (-)
- iniziano 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. Una volta creato, 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 completo del cluster, 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 sono 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
- Il log di controllo Admin creato da Cloud Audit Logs
Il nome, il progetto e la località del cluster identificano insieme in modo univoco il cluster in Google Cloud.

Importante Se prevedi di installare Anthos Service Mesh, devi installare la versione 1.19.3 o successive. Questo campo è obbligatorio perché i servizi Fleet e Connect vengono eseguiti in una regione.
VERSION: la versione di GKE on VMware per il cluster utente.
YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: se non includi il flag --admin-users come 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 dovrai 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
```
Una volta creato il cluster, l'API GKE On-Prem applica al cluster i criteri di controllo dell'accesso basato su ruoli (RBAC) di Kubernetes per concedere a te e agli altri utenti amministratori il ruolo clusterrole/cluster-admin di Kubernetes, che fornisce accesso completo a tutte le risorse del cluster in tutti gli spazi dei nomi.

Nota: oltre ai criteri RBAC di Kubernetes, devi concedere alcuni ruoli IAM (Identity and Access Management) agli utenti che non sono proprietari del progetto. Per maggiori dettagli sulla concessione dei ruoli IAM, consulta Concedere 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: includi questo flag per specificare la configurazione dei pool di indirizzi che devono essere utilizzati dal bilanciatore del carico MetalLB. Il valore del flag ha il seguente formato:
```
--metal-lb-config-address-pool 'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
```
Il valore contiene segmenti che iniziano con le parole chiave pool, avoid-buggy-ip, manual-assign e addresses. Separa ogni segmento con una virgola.
- pool: un nome a tua scelta per la piscina.
- avoid-buggy-ips1: se imposti questa opzione su True, il controller MetalLB non assegnerà indirizzi IP che terminano con .0 o .255 ai servizi. In questo modo si evita il problema dei dispositivi dei consumatori con bug che rilasciano erroneamente il traffico inviato a quegli 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, impostalo su True. Successivamente, uno sviluppatore può creare un servizio di tipo LoadBalancer e specificare manualmente uno degli indirizzi dal pool. Se non specificato, il criterio manual-assign è impostato su False.
- Nell'elenco di addresses: ogni indirizzo deve essere un intervallo con la notazione CIDR o il formato dell'intervallo con trattino. Per specificare un singolo indirizzo IP in un pool (ad esempio per il VIP in entrata), utilizza /32 nella notazione CIDR, ad esempio: 192.0.2.1/32.
Tieni presente quanto segue:
- Racchiudi l'intero valore tra virgolette singole.
- Lo spazio vuoto non è consentito.
- Separa ogni intervallo di indirizzi IP con un punto e virgola.
Ad esempio:
```
--metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'
```

CONTROL_PLANE_VIP: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il server API Kubernetes del cluster utente.
Esempio: --control-plane-vip=203.0.113.3
INGRESS_VIP: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il proxy in entrata.
Esempio: --ingress-vip=10.251.134.80

L'indirizzo IP per il VIP in entrata deve 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 da te fornito. Non includere questo flag se vuoi fornire indirizzi IP statici per i nodi del cluster o se vuoi configurare il bilanciamento del carico manuale.

MetalLB e IP statici

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

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

gcloud container vmware clusters create USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership=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=SERVICE_CIDR_BLOCK \
    --pod-address-cidr-blocks=POD_CIDR_BLOCK \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...' \
    --dns-servers=DNS_SERVER,... \
    --dns-search-domains=DNS_SEARCH_DOMAIN,... \
    --ntp-servers=NTP_SERVER,...

Sostituisci quanto segue:

USER_CLUSTER_NAME: un nome a tua scelta per il cluster utente. Non è possibile modificare il nome dopo la creazione del cluster. Il nome deve avere le seguenti caratteristiche:
- Deve contenere al massimo 40 caratteri
- Contenere solo caratteri alfanumerici minuscoli o un trattino (-)
- iniziano 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. Una volta creato, 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 completo del cluster, 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 sono 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
- Il log di controllo Admin creato da Cloud Audit Logs
Il nome, il progetto e la località del cluster identificano insieme in modo univoco il cluster in Google Cloud.

Importante Se prevedi di installare Anthos Service Mesh, devi installare la versione 1.19.3 o successive. Questo campo è obbligatorio perché i servizi Fleet e Connect vengono eseguiti in una regione.
VERSION: la versione di GKE on VMware per il cluster utente.
YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: se non includi il flag --admin-users come 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 dovrai 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
```
Una volta creato il cluster, l'API GKE On-Prem applica al cluster i criteri di controllo dell'accesso basato su ruoli (RBAC) di Kubernetes per concedere a te e agli altri utenti amministratori il ruolo clusterrole/cluster-admin di Kubernetes, che fornisce accesso completo a tutte le risorse del cluster in tutti gli spazi dei nomi.

Nota: oltre ai criteri RBAC di Kubernetes, devi concedere alcuni ruoli IAM (Identity and Access Management) agli utenti che non sono proprietari del progetto. Per maggiori dettagli sulla concessione dei ruoli IAM, consulta Concedere 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: includi questo flag per specificare la configurazione dei pool di indirizzi che devono essere utilizzati dal bilanciatore del carico MetalLB. Il valore del flag ha il seguente formato:
```
--metal-lb-config-address-pool 'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
```
Il valore contiene segmenti che iniziano con le parole chiave pool, avoid-buggy-ip, manual-assign e addresses. Separa ogni segmento con una virgola.
- pool: un nome a tua scelta per la piscina.
- avoid-buggy-ips1: se imposti questa opzione su True, il controller MetalLB non assegnerà indirizzi IP che terminano con .0 o .255 ai servizi. In questo modo si evita il problema dei dispositivi dei consumatori con bug che rilasciano erroneamente il traffico inviato a quegli 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, impostalo su True. Successivamente, uno sviluppatore può creare un servizio di tipo LoadBalancer e specificare manualmente uno degli indirizzi dal pool. Se non specificato, il criterio manual-assign è impostato su False.
- Nell'elenco di addresses: ogni indirizzo deve essere un intervallo con la notazione CIDR o il formato dell'intervallo con trattino. Per specificare un singolo indirizzo IP in un pool (ad esempio per il VIP in entrata), utilizza /32 nella notazione CIDR, ad esempio: 192.0.2.1/32.
Tieni presente quanto segue:
- Racchiudi l'intero valore tra virgolette singole.
- Lo spazio vuoto non è consentito.
- Separa ogni intervallo di indirizzi IP con un punto e virgola.
Ad esempio:
```
--metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'
```

CONTROL_PLANE_VIP: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il server API Kubernetes del cluster utente.
Esempio: --control-plane-vip=203.0.113.3
INGRESS_VIP: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il proxy in entrata.
Esempio: --ingress-vip=10.251.134.80

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

--static-ip-config-ip-blocks: specifica il gateway predefinito, la subnet mask e un elenco di indirizzi IP statici per i nodi worker nel cluster utente. Il valore del flag ha il seguente formato:
```
--static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'
```
Il valore contiene segmenti che iniziano con le parole chiave gateway, netmask e ips. Separa i segmenti con una virgola.

Tieni presente quanto segue:
- Racchiudi l'intero valore tra virgolette singole.
- Lo spazio vuoto non è consentito, tranne tra un indirizzo IP e un nome host.
Nell'elenco degli indirizzi IP:
- Puoi specificare un singolo indirizzo IP o un blocco CIDR di indirizzi IP.
- Separa ogni indirizzo IP o blocco CIDR con un punto e virgola.
- Per un singolo indirizzo IP, puoi facoltativamente specificare un nome host dopo l'indirizzo IP. Separa l'indirizzo IP e il nome host con uno spazio. Quando non specifichi un nome host, GKE on VMware 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 di indirizzi IP dei server DNS per le VM.
DNS_SEARCH_DOMAIN: un elenco separato da virgole dei domini di ricerca DNS che gli host possono utilizzare. Questi domini vengono utilizzati come parte di un elenco di ricerca di domini.
Ad esempio:
```
--dns-search-domains example.com,examplepetstore.com
```
NTP_SERVER: un elenco separato da virgole di indirizzi IP dei server temporali da utilizzare dalle VM.

F5 BIG-IP e DHCP

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

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

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=SERVICE_CIDR_BLOCK \
    --pod-address-cidr-blocks=POD_CIDR_BLOCK \
    --f5-config-address=F5_CONFIG_ADDRESS \
    --f5-config-partition=F5_CONFIG_PARTITION \
    --f5-config-snat-pool=F5_CONFIG_SNAT_POOL \
    --control-plane-vipCONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --enable-dhcp

USER_CLUSTER_NAME: un nome a tua scelta per il cluster utente. Non è possibile modificare il nome dopo la creazione del cluster. Il nome deve avere le seguenti caratteristiche:
- Deve contenere al massimo 40 caratteri
- Contenere solo caratteri alfanumerici minuscoli o un trattino (-)
- iniziano 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. Una volta creato, 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 completo del cluster, 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 sono 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
- Il log di controllo Admin creato da Cloud Audit Logs
Il nome, il progetto e la località del cluster identificano insieme in modo univoco il cluster in Google Cloud.

Importante Se prevedi di installare Anthos Service Mesh, devi installare la versione 1.19.3 o successive. Questo campo è obbligatorio perché i servizi Fleet e Connect vengono eseguiti in una regione.
VERSION: la versione di GKE on VMware per il cluster utente.
YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: se non includi il flag --admin-users come 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 dovrai 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
```
Una volta creato il cluster, l'API GKE On-Prem applica al cluster i criteri di controllo dell'accesso basato su ruoli (RBAC) di Kubernetes per concedere a te e agli altri utenti amministratori il ruolo clusterrole/cluster-admin di Kubernetes, che fornisce accesso completo a tutte le risorse del cluster in tutti gli spazi dei nomi.

Nota: oltre ai criteri RBAC di Kubernetes, devi concedere alcuni ruoli IAM (Identity and Access Management) agli utenti che non sono proprietari del progetto. Per maggiori dettagli sulla concessione dei ruoli IAM, consulta Concedere 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

F5_CONFIG_ADDRESS: l'indirizzo del bilanciatore del carico BIG-IP di F5.
F5_CONFIG_PARTITION:il nome di una partizione BIG-IP creata per il cluster utente.
F5_CONFIG_SNAT_POOL: il nome del pool SNAT, se applicabile.

CONTROL_PLANE_VIP: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il server API Kubernetes del cluster utente.
Esempio: --control-plane-vip=203.0.113.3
INGRESS_VIP: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il proxy in entrata.
Esempio: --ingress-vip=10.251.134.80

L'indirizzo IP per il VIP in entrata deve 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 da te fornito. Non includere questo flag se vuoi fornire indirizzi IP statici per i nodi del cluster o se vuoi configurare il bilanciamento del carico manuale.

Bilanciatore del carico manuale e IP statici

Questo esempio mostra come creare un cluster utente con un bilanciatore del carico manuale e come assegnare indirizzi IP statici ai nodi 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 Kubernetes, il proxy in entrata e il servizio aggiuntivo per l'aggregazione dei log sono esposti da un servizio Kubernetes di tipo LoadBalancer. Scegli i tuoi valori nodePort nell'intervallo 30.000-32.767 per questi servizi. Per il proxy in entrata, scegli un valore nodePort per il traffico HTTP e HTTPS. Per ulteriori informazioni, consulta Attivazione della modalità di bilanciamento del carico manuale.

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=SERVICE_CIDR_BLOCK \
    --pod-address-cidr-blocks=POD_CIDR_BLOCK \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --control-plane-node-port=CONTROL_PLANE_NODE_PORT \
    --ingress-vip=INGRESS_VIP \
    --ingress-http-node-port=INGRESS_HTTP_NODE_PORT \
    --ingress-https-node-port=INGRESS_HTTPS_NODE_PORT \
    --konnectivity-server-node-port=KONNECTIVITY_SERVER_NODE_PORT

Sostituisci quanto segue:

USER_CLUSTER_NAME: un nome a tua scelta per il cluster utente. Non è possibile modificare il nome dopo la creazione del cluster. Il nome deve avere le seguenti caratteristiche:
- Deve contenere al massimo 40 caratteri
- Contenere solo caratteri alfanumerici minuscoli o un trattino (-)
- iniziano 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. Una volta creato, 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 completo del cluster, 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 sono 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
- Il log di controllo Admin creato da Cloud Audit Logs
Il nome, il progetto e la località del cluster identificano insieme in modo univoco il cluster in Google Cloud.

Importante Se prevedi di installare Anthos Service Mesh, devi installare la versione 1.19.3 o successive. Questo campo è obbligatorio perché i servizi Fleet e Connect vengono eseguiti in una regione.
VERSION: la versione di GKE on VMware per il cluster utente.
YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: se non includi il flag --admin-users come 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 dovrai 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
```
Una volta creato il cluster, l'API GKE On-Prem applica al cluster i criteri di controllo dell'accesso basato su ruoli (RBAC) di Kubernetes per concedere a te e agli altri utenti amministratori il ruolo clusterrole/cluster-admin di Kubernetes, che fornisce accesso completo a tutte le risorse del cluster in tutti gli spazi dei nomi.

Nota: oltre ai criteri RBAC di Kubernetes, devi concedere alcuni ruoli IAM (Identity and Access Management) agli utenti che non sono proprietari del progetto. Per maggiori dettagli sulla concessione dei ruoli IAM, consulta Concedere 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
CONTROL_PLANE_NODE_PORT: un valore nodePort per il server API Kubernetes.
INGRESS_VIP: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il proxy in entrata.

Esempio: --ingress-vip=203.0.113.4
INGRESS_HTTP_NODE_PORT: un valore nodePort per il traffico HTTP verso il proxy in entrata.
INGRESS_HTTPS_NODE_PORT: un valore nodePort per il traffico HTTPS verso il proxy in entrata.
KONNECTIVITY_SERVER_NODE_PORT: un valore nodePort per il server Konnectivity.

--static-ip-config-ip-blocks: specifica il gateway predefinito, la subnet mask e un elenco di indirizzi IP statici per i nodi worker nel cluster utente. Il valore del flag ha il seguente formato:
```
--static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'
```
Il valore contiene segmenti che iniziano con le parole chiave gateway, netmask e ips. Separa i segmenti con una virgola.

Tieni presente quanto segue:
- Racchiudi l'intero valore tra virgolette singole.
- Lo spazio vuoto non è consentito, tranne tra un indirizzo IP e un nome host.
Nell'elenco degli indirizzi IP:
- Puoi specificare un singolo indirizzo IP o un blocco CIDR di indirizzi IP.
- Separa ogni indirizzo IP o blocco CIDR con un punto e virgola.
- Per un singolo indirizzo IP, puoi facoltativamente specificare un nome host dopo l'indirizzo IP. Separa l'indirizzo IP e il nome host con uno spazio. Quando non specifichi un nome host, GKE on VMware 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 di indirizzi IP dei server DNS per le VM.
DNS_SEARCH_DOMAIN: un elenco separato da virgole dei domini di ricerca DNS che gli host possono utilizzare. Questi domini vengono utilizzati come parte di un elenco di ricerca di domini.
Ad esempio:
```
--dns-search-domains example.com,examplepetstore.com
```
NTP_SERVER: un elenco separato da virgole di indirizzi IP dei server temporali da utilizzare dalle VM.

Flag del piano di controllo

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

--cpus=vCPUS: il numero di vCPU (minimo 4) per ciascun nodo del piano di controllo per il cluster utente. Se non specificato, il valore predefinito è 4 vCPU.
--memory=MEMORY: la dimensione della memoria in mebibyte (MiB) per ogni piano di controllo per il cluster utente. Il valore minimo è 8192 e deve essere un multiplo di 4. Se non specificato, il valore predefinito è 8192.
--replicas=NODES: il numero di nodi del piano di controllo per il cluster utente. Ad esempio, puoi selezionare 1 nodo del piano di controllo per un ambiente di sviluppo e 3 nodi del piano di controllo per ambienti di produzione ad alta disponibilità.
--enable-auto-resize: se vuoi abilitare il ridimensionamento automatico dei nodi del piano di controllo per il cluster utente, includi --enable-auto-resize. Il ridimensionamento indica che le risorse vCPU e di memoria assegnate a un nodo vengono regolate automaticamente. Se questa opzione è abilitata, i nodi del piano di controllo per il cluster utente vengono ridimensionati in base al numero di nodi worker nel cluster utente. Man mano che aggiungi altri nodi worker al cluster utente, le dimensioni dei nodi del piano di controllo aumentano.
--enable-control-plane-v2: se vuoi abilitare il piano di controllo V2, includi --enable-control-plane-v2. Quando il piano di controllo V2 è abilitato, il piano di controllo per un cluster utente viene eseguito su uno o più nodi nel cluster utente stesso. Per impostazione predefinita, il piano di controllo per un cluster utente viene eseguito su uno o più nodi nel cluster di amministrazione (denominato modello kubeception). Quando il piano di controllo V2 è abilitato, i valori per --cpus e --memory si applicano ai nodi del piano di controllo nel cluster utente. Il numero di nodi è determinato dal numero di indirizzi IP inseriti in --control-plane-ip-block. Quando il piano di controllo V2 non è abilitato, i valori per --cpus, --memory e --replicas si applicano ai nodi del piano di controllo nel cluster di amministrazione. Assicurati di tenere da parte un numero sufficiente di indirizzi IP per il cluster di amministrazione.

Se abiliti il piano di controllo V2, devi specificare anche i seguenti flag:
- --dns-servers=DNS_SERVER_1,...: un elenco separato da virgole di indirizzi IP dei server DNS per le VM.
- --ntp-servers=NTP_SERVER_1,...: un elenco separato da virgole di indirizzi IP dei server orari che le VM possono utilizzare.
- --control-plane-ip-block, che ha il seguente formato:
```
  --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1;CP_IP_ADDRESS_2 CP_HOST_2'
```
  Il valore contiene segmenti che iniziano con le parole chiave gateway, netmask e ips. Separa i segmenti con una virgola.
  
  Tieni presente quanto segue:
  - Racchiudi l'intero valore tra virgolette singole.
  - Lo spazio vuoto non è consentito, tranne tra un indirizzo IP e un nome host.
    
    Nell'elenco degli indirizzi IP:
  - Puoi specificare un singolo indirizzo IP o un blocco CIDR di indirizzi IP.
  - Separa ogni indirizzo IP o blocco CIDR con un punto e virgola.
  - Per un singolo indirizzo IP, puoi specificare facoltativamente un nome host dopo l'indirizzo IP. Separa l'indirizzo IP e il nome host con uno spazio.
  - Se specifichi un blocco CIDR, non specificare un valore per il nome host.
    
    Ad esempio:
```
--control-plane-ip-block 'gateway=192.168.0.1,netmask=255.0.0.0,ips=192.168.1.1;192.168.1.2 hostname-2;192.168.2.2/28`
```
- (Facoltativo) --dns-search-domains=DNS_SEARCH_DOMAIN_1,...: un elenco separato da virgole dei domini di ricerca DNS che gli host possono utilizzare. Questi domini vengono utilizzati come parte di un elenco di ricerca di domini.
  
  Ad esempio:
```
--dns-search-domains example.com,examplepetstore.com
```
Per un elenco completo dei flag e delle relative descrizioni, consulta il riferimento dell'interfaccia a riga di comando gcloud.

Flag vSphere

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

Nota: se hai seguito Configura l'infrastruttura minima, hai un solo host ESXi, quindi assicurati di includere questo flag.
--disable-vsphere-csi: se non includi questo flag, nel cluster utente viene eseguito il deployment dei componenti CSI (vSphere Container Storage Interface). Il driver CSI viene eseguito in un cluster Kubernetes nativo di cui è stato eseguito il deployment in vSphere per il provisioning di volumi permanenti nello spazio di archiviazione vSphere. Per ulteriori informazioni, consulta Utilizzo del driver vSphere Container Storage Interface. Se non vuoi eseguire il deployment dei componenti CSI, includi questo flag.

Per un elenco completo dei flag e delle relative descrizioni, consulta la documentazione di riferimento dell'interfaccia a riga di comando gcloud

Prima di eseguire il comando gcloud per creare il cluster, ti consigliamo di 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.

L'output del comando è simile al seguente:
```
Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.
```
Nell'output di esempio, la stringa operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 è 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 ulteriori informazioni, consulta la pagina relativa alle operazioni di gcloud container vmware.

Per creare il cluster utente sono necessari almeno 15 minuti. Puoi visualizzare il cluster nella console Google Cloud nella pagina dei cluster Anthos.

Crea un pool di nodi

Dopo la creazione del cluster, devi creare almeno un pool di nodi prima di eseguire il deployment dei carichi di lavoro.
```
gcloud container vmware node-pools create NODE_POOL_NAME \
--cluster=USER_CLUSTER_NAME  \
--project=FLEET_HOST_PROJECT_ID \
--location=REGION \
--image-type=IMAGE_TYPE  \
--boot-disk-size=BOOT_DISK_SIZE \
--cpus=vCPUS \
--memory=MEMORY \
--replicas=NODES \
--enable-load-balancer
```
Sostituisci quanto segue:
NODE_POOL_NAME: un nome a tua scelta per il pool di nodi. Il nome deve:
- Deve contenere al massimo 40 caratteri
- Contenere solo caratteri alfanumerici minuscoli o un trattino (-)
- iniziano 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 specificata al momento della creazione del cluster.
IMAGE_TYPE: il tipo di immagine del sistema operativo da eseguire sulle VM nel pool di nodi. Imposta una delle seguenti opzioni: ubuntu_containerd o cos.
BOOT_DISK_SIZE: la dimensione del disco di avvio in gibibyte (GiB) per ogni nodo nel pool. Il valore minimo è 40 GiB.
vCPUs: il numero di vCPU per ciascun nodo nel pool di nodi. Il numero minimo è 4.
MEMORY: la dimensione della memoria in mebibyte (MiB) per ogni nodo nel pool. Il minimo è 8192 MiB per nodo worker del cluster utente e il valore deve essere un multiplo di 4.
NODES: il numero di nodi nel pool di nodi. Il 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 Aggiungere un pool di nodi e il riferimento dell'interfaccia a riga di comando gcloud.

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/global/memberships/admin-cluster-1 \
    --version=1.29.100-gke.248 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --enable-dhcp \
    --service-address-cidr-blocks=10.96.232.0/24 \
    --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=10.251.133.0/24;10.251.134.80/32;10.251.134.81/32' \
    --metal-lb-config-address-pools='pool=lb-pool-2,manual-assign=True,addresses=172.16.20.62/32' \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

Per una descrizione del flag --metal-lb-config-address-pools, consulta Bilanciatore del carico.

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.29.100-gke.248 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --static-ip-config-ip-blocks='gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10 user-vm-1;172.16.20.11 user-vm-2' \
    --static-ip-config-ip-blocks='gateway=172.16.23.255,netmask=255.255.252.0,ips=172.16.20.12 user-vm-3;172.16.20.13 extra-vm' \
    --dns-servers=203.0.113.1,198.51.100.1 \
    --dns-search-domains=example.com,altostrat.com \
    --ntp-servers=216.239.35.4,216.239.35.5 \
    --service-address-cidr-blocks=10.96.232.0/24 \
    --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=10.251.133.0/24;10.251.134.80/32;10.251.134.81/32' \
    --metal-lb-config-address-pools='pool=lb-pool-2,manual-assign=True,addresses=172.16.20.62/32' \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

F5 BIG-IP e DHCP

gcloud container vmware clusters create user-cluster-2 \
    --project=example-project-12345 \
    --location=us-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/global/memberships/admin-cluster-1 \
    --version=1.29.100-gke.248 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --enable-dhcp \
    --service-address-cidr-blocks=10.96.232.0/24 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --f5-config-address=203.0.113.2 \
    --f5-config-partition=my-f5-admin-partition \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

Per una descrizione dei flag F5, consulta Bilanciatore del carico.

Bilanciatore del carico 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/global/memberships/admin-cluster-1 \
    --version=1.29.100-gke.248 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --static-ip-config-ip-blocks='gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10 user-vm-1;172.16.20.11 user-vm-2' \
    --static-ip-config-ip-blocks='gateway=172.16.23.255,netmask=255.255.252.0,ips=172.16.20.12 user-vm-3;172.16.20.13 extra-vm' \
    --dns-servers=203.0.113.1,198.51.100.1  \
    --ntp-servers=216.239.35.4,216.239.35.5 \
    --service-address-cidr-blocks=10.96.232.0/24 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --control-plane-vip=172.16.20.61 \
    --control-plane-node-port=30968 \
    --ingress-vip=172.16.20.62 \
    --ingress-http-node-port=32527 \
    --ingress-https-node-port=30139 \
    --konnectivity-server-node-port=30969

Terraform

Prima di iniziare

Ottieni il nome e la località di appartenenza del parco risorse del tuo 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 Fleet e Connect globali. 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 del parco risorse del cluster di amministrazione. Questa è una regione globale o di Google Cloud. Utilizza la posizione 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 and Connect. Specifica us-west1 o un'altra regione supportata.
L'output del comando è simile al seguente:
```
versions:
- isInstalled: true
  version: 1.14.3-gke.25
- version: 1.14.4-gke.54
- version: 1.15.0-gke.581
```
Le versioni che puoi utilizzare per creare un cluster utente sono annotate con isInstalled=true, il che significa che il cluster di amministrazione ha i componenti specifici della versione necessari per gestire i cluster utente di quella versione. Se vuoi creare un cluster utente con un'altra versione disponibile, consulta Installare una versione successiva rispetto a quella del cluster di amministrazione.

Esempio

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

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

Imposta variabili in `terraform.tfvars`

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

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

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

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"] }
]
```
Le variabili sono descritte nel seguente elenco:
- 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. Una volta creato, 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 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.
- admin_cluster_name: il nome del cluster di amministrazione che gestisce il cluster utente. L'esempio presuppone che il cluster di amministrazione utilizzi Globale come regione. Se hai un cluster di amministrazione a livello di regione:
  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. Modifica global nella regione utilizzata dal cluster di amministrazione e salva il file.
- on_prem_version: la versione di Google Distributed Cloud per il tuo cluster utente. In genere, specifichi la stessa versione del cluster di amministrazione. Per specificare una versione successiva, installa una versione successiva rispetto a quella del cluster di amministrazione. Se non conosci la versione del cluster di amministrazione, esegui gcloud container vmware clusters query-version-config, che è il primo passaggio per installare una versione successiva rispetto alla versione del cluster di amministrazione.
- admin_user_emails: un elenco di indirizzi email degli utenti a cui vengono concessi i privilegi amministrativi sul cluster. Assicurati di aggiungere il tuo indirizzo email se intendi amministrare il cluster.
  
  Al momento della creazione del cluster, 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 Kubernetes, che fornisce accesso completo a tutte le risorse del cluster in tutti gli spazi dei nomi. Consente inoltre agli utenti di accedere alla console con la propria identità Google.
- cluster_name: un nome a tua scelta per il cluster utente. Il nome non può essere modificato dopo la creazione del cluster. Il nome deve:
  - Deve contenere al massimo 40 caratteri
  - Contenere solo caratteri alfanumerici minuscoli o un trattino (-)
  - iniziano con un carattere alfabetico
  - terminare con un carattere alfanumerico
- control_plane_node_cpus: il numero di vCPU per ciascun nodo del piano di controllo per il tuo cluster utente. Il numero minimo è 4 vCPU.
- control_plane_node_memory: la dimensione della memoria in mebibyte (MiB) per ogni piano di controllo per il cluster utente. Il valore minimo è 8192 e deve essere un multiplo di 4.
- control_plane_node_replicas: il numero di nodi del piano di controllo per il cluster utente. Ad esempio, puoi inserire 1 nodo del piano di controllo per un ambiente di sviluppo e 3 nodi del piano di controllo per ambienti di produzione ad alta disponibilità.
- control_plane_vip: l'indirizzo IP virtuale (VIP) che hai scelto di configurare sul bilanciatore del carico per il server API Kubernetes del cluster utente.
- ingress_vip: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il proxy in entrata.
- lb_address_pools: un elenco di mappe che definiscono i pool di indirizzi che devono essere utilizzati dal bilanciatore del carico MetalLB. Il VIP in entrata deve trovarsi in uno di questi pool. Specifica quanto segue:
  - name: un nome per il pool.
  - addresses: un intervallo di indirizzi con notazione CIDR o intervallo con trattino. Per specificare un singolo indirizzo IP in un pool (ad esempio per il VIP in entrata), utilizza /32 nella notazione CIDR, ad esempio 192.0.2.1/32.
  Sostituisci gli indirizzi IP di esempio con i tuoi valori e, se necessario, aggiungi ulteriori pool di indirizzi.
Salva le modifiche in terraform.tfvars. Se non vuoi apportare modifiche facoltative a main.tf, passa alla sezione seguente, Creare il cluster e un pool di nodi.

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

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

cp main.tf main.tf.bak

Modalità di indirizzamento IP del nodo worker

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

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

Configura piano di controllo V2

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

Aggiungi la seguente riga dopo la riga con admin_cluster_membership:
```
  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 piano di controllo.

Crea il cluster e un pool di nodi

Inizializza e crea il piano Terraform:
```
terraform init
```
Terraform installa le librerie necessarie, ad esempio il provider Google Cloud.
Rivedi la configurazione e apporta le modifiche necessarie:
```
terraform plan
```
Applica il piano Terraform per creare il cluster utente:
```
terraform apply
```
Sono necessari almeno 15 minuti per creare il cluster utente e altri 15 minuti per creare il pool di nodi. Puoi visualizzare il cluster nella console Google Cloud nella pagina dei cluster Anthos.

Installa una versione successiva rispetto a quella del cluster di amministrazione

Un cluster di amministrazione può gestire cluster utente con versioni diverse. Se vuoi creare un cluster utente con una versione successiva 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:

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 \
    --location=REGION
```
Sostituisci quanto segue:
- ADMIN_CLUSTER_NAME: il nome del cluster di amministrazione.
- FLEET_HOST_PROJECT_ID: l'ID del progetto in cui è registrato il cluster di amministrazione.
- REGION: la regione Google Cloud in cui viene eseguita l'API GKE On-Prem. Questa è la regione che specificherai durante la creazione del cluster utente. Specifica us-west1 o un'altra regione supportata.
L'output del comando è simile al seguente:
```
versions:
- isInstalled: true
  version: 1.14.3-gke.25
- version: 1.14.4-gke.54
- version: 1.15.0-gke.581
```
Le versioni installate nel cluster di amministrazione sono annotate con isInstalled=true.
Se non lo hai già fatto, registra il cluster di amministrazione nell'API GKE On-Prem. Dopo aver registrato il cluster nell'API GKE On-Prem, non devi ripetere questo passaggio.
Scarica la nuova versione dei componenti ed eseguine il deployment nel cluster di amministrazione:
```
gcloud vmware admin-clusters update ADMIN_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --required-platform-version=VERSION
```
Questo comando scarica la versione dei componenti specificati in --required-platform-version nel cluster di amministrazione, quindi esegue il deployment dei componenti. Ora puoi creare un cluster utente con la versione specificata.

Risoluzione dei problemi

Consulta Risolvere i problemi di creazione e upgrade del cluster.

Creazione di un cluster utente

Prima di iniziare

Creazione di un cluster utente

Gkectl

Panoramica della procedura

Compila i file di configurazione

name

gkeOnPremVersion

enableControlplaneV2

Kubernetes

enableDataplaneV2

vCenter

Utilizzo di un data center e di 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

usageMetering

cloudAuditLogging

Esempio di file di configurazione compilati

user-ipblock.yaml

user-cluster.yaml

Convalidare il file di configurazione

3. (Facoltativo) Importa immagini del sistema operativo in vSphere ed esegui il push delle immagini container a un registro privato

4. Creazione di un cluster utente

Crea un cluster utente:

Individuare il file kubeconfig del cluster utente

5. Verifica che il cluster utente sia in esecuzione

Console

Inizia

Impostazioni di base del cluster

Piano di controllo

Networking

Bilanciatore del carico

Abbinato a MetalLB

F5 BIG-IP

Manuale

Funzionalità

Pool di nodi

Interfaccia a riga di comando gcloud

Prima di iniziare

Esempi

MetalLB e DHCP

MetalLB e IP statici

F5 BIG-IP e DHCP

Bilanciatore del carico manuale e IP statici

Flag del piano di controllo

Flag vSphere

Crea un pool di nodi

Esempi di comandi gcloud

MetalLB e DHCP

MetalLB e IP statici

F5 BIG-IP e DHCP

Bilanciatore del carico manuale e IP statici

Terraform

Prima di iniziare

Esempio

Imposta variabili in terraform.tfvars

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

Modalità di indirizzamento IP del nodo worker

Configura piano di controllo V2

Crea il cluster e un pool di nodi

Installa una versione successiva rispetto a quella del cluster di amministrazione

Risoluzione dei problemi

Passaggi successivi

`name`

`gkeOnPremVersion`

`enableControlplaneV2`

`enableDataplaneV2`

`vCenter`

`network`

`loadBalancer`

`advancedNetworking`

`multipleNetworkInterfaces`

`storage`

`masterNode`

`nodePools`

`antiAffinityGroups`

`stackdriver`

`gkeConnect`

`gkeOnPremAPI`

`usageMetering`

`cloudAuditLogging`

Imposta variabili in `terraform.tfvars`

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