Crea un cluster utente da utilizzare con i domini di topologia

In Google Distributed Cloud, i workload 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 successiva di Google Distributed Cloud.

La configurazione di un dominio di topologia richiede l'attivazione del cluster avanzato.

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 di Google Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Prima di iniziare

Panoramica della procedura

I passaggi principali per utilizzare gkectl per creare un cluster utente sono i seguenti:

  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 del 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. 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 tuoi workload.

Compila il file di configurazione del cluster utente

Se hai utilizzato gkeadm per creare la workstation di amministrazione, gkeadm ha generato un template 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 template per il file di configurazione del cluster utente.

Per generare un template 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 di tua scelta per il template 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.36.200-gke.118.

Acquisisci familiarità 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é dovrai consultarlo durante il completamento dei passaggi seguenti.

name

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

gkeOnPremVersion

Questo campo è già compilato. Specifica la versione di Google Distributed Cloud. Ad esempio, 1.36.200-gke.118.

enableAdvancedCluster

Imposta enableAdvancedCluster su true.

enableControlplaneV2

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

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

enableDataplaneV2

Imposta enableDataplaneV2 su true.

vCenter

Rimuovi l'intera sezione. Invece, configuri 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 netmask e i nodi del control plane sono configurati in un file di blocco IP.

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

  • Decidi in che modo i nodi worker devono ottenere i propri 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 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 i propri indirizzi da un server DHCP.

    Indipendentemente dal fatto che tu utilizzi un server DHCP o specifichi un elenco di indirizzi IP statici, devi avere un numero sufficiente di indirizzi IP disponibili per il tuo cluster utente. Per una spiegazione del numero di indirizzi IP necessari, consulta Pianifica gli indirizzi IP.

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

loadBalancer

advancedNetworking

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

multipleNetworkInterfaces

Imposta multipleNetworkInterfaces su false. Più interfacce di rete 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 affidabilità (HA). Imposta il campo replicas su 3 per specificare che il cluster avrà tre nodi del control plane.

  • Per abilitare il ridimensionamento automatico dei 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 all'interno di 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, ad eccezione di nodePools[i].vsphere.tags. Specifica queste informazioni nel file di configurazione dell'infrastruttura vSphere per dominio di topologia.

  • Imposta nodePools[i].osImageType su ubuntu_cgv2.

Per informazioni più generali sui pool di nodi, consulta Pool di nodi e Creazione e gestione dei pool di nodi.

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 essere lo stesso dell'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 parco risorse Google Cloud .

Compila la sezione gkeConnect per specificare un progetto host del parco risorse 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 gli stessi, la creazione del cluster non va a buon fine.

Se vuoi, puoi specificare una regione in cui vengono eseguiti i servizi del parco risorse e di 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 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 del cluster disponibile per i cluster che utilizzano i 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 instackdriver.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 seguire i passaggi descritti in Prima di iniziare per attivare e utilizzare l'API GKE On-Prem nel progetto.

  • Se non vuoi registrare il cluster nell'API GKE On-Prem, includi questa sezione e imposta gkeOnPremAPI.enabled su false. Se non vuoi registrare cluster nel progetto, disabilita gkeonprem.googleapis.com (il nome del servizio per l'API GKE On-Prem) nel progetto. Per istruzioni, vedi 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 essere lo stesso dell'ID in gkeConnect.projectID e stackdriver.projectID.

  • La regione in cloudAuditLogging.clusterLocation deve essere la stessa di 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 sono abilitati i domini di topologia.

schedulerConfiguration

Se vuoi impostare configurazioni aggiuntive che verranno passate 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.36.200-gke.118
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 sono presenti 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 control plane e dei nodi worker sono specificati in un file di blocco IP. Il file del blocco IP contiene quattro indirizzi per i nodi worker, anche se i nodi worker sono solo tre. 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 control plane hanno il flag isControlPlane: true.

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

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

  • 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 del blocco IP

Copia il modello per il file del blocco IP nel file nella directory specificata nel campo network.ipMode.ipBlockFilePath nel 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 netmask 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 affidabilità (HA), specifica tre indirizzi IP. In caso contrario, specifica un indirizzo IP. Il numero di indirizzi IP specificati per i nodi del control plane deve corrispondere al numero nel campo masterNode.replicas nel file di configurazione del cluster utente.

Se network.ipMode.type è impostato su "static", aggiungi gli indirizzi IP dei nodi worker al file del 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 saperne di più, consulta 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 attuale. 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 della topologia viene compilata nelle etichette dei nodi nel dominio della 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 template del 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, specifichi la chiave come valore per il campo topologySpreadConstraints.topologyKey. In questo modo, lo scheduler di Kubernetes può distribuire i pod nel dominio della topologia per garantire l'alta affidabilità ed evitare un'eccessiva concentrazione in una singola area in caso di errore.

Risoluzione dei problemi

Consulta la sezione Risoluzione dei problemi di creazione e upgrade dei cluster.

Passaggi successivi