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:

1. Connettiti alla workstation di amministrazione

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

2. Compila i file di configurazione

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

3. (Facoltativo) Importa le immagini del sistema operativo in vSphere e carica le immagini dei container nel registry privato, se applicabile.

   Esegui gkectl prepare.

4. Creazione di un cluster utente

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

5. Verificare 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 amministrativa, ha generato un file di configurazione chiamato user-cluster.yaml. Questo file di configurazione serve per creare il cluster di utenti.

Acquisisci familiarità con il file di configurazione esaminando il documento relativo al file di configurazione del cluster utente. Ti consigliamo di tenere aperto questo documento in una scheda o una finestra separata, poiché lo consulterai durante l'esecuzione dei passaggi che seguono.

name

Imposta il campo name sul nome che preferisci per il cluster di utenti.

gkeOnPremVersion

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

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 Controlplane 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 control plane del cluster utente nel file di blocco IP del cluster di amministrazione.

enableDataplaneV2

Imposta enableDataplaneV2 su true.

vCenter

I valori impostati nella sezione vCenter del file di configurazione del cluster di amministrazione sono globali. In altre parole, si applicano al cluster di amministrazione e ai relativi cluster di utenti associati.

Per ogni cluster utente creato, hai la possibilità di sostituire alcuni dei valori vCenter globali.

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

In particolare, ti consigliamo di utilizzare cluster vSphere separati per il cluster di amministrazione e i cluster utente, nonché data center separati per il cluster di amministrazione e i cluster utente.

Utilizzo di un data center e di un cluster vSphere

L'opzione predefinita è utilizzare un data center e 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 anche specificare:

• 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 amministrativo deve avere accesso al data center del cluster amministrativo, mentre l'account vCenter per il cluster utente deve avere accesso solo al data center del cluster utente.

Utilizzo di istanze separate di vCenter Server

In alcuni casi, ha senso creare un cluster utente che utilizzi la propria istanza di vCenter Server. In altre parole, il cluster di amministrazione e un cluster utente associato utilizzano istanze diverse di vCenter Server.

Ad esempio, in una località edge, potresti avere una macchina fisica su cui è in esecuzione vCenter Server e una o più macchine fisiche su cui è in esecuzione 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 l'intera sezione vCenter del file di configurazione del cluster utente. In particolare, specifica un valore per vCenter.address diverso dall'indirizzo del server vCenter specificato nel file di configurazione del cluster di amministrazione. Ad esempio:

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

Compila anche il campo network.vCenter.networkName.

network

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

• Da un server DHCP configurato in precedenza. Imposta network.ipMode.type su "dhcp".

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

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

I nodi del control plane per il cluster utente devono ottenere i propri indirizzi IP da un elenco di indirizzi statici 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à (HA), specifica tre indirizzi IP. In caso contrario, specifica un indirizzo IP.

Specifica i server DNS e NTP compilando la sezione hostConfig. Questi server DNS e NTP sono destinati ai nodi del 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 del numero di indirizzi IP necessari, consulta Pianifica gli indirizzi IP.

loadBalancer

Metti da parte 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 tuoi VIP come valori per loadBalancer.vips.controlPlaneVIP e loadBalancer.vips.ingressVIP.

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

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

• Bilanciamento del carico manuale. Imposta loadBalancer.kind su "ManualLB" e compila la sezione manualLB. Per ulteriori informazioni, consulta Bilanciamento del carico manuale.

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

advancedNetworking

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

multipleNetworkInterfaces

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

storage

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

masterNode

Nella sezione masterNode puoi specificare il numero di nodi del piano di controllo che vuoi per il tuo cluster utente: 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 saperne di più, consulta Pool di nodi e Creare e gestire i pool di nodi.

antiAffinityGroups

Imposta antiAffinityGroups.enabled su true o false.

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

stackdriver

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

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

Tieni presente i seguenti requisiti per i nuovi cluster:

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

• La regione Google Cloud impostata in stackdriver.clusterLocation deve essere la stessa della regione impostata in cloudAuditLogging.clusterLocation e gkeConnect.location (se il campo è incluso nel file di configurazione). 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 va a buon fine.

gkeConnect

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

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

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

Se includi gkeConnect.location nel file di configurazione, la regione specificata deve essere la stessa configurata in cloudAuditLogging.clusterLocation, stackdriver.clusterLocation e gkeOnPremAPI.location. Se le regioni non sono uguali, 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 le istruzioni, vedi Disattivare i servizi.

usageMetering

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

cloudAuditLogging

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

Tieni presente i seguenti requisiti per i nuovi cluster:

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

• La regione in cloudAuditLogging.clusterLocation deve essere uguale a quella impostata in gkeConnect.location (se il campo è incluso nel file di configurazione) e stackdriver.clusterLocation. Inoltre, se gkeOnPremAPI.enabled è true, la stessa regione deve essere impostata in gkeOnPremAPI.location.

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

Esempio di file di configurazione compilati

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

user-ipblock.yaml

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

user-cluster.yaml

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

Di seguito sono riportati 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 i nodi worker dovessero ricevere i propri indirizzi IP da un server DHCP, questi server DNS e NTP sarebbero solo per i nodi del piano di controllo.

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

• 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 control plane e il VIP di ingresso si trovano entrambi nella stessa VLAN dei nodi worker e dei nodi del control plane.

• Le VIP riservate ai servizi di tipo LoadBalancer sono specificate nella sezione loadBalancer.metalLB.addressPools del file di configurazione del cluster utente. 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. Pertanto, il cluster utente utilizza le stesse risorse vSphere del cluster di amministrazione.

Convalida il file di configurazione

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

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

Sostituisci quanto segue:

• ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig per il tuo cluster di amministrazione

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

Se il comando restituisce messaggi di errore, 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 di amministrazione.

• 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 pacchetto. Questo file si trova sulla tua workstation di amministrazione in /var/lib/gke/bundles/. Ad esempio:

  /var/lib/gke/bundles/gke-onprem-vsphere-1.30.400-gke.133-full.tgz
  

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

4. Creazione di un cluster utente

Crea un cluster utente:

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG 

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.

Individua il file kubeconfig del cluster utente

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

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. Verificare che il cluster utente sia in esecuzione

Verifica che il cluster utente sia in esecuzione:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

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

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

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

Console

Inizia

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

   Vai a Crea un cluster Google Distributed Cloud

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

Impostazioni di base del cluster

Inserisci le informazioni di base sul cluster.

1. Inserisci un nome per il cluster di utenti.

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

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

   Se il cluster di amministrazione che vuoi utilizzare non 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.

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

   • 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 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 località del cluster identificano in modo univoco il cluster in Google Cloud.

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

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

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

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

Control plane

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

1. Nel campo VCPU dei nodi del piano di controllo, inserisci il numero di vCPU (minimo 4) per ciascun nodo del piano di controllo per il tuo cluster utente.

2. 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.

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

4. 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 questa opzione è abilitata, i nodi del piano di controllo per il cluster utente vengono ridimensionati in base al numero di nodi worker nel cluster utente. Pertanto, man mano che aggiungi altri nodi worker al cluster utente, le dimensioni dei nodi del piano di controllo vengono aumentate.

5. Se vuoi, seleziona Attiva control plane v2. L'abilitazione del control plane v2 significa che il control plane per un cluster utente viene eseguito su uno o più nodi nel cluster utente stesso, anziché nel cluster di amministrazione (chiamato 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. Il numero di nodi è determinato dal numero di indirizzi IP inseriti. Quando il control plane v2 non è attivo, i campi vCPU, memoria e numero di nodi del control plane si applicano ai nodi del cluster di amministrazione. Assicurati di mettere da parte indirizzi IP sufficienti per il cluster di amministrazione.

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

Networking

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

1. 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 loro indirizzo IP da un server DHCP.

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

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

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

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

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

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

      • Se inserisci un singolo indirizzo IP, puoi 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.

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

   • CIDR dei servizi: 10.96.0.0/20
   • CIDR pod: 192.168.0.0/16

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

4. Se hai selezionato Modalità IP statico o Abilita 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.

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

Bilanciatore del carico

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

Seleziona il tipo di bilanciatore del carico dall'elenco.

Funzionalità

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

1. I seguenti elementi vengono 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

2. I seguenti elementi sono attivati per impostazione predefinita, ma puoi disattivarli:

   • Attiva il driver CSI vSphere: chiamato anche plug-in vSphere Container Storage. Il driver Container Storage Interface (CSI) viene eseguito in un cluster Kubernetes di cui è stato eseguito il deployment in vSphere per il provisioning di volumi permanenti nell'archiviazione 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.

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