Anthos clusters on VMware ora è Google Distributed Cloud (solo software) per VMware. Per ulteriori informazioni, consulta la panoramica del prodotto.

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. Questa pagina è dedicata a Amministratori, architetti e operatori che configurano, monitorano per gestire l'infrastruttura tecnica. Per scoprire di più sui ruoli comuni ed esempi a cui facciamo riferimento nei contenuti di Google Cloud, Ruoli e attività utente comuni di GKE Enterprise.

Esistono diversi strumenti che puoi utilizzare per creare un cluster di utenti:

gkectl
Console Google Cloud
Google Cloud CLI
Terraform

Tre di questi strumenti (la console, l'interfaccia a riga di comando gcloud e Terraform) sono client dell'API GKE On-Prem.

Per indicazioni su quale strumento utilizzare, consulta Scegliere uno strumento per gestire il ciclo di vita del cluster.

Prima di iniziare

Se non l'hai ancora fatto, configura le risorse Google Cloud come descritto in questi documenti:
Quando configuri progetto host del parco risorse, tieni presente la tua scelta dello strumento. Se hai scelto uno dei Per i client API GKE On-Prem, devi abilitare altre API. Per l'elenco delle API, consulta Abilitare le API nel progetto host del parco veicoli.
Prima di creare un cluster utente, devi disporre di un cluster di amministrazione per gestire per il cluster utente. Se non l'hai ancora fatto, crea un postazione di lavoro di amministrazione e un cluster di amministrazione.
Determina la versione del cluster utente da installare. Quando crei un cluster utente, in genere installi la versione corrispondente a quella del cluster di amministrazione. Ma puoi installare una patch successiva e nella versione 1.28 e successive, i cluster utente possono essere o versioni successive del rispettivo cluster di amministrazione.
Ti consigliamo vivamente di abilitare il piano di controllo V2. Quando il piano di controllo V2 se abilitato, il piano di controllo per il cluster utente viene eseguito su uno o più nodi nel cluster utente stesso. Se prevedi di installare la versione 1.30 o una versione successiva standard, il piano di controllo V2 è obbligatorio. L'alternativa è creare un utente che utilizza kubeception. Nel caso di kubeception, il control plane per il cluster utente viene eseguito su uno o più nodi del cluster di amministrazione.
Esamina il documento di pianificazione degli indirizzi IP, e assicurati di avere a disposizione un numero sufficiente di indirizzi IP.
Consulta la panoramica del bilanciamento del carico e rivedi la tua decisione sul tipo di bilanciatore del carico che vuoi utilizzare. Puoi utilizzare il bilanciatore del carico MetalLB in bundle oppure 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 di cui hai bisogno e quale sistema operativo vuoi eseguire in ciascuno dei tuoi pool.
Valuta se vuoi utilizzare elementi Cluster vSphere per il cluster di amministrazione e i cluster utente e se vuoi utilizzare data center. Valuta anche se vuoi utilizzare istanze separate di Server vCenter.
Nella versione 1.29 e successive, i controlli preflight lato server vengono abilitati predefinito. I controlli preliminari lato server richiedono regole firewall aggiuntive. In Regole firewall per i cluster di amministrazione, cerca "Controlli preliminari" 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é a livello locale 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 in un cluster utente.

Creazione di un cluster utente

gkectl

Panoramica della procedura

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

Connettiti alla workstation di amministrazione

La workstation di amministrazione è una macchina con gli strumenti necessari per creare un cluster utente.
Compila i file di configurazione

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

Esegui gkectl prepare.
Creazione di un cluster utente

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

Utilizza kubectl per visualizzare i nodi del cluster.

Al termine di questa procedura, avrai un cluster utente in esecuzione in cui puoi eseguire il deployment dei tuoi 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 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 serve a creare l'utente in un cluster Kubernetes.

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

`name`

Imposta il parametro name con 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.30.0-gke.1930.

`enableControlplaneV2`

Per creare un cluster utente con il control plane V2 abilitato, imposta enableControlplaneV2 su true.

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

kubeception

Se imposti questo campo su false, il cluster utilizzerà kubecetption. Con kubeception, il piano di controllo 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 piano di controllo del cluster utente nella File del blocco IP del cluster di amministrazione.

`enableDataplaneV2`

Imposta enableDataplaneV2 a true.

`vCenter`

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

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

Per sostituire uno dei valori vCenter globali, compila i campi pertinenti nella sezione vCenter del file di configurazione del cluster utente.

In particolare, potresti voler usare cluster vSphere separati per l'amministratore cluster e cluster utente e potresti voler usare data center separati per il tuo 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 di un cluster vSphere per il cluster di amministrazione e il cluster utente. Per questa opzione, non impostare valori vCenter nel file di configurazione del cluster utente. I valori vCenter verranno ereditati dal cluster di amministrazione.

Utilizzo di cluster vSphere separati

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

Se il cluster amministratore e il cluster utente si trovano in cluster vSphere separati, possono essere nello stesso data center o in data center diversi.

Utilizzo di data center vSphere separati

Il cluster di utenti e il cluster di amministratori possono trovarsi in centri dati 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.credentialsdiversi, rispetto al cluster di amministrazione. L'account vCenter per Il cluster di amministrazione deve accedere al data center del cluster di amministrazione, mentre il cluster di amministrazione vCenter l'account 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 di vCenter Server. In altre parole, il cluster di amministrazione e un cluster utente associato utilizzano istanze diverse di vCenter Server.

Ad esempio, in una località perimetrale, potresti voler disporre di una macchina fisica con vCenter Server e una o più macchine fisiche che eseguono ESXi. Potresti 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 il modulo 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 network.vCenter.networkName .

`network`

Decidi come vuoi che i nodi worker ricevano i loro indirizzi IP. Opzioni sono:

Da un server DHCP configurato in anticipo. Imposta network.ipMode.type a "dhcp".
Da un elenco di indirizzi IP statici che hai fornito. Imposta network.ipMode.type a "static" e crea un File dei blocchi IP che fornisce gli indirizzi IP statici. Per un esempio di file di blocco IP, consulta Esempio di file di configurazione compilati.

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

I nodi del control plane per il cluster utente devono ottenere i propri indirizzi IP da un elenco di indirizzi statici da te fornito. Questo accade anche se i nodi worker ricevono i propri indirizzi da un server DHCP. Per specificare indirizzi IP statici per i tuoi nodi del piano di controllo, compila la sezione network.controlPlaneIPBlock. Se vuoi un cluster utente ad alta disponibilità, specifica tre IP indirizzi IP esterni. 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 destinati anche ai nodi worker.

I valori precompilati di network.podCIDR e network.serviceCIDR possono essere lasciati invariati, a meno che non entrino in conflitto con gli indirizzi già in uso nella rete. Kubernetes utilizza questi intervalli per assegnare indirizzi IP ai pod e ai servizi nel cluster.

Indipendentemente dal fatto che tu utilizzi un server DHCP o specifichi un elenco di indirizzi IP statici, devi disporre di indirizzi IP sufficienti per il cluster di utenti. Per una spiegazione di quanti indirizzi IP sono necessari, vedi Pianifica gli indirizzi IP.

`loadBalancer`

Riserva un VIP per il server API Kubernetes del tuo cluster utente. Metti da parte un altro VIP per il servizio in entrata del cluster utente. Fornisci i 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 con 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, consulta la sezione Bilanciamento del carico in bundle con MetalLB.
Bilanciamento del carico manuale. Imposta loadBalancer.kind su "ManualLB" e compila il manualLB . Per ulteriori informazioni, consulta Bilanciamento del carico manuale.

Per ulteriori informazioni sulle opzioni di bilanciamento del carico, vedi Panoramica del bilanciamento del carico.

`advancedNetworking`

Se prevedi di creare un'istanza gateway NAT in uscita, imposta advancedNetworking a true.

`multipleNetworkInterfaces`

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

`storage`

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

`masterNode`

Nella masterNode puoi specificare il numero di nodi del piano di controllo che vuoi per il cluster: uno o tre. Puoi anche specificare un data store per i nodi del piano di controllo e se vuoi attivare il ridimensionamento automatico per i nodi del piano di controllo.

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 hanno tutti la stessa configurazione. Ad esempio, i nodi di un pool potrebbero eseguire Windows e quelli di un altro pool Linux.

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

Per ulteriori informazioni, vedi Pool di nodi e Creazione e gestione dei pool di nodi.

`antiAffinityGroups`

Imposta antiAffinityGroups.enabled a true o false.

Questo campo specifica se Google Distributed Cloud crea Pianificazione risorse distribuite (DRS) di anti-affinità per i nodi worker, con conseguente distribuiti su almeno tre host fisici nel tuo data center.

`stackdriver`

Se vuoi abilitare Cloud Logging e Cloud Monitoring per il cluster, compila 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 tra 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 (se il campo è incluso nel file di configurazione). Inoltre, se gkeOnPremAPI.enabled è true, la stessa regione deve essere impostato in gkeOnPremAPI.location.

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

`gkeConnect`

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

Compila il campo gkeConnect per specificare 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 il parco risorse Collega i servizi eseguiti in gkeConnect.location. Se non includi questo campo, il cluster utilizza le istanze globali di questi servizi.

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

`gkeOnPremAPI`

In 1.16 e versioni successive, se l'API GKE On-Prem è abilitata nel progetto Google Cloud, tutti i cluster del progetto vengono registrati nell'API GKE On-Prem automaticamente 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 svolgere 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, disattiva gkeonprem.googleapis.com (il nome del servizio per l'API GKE On-Prem) nel progetto. Per istruzioni, vedi Disattivazione dei servizi.

`usageMetering`

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

`cloudAuditLogging`

Se vuoi integrare gli audit log dall'API Kubernetes del cluster server con Cloud Audit Logs, compila 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 essere uguale alla regione impostata in gkeConnect.location (se il campo è incluso nel tuo file di configurazione) e stackdriver.clusterLocation. Inoltre, se gkeOnPremAPI.enabled è true, deve essere impostata 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.30.0-gke.1930
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 blocco IP. Il file del blocco IP contiene quattro indirizzi anche se sono presenti solo tre nodi worker. L'indirizzo IP aggiuntivo è necessario durante l'upgrade, l'aggiornamento e la riparazione automatica del cluster.
I server DNS e NTP sono specificati nella sezione hostConfig. In questo esempio, questi server DNS e NTP sono destinati ai nodi del piano di controllo e ai nodi worker. Questo perché i nodi worker hanno indirizzi IP statici. Se che i nodi worker riceveranno i propri indirizzi IP da un server DHCP, I server DNS e NTP sono destinati solo ai 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.
Control plane V2 è abilitato.
Il campo masterNode.replicas è impostato su 3, pertanto 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 dai nodi worker e dai nodi del piano di controllo.
I VIP riservati ai servizi di tipo LoadBalancer sono specificati in la sezione loadBalancer.metalLB.addressPools del cluster utente di configurazione del deployment. Questi VIP si trovano nella stessa VLAN dei nodi worker e degli nodi del piano di controllo. L'insieme di VIP specificato in questa sezione deve includere il VIP di ingresso e non deve includere il VIP del control plane.
Il file di configurazione del cluster utente non include una sezione vCenter. Quindi... il cluster utente utilizza le stesse risorse vSphere del cluster di amministrazione.

Convalida il file di configurazione

Dopo aver compilato il file di configurazione del cluster utente, esegui 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 della configurazione del cluster utente file

Se il comando restituisce messaggi di errore, correggi i problemi e convalida di nuovo il file.

Se vuoi saltare le convalide più dispendiose in termini di tempo, passa il flag --fast. Per saltare le singole convalide, utilizza i flag --skip-validation-xxx. Per approfondire il comando check-config, consulta Eseguire i controlli preflight.

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

Esegui gkectl prepare se una delle seguenti condizioni è vera:

Il cluster utente si trova in un data center vSphere diverso da quello del cluster amministrativo.
Il cluster utente ha un server vCenter diverso da quello del cluster di amministrazione.
Il cluster utente utilizza un registry dei contenitori 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 del bundle. Questo file è sul tuo amministratore workstation in /var/lib/gke/bundles/. Ad esempio:
```
/var/lib/gke/bundles/gke-onprem-vsphere-1.30.0-gke.1930-full.tgz
```
USER_CLUSTER_CONFIG: il percorso della configurazione del cluster utente file

4. Creazione di un cluster utente

Crea un cluster utente:

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

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

Individuare il file kubeconfig del cluster utente

Il comando gkectl create cluster crea un file kubeconfig denominato USER_CLUSTER_NAME-kubeconfig nella directory corrente. Ti servirà kubeconfig 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.

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 Google Distributed Cloud.

Vai a Creare un cluster Google Distributed Cloud
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 nello stesso progetto in cui è registrato il cluster di amministrazione. Dopo che l'utente il cluster viene creato, viene registrato automaticamente nell'istanza nel parco risorse del progetto.

Impostazioni di base del cluster

Inserisci le informazioni di base sul cluster.

Inserisci un nome per il cluster di utenti.
In Cluster di amministrazione, seleziona il cluster di amministrazione dall'elenco. Se non hai specificato un nome per il cluster di amministrazione quando lo hai creato, il nome viene generato nel formato gke-admin-[HASH]. In caso contrario riconosci il nome del cluster di amministrazione, esegui questo comando workstation di amministrazione:
```
KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
kubectl get OnPremAdminCluster -n kube-system -o=jsonpath='{.items[0].metadata.name}'
```
Se il cluster di amministrazione che vuoi utilizzare non viene visualizzato, consulta la sezione sulla risoluzione dei problemi Il cluster di amministrazione non viene visualizzato nell'elenco a discesa Nozioni di base sui cluster.
Nel campo Posizione API Google Cloud, seleziona la regione Google Cloud da dall'elenco. Questa impostazione specifica la regione in cui Le API e i servizi eseguono:
- API GKE On-Prem (gkeonprem.googleapis.com)
- Servizio per il parco risorse (gkehub.googleapis.com)
- Connetti servizio (gkeconnect.googleapis.com)
Questa impostazione controlla anche la regione in cui vengono archiviati i seguenti elementi:
- I metadati del cluster utente necessari all'API GKE On-Prem per gestire il ciclo di vita del cluster
- I dati di Cloud Logging e Cloud Monitoring dei componenti di sistema
- Il log di controllo Admin creato da Cloud Audit Logs
Il nome, il progetto e la località del cluster identificano in modo univoco il cluster in Google Cloud.
Seleziona la versione di Google Distributed Cloud per il tuo cluster utente.
In qualità di creatore del cluster, ti vengono concessi i privilegi di amministratore del cluster. (Facoltativo) Inserisci l'indirizzo email di un altro utente che eseguirà il cluster nel campo Utente amministratore cluster nella Autorizzazione.

Quando viene 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 amministratore il ruolo clusterrole/cluster-admin di Kubernetes, che fornisce l'accesso completo a tutte le risorse del cluster in tutti gli spazi dei nomi.

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

Control plane

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

Nel campo vCPU del nodo del piano di controllo, inserisci il numero di vCPU (minimo 4) per ciascun nodo del piano di controllo per il cluster utente.
Nel campo Memoria del nodo del control plane, inserisci la dimensione della memoria in MiB (minimo 8192 e deve essere un multiplo di 4) per ogni control plane 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 tre piani di controllo nodi per ambienti di produzione ad alta disponibilità.
Se vuoi, seleziona Ridimensionamento automatico dei nodi. Il ridimensionamento significa che le risorse vCPU e di memoria assegnate a un nodo vengono regolate automaticamente. Se l'opzione è abilitata, i nodi del piano di controllo per il cluster utente vengono ridimensionati in base al numero di nodi worker nel cluster utente. Quindi, se aggiungi più nodi worker al cluster utente, i nodi del piano di controllo di dimensioni maggiori.
(Facoltativo) Seleziona Abilita piano di controllo v2. Abilitazione del piano di controllo V2 in corso... significa che il piano di controllo per un cluster utente viene eseguito su uno o più nodi nel cluster utente stesso anziché nel cluster di amministrazione (definito come kubeception).

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

Quando il control plane v2 è abilitato, i campi vCPU e memoria si applicano ai nodi del piano di controllo nel cluster utente. Viene determinato il numero di nodi in base al numero di indirizzo IP inserito. Se il piano di controllo V2 abilitati, i campi vCPU, memoria e numero di nodi del piano di controllo ai nodi nel cluster di amministrazione. Assicurati di mettere da parte indirizzi IP sufficienti per il cluster di amministrazione.
Fai clic su Avanti per andare alla sezione Networking.

Networking

In questa sezione specifichi gli indirizzi IP dei nodi, dei pod e dei servizi del tuo cluster. Un cluster utente deve avere un indirizzo IP per ogni nodo e indirizzo IP aggiuntivo per un nodo temporaneo necessario durante il cluster upgrade, aggiornamenti e riparazioni automatiche. Per ulteriori informazioni, consulta Quanti indirizzi IP sono necessari per un cluster di utenti?.

Nella sezione Indirizzi IP dei nodi, seleziona la modalità IP per il cluster utente. Seleziona una delle seguenti opzioni:
- DHCP: scegli DHCP se vuoi che i nodi del cluster ricevano il proprio 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 CIDR di servizi e pod. Per la modalità IP statico, fornisci le seguenti informazioni:
1. Inserisci l'indirizzo IP del Gateway per il cluster utente.
2. Inserisci la subnet mask per i nodi del cluster utente.
3. Nella sezione Indirizzi IP, inserisci gli indirizzi IP e, facoltativamente, i nomi host dei nodi nel cluster utente. Puoi inserire un singolo indirizzo IP v4 (ad esempio 192.0.2.1) o un CIDR blocco 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 anche inserire un nome host. Se non inserisci un nome host, Google Distributed Cloud utilizza il nome della VM di vSphere come nome host.
4. Fai clic su + Aggiungi indirizzo IP se necessario per inserire altri indirizzi IP.
Nella sezione CIDR di servizi e pod, la console fornisce quanto segue per i tuoi servizi e 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 conoscere le best practice.
Se hai selezionato Modalità IP statico o Abilita il 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. Se vuoi, inserisci i domini di ricerca DNS.
Fai clic su Avanti per andare alla sezione Bilanciatore del carico.

Bilanciatore del carico

Scegli il bilanciatore del carico da configurare per il cluster. Consulta: Panoramica del bilanciatore del carico per ulteriori informazioni.

Seleziona il tipo di bilanciatore del carico dall'elenco.

Abbinato a MetalLB

Configura il bilanciamento del carico in bundle con MetalLB. Puoi usare MetalLB per solo se il cluster di amministrazione utilizza SeeSaw o MetalLB. Questo richiede una configurazione minima. MetalLB viene eseguito direttamente sui nodi del cluster e non richiede VM aggiuntive. Per saperne di più sui vantaggi dell'utilizzo di MetalLB e sul suo confronto con le 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 contenente il VIP di ingresso in 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 per i servizi di tipo LoadBalancer non rientrano nello stesso intervallo di indirizzi IP del VIP in entrata, fai clic su + Aggiungi intervallo di indirizzi IP e inserisci un altro intervallo di indirizzi.
  
  Gli indirizzi IP in ogni pool non possono sovrapporsi e devono trovarsi nella stessa subnet dei nodi del cluster.
4. In Assegnazione di indirizzi IP, seleziona una delle seguenti opzioni:
  - Automatico: scegli questa opzione se vuoi che il controller MetalLB venga Assegna automaticamente gli indirizzi IP dal pool di indirizzi ai servizi di tipo LoadBalancer
  - Manuale: scegli questa opzione se intendi utilizzare indirizzi provenienti da il pool per specificare manualmente gli indirizzi per i servizi di tipo LoadBalancer
5. Fai clic su Evita indirizzi IP che presentano bug se non vuoi che il controller MetalLB utilizzi indirizzi del pool che terminano con .0 o .255. Ciò evita il problema dei bug nei dispositivi dei consumatori che generano 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. inviati al Server API Kubernetes del cluster utente. Il server API Kubernetes per il cluster utente viene eseguito su un nodo del cluster di amministrazione. Questo indirizzo IP deve essere nello stesso indirizzo Dominio L2 come 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 dell'integrazione con Google Distributed Cloud.

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

Nella sezione IP virtuali, inserisci quanto segue:
- VIP del piano di controllo: l'indirizzo IP di destinazione da utilizzare per il traffico inviato al server API Kubernetes.
- VIP in entrata: l'indirizzo IP da configurare sul bilanciatore del carico per il proxy in entrata.
Nel campo Indirizzo, inserisci l'indirizzo del bilanciatore del carico BIG-IP di F5.
Nel campo Partition (Partizione), inserisci il nome di una partizione BIG-IP che hai creato per il cluster di utenti.
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 esposti ciascuno da un servizio Kubernetes di tipo LoadBalancer. Scegli i tuoi valori nodePort nel 30000-32767 per questi Servizi. Per il proxy in entrata, scegli un valore nodePort sia per il traffico HTTP che per quello HTTPS. Per ulteriori informazioni, consulta la sezione Attivare la 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. inviati 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 Ingress, inserisci un valore nodePort per il traffico HTTP verso il proxy in entrata.
Nel campo Porta nodo HTTPS Ingress, inserisci un valore nodePort per il traffico HTTPS verso il proxy in entrata.
Nel campo Porta del nodo 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 nel 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 delle attività di amministrazione
Le seguenti opzioni sono abilitate per impostazione predefinita, ma è possibile disabilitarle:
- Abilita driver CSI vSphere: chiamato anche vSphere Container Storage Plug-in. 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 vSphere. Per ulteriori informazioni, consulta Utilizzare il driver Container Storage Interface di vSphere.
- Attiva i gruppi anti-affinità: le regole anti-affinità Distributed Resource Scheduler (DRS) di VMware vengono create automaticamente per i nodi del cluster utente, in modo da distribuirle in almeno 3 host fisici del data center. Assicurati che l'ambiente vSphere soddisfi i requisiti.
Nota: se hai seguito la procedura per la configurazione di un'infrastruttura minima, hai un solo host ESXi, quindi assicurati di deselezionare Abilita gruppi anti-affinità.

Fai clic su Avanti per configurare un pool di nodi

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 creato in questo cluster. Per scoprire di più, consulta la pagina Creare e gestire i pool di nodi.

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

Inserisci il Nome del pool di nodi o accetta "default-pool" come nome.

Inserisci il numero di vCPU per ogni nodo nel pool (minimo 4 per worker cluster utente).

Inserisci la dimensione della memoria in mebibyte (MiB) per ogni nodo del pool (minimo 8192 MiB per nodo worker del cluster utente e deve essere un multiplo di 4).

Nel campo Nodi, inserisci il numero di nodi nel pool (min 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.

Seleziona il tipo di immagine sistema operativo: Ubuntu, Ubuntu Containerd, o COS.

Inserisci la dimensione del disco di avvio in gibibyte (GiB) (minimo 40 GiB).

Se utilizzi MetalLB come bilanciatore del carico, MetalLB deve essere abilitato in almeno un pool di nodi. Esci da Utilizza questo pool di nodi per Bilanciamento del carico MetalLB selezionato o aggiungi un altro pool di nodi da utilizzare per MetalLB

Nella sezione Metadati del pool di nodi (facoltativo), se vuoi aggiungere etichette e contaminazioni Kubernetes, procedi nel seguente modo:

Fai clic su + Aggiungi etichette Kubernetes. Inserisci la Chiave e Valore dell'etichetta. Ripeti queste operazioni in base alle necessità.

Fai clic su + Aggiungi contaminazione. Inserisci Chiave, Valore e Effetto per l'alterazione. Ripeti queste operazioni in base alle necessità.

Fai clic su Verifica e completa per creare il cluster di utenti. Ci vogliono 15 minuti o più per creare il cluster utente. Nella console viene visualizzato lo stato messaggi durante la verifica delle impostazioni e la creazione del cluster nei dati Google Cloud.

Se si verifica un errore durante la verifica delle impostazioni, la console mostra un messaggio di errore sufficientemente chiaro per consentirti di correggere il problema di configurazione e riprovare a creare il cluster.

Per ulteriori informazioni sui possibili errori e su come correggerli, consulta Risolvi i problemi relativi alla creazione di cluster utente nella console Google Cloud.

Interfaccia a riga di comando gcloud

Per creare un cluster utente, utilizza il seguente comando:

gcloud container vmware clusters create

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

gcloud container vmware node-pools create

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

Raccogliere informazioni

Raccogli le informazioni necessarie per creare il cluster.

Ottieni il nome e la posizione dell'appartenenza al 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 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 posizione specifica dove vengono eseguiti i servizi Fleet e Connect. Amministratore i cluster creati prima alla 1.28 sono gestiti dal parco risorse globale Connetti i servizi. In 1.28 e versioni 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 che in cui è registrato il cluster di amministrazione.

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

REGION: la regione Google Cloud che che utilizzerai quando crei il cluster utente. Questa è la regione l'API GKE On-Prem esegue 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 conoscere la regione del cluster amministrativo, esegui il seguente 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 altro regione supportata. Se successivamente registri il cluster di amministrazione nell'API GKE On-Prem, utilizza la stessa regione del 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. Versioni che puoi utilizzare per creare o esegui l'upgrade di un cluster utente con annotazione isInstalled: true, che significa che il cluster di amministrazione ha i componenti specifici della versione necessari per gestire i cluster utente di quella versione. Se vuoi utilizzare una versione installata sul cluster di amministrazione, vai alla sezione Esempi per creare il cluster utente.

Installa una versione più recente

Un cluster di amministrazione può gestire cluster utente con 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 superiore a quella del cluster di amministrazione, devi scaricare ed eseguire il deployment dei componenti di cui il cluster di amministrazione ha bisogno 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 nel dell'output del comando query-version-config.

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

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

Esempi

Gli esempi riportati di seguito mostrano come creare un cluster di utenti con diversi bilanciatori di carico con Controlplane V2 abilitato. Con il piano di controllo V2, di un cluster utente viene eseguito su uno o più nodi nel cluster utente stesso. Ti consigliamo di attivare Controlplane V2 e, nella versione 1.30 e successive, è obbligatorio attivare Controlplane V2 per i nuovi cluster utente. Per informazioni sulle opzioni di bilanciamento del carico disponibili, consulta la Panoramica del bilanciatore del carico.

La maggior parte degli esempi utilizza i valori predefiniti per configurare il piano di controllo nodi. Se vuoi modificare i valori predefiniti, includi i flag descritti nella sezione Flag del piano di controllo. Se necessario, puoi modificare anche alcune impostazioni di vSphere.

Prima di eseguire il comando gcloud per creare il cluster, puoi includi --validate-only per convalidare la configurazione che hai specificato i flag al comando gcloud. Quando è tutto pronto per creare il cluster, rimuovi il flag ed esegui il comando.

Se ricevi un messaggio di errore dopo il comando gcloud container vmware clusters create è in esecuzione da circa un minuto o più, controlla se il cluster era parzialmente creato eseguendo questo comando:

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

Se il cluster non è elencato nell'output, correggi l'errore ed esegui nuovamente il comando 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

Dopodiché correggi l'errore ed esegui nuovamente gcloud container vmware clusters create.

Quando il cluster è in esecuzione, devi aggiungere un pool di nodi prima del deployment come descritto in Creare un pool di nodi .

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

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

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

Bandiera Descrizione

--admin-users Concedi a te e a un altro utente diritti amministrativi completi sul cluster.

--enable-control-plane-v2 Attiva Controlplane V2, che è consigliato e obbligatorio nella versione 1.30 e successive.

--control-plane-ip-block Un indirizzo IP per il nodo del piano di controllo. Per creare un ad alta disponibilità, specifica tre indirizzi IP aggiungi il flag --replicas=3.

--metal-lb-config-address-pools Due pool di indirizzi per il bilanciatore del carico MetalLB. Hai bisogno di: almeno un pool di indirizzi e, se necessario, puoi specificarne altri. Per comodità, l'esempio contiene un pool di indirizzi con il nome "ingress-vip-pool" per ricordare che l'indirizzo IP del VIP in entrata deve trovarsi in uno dei pool di indirizzi. Tu specifichi il CIDR di un singolo indirizzo IP aggiungendo /32 al Indirizzo IP.

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

Sostituisci quanto segue:

USER_CLUSTER_NAME: un nome a tua scelta per il cluster di utenti. Il nome non può essere modificato dopo la creazione del cluster. Il nome deve avere le seguenti caratteristiche:

Deve contenere al massimo 40 caratteri

Deve contenere solo caratteri alfanumerici minuscoli o un trattino (-).

iniziano con un carattere alfabetico

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 del cluster di amministrazione registrato. Dopo la creazione, il cluster utente viene registrato automaticamente nel parco risorse del progetto selezionato. Il progetto host del parco risorse e non possono essere modificate dopo la creazione del cluster.

ADMIN_CLUSTER_NAME: il nome del cluster di amministrazione che gestisce il cluster utente. Nel flag --admin-cluster-membership puoi utilizzare il nome del cluster completamente specificato, che ha il seguente formato:
projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

In alternativa, puoi impostare --admin-cluster-membership sul nome del cluster di amministrazione, come nel comando di esempio. Quando utilizzi solo il nome del cluster di amministrazione, imposta l'ID progetto del cluster di amministrazione con --admin-cluster-membership-project e la posizione con --admin-cluster-membership-location. La località del cluster amministrativo è 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 altro 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 di cui l'API GKE On-Prem ha bisogno per gestire il ciclo di vita del cluster

I dati di Cloud Logging e Cloud Monitoring dei componenti di sistema

L'audit log amministrativo creato da Cloud Audit Logs

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

Importante: se prevedi di installare Cloud Service Mesh, devi installare la versione 1.19.3 o successive. Questa operazione è necessaria perché I servizi Fleet e Connect vengono eseguiti in una regione.

VERSION: la versione di Google Distributed Cloud per il tuo cluster di utenti.

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

Alla creazione del cluster, l'API GKE On-Prem applica lo standard Kubernetes i criteri di controllo dell'accesso basato sui ruoli (RBAC) al cluster per concedere a te agli 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.

Nota: oltre ai criteri RBAC di Kubernetes, devi concedere I ruoli IAM (Identity and Access Management) per gli utenti che non sono proprietari del progetto. Per maggiori dettagli sulla concessione dei ruoli IAM, consulta Assegna 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 per pool di indirizzi che devono essere usati dal bilanciatore del carico MetalLB. Il valore del flag ha 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 ha segmenti che iniziano con le parole chiave pool, avoid-buggy-ip, manual-assign e addresses. Separa ogni segmento con una virgola.

pool: un nome scelto da te per il pool.

avoid-buggy-ips1: Se imposti True, il controller MetalLB non assegneranno indirizzi IP che terminano con .0 o .255 ai servizi. In questo modo si evita il problema dei dispositivi consumer con bug che eliminano erroneamente il traffico inviato a questi indirizzi IP speciali. In caso contrario specificato, il valore predefinito è False.

manual-assign: se non vuoi che il controller MetalLB Assegna automaticamente gli indirizzi IP da questo pool ai servizi, imposta questo valore su True. Dopodiché uno sviluppatore può creare un servizio di tipo LoadBalancer e specificare manualmente uno degli indirizzi del pool. Se non specificato, manual-assign viene impostato su False.

Nell'elenco di addresses: ogni indirizzo deve essere un intervallo in o la notazione CIDR 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 a tua disposizione scelto di configurare sul bilanciatore del carico per il server API Kubernetes del cluster utente.
Esempio: --control-plane-vip=203.0.113.3

INGRESS_VIP: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il proxy in entrata.
Esempio: --ingress-vip=10.251.134.80

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

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

Puoi utilizzare MetalLB per il cluster utente solo se il cluster di amministrazione è utilizzando MetalLB. Questa opzione di bilanciamento del carico richiede configurazione. MetalLB viene eseguito direttamente sui nodi del cluster e non richiede VM aggiuntive. Per saperne di più sui vantaggi dell'utilizzo di MetalLB e sul suo confronto con le altre opzioni di bilanciamento del carico, consulta Bilanciamento del carico in bundle con MetalLB.

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

Bandiera Descrizione

--admin-users Concedi a te e a un altro utente diritti amministrativi completi sul cluster.

--enable-control-plane-v2 Attiva Controlplane V2, che è consigliato e obbligatorio nella versione 1.30 e successive.

--control-plane-ip-block Un indirizzo IP per il nodo del piano di controllo. Per creare un ad alta disponibilità, specifica tre indirizzi IP aggiungi il flag --replicas=3.

--metal-lb-config-address-pools Due pool di indirizzi per il bilanciatore del carico MetalLB. Devi avere almeno un pool di indirizzi e puoi specificarne altri, se necessario. Per comodità, l'esempio contiene un pool di indirizzi con il nome "ingress-vip-pool" per ricordare che l'indirizzo IP del VIP in entrata deve trovarsi in uno dei pool di indirizzi. Tu specifichi il CIDR di un singolo indirizzo IP aggiungendo /32 al Indirizzo IP.

--static-ip-config-ip-blocks Quattro indirizzi IP per i nodi worker nei cluster. Sono inclusi un indirizzo per un nodo aggiuntivo che può essere utilizzato durante l'upgrade e l'aggiornamento. Se necessario, puoi specificare più indirizzi IP. Il nome host è facoltativo.

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

Sostituisci quanto segue:

USER_CLUSTER_NAME: un nome a tua scelta per il cluster di utenti. Il nome non può essere modificato dopo la creazione del cluster. Il nome deve avere le seguenti caratteristiche:

Deve contenere al massimo 40 caratteri

Deve contenere solo caratteri alfanumerici minuscoli o un trattino (-).

iniziano con un carattere alfabetico

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 del cluster di amministrazione registrato. Dopo la creazione, il cluster utente viene registrato automaticamente nel parco risorse del progetto selezionato. Il progetto host del parco risorse e non possono essere modificate dopo la creazione del cluster.

ADMIN_CLUSTER_NAME: il nome del cluster di amministrazione che gestisce il cluster utente. Nel flag --admin-cluster-membership puoi utilizzare il nome del cluster completamente specificato, che ha il seguente formato:
projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

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

REGION: la regione Google Cloud in cui API GKE On-Prem (gkeonprem.googleapis.com), servizio parco risorse (gkehub.googleapis.com) e il servizio Connect (gkeconnect.googleapis.com) esegui. Specifica us-west1 o un'altra regione supportata. La regione non può essere modificata dopo la creazione del cluster. Questa impostazione specifica la regione in cui vengono archiviati i seguenti elementi:

I metadati del cluster utente di cui l'API GKE On-Prem ha bisogno per gestire il ciclo di vita del cluster

I dati di Cloud Logging e Cloud Monitoring dei componenti di sistema

L'audit log amministrativo creato da Cloud Audit Logs

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

Importante: se prevedi di installare Cloud Service Mesh, devi installare la versione 1.19.3 o successive. Questa operazione è necessaria perché I servizi Fleet e Connect vengono eseguiti in una regione.

VERSION: la versione di Google Distributed Cloud per il tuo cluster di utenti.

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

Alla creazione del cluster, l'API GKE On-Prem applica lo standard Kubernetes i criteri di controllo dell'accesso basato sui ruoli (RBAC) al cluster per concedere a te agli 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.

Nota: oltre ai criteri RBAC di Kubernetes, devi concedere I ruoli IAM (Identity and Access Management) per gli utenti che non sono proprietari del progetto. Per maggiori dettagli sulla concessione dei ruoli IAM, consulta Assegna i ruoli richiesti.

SERVICE_CIDR_BLOCK: un intervallo di indirizzi IP in 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 per pool di indirizzi che devono essere usati dal bilanciatore del carico MetalLB. Il valore del flag ha 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 ha segmenti che iniziano con le parole chiave pool, avoid-buggy-ip, manual-assign e addresses. Separa ogni segmento con una virgola.

pool: un nome scelto da te per il pool.

avoid-buggy-ips1: Se imposti True, il controller MetalLB non assegneranno indirizzi IP che terminano con .0 o .255 ai servizi. In questo modo si evita il problema dei dispositivi consumer con bug che eliminano erroneamente il traffico inviato a questi indirizzi IP speciali. In caso contrario specificato, il valore predefinito è False.

manual-assign: se non vuoi che il controller MetalLB Assegna automaticamente gli indirizzi IP da questo pool ai servizi, imposta questo valore su True. Lo sviluppatore può quindi creare un servizio di tipo LoadBalancer e specificare manualmente uno degli indirizzi del pool. Se non specificato, il valore manual-assign è impostato su False.

Nell'elenco di addresses: ogni indirizzo deve essere un intervallo in o la notazione CIDR formato dell'intervallo con trattino. Per specificare un singolo indirizzo IP in un pool (ad esempio per l'indirizzo VIP di ingresso), utilizza /32 in 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 a tua disposizione scelto di configurare sul bilanciatore del carico per il server API Kubernetes del cluster utente.
Esempio: --control-plane-vip=203.0.113.3

INGRESS_VIP: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il proxy in entrata.
Esempio: --ingress-vip=10.251.134.80

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

--static-ip-config-ip-blocks: specifica il gateway predefinito, la subnet mask e un elenco degli indirizzi IP statici per i nodi worker nel cluster utente. Il valore del flag ha il seguente formato:

--static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'

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

Tieni presente quanto segue:

Racchiudi l'intero valore tra virgolette singole.

Gli spazi non sono consentiti, tranne tra un indirizzo IP e un nome host.

Nell'elenco degli indirizzi IP:

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

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

Per un singolo indirizzo IP, puoi facoltativamente specificare un nome host dopo l'indirizzo IP. Separa l'indirizzo IP e il nome host con uno spazio. Se non specifichi un nome host, Google Distributed Cloud utilizza il nome della VM da vSphere come nome host.

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

Ad esempio:

--static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'

DNS_SERVER: un elenco separato da virgole di indirizzi IP del DNS per le VM.

DNS_SEARCH_DOMAIN: un elenco separato da virgole della ricerca DNS domini utilizzabili dagli host. Questi domini vengono utilizzati come parte di un elenco di ricerca di domini.
Ad esempio:

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

NTP_SERVER: un elenco separato da virgole degli indirizzi IP dei server di tempo da utilizzare per le VM.

Bilanciatore del carico manuale e IP statici
Questo esempio mostra come creare un cluster utente con un caricamento manuale e l'assegnazione di indirizzi IP statici al cluster, nodi worker.

Puoi utilizzare un bilanciatore del carico manuale per il cluster utente solo se il tuo cluster di amministrazione utilizza un bilanciatore del carico manuale. In Google Distributed Cloud, Server API Kubernetes, proxy in entrata e servizio aggiuntivo per il log ciascuna è esposta 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. Consulta: Attivazione della modalità di bilanciamento del carico manuale per ulteriori informazioni.

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

Bandiera Descrizione

--admin-users Concedi a te e a un altro utente diritti amministrativi completi sul cluster.

--enable-control-plane-v2 Attiva Controlplane V2, che è consigliato e obbligatorio nella versione 1.30 e successive.

--control-plane-ip-block Un indirizzo IP per il nodo del piano di controllo. Per creare un ad alta disponibilità, specifica tre indirizzi IP aggiungi il flag --replicas=3.

--static-ip-config-ip-blocks Quattro indirizzi IP per i nodi worker nei cluster. tra cui un indirizzo per un nodo aggiuntivo che può essere utilizzato durante l'upgrade e l'aggiornamento. Se necessario, puoi specificare più indirizzi IP. Il nome host è facoltativo.

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

Sostituisci quanto segue:

USER_CLUSTER_NAME: un nome a tua scelta per il cluster di utenti. Il nome non può essere modificato dopo la creazione del cluster. Il nome deve avere le seguenti caratteristiche:

Deve contenere al massimo 40 caratteri

Deve contenere solo caratteri alfanumerici minuscoli o un trattino (-).

iniziano con un carattere alfabetico

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 del cluster di amministrazione registrato. Dopo la creazione, il cluster utente viene registrato automaticamente nel parco risorse del progetto selezionato. Il progetto host del parco risorse e non possono essere modificate dopo la creazione del cluster.

ADMIN_CLUSTER_NAME: il nome del cluster di amministrazione che gestisce il cluster utente. Nel flag --admin-cluster-membership puoi utilizzare il nome del cluster completamente specificato, che ha il seguente formato:
projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

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

REGION: la regione Google Cloud in cui API GKE On-Prem (gkeonprem.googleapis.com), servizio parco risorse (gkehub.googleapis.com) e il servizio Connect (gkeconnect.googleapis.com) esegui. Specifica us-west1 o un altro 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 di cui l'API GKE On-Prem ha bisogno per gestire il ciclo di vita del cluster

I dati di Cloud Logging e Cloud Monitoring dei componenti di sistema

L'audit log amministrativo creato da Cloud Audit Logs

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

Importante: se prevedi di installare Cloud Service Mesh, devi installare la versione 1.19.3 o successive. Questa operazione è necessaria perché I servizi Fleet e Connect vengono eseguiti in una regione.

VERSION: la versione di Google Distributed Cloud per il tuo cluster di utenti.

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

Alla creazione del cluster, l'API GKE On-Prem applica lo standard Kubernetes i criteri di controllo dell'accesso basato sui ruoli (RBAC) al cluster per concedere a te agli 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.

Nota: oltre ai criteri RBAC di Kubernetes, devi concedere I ruoli IAM (Identity and Access Management) per gli utenti che non sono proprietari del progetto. Per informazioni dettagliate sulla concessione dei ruoli IAM, consulta Concedere i ruoli richiesti.

SERVICE_CIDR_BLOCK: un intervallo di indirizzi IP in CIDR da utilizzare per i servizi nel cluster. Deve essere un intervallo di almeno /24.
Esempio: --service-address-cidr-blocks=10.96.0.0/20

POD_CIDR_BLOCK: un intervallo di indirizzi IP in formato CIDR da utilizzare per i pod nel cluster. Deve essere un intervallo di almeno /18.
Esempio: --pod-address-cidr-blocks=192.168.0.0/16

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

Esempio: --control-plane-vip=203.0.113.3

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

Esempio: --ingress-vip=203.0.113.4

INGRESS_HTTP_NODE_PORT: un valore nodePort per Traffico HTTP verso il proxy in entrata (ad esempio 30243).

INGRESS_HTTPS_NODE_PORT: un valore nodePort per il traffico HTTPS al proxy di ingresso (ad esempio 30879).

--static-ip-config-ip-blocks: specifica il gateway predefinito, la subnet mask e un elenco degli indirizzi IP statici per i nodi worker nel cluster utente. Il valore del flag ha il seguente formato:

--static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'

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

Tieni presente quanto segue:

Racchiudi l'intero valore tra virgolette singole.

Gli spazi non sono consentiti, tranne tra un indirizzo IP e un nome host.

Nell'elenco di indirizzi IP:

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

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

Per un singolo indirizzo IP, puoi facoltativamente specificare un nome host dopo l'indirizzo IP. Separa l'indirizzo IP e il nome host con uno spazio. Se non specifichi un nome host, Google Distributed Cloud utilizza il nome della VM da vSphere come nome host.

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

Ad esempio:

--static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'

DNS_SERVER: un elenco separato da virgole di indirizzi IP del DNS per le VM.

DNS_SEARCH_DOMAIN: un elenco separato da virgole della ricerca DNS domini utilizzabili dagli host. Questi domini vengono utilizzati come parte di un elenco di ricerca di domini.
Ad esempio:

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

NTP_SERVER: un elenco separato da virgole dell'IP gli indirizzi IP dei server di riferimento che le VM possono utilizzare.

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 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 per il tuo cluster utente. Il valore minimo è 8192 e deve essere un multiplo di 4. Se non specificato, il valore predefinito è 8192.

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

--enable-auto-resize: se vuoi attivare il ridimensionamento automatico dei nodi del piano di controllo per il cluster utente, includi --enable-auto-resize. Il ridimensionamento significa che le risorse vCPU e di memoria assegnate a un nodo vengono aggiustate automaticamente. Se abilitato, i nodi del piano di controllo per l'utente i cluster vengono ridimensionati in base al numero di nodi worker dell'utente in un cluster Kubernetes. Quindi, se aggiungi altri nodi worker al cluster utente, dei nodi del piano di controllo sono maggiori.

--enable-control-plane-v2: per attivare Control plane V2, che consigliamo, includere questo flag. Quando il control plane v2 è abilitato, il control plane per un cluster utente viene eseguito su uno o più nodi nel cluster utente stesso. Nella versione 1.30 e successive, è richiesta la versione 2 di Controlplane.

Quando abiliti il piano di controllo V2, devi specificare anche i seguenti flag:

--dns-servers=DNS_SERVER_1,...: una virgola separata 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 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 contiene segmenti che iniziano con le parole chiave gateway, netmask e ips. Separa i segmenti con una virgola.

Tieni presente quanto segue:

Racchiudi l'intero valore tra virgolette singole.

Gli spazi non sono consentiti, tranne tra un indirizzo IP e un nome host.

Nell'elenco di indirizzi IP:

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

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

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

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

Ad esempio:

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

(Facoltativo) --dns-search-domains=DNS_SEARCH_DOMAIN_1,...: un elenco separato da virgole dei domini di ricerca DNS 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 dell'interfaccia a riga di comando gcloud.

Flag vSphere

Se necessario, specifica i seguenti flag facoltativi:

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

Nota: se hai seguito la procedura Configurare un'infrastruttura minima, hai un solo host ESXi, quindi assicurati di includere questo flag.

--disable-vsphere-csi: se non includi questo flag, i componenti CSI (Container Storage Interface) di vSphere vengono dipartiti nel cluster di utenti. 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 Utilizzare il 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 il riferimento all'interfaccia a riga di comando gcloud

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 lungo termine. Tu puoi verificare 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 gcloud container vmware operations.

La creazione del cluster di utenti richiede almeno 15 minuti. Puoi visualizzare nel cluster nella console Google Cloud Cluster GKE .

Crea un pool di nodi

Dopo la creazione del cluster, devi creare almeno un pool di nodi prima 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 pool di nodi. Il nome deve:

Deve contenere al massimo 40 caratteri.

Deve contenere solo caratteri alfanumerici minuscoli o un trattino (-).

iniziano con un carattere alfabetico

terminare con un carattere alfanumerico

USER_CLUSTER_NAME: il nome della persona nel cluster utente.

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

REGION: la regione Google Cloud che specificato al momento della creazione del cluster.

IMAGE_TYPE: il tipo di immagine del sistema operativo da eseguire sulle VM in del pool di nodi. Imposta una delle seguenti opzioni: 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 numero minimo è 4.

MEMORY: la dimensione della memoria in mebibyte (MiB) per ogni di un 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. La minimo è 3.

Se utilizzi MetalLB come bilanciatore del carico, includi facoltativamente --enable-load-balancer se vuoi consentire il funzionamento dello speaker MetalLB tra i nodi nel pool. MetalLB deve essere abilitato in almeno un pool di nodi. Se non includi questo flag, devi creare un altro pool di nodi da utilizzare per MetalLB

Per informazioni sui flag facoltativi, consulta Aggiungere un pool di nodi e la documentazione di 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/us-west1/memberships/admin-cluster-1 \ --version=1.29.400-gke.81 \ --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

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.400-gke.81 \ --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

Bilanciatore del carico manuale & IP statici

gcloud container vmware clusters create user-cluster-4 \ --project=example-project-12345 \ --location=asia-east1 \ --admin-cluster-membership=projects/example-project-12345/locations/asia-east1/memberships/admin-cluster-1 \ --version=1.29.400-gke.81 \ --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

Ottieni il nome e la posizione dell'appartenenza al 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 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. In 1.28 e versioni successive, puoi specificare global o una regione Google Cloud quando crei il cluster.

Per visualizzare 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 che in cui è registrato il cluster di amministrazione.

ADMIN_CLUSTER_REGION: la regione di appartenenza del fleet del cluster di amministrazione. È globale o è un servizio Google Cloud regione. Utilizza la posizione per il cluster di amministrazione dall'output di gcloud container fleet memberships list.

REGION: la regione Google Cloud che utilizzerai per creare il cluster. Si tratta della 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

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

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 ulteriori informazioni e altri esempi, consulta la documentazione di riferimento di google_gkeonprem_vmware_cluster.

Imposta le variabili in terraform.tfvars

Il sample fornisce un file di variabili di esempio da passare a main.tf, che mostra come configurare il bilanciatore del carico MetalLB incluso e consentire ai nodi del cluster di ottenere i propri indirizzi IP da un server DHCP fornito da te.

Clona il repository anthos-samples e vai alla directory dove 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. Questo deve essere lo stesso progetto in cui è registrato il cluster di amministrazione. Dopo il giorno il cluster utente viene creato, viene registrato automaticamente nel parco risorse del progetto selezionato. Il progetto host del parco risorse non può essere modificato dopo viene creato il cluster.

region: la regione Google Cloud in cui vengono eseguite l'API GKE On-Prem (gkeonprem.googleapis.com), il servizio Fleet (gkehub.googleapis.com) e il servizio Connect (gkeconnect.googleapis.com). Specifica us-west1 o un'altra regione supportata.

admin_cluster_name: il nome del cluster di amministrazione che gestisce il cluster di utenti. L'esempio presuppone che il cluster di amministrazione utilizzi Global come regione. Se hai un cluster di amministrazione regionale:

Apri main.tf in un editor di testo.

Cerca admin_cluster_membership, che assomiglia a seguenti:

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

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 di utenti. In genere, viene specificata 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 di Installare una versione successiva alla versione del cluster di amministrazione.

admin_user_emails: un elenco di indirizzi email degli utenti a cui devono essere concessi i 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 al cluster i criteri di controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes per concedere agli utenti amministratore il ruolo clusterrole/cluster-admin di Kubernetes, che fornisce l'accesso completo a tutte le risorse del cluster in tutti gli spazi dei nomi. In questo modo, gli utenti possono accedere alla console anche utilizzando la propria identità Google.

cluster_name: un nome a tua scelta per il cluster utente. Il nome e non possono essere modificate dopo la creazione del cluster. Il nome deve:

Deve contenere al massimo 40 caratteri.

Deve 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 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 control plane del tuo 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 del cluster utente. Ad esempio, puoi inserire un nodo del piano di controllo per un ambiente di sviluppo e tre nodi del piano di controllo per ambienti di produzione ad alta disponibilità (HA).

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

ingress_vip: l'indirizzo IP che hai scelto di configurare nella 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 con intervallo tra virgole. per specificare un singolo IP in un pool (ad esempio per il VIP in entrata), utilizza /32 nel CIDR ad esempio: 192.0.2.1/32.

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

Salva le modifiche in terraform.tfvars. Se non vuoi apportare modifiche facoltative a main.tf, vai alla sezione successiva, 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 Realizza in main.tf. Prima di apportare modifiche, esegui il backup di main.tf:

cp main.tf main.tf.bak

Modalità di indirizzamento IP del nodo worker

Per impostazione predefinita, main.tf configura il cluster in modo che utilizzi un server DHCP per assegnare gli indirizzi IP ai nodi worker del cluster. DHCP viene configurato includendo la mappa dhcp_config all'interno del blocco network_config. Se vuoi fornire indirizzi IP statici per i tuoi 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 tuo cluster. Deve essere un intervallo di almeno /24.

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

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

ntp_servers: un elenco degli indirizzi IP dei server di riferimento dell'ora per le VM per l'utilizzo.

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 nodi worker.

Configura piano di controllo V2

Per impostazione predefinita, main.tf configura il control plane per il cluster utente in modo che venga eseguito su uno o più nodi del cluster di amministrazione (modello kubeception). Se preferisci, puoi abilitare il piano di controllo V2. Quando Il piano di controllo V2 è abilitato, il piano di controllo per un cluster utente viene eseguito su 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 per 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 del tuo i 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.

Esamina la configurazione e apporta le modifiche necessarie:

terraform plan

Applica il piano Terraform per creare il cluster di utenti:

terraform apply

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

Bandiera	Descrizione
`--admin-users`	Concedi a te e a un altro utente diritti amministrativi completi sul cluster.
`--enable-control-plane-v2`	Attiva Controlplane V2, che è consigliato e obbligatorio nella versione 1.30 e successive.
`--control-plane-ip-block`	Un indirizzo IP per il nodo del piano di controllo. Per creare un ad alta disponibilità, specifica tre indirizzi IP aggiungi il flag `--replicas=3`.
`--metal-lb-config-address-pools`	Due pool di indirizzi per il bilanciatore del carico MetalLB. Hai bisogno di: almeno un pool di indirizzi e, se necessario, puoi specificarne altri. Per comodità, l'esempio contiene un pool di indirizzi con il nome "ingress-vip-pool" per ricordare che l'indirizzo IP del VIP in entrata deve trovarsi in uno dei pool di indirizzi. Tu specifichi il CIDR di un singolo indirizzo IP aggiungendo `/32` al Indirizzo IP.

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

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

Risoluzione dei problemi

Consulta Risolvere i problemi di creazione e upgrade del cluster.

Passaggi successivi

Connettiti al cluster dalla console Google Cloud.

Esegui il deployment di un'applicazione.

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

kubeception

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

Convalida il file di configurazione

3. (Facoltativo) Importa le immagini del sistema operativo in vSphere ed esegui il push delle immagini dei container in un registry 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

Control plane

Networking

Bilanciatore del carico

Abbinato a MetalLB

F5 BIG-IP

Manuale

Funzionalità

Pool di nodi

Interfaccia a riga di comando gcloud

Raccogliere informazioni

Installa una versione più recente

Esempi

MetalLB e DHCP

MetalLB e IP statici

Bilanciatore del carico manuale e IP statici

Flag del piano di controllo

Flag vSphere

Monitorare l'avanzamento della creazione del cluster

Crea un pool di nodi

Esempi di comandi gcloud

MetalLB e DHCP

MetalLB e IP statici

Bilanciatore del carico manuale & IP statici

Terraform

Prima di iniziare

Esempio

Imposta le 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

Risoluzione dei problemi

Passaggi successivi

`name`

`gkeOnPremVersion`

`enableControlplaneV2`

`enableDataplaneV2`

`vCenter`

`network`

`loadBalancer`

`advancedNetworking`

`multipleNetworkInterfaces`

`storage`

`masterNode`

`nodePools`

`antiAffinityGroups`

`stackdriver`

`gkeConnect`

`gkeOnPremAPI`

`usageMetering`

`cloudAuditLogging`

Imposta le variabili in `terraform.tfvars`

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