Creare un cluster utente da utilizzare con i domini di topologia

In Google Distributed Cloud, i tuoi 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.

La configurazione di un dominio di topologia richiede l'attivazione del cluster avanzato. Tieni presenti le seguenti limitazioni relative all'anteprima avanzata del cluster:

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

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

Prima di iniziare

Panoramica della procedura

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

  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 maschera di rete, 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. Verifica che il cluster utente sia in esecuzione
    Utilizza kubectl per visualizzare i nodi del cluster.

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

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 workstation amministrativa, puoi utilizzare gkectl per generare un modello per il file di configurazione del cluster utente.

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

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

Sostituisci quanto segue:

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

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

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

name

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

gkeOnPremVersion

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

enableAdvancedCluster

Imposta enableAdvancedCluster su true.

enableControlplaneV2

Controlplane V2 è obbligatorio per tutti i cluster utente 1.30 e versioni successive. Imposta enableControlplaneV2 su true.

Quando Controlplane 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 vengono 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 maschera di rete 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 ottengano i loro indirizzi IP. Le opzioni sono:

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

    • Da un elenco di indirizzi IP statici forniti nel file del blocco IP. Imposta network.ipMode.type su "static".

    I nodi del control plane del cluster utente devono ottenere i propri indirizzi IP da un elenco di indirizzi statici forniti nel file del blocco IP. Questo vale anche se i nodi worker ricevono gli 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 un numero sufficiente di indirizzi IP disponibili per il cluster di utenti. Per una spiegazione del numero di indirizzi IP necessari, vedi Pianificare gli indirizzi IP.

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

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 CPU e memoria per i nodi del control plane del cluster utente, compila i campi cpus e memoryMB nella sezione masterNode.

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

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

  • Rimuovi l'intera sezione masterNode.vsphere.

  • Compila il campo masterNode.topologyDomains con il nome del dominio di topologia in cui vuoi che si trovino i nodi del control plane.

nodePools

Un pool di nodi è un gruppo di nodi worker in un cluster che condividono la stessa configurazione. Ad esempio, potresti voler configurare un dominio di topologia separato 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 nella sezione nodePools[i].vsphere tranne nodePools[i].vsphere.tags. Specifichi queste informazioni nel file di configurazione dell'infrastruttura vSphere per dominio di topologia.

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

Per informazioni più generali sui node pool, consulta Node pool e Creazione e gestione dei node pool.

antiAffinityGroups

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

stackdriver

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

Tieni presente i seguenti requisiti:

  • L'ID in stackdriver.projectID deve corrispondere 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, la stessa regione deve essere impostata in gkeOnPremAPI.location.

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

gkeConnect

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

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

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

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

gkeOnPremAPI

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 dei 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 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 la stessa specificata in cloudAuditLogging.clusterLocation, gkeConnect.location e stackdriver.clusterLocation.

  • Se vuoi registrare tutti i cluster del progetto nell'API GKE On-Prem, assicurati di eseguire i passaggi descritti in Prima di iniziare per attivare e utilizzare l'API GKE On-Prem nel progetto.

  • Se non vuoi registrare il cluster nell'API GKE On-Prem, includi questa sezione e imposta gkeOnPremAPI.enabled su false. Se non vuoi registrare cluster nel progetto, disabilita gkeonprem.googleapis.com (il nome del servizio per l'API GKE On-Prem) nel progetto. Per le istruzioni, vedi Disabilitare i servizi.

cloudAuditLogging

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

Tieni presente i seguenti requisiti:

# advanced-cluster-change #

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

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

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

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

preparedSecrets

Rimuovi il campo preparedSecrets. Le credenziali preparate non sono supportate quando i domini della topologia sono abilitati.

schedulerConfiguration

Se vuoi configurare impostazioni aggiuntive da passare a kube-scheduler, aggiungi la sezione schedulerConfiguration al file di configurazione.

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.32.200-gke.104
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

Ecco i punti importanti da comprendere nell'esempio precedente:

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

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

  • Sono abilitati i cluster avanzati, Controlplane V2 e Dataplane V2.

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

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

Compila il file di blocco IP

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

Aggiungi gli indirizzi IP per il gateway, la maschera di rete e i nodi del control plane al file del blocco IP. Per ogni indirizzo IP del nodo del control plane, aggiungi isControlPlane: true come mostrato nell'esempio precedente. Se vuoi un cluster utente ad alta disponibilità, specifica tre indirizzi IP. Altrimenti, specifica un indirizzo IP. Il numero di indirizzi IP specificato per i nodi del control plane 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 di lavoro 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, vedi l'esempio per i domini di topologia.

Creazione di un cluster utente

Esegui questo comando per creare un cluster utente:

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 un secondo momento per interagire con il cluster utente.

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

kubectl config get-clusters --kubeconfig USER_CLUSTER_KUBECONFIG

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

NAME
my-user-cluster

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

Verifica che il cluster utente sia in esecuzione

Verifica che il cluster utente sia in esecuzione:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

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

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

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

Configura PodTemplate

L'etichetta di topologia viene compilata con le etichette dei nodi nel dominio di topologia. A meno che la configurazione del dominio della topologia non abbia utilizzato il vincolo predefinito, "topology.kubernetes.io/zone" come chiave della topologia, devi configurare la chiave della 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 distribuisce i pod nel dominio della topologia per garantire l'alta disponibilità ed evitare un'eccessiva concentrazione in una singola area in caso di errore.

Risoluzione dei problemi

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

Passaggi successivi