Creare un cluster utente da utilizzare con i domini di topologia

In Google Distributed Cloud, i carichi di lavoro vengono eseguiti su uno o più cluster utente. Questa pagina mostra come creare un cluster utente da utilizzare nei domini di topologia di Google Distributed Cloud. Per utilizzare i domini di topologia è necessaria la versione 1.31 o successive di Google Distributed Cloud.

Per configurare un dominio di topologia, devi attivare il cluster avanzato. Tieni presenti le seguenti limitazioni dell'anteprima avanzata del cluster:

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

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

Prima di iniziare

Panoramica della procedura

Per utilizzare gkectl per creare un cluster di utenti, sono necessari i seguenti passaggi principali:

  1. Compila il file di configurazione del cluster utente
    Specifica i dettagli del nuovo cluster nel file di configurazione del cluster utente.
  2. Compila il file di blocco IP
    Specifica gli indirizzi IP per il gateway, la netmask, i nodi del control plane e, facoltativamente, i nodi worker in un file di blocco IP.
  3. Creazione di un cluster utente
    Esegui gkectl create cluster per creare un cluster come specificato nei file di configurazione.
  4. 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.

Compila il file di configurazione del cluster utente

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

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

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

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

Sostituisci quanto segue:

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

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

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 su un nome a tua scelta per il cluster di utenti.

gkeOnPremVersion

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

enableAdvancedCluster

Imposta enableAdvancedCluster su true.

enableControlplaneV2

Il control plane v2 è obbligatorio per tutti i cluster utente 1.30 e versioni successive. Imposta enableControlplaneV2 sutrue.

Quando il control plane v2 è abilitato, il control plane per il cluster utente viene eseguito sui nodi del cluster utente stesso.

enableDataplaneV2

Imposta enableDataplaneV2 su true.

vCenter

Rimuovi l'intera sezione. Devi invece configurare le informazioni di vCenter nel file di configurazione dell'infrastruttura vSphere per dominio di topologia.

network

  • Rimuovi quanto segue dal file di configurazione:

    • L'intera sezione network.hostConfig. Queste informazioni sono configurate nel file di configurazione dell'infrastruttura vSphere per dominio di topologia.
    • Il campo network.vCenter.networkName. Questo campo è configurato nel file di configurazione dell'infrastruttura vSphere per dominio di topologia.
    • L'intera sezione network.controlPlaneIPBlock. Gli indirizzi IP per il gateway, la netmask e i nodi del control plane sono configurati in un file di blocco IP.

  • Imposta network.ipMode.ipBlockFilePath sul percorso del file di blocco IP.

  • 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 nel file di blocco IP. Imposta network.ipMode.type su "static".

    I nodi del piano di controllo per il cluster utente devono ottenere i propri indirizzi IP da un elenco di indirizzi statici che fornisci nel file del blocco IP. Questo accade anche se i nodi worker ricevono i loro indirizzi da un server DHCP.

    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 tuo cluster di utenti. Per una spiegazione del numero di indirizzi IP necessari, consulta Pianifica gli indirizzi IP.

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

loadBalancer

advancedNetworking

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

multipleNetworkInterfaces

Imposta multipleNetworkInterfaces su false. Le interfacce di rete multiple per i pod non sono supportate con i domini di topologia.

storage

Imposta storage.vSphereCSIDisabled su true per disattivare il deployment dei componenti CSI vSphere.

masterNode

  • Se vuoi specificare la CPU e la memoria per i nodi del control plane del cluster utente, compila i campi cpus e memoryMB nella sezione masterNode.

  • Sono supportati solo i cluster ad alta disponibilità (HA). Imposta il campo replicas su 3 per specificare che il cluster avrà tre nodi del piano di controllo.

  • Per abilitare il ridimensionamento automatico dei nodi del control plane, imposta autoResize.enabled su true.

  • Rimuovi l'intera masterNode.vsphere sezione.

  • Compila il campo masterNode.topologyDomains con il nome del dominio di topologia in cui devono trovarsi i nodi del piano di controllo.

nodePools

Un pool di nodi è un gruppo di nodi worker in un cluster che hanno tutti la stessa configurazione. Ad esempio, ti consigliamo di configurare un dominio di topologia distinto per ogni pool di nodi. Devi specificare almeno un pool di nodi compilando la sezione nodePools.

Per ogni pool di nodi specificato:

  • Compila il campo nodePools[i].topologyDomains con il nome del dominio di topologia in cui vuoi che si trovi il pool di nodi.

  • Rimuovi tutti i campi della sezione nodePools[i].vsphere tranne nodePools[i].vsphere.tags. Specifica queste informazioni nel file di configurazione dell'infrastruttura vSphere per dominio di topologia.

# advanced-cluster-change #

Imposta nodePools[i].osImageType su ubuntu_cgroupv2 o ubuntu_containerd.

Per informazioni più generali sui node pool, consulta Node pool e Creare e gestire i node pool.

antiAffinityGroups

Imposta antiAffinityGroups.enabled sufalse. Le regole di anti-affinità di Distributed Resource Scheduler (DRS) non sono supportate con i domini di topologia.

stackdriver

Compila la sezione stackdriver per attivare Cloud Logging e Cloud Monitoring per il tuo cluster.

Tieni presente i seguenti requisiti:

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

  • La regione Google Cloud impostata in stackdriver.clusterLocation deve essere la stessa della regione impostata in cloudAuditLogging.clusterLocation e gkeConnect.location. Inoltre, se gkeOnPremAPI.enabled è true, 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 di utenti deve essere registrato a un 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.

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

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

gkeOnPremAPI

Questa sezione descrive come i cluster vengono registrati nell'API GKE On-Prem.

Lo strumento a riga di comando gkectl è l'unico strumento di gestione del ciclo di vita del cluster disponibile per i cluster che utilizzano domini di topologia. Sebbene la console Google Cloud , Google Cloud CLI e Terraform non siano supportati per i cluster che utilizzano i domini di topologia, puoi facoltativamente registrare il cluster nell'API GKE On-Prem al momento della creazione.

Se l'API GKE On-Prem è abilitata nel tuo progettoGoogle Cloud , tutti i cluster del progetto vengono registrati automaticamente nell'API GKE On-Prem nella regione configurata in stackdriver.clusterLocation. La regione gkeOnPremAPI.location deve essere uguale a quella specificata in cloudAuditLogging.clusterLocation, gkeConnect.location 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.

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:

# advanced-cluster-change #

Imposta cloudAuditLogging.serviceAccountKeyPath sullo stesso percorso di stackdriver.serviceAccountKeyPath.

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

  • La regione in cloudAuditLogging.clusterLocation deve essere 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.

preparedSecrets

Rimuovi il campo preparedSecrets. Le credenziali preparate non sono supportate se i domini di topologia sono abilitati.

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
  - netmask: 255.255.255.0
    gateway: 100.115.223.254
    ips:
    - ip: 100.115.222.205
      hostname: cp-1
      isControlPlane: true
    - ip: 100.115.222.206
      hostname: cp-2
      isControlPlane: true
    - ip: 100.115.222.207
      hostname: cp-3
      isControlPlane: true

user-cluster.yaml

cat user-cluster.yaml
apiVersion: v1
kind: UserCluster
name: "my-user-cluster"
gkeOnPremVersion: 1.31.0-gke.889
enableAdvancedCluster: true
enableControlplaneV2: true
enableDataplaneV2: true
network:
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  serviceCIDR: 10.96.0.0/20
  podCIDR: 192.168.0.0/16
loadBalancer:
  vips:
    controlPlaneVIP: "100.115.222.200"
    ingressVIP: "172.16.21.30"
  kind: "ManualLB"
  manualLB:
    ingressHTTPNodePort: 32527
    ingressHTTPSNodePort: 30139
    controlPlaneNodePort: 30968
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool1"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  topologyDomains:
  - "domain1"
antiAffinityGroups:
  enabled: false
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:

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

  • Gli indirizzi IP dei nodi del piano di controllo e dei nodi worker sono specificati in un file di blocco IP. Il file di blocco IP contiene quattro indirizzi per i nodi worker anche se sono presenti solo tre nodi worker. L'indirizzo IP del nodo worker aggiuntivo è necessario durante l'upgrade, l'aggiornamento e la riparazione automatica del cluster. Gli indirizzi IP dei nodi del piano di controllo hanno il flagisControlPlane: true.

  • I cluster avanzati, Controlplane V2 e Dataplane V2 sono abilitati.

  • Il campo masterNode.replicas è impostato su 3, pertanto il cluster avrà un piano di controllo ad alta disponibilità.

  • Il VIP del piano di controllo si trovi nella stessa VLAN dei nodi del piano di controllo e il VIP di ingresso si trovi nella stessa VLAN dei nodi worker

Compila il file di blocco IP

Copia il modello per il file di blocco IP nel file nella directory specificata nel campo network.ipMode.ipBlockFilePath nel file di configurazione del cluster utente. Crea file di blocco IP separati per il cluster di amministrazione e per ogni cluster di utenti.

Aggiungi gli indirizzi IP del gateway, della netmask e dei nodi del piano di controllo al file del blocco IP. Per ogni indirizzo IP del nodo del piano di controllo, aggiungiisControlPlane: true come mostrato nell'esempio precedente. Se vuoi un cluster utente ad alta disponibilità (HA), specifica tre indirizzi IP. In caso contrario, specifica un indirizzo IP. Il numero di indirizzi IP specificati per i nodi del piano di controllo deve corrispondere al numero nel campo masterNode.replicas del file di configurazione del cluster utente.

Se network.ipMode.type è impostato su "static", aggiungi gli indirizzi IP dei nodi worker al file di blocco IP. Assicurati di specificare un indirizzo IP aggiuntivo da utilizzare durante l'upgrade, l'aggiornamento e la riparazione automatica del cluster.

Ogni indirizzo gateway nel file del blocco IP deve corrispondere all'indirizzo specificato in un campo topologyDomains[i].network.gateway nel file di configurazione dell'infrastruttura vSphere. Per ulteriori informazioni, consulta esempio per i domini di topologia.

Creazione di un cluster utente

Esegui il comando seguente per creare un cluster di utenti:

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Individua il file kubeconfig del cluster utente

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

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

Configura PodTemplate

L'etichetta della topologia viene compilata nelle etichette dei nodi nel dominio della topologia. A meno che la configurazione del dominio di topologia non abbia utilizzato il vincolo predefinito, "topology.kubernetes.io/zone" come chiave di topologia, devi configurare la chiave di topologia nel modello di pod del tuo deployment, StatefulSet o ReplicaSet, a seconda dei casi.

Ad esempio, supponiamo di aver definito la chiave nell'etichetta della topologia come"topology.examplepetstore.com/zone". In PodTemplate, specifica la chiave come valore per il campo topologySpreadConstraints.topologyKey. In questo modo, lo scheduler Kubernetes può distribuire i pod nel dominio della topologia per garantire un'alta disponibilità ed evitare una concentrazione eccessiva in una singola area in caso di guasto.

Risoluzione dei problemi

Consulta la sezione Risoluzione dei problemi relativi alla creazione e all'upgrade dei cluster.

Passaggi successivi