Creazione di un cluster utente

gkectl

Per impostazione predefinita nella versione 1.32 e successive, i nuovi cluster creati utilizzando gkectl vengono creati con il cluster avanzato abilitato. Assicurati di esaminare le differenze quando esegui cluster avanzati. Se non vuoi attivare il cluster avanzato, devi impostare enableAdvancedCluster su false nel file di configurazione.

Panoramica della procedura

Di seguito sono riportati i passaggi principali per utilizzare gkectl per creare un cluster di utenti:

1. Compila i file di configurazione

   Specifica i dettagli del nuovo cluster completando un file di configurazione del cluster utente, un file di configurazione delle credenziali ed eventualmente un file di blocco IP.

2. (Facoltativo) Importa le immagini del sistema operativo in vSphere e invia le immagini dei container al registro privato, se applicabile.

   Esegui gkectl prepare.

3. Creazione di un cluster utente

   Esegui gkectl create cluster per creare un cluster come specificato nel file di configurazione.

4. Verifica che il cluster utente sia in esecuzione

   Utilizza kubectl per visualizzare i nodi del cluster.

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

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

Compila i file di configurazione

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

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

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

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

Sostituisci quanto segue:

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

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

Familiarizza con il file di configurazione esaminando il documento File di configurazione del cluster utente. Ti consigliamo di tenere aperto questo documento in una scheda o finestra separata, perché lo consulterai mentre completi i passaggi successivi.

name

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

gkeOnPremVersion

Questo campo è già compilato per te. Specifica la versione di Google Distributed Cloud. Ad esempio, 1.32.100-gke.106.

enableAdvancedCluster

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

Tieni presenti le seguenti limitazioni relative all'anteprima avanzata del cluster:

• Puoi abilitare il cluster avanzato al momento della creazione del cluster solo per i nuovi cluster 1.31.
• Una volta abilitato il cluster avanzato, non potrai eseguire l'upgrade del cluster alla versione 1.32. Attiva il cluster avanzato solo in un ambiente di test.

enableControlplaneV2

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

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

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

kubeception

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

Per un cluster kubeception:

• Imposta enableControlplaneV2 su false.

• Non compilare la sezione controlPlaneIPBlock.

• Specifica gli indirizzi IP per i nodi del control plane del cluster utente nel file di blocco IP del cluster di amministrazione.

enableDataplaneV2

Imposta enableDataplaneV2 su true.

vCenter

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

Per ogni cluster utente che crei, hai la possibilità di ignorare alcuni dei valori vCenter globali.

Per ignorare uno qualsiasi dei valori globali 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 data center separati per il cluster di amministrazione e i cluster utente.

Utilizzo di un data center e un cluster vSphere

L'opzione predefinita prevede l'utilizzo di un data center e 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 di vCenter verranno ereditati dal cluster di amministrazione.

Utilizzo di cluster vSphere separati

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

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

Utilizzo di data center vSphere separati

Il cluster utente e il cluster amministratore 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 di utenti può utilizzare un account vCenter diverso, con vCenter.credentials diversi, rispetto al cluster di amministrazione. L'account vCenter per il cluster di amministrazione deve accedere al data center del cluster di amministrazione, mentre l'account vCenter per il cluster utente deve accedere solo al data center del cluster utente.

Utilizzo di istanze separate di vCenter Server

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

Ad esempio, in una località edge, potresti voler avere una macchina fisica che esegue vCenter Server e una o più macchine fisiche che eseguono ESXi. Puoi quindi utilizzare la tua istanza locale di vCenter Server per creare una gerarchia di oggetti vSphere, inclusi 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 di vCenter Server 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 ottengano i loro indirizzi IP. Le opzioni sono:

• Da un server DHCP che hai configurato in anticipo. Imposta network.ipMode.type su "dhcp".

• Da un elenco di indirizzi IP statici che fornisci. Imposta network.ipMode.type su "static" e crea un file di blocco IP che fornisca gli indirizzi IP statici. Per un esempio di file di blocco IP, vedi Esempio di file di configurazione compilati.

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

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

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

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

Indipendentemente dal fatto che tu utilizzi 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

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

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

• Bilanciamento del carico in bundle MetalLB. Imposta loadBalancer.kind su "MetalLB". Compila anche la sezione loadBalancer.metalLB.addressPools e imposta enableLoadBalancer su true per almeno uno dei tuoi pool di nodi. Per ulteriori informazioni, vedi Bilanciamento del carico in bundle con MetalLB.

• Bilanciamento del carico manuale. Imposta loadBalancer.kind su "ManualLB" e compila la sezione manualLB. Per saperne di più, consulta Bilanciamento del carico manuale.

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

advancedNetworking

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

multipleNetworkInterfaces

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

storage

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

masterNode

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

Se il campo enableAdvancedCluster è true, devi impostare il campo replicas su 3. Solo i cluster utente HA sono supportati nei cluster avanzati.

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

nodePools

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

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

Se abiliti il cluster avanzato, imposta nodePools[i]osImageType su ubuntu_cgroupv2 o ubuntu_containerd.

Per saperne di più, consulta Pool di nodi e Creare e gestire pool di nodi.

antiAffinityGroups

Imposta antiAffinityGroups.enabled su true o false.

Questo campo specifica se Google Distributed Cloud crea regole anti-affinità Distributed Resource Scheduler (DRS) per i nodi worker, in modo da distribuirli in almeno tre host fisici del 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. ovvero, 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 essere la stessa della regione impostata in cloudAuditLogging.clusterLocation e gkeConnect.location. Inoltre, se gkeOnPremAPI.enabled è true, in gkeOnPremAPI.location deve essere impostata la stessa regione.

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

gkeConnect

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

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

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

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

gkeOnPremAPI

Nelle versioni 1.16 e successive, se l'API GKE On-Prem è abilitata nel tuo progettoGoogle Cloud , tutti i cluster del progetto vengono registrati automaticamente nell'API GKE On-Prem nella regione configurata in stackdriver.clusterLocation. La regione gkeOnPremAPI.location deve corrispondere 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 cluster nel progetto, disabilita gkeonprem.googleapis.com (il nome del servizio per l'API GKE On-Prem) nel progetto. Per istruzioni, vedi Disattivare i servizi.

cloudAuditLogging

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

Tieni presente i seguenti requisiti:

• Se abiliti il cluster avanzato, imposta cloudAuditLogging.serviceAccountKeyPath sullo stesso percorso di stackdriver.serviceAccountKeyPath.

• L'ID in cloudAuditLogging.projectID deve essere uguale all'ID in gkeConnect.projectID e stackdriver.projectID.

• La regione in cloudAuditLogging.clusterLocation deve essere la stessa impostata in gkeConnect.location e stackdriver.clusterLocation. Inoltre, se gkeOnPremAPI.enabled è true, la stessa regione deve essere impostata in gkeOnPremAPI.location.

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

Esempio di file di configurazione compilati

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

user-ipblock.yaml

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

user-cluster.yaml

cat user-cluster.yaml
apiVersion: v1
kind: UserCluster
name: "my-user-cluster"
gkeOnPremVersion: 1.32.100-gke.106
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

Ecco i punti importanti da comprendere nell'esempio precedente:

• Il campo nodePools.replicas è impostato su 3, il che significa che ci sono tre nodi worker in "worker-node-pool". Tutti i nodi di lavoro utilizzano indirizzi IP statici perché network.ipMode.type è impostato su "static".

• Gli indirizzi IP statici per i nodi worker sono specificati in un file di blocco IP. Il file del blocco IP contiene quattro indirizzi anche se ci sono solo tre nodi worker. L'indirizzo IP aggiuntivo è necessario durante l'upgrade, l'aggiornamento e la riparazione automatica del cluster.

• I server DNS e NTP sono specificati nella sezione hostConfig. In questo esempio, questi server DNS e NTP sono per i nodi del control plane e i nodi worker. Questo perché i nodi worker hanno indirizzi IP statici. Se i nodi worker ricevono i loro indirizzi IP da un server DHCP, questi server DNS e NTP sono solo per i nodi del control plane.

• Gli indirizzi IP statici per i tre nodi del control plane sono specificati nella sezione network.controlPlaneIPBlock del file di configurazione del cluster utente. Non è necessario un indirizzo IP aggiuntivo in questo blocco.

• Controlplane V2 è abilitato.

• Il campo masterNode.replicas è impostato su 3, quindi il cluster avrà un control plane ad alta disponibilità.

• Il VIP del control plane e il VIP Ingress si trovano entrambi nella stessa VLAN dei nodi worker e dei nodi del control plane.

• Gli IP virtuali riservati ai servizi di tipo LoadBalancer sono specificati nella sezione loadBalancer.metalLB.addressPools del file di configurazione del cluster utente. Questi VIP si trovano nella stessa VLAN dei nodi worker e dei nodi del control plane. L'insieme di VIP specificati in questa sezione deve includere il VIP Ingress e non deve includere il VIP del control plane.

• Il file di configurazione del cluster utente non include una sezione vCenter. In questo modo, 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 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 di nuovo il file.

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

(Facoltativo) Importa le immagini del sistema operativo in vSphere ed esegui il push delle immagini container in 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 vCenter Server diverso dal cluster di amministrazione.

• Il cluster utente ha una cartella vCenter diversa da quella del cluster di amministrazione.

• Il cluster utente utilizza un registro dei container privato diverso da quello 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 bundle. Questo file si trova nella tua workstation di amministrazione in /var/lib/gke/bundles/. Ad esempio:

  /var/lib/gke/bundles/gke-onprem-vsphere-1.32.100-gke.106-full.tgz
  

• USER_CLUSTER_CONFIG: il percorso del file di configurazione del cluster utente

Creazione di un cluster utente

Esegui questo comando per creare un cluster utente:

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

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

Individua il file kubeconfig del cluster utente

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

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

kubectl config get-clusters --kubeconfig USER_CLUSTER_KUBECONFIG

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

NAME
my-user-cluster

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

Verifica che il cluster utente sia in esecuzione

Verifica che il cluster utente sia in esecuzione:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

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

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

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

Console

Inizia

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

   Vai a Crea cluster VM

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

3. Nella sezione Scegli il tipo di cluster, seleziona Crea un cluster utente per un cluster di amministrazione esistente.

Impostazioni di base del cluster

Inserisci le informazioni di base sul cluster.

1. Inserisci un nome per il cluster di utenti.

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

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

   Se il cluster di amministrazione che vuoi utilizzare non viene visualizzato, consulta la sezione per la risoluzione dei problemi Il cluster di amministrazione non viene visualizzato nell'elenco a discesa Nozioni di base sui cluster.

3. Nel campo GCP API Location (Posizione API GCP), seleziona la regione Google Cloud dall'elenco. Questa impostazione specifica la regione in cui vengono eseguiti i seguenti servizi e API:

   • API GKE On-Prem (gkeonprem.googleapis.com)
   • Servizio flotta (gkehub.googleapis.com)
   • Servizio Connect (gkeconnect.googleapis.com)

   Questa impostazione controlla anche la regione in cui vengono archiviati:

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

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

4. Seleziona la versione di Google Distributed Cloud per il cluster utente.

5. In qualità di creatore del cluster, ti vengono concessi i privilegi di amministratore del cluster. (Facoltativo) Inserisci l'indirizzo email di un altro utente che amministrerà il cluster nel campo Utente amministratore cluster della sezione Autorizzazione.

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

6. Fai clic su Avanti per andare alla sezione Control plane.

Control plane

Tutti i campi della sezione Control plane sono impostati con i valori predefiniti. Rivedi i valori predefiniti e, se vuoi, modificali in base alle esigenze.

1. Nel campo vCPU nodo del control plane, inserisci il numero di vCPU (minimo 4) per ciascun nodo del control plane per il tuo cluster utente.

2. Nel campo Memoria nodo del control plane, inserisci la dimensione della memoria in MiB (minimo 8192 e deve essere un multiplo di 4) per ogni control plane del tuo cluster utente.

3. In Nodi del control plane, seleziona il numero di nodi del control plane per il cluster utente. Ad esempio, puoi selezionare 1 nodo del control plane per un ambiente di sviluppo e 3 nodi del control plane per ambienti di produzione ad alta disponibilità.

4. (Facoltativo) Seleziona Ridimensionamento automatico dei nodi. Il ridimensionamento comporta la regolazione automatica delle risorse vCPU e di memoria assegnate a un nodo. Se questa opzione è abilitata, i nodi del control plane per il cluster utente vengono ridimensionati in base al numero di nodi worker nel cluster utente. Pertanto, man mano che aggiungi più nodi worker al cluster utente, le dimensioni dei nodi del control plane aumentano.

5. Nella sezione IP dei nodi del control plane, inserisci gli indirizzi IP per il gateway, la subnet mask e i nodi del control plane.

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

Networking

In questa sezione, specifica gli indirizzi IP per i nodi, i pod e i servizi del tuo cluster. Un cluster utente deve avere un indirizzo IP per ogni nodo e un indirizzo IP aggiuntivo per un nodo temporaneo necessario durante gli upgrade, gli aggiornamenti e la riparazione automatica del cluster. Per ulteriori informazioni, vedi Di quanti indirizzi IP ha bisogno un cluster di utenti?.

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

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

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

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

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

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

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

      • Se inserisci un blocco CIDR, non inserire un nome host.

      • Se inserisci un singolo indirizzo IP, puoi facoltativamente inserire un nome host. Se non inserisci un nome host, Google Distributed Cloud utilizza il nome della VM da vSphere come nome host.

   4. Fai clic su + Aggiungi indirizzo IP in base alle esigenze per inserire altri indirizzi IP.

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

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

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

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

   1. Inserisci gli indirizzi IP dei server DNS.
   2. Inserisci gli indirizzi IP dei server NTP.
   3. (Facoltativo) Inserisci i domini di ricerca DNS.

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

Bilanciatore del carico

Scegli il bilanciatore del carico da configurare per il cluster. Per saperne di più, consulta Panoramica del bilanciatore del carico.

Seleziona il tipo di bilanciatore del carico dall'elenco.

Funzionalità

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

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

   • Cloud Logging dei servizi di sistema

   • Cloud Monitoring dei servizi di sistema

   • Il log di controllo delle attività di amministrazione

2. Le seguenti funzionalità sono attive per impostazione predefinita, ma puoi disattivarle:

   • Attiva driver CSI vSphere: chiamato anche plug-in vSphere Container Storage. Il driver Container Storage Interface (CSI) viene eseguito in un cluster Kubernetes di cui è stato eseguito il deployment in vSphere per il provisioning di volumi permanenti nell'archiviazione di vSphere. Per ulteriori informazioni, consulta Utilizzo del driver Container Storage Interface di vSphere.

   • Attiva gruppi anti-affinità: le regole anti-affinità Distributed Resource Scheduler (DRS) di VMware vengono create automaticamente per i nodi del cluster utente, in modo da distribuirli in almeno 3 host fisici del data center. Assicurati che il tuo ambiente vSphere soddisfi i requisiti.

3. 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 saperne di più, consulta Creare e gestire i pool di nodi .

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

   1. Inserisci il Nome pool di nodi o accetta "default-pool" come nome.
   2. Inserisci il numero di vCPUs per ogni nodo nel pool (minimo 4 per worker cluster utente).
   3. Inserisci la dimensione della memoria in mebibyte (MiB) per ogni nodo nel pool (minimo 8192 MiB per nodo worker del cluster utente; il valore deve essere un multiplo di 4).
   4. Nel campo Nodi, inserisci il numero di nodi nel pool (minimo 3). Se hai inserito indirizzi IP statici per gli IP nodo 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 del 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 unpool di nodil. Lascia selezionata l'opzione Utilizza questo pool di nodi per il bilanciamento del carico MetalLB o aggiungi un altro pool di nodi da utilizzare per MetalLB.

2. Nella sezione Metadati del node pool (facoltativo), se vuoi aggiungere etichette e taint> di Kubernetes, fai quanto segue:

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

3. Fai clic su Verifica e completa per creare il cluster di utenti. La creazione del cluster utente richiede 15 minuti o più. La console mostra 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, la console visualizza un messaggio di errore che dovrebbe essere abbastanza chiaro da consentirti di risolvere il problema di configurazione e riprovare a creare il cluster.

   Per ulteriori informazioni sui possibili errori e su come risolverli, consulta Risoluzione dei problemi relativi alla creazione di cluster utente nella Google Cloud console.

Interfaccia a riga di comando gcloud

Utilizza il seguente comando per creare un cluster utente:

gcloud container vmware clusters create

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

gcloud container vmware node-pools create

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

Raccogliere informazioni

Raccogli alcune informazioni necessarie per creare il cluster.

1. Recupera il nome e la posizione di appartenenza al parco risorse del cluster di amministrazione:

   gcloud container fleet memberships list \
       --project=FLEET_HOST_PROJECT_ID
   

   Sostituisci FLEET_HOST_PROJECT_ID con l'ID del progetto a cui è registrato il cluster di amministrazione.

   L'output è simile al seguente:

   NAME             EXTERNAL_ID                           LOCATION
   admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
   admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
   admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1
   

   La località specifica dove vengono eseguiti i servizi Fleet e Connect. I cluster di amministrazione creati prima della versione 1.28 sono gestiti dai servizi globali Fleet e Connect. Nelle versioni 1.28 e successive, puoi specificare global o una regione Google Cloud quando crei il cluster di amministrazione. Specifichi la regione nel flag --admin-cluster-membership-location nei comandi di esempio che seguono.

2. Per ottenere 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 a cui è registrato il cluster di amministrazione.

   • ADMIN_CLUSTER_REGION: la regione di appartenenza del parco del cluster di amministrazione. Può essere globale o una Google Cloud regione. Utilizza la posizione del cluster di amministrazione dall'output di gcloud container fleet memberships list.

   • REGION: la Google Cloud regione che utilizzerai quando crei il cluster utente. Questa è la regione in cui l'API GKE On-Prem viene eseguita e archivia i relativi metadati.

     • Se il cluster di amministrazione è registrato nell'API GKE On-Prem, utilizza la stessa regione del cluster di amministrazione. Per scoprire la regione del cluster di amministrazione, esegui questo comando:

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

     • Se il cluster di amministrazione non è registrato nell'API GKE On-Prem, specifica us-west1 o un'altra regione supportata. Se in seguito registri il cluster di amministrazione nell'API GKE On-Prem, utilizza la stessa regione in cui si trova il cluster utente.

   L'output del comando gcloud container vmware clusters query-version-config è simile al seguente:

   versions:
   - isInstalled: true
     version: 1.28.800-gke.109
   - version: 1.29.0-gke.1456
   - version: 1.29.100-gke.248
   - version: 1.29.200-gke.245
   - version: 1.29.300-gke.184
   

   Il comando restituisce anche una spiegazione delle versioni che puoi utilizzare per la creazione o l'upgrade del cluster utente. Le versioni consentite sono annotate con isInstalled: true, il che significa che il cluster di amministrazione dispone dei componenti specifici della versione necessari per gestire i cluster utente di quella versione. Se vuoi utilizzare una versione installata sul cluster di amministrazione, vai alla sezione Esempi per creare il cluster utente.

Installare una versione diversa

Un cluster di amministrazione può gestire cluster utente in versioni diverse. L'output del comando query-version-config elenca altre versioni che puoi utilizzare quando crei il cluster. Se vuoi creare un cluster utente con una versione diversa da quella del cluster di amministrazione, devi scaricare e implementare i componenti necessari al cluster di amministrazione per gestire i cluster utente di quella versione, come segue:

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

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

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

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

Esempi

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

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

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

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

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

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

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

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

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

Dopo l'esecuzione del cluster, devi aggiungere un pool di nodi prima di eseguire il deployment dei carichi di lavoro, come descritto nella sezione Crea un node pool.

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

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

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

Flag del control plane

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

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

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

• --replicas=NODES: il numero di nodi del control plane per il cluster utente. Ad esempio, puoi selezionare 1 nodo del control plane per un ambiente di sviluppo e 3 nodi del control plane per ambienti di produzione ad alta disponibilità (HA).

• --enable-auto-resize: se vuoi attivare il ridimensionamento automatico dei nodi del control plane per il cluster utente, includi --enable-auto-resize. Il ridimensionamento comporta la modifica automatica delle risorse vCPU e di memoria assegnate a un nodo. Se questa opzione è abilitata, i nodi del control plane per il cluster utente vengono ridimensionati in base al numero di nodi worker nel cluster utente. Man mano che aggiungi altri nodi worker al cluster utente, le dimensioni dei nodi del control plane aumentano.

• --enable-control-plane-v2: per abilitare Controlplane V2, che consigliamo, includi questo flag. Quando Controlplane V2 è abilitato, il control plane per un cluster utente viene eseguito su uno o più nodi nel cluster utente stesso. Nella versione 1.30 e successive, è richiesto Controlplane V2.

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

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

  • --ntp-servers=NTP_SERVER_1,...: un elenco separato da virgole degli indirizzi IP dei server di sincronizzazione dell'ora da utilizzare per le VM.

  • --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 ha 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 di indirizzi IP CIDR.

    • 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 utilizzabili dagli host. Questi domini vengono utilizzati come parte di un elenco di ricerca di domini.

    Ad esempio:

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

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

  Flag vSphere

  Specifica i seguenti flag facoltativi, se necessario:

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

• --disable-vsphere-csi: se non includi questo flag, i componenti vSphere Container Storage Interface (CSI) vengono implementati nel cluster utente. Il driver CSI viene eseguito in un cluster Kubernetes nativo di cui è stato eseguito il deployment in vSphere per il provisioning di volumi permanenti nell'archiviazione di vSphere. Per ulteriori informazioni, consulta Utilizzo del driver Container Storage Interface di vSphere. 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 di gcloud CLI.

  Monitorare l'avanzamento della creazione del cluster

  L'output del comando di creazione del cluster è simile al seguente:

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

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

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

  Per saperne di più, consulta gcloud container vmware operations.

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

  Crea un node pool

  Dopo aver creato il cluster, devi creare almeno un pool di nodi prima di eseguire il deployment dei 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 scelto da te per il node pool. Il nome deve:

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

• USER_CLUSTER_NAME: il nome del cluster utente appena creato.

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

• REGION: La Google Cloud regione che hai specificato durante la creazione del cluster.

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

• BOOT_DISK_SIZE: le dimensioni del disco di avvio in gibibyte (GiB) per ogni nodo nel pool. Il valore minimo è 40 GiB.

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

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

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

• Se utilizzi MetalLB come bilanciatore del carico, includi facoltativamente --enable-load-balancer se vuoi consentire l'esecuzione di MetalLB Speaker 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 la documentazione di riferimento di gcloud CLI.

Comandi gcloud di esempio

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

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.32.0-gke.1087 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.10 user-vm-1;192.0.2.11 user-vm-2' \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.12 user-vm-3;192.0.2.13 extra-vm' \
    --dns-servers=203.0.113.1,203.0.113.2  \
    --dns-search-domains=example.com,altostrat.com \
    --ntp-servers=203.0.113.3,203.0.113.4 \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=192.0.2.254,netmask=255.255.255.0,ips=198.51.100.1 cp-vm-1;198.51.100.2 cp-vm-2;198.51.100.3 cp-vm-3' \
    --replicas=3 \
    --metal-lb-config-address-pools='pool=lb-pool-1,manual-assign=False,avoid-buggy-ips=True,addresses=192.0.2.0/26;lb-ingress-vip-pool,manual-assign=True,addresses=198.51.100.1/32' \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

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

Terraform

Prima di iniziare

1. Recupera il nome e la posizione di appartenenza al parco risorse del cluster di amministrazione:

   gcloud container fleet memberships list \
       --project=FLEET_HOST_PROJECT_ID
   

   Sostituisci FLEET_HOST_PROJECT_ID con l'ID del progetto a cui è registrato il cluster di amministrazione.

   L'output è simile al seguente:

   NAME             EXTERNAL_ID                           LOCATION
   admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
   admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
   admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1
   

   La località specifica dove vengono eseguiti i servizi Fleet e Connect. I cluster di amministrazione creati prima della versione 1.28 sono gestiti dai servizi globali Fleet e Connect. Nelle versioni 1.28 e successive, puoi specificare global o una regione Google Cloud quando crei il cluster.

2. Per ottenere 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 a cui è registrato il cluster di amministrazione.

   • ADMIN_CLUSTER_REGION: la regione di appartenenza del parco del cluster di amministrazione. Può essere globale o una Google Cloud regione. Utilizza la posizione del cluster di amministrazione dall'output di gcloud container fleet memberships list.

   • REGION: La Google Cloud regione che utilizzerai quando crei il cluster. Questa è la regione in cui vengono eseguiti l'API GKE On-Prem e i servizi Fleet e Connect. Specifica us-west1 o un'altra regione supportata.

   L'output 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
   

   Il comando restituisce anche una spiegazione delle versioni che puoi utilizzare per la creazione o l'upgrade del cluster utente. Le versioni consentite sono annotate con isInstalled: true, il che significa che il cluster di amministrazione dispone dei componenti specifici della versione necessari per gestire i cluster utente di quella versione. Se vuoi utilizzare una versione installata sul cluster di amministrazione, vai alla sezione Esempio per creare il cluster utente.

Installare una versione diversa

Un cluster di amministrazione può gestire cluster utente in versioni diverse. L'output del comando query-version-config elenca altre versioni che puoi utilizzare quando crei il cluster. Se vuoi creare un cluster utente con una versione diversa da quella del cluster di amministrazione, devi scaricare e implementare i componenti necessari al cluster di amministrazione per gestire i cluster utente di quella versione, come segue:

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

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

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

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

Esempio

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

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

Imposta le variabili in terraform.tfvars

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

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

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

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

   cp terraform.tfvars.sample terraform.tfvars
   

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

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

   Il seguente elenco descrive le variabili:

   • project_id: l'ID del progetto in cui vuoi creare il cluster. Il progetto specificato viene utilizzato anche come progetto host del parco risorse. Deve essere lo stesso progetto in cui è registrato il cluster di amministrazione. Dopo la creazione del cluster utente, questo 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 global come regione. Se hai un cluster di amministrazione regionale:

     1. Apri main.tf in un editor di testo.
     2. Cerca admin_cluster_membership, che ha il seguente aspetto:

     admin_cluster_membership = "projects/${var.project_id}/locations/global/memberships/${var.admin_cluster_name}"

     1. Modifica global con la regione utilizzata dal cluster di amministrazione e salva il file.

   • on_prem_version: la versione di Google Distributed Cloud per il cluster utente.

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

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

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

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

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

   • control_plane_node_memory: La dimensione della memoria in mebibyte (MiB) per ciascun control plane del cluster utente. Il valore minimo è 8192 e deve essere un multiplo di 4.

   • control_plane_node_replicas: il numero di nodi del control plane per il cluster utente. Ad esempio, puoi inserire 1 nodo del control plane per un ambiente di sviluppo e 3 nodi del control plane per ambienti di produzione ad alta disponibilità (HA).

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

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

   • lb_address_pools: un elenco di mappe che definiscono i pool di indirizzi da utilizzare 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 in notazione CIDR o in formato intervallo con trattino. Per specificare un singolo indirizzo IP in un pool (ad esempio per il VIP Ingress), utilizza /32 nella notazione CIDR, ad esempio: 192.0.2.1/32.

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

4. Salva le modifiche in terraform.tfvars. Se non vuoi apportare modifiche facoltative a main.tf, vai alla sezione successiva, Crea il cluster e un node pool.

Configura Controlplane V2

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

  cp main.tf main.tf.bak
  

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

1. Aggiungi la seguente riga al blocco resource:

     enable_control_plane_v2 = "true"
   

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

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

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

(Facoltativo) Abilita il cluster avanzato

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

enable_advanced_cluster = true

Assicurati di esaminare le differenze quando esegui cluster avanzati prima di attivare il cluster avanzato.

(Facoltativo) Modalità di assegnazione degli indirizzi IP dei nodi worker

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

cp main.tf main.tf.bak

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

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

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

2. Sostituisci quanto segue con i tuoi valori:

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

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

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

   • ntp_servers: un elenco degli indirizzi IP dei server di sincronizzazione dell'ora da utilizzare per le VM.

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

Crea il cluster e un pool di nodi

1. Inizializza e crea il piano Terraform:

   terraform init
   

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

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

   terraform plan
   

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

   terraform apply
   

   La creazione del cluster utente richiede circa 15 minuti o più e altri 15 minuti per creare ilpool di nodil. Puoi visualizzare il cluster nella console Google Cloud nella pagina Cluster GKE.

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

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

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

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

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

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