Crea un cluster di amministrazione

Questo documento mostra come creare un cluster di amministrazione per Google Distributed Cloud. Il cluster di amministrazione gestisce i cluster utente che eseguono i carichi di lavoro.

Per maggiori dettagli sul cluster di amministrazione, consulta la panoramica dell'installazione.

Panoramica della procedura

Questi sono i passaggi principali necessari per creare un cluster di amministrazione:

1. Prepara una workstation di amministrazione.

   Questa macchina dispone degli strumenti necessari per creare nuovi cluster.

2. Compila i file di configurazione.

   Specifica i dettagli del nuovo cluster di amministrazione completando e convalidando un file di configurazione del cluster di amministrazione, un file di configurazione delle credenziali ed eventualmente un file dei blocchi IP.

3. Importa immagini del sistema operativo in vSphere ed esegui il push delle immagini container al registro privato, se applicabile.

   Esegui gkectl prepare.

4. Creare un cluster di amministrazione.

   Utilizza gkectl per creare un nuovo cluster di amministrazione come specificato nei file di configurazione completati. Quando Google Distributed Cloud crea un cluster di amministrazione, esegue il deployment di un cluster Kubernetes in Docker (kind) per ospitare temporaneamente i controller Kubernetes necessari per creare il cluster di amministrazione. Questo cluster temporaneo è chiamato cluster di bootstrap. I cluster utente vengono creati e aggiornati dall'amministratore responsabile senza utilizzare un cluster di bootstrap.

5. Verifica che il cluster di amministrazione sia in esecuzione.

   Utilizza kubectl per visualizzare i nodi del cluster.

Al termine di questa procedura, avrai a disposizione un cluster di amministrazione in esecuzione che puoi utilizzare per creare e gestire i cluster utente.

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

Prima di iniziare

• Consulta il documento di pianificazione degli indirizzi IP. Assicurati di disporre di un numero sufficiente di indirizzi IP per i tre nodi del piano di controllo e un VIP del piano di controllo. Se prevedi di creare qualsiasi cluster utente kubeception, devi disporre di un numero sufficiente di indirizzi IP per i nodi del piano di controllo di quei cluster utente.

• Consulta la panoramica del bilanciamento del carico e rivedi la decisione sul tipo di bilanciatore del carico da utilizzare. Per alcuni bilanciatori del carico, devi configurare quest'ultimo prima di creare il cluster di amministrazione.

• Dai un'occhiata alla sezione privateRegistry e decidi se utilizzare un registry pubblico o privato per i componenti di Google Distributed Cloud.

• Esamina il campo osImageType e decidi quale tipo di sistema operativo eseguire sui nodi del cluster di amministrazione.

• Se la tua organizzazione richiede che il traffico in uscita passi attraverso un server proxy, assicurati di inserire nella lista consentita le API richieste e l'indirizzo di Container Registry.

• Nella versione 1.29 e successive, i controlli preflight lato server sono abilitati per impostazione predefinita. I controlli preflight lato server richiedono regole firewall aggiuntive. In Regole firewall per i cluster di amministrazione, cerca "Controlli preflight" e assicurati che tutte le regole firewall richieste siano configurate. I controlli preflight lato server vengono eseguiti sul cluster di bootstrap e non localmente sulla workstation di amministrazione.

1. Prepara la workstation di amministrazione

Assicurati di aver configurato e di poter accedere alla workstation di amministrazione come descritto in Creare una workstation di amministrazione. La workstation di amministrazione ha gli strumenti necessari per creare il cluster di amministrazione.

Esegui tutti i passaggi rimanenti in questo documento sulla workstation di amministrazione.

2. Compila il file di configurazione

Se hai utilizzato gkeadm per creare la tua workstation di amministrazione, è stato generato un file di configurazione denominato admin-cluster.yaml.

Se non hai utilizzato gkeadm per creare la tua workstation di amministrazione, genera admin-cluster.yaml eseguendo questo comando sulla workstation di amministrazione:

gkectl create-config admin

Questo file di configurazione consente di creare il cluster di amministrazione.

Acquisisci familiarità con il file di configurazione analizzando il documento sul file di configurazione del cluster di amministrazione. Ti consigliamo di tenere questo documento aperto in una scheda o finestra separata, perché lo userai man mano che completi i passaggi seguenti.

name

Se vuoi specificare un nome per il cluster di amministrazione, compila il campo name.

bundlePath

Il bundle è un file compresso che contiene i componenti del cluster. È inclusa nella workstation di amministrazione. Questo campo è già stato compilato.

vCenter

I campi di questa sezione sono già compilati con i valori che hai inserito durante la creazione della workstation di amministrazione.

network

Compila la sezione network.controlPlaneIPBlock e la sezione network.hostConfig. Imposta anche adminMaster.replicas su 3.

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

Compila gli altri campi della sezione Network del file di configurazione in base alle necessità.

loadBalancer

Riserva un VIP per il server API Kubernetes del tuo cluster di amministrazione. Fornisci il tuo VIP come valore per loadBalancer.vips.controlPlaneVIP

Per maggiori informazioni, consulta VIP nella subnet del cluster di amministrazione.

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

• Bilanciamento del carico in bundle con MetalLB. Imposta loadBalancer.kind su "MetalLB".

• Bilanciamento del carico integrato con F5 BIG-IP. Imposta loadBalancer.kind su "F5BigIP" e compila la sezione f5BigIP.

• Bilanciamento del carico manuale. Imposta loadBalancer.kind su "ManualLB" e compila la sezione manualLB.

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

antiAffinityGroups

Imposta antiAffinityGroups.enabled su true o false in base alle tue preferenze.

Utilizza questo campo per specificare se vuoi che Google Distributed Cloud crei regole di anti-affinità del Distributed Resource Scheduler (DRS) di VMware per i nodi del cluster di amministrazione, in modo che vengano distribuite su almeno tre host fisici nel tuo data center.

adminMaster

Se vuoi specificare CPU e memoria per i nodi del piano di controllo del cluster di amministrazione, compila i campi cpus e memoryMB della sezione adminMaster.

Imposta il campo replicas nella sezione adminMaster su 3.

proxy

Se la rete che avrà i nodi del cluster di amministrazione è dietro un server proxy, compila la sezione proxy.

privateRegistry

Decidi dove vuoi conservare le immagini container per i componenti Google Distributed Cloud. Le opzioni sono:

• Container Registry

• Il tuo registro Docker privato.

Se vuoi utilizzare il tuo registro privato, compila la sezione privateRegistry.

componentAccessServiceAccountKeyPath

Google Distributed Cloud utilizza il tuo account di servizio di accesso ai componenti per scaricare i componenti del cluster da Container Registry. Questo campo contiene il percorso di un file chiave JSON per il tuo account di servizio di accesso ai componenti.

Questo campo è già stato compilato.

gkeConnect

Registra il cluster di amministrazione in un parco risorse Google Cloud compilando la sezione gkeConnect. Se includi le sezioni stackdriver e cloudAuditLogging nel file di configurazione, 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 riesce.

Nella versione 1.28 e successive, puoi facoltativamente specificare una regione in cui vengono eseguiti i servizi Fleet e Connect in gkeConnect.location. Se non includi questo campo, il cluster usa le istanze globali dei servizi.

Se includi gkeConnect.location, la regione specificata deve essere uguale a quella configurata in cloudAuditLogging.clusterLocation, stackdriver.clusterLocation e gkeOnPremAPI.location. Se le regioni non sono le stesse, la creazione del cluster non riesce.

gkeOnPremAPI

Se l'API GKE On-Prem è abilitata nel tuo progetto Google Cloud, tutti i cluster nel 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 le regioni non corrispondono, la creazione del cluster non riesce.

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

stackdriver

Se vuoi abilitare 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 admin.

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 corrispondere a quella impostata in cloudAuditLogging.clusterLocation e gkeConnect.location (se il campo è incluso nel file di configurazione). Inoltre, se gkeOnPremAPI.enabled è true, è necessario impostare la stessa regione in gkeOnPremAPI.location.

Se gli ID progetto e le regioni non sono uguali, la creazione del cluster non riesce.

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 per i nuovi cluster:

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

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

Se gli ID progetto e le regioni non sono uguali, la creazione del cluster non riesce.

clusterBackup

Se vuoi abilitare il backup del cluster di amministrazione, imposta clusterBackup.datastore sul datastore vSphere in cui vuoi salvare i backup del cluster.

autoRepair

Se vuoi abilitare la riparazione automatica dei nodi per il cluster di amministrazione, imposta autoRepair.enabled su true.

secretsEncryption

Se vuoi abilitare la crittografia dei secret sempre attivi, compila la sezione secretsEncryption.

osImageType

Decidi quale tipo di immagine del sistema operativo utilizzare per i nodi del cluster di amministrazione e compila la sezione osImageType di conseguenza.

Esempio di file di configurazione compilati

Ecco un esempio di file di configurazione del cluster di amministrazione compilato. La configurazione abilita alcune delle funzionalità disponibili, ma non tutte.

vc-01-admin-cluster.yaml

apiVersion: v1
kind: AdminCluster
name: "gke-admin-01"
bundlePath: "/var/lib/gke/bundles/gke-onprem-vsphere-1.28.0-gke.1-full.tgz"
vCenter:
  address: "vc01.example"
  datacenter: "vc-01"
  cluster: "vc01-workloads-1"
  resourcePool: "vc-01-pool-1"
  datastore: "vc01-datastore-1"
  caCertPath: "/usr/local/google/home/me/certs/vc01-cert.pem""
  credentials:
    fileRef:
      path: "credential.yaml"
      entry: "vCenter"
network:
  hostConfig:
    dnsServers:
    - "203.0.113.1"
    - "198.51.100.1"
    ntpServers:
    - "216.239.35.4"
  serviceCIDR: "10.96.232.0/24"
  podCIDR: "192.168.0.0/16"
  vCenter:
    networkName: "vc01-net-1"
  controlPlaneIPBlock:
    netmask: "255.255.248.0"
    gateway: "21.0.143.254"
    ips:
    - ip: "21.0.140.226"
      hostname: "admin-cp-vm-1"
    - ip: "21.0.141.48"
      hostname: "admin-cp-vm-2"
    - ip: "21.0.141.65"
      hostname: "admin-cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.59"
  kind: "MetalLB"
antiAffinityGroups:
  enabled: true
adminMaster:
  cpus: 4
  memoryMB: 16384
  replicas: 3
componentAccessServiceAccountKeyPath: "sa-key.json"
gkeConnect:
  projectID: "my-project-123"
  registerServiceAccountKeyPath: "connect-register-sa-2203040617.json"
stackdriver:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  enableVPC: false
  serviceAccountKeyPath: "log-mon-sa-2203040617.json"
  disableVsphereResourceMetrics: false
clusterBackup:
  datastore: "vc-01-datastore-bu"
autoRepair:
  enabled: true
osImageType: "ubuntu_containerd"

Convalidare il file di configurazione

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

gkectl check-config --config ADMIN_CLUSTER_CONFIG

Sostituisci ADMIN_CLUSTER_CONFIG con il percorso del file di configurazione del cluster di amministrazione.

Se il comando restituisce messaggi di errore, risolvi i problemi e convalida nuovamente il file.

Se vuoi saltare le convalide che richiedono più tempo, passa il flag --fast. Per saltare le singole convalide, utilizza i flag --skip-validation-xxx. Per scoprire di più sul comando check-config, consulta Esecuzione dei controlli preflight.

3. Recupera immagini sistema operativo

Esegui gkectl prepare per inizializzare il tuo ambiente vSphere:

gkectl prepare --config ADMIN_CLUSTER_CONFIG

Il comando gkectl prepare esegue le seguenti attività preparatorie:

• Importa immagini del sistema operativo in vSphere e le contrassegna come modelli di VM.

• Se utilizzi un registro Docker privato, esegue il push delle immagini container nel registro.

• Facoltativamente, convalida le attestazioni di build delle immagini container, verificando quindi che le immagini siano state create e firmate da Google e siano pronte per il deployment.

Nota: se utilizzi nomi DNS interni o la workstation non può accedere agli indirizzi DNS pubblici di Google (8.8.8.8 o 8.8.4.4), devi specificare il server dei nomi interno in /etc/resolv.conf.

5. Crea il cluster di amministrazione

Crea il cluster di amministrazione:

gkectl create admin --config ADMIN_CLUSTER_CONFIG

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

Riprendi la creazione del cluster di amministrazione dopo un errore

Se la creazione del cluster di amministrazione non riesce o viene annullata, puoi eseguire di nuovo il comando create:

gkectl create admin --config ADMIN_CLUSTER_CONFIG

Individuare il file kubeconfig del cluster di amministrazione

Il comando gkectl create admin crea un file kubeconfig denominato kubeconfig nella directory attuale. In seguito avrai bisogno di questo file kubeconfig per interagire con il cluster di amministrazione.

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

kubectl config get-clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

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

NAME
gke-admin-tqk8x

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

Gestisci il file checkpoint.yaml

Quando hai eseguito il comando gkectl create admin per creare il cluster di amministrazione, ha creato un file di checkpoint nella stessa cartella del datastore del disco dati del cluster di amministrazione. Per impostazione predefinita, questo file è denominato DATA_DISK_NAME‑checkpoint.yaml. Se la lunghezza di DATA_DISK_NAME è superiore o uguale a 245 caratteri, a causa del limite di vSphere sulla lunghezza del nome del file, il nome è DATA_DISK_NAME.yaml.

Questo file contiene lo stato e le credenziali del cluster di amministrazione e viene utilizzato per gli upgrade futuri. Non eliminare questo file a meno che tu non stia seguendo la procedura per l'eliminazione di un cluster di amministrazione.

Se hai abilitato la crittografia delle VM nell'istanza di vCenter Server, devi disporre del privilegio Operazioni di crittografia.Accesso diretto prima di creare o eseguire l'upgrade del cluster di amministrazione. In caso contrario, il checkpoint non verrà caricato. Se non riesci a ottenere questo privilegio, puoi disabilitare il caricamento del file del checkpoint utilizzando il flag nascosto --disable-checkpoint quando esegui un comando pertinente.

Il file checkpoint.yaml viene aggiornato automaticamente quando esegui il comando gkectl upgrade admin o quando esegui un comando gkectl update che interessa il cluster di amministrazione.

6. Verifica che il cluster di amministrazione sia in esecuzione

Verifica che il cluster di amministrazione sia in esecuzione:

kubectl get nodes --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Sostituisci ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione.

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

admin-cp-vm-1   Ready    control-plane,master   ...
admin-cp-vm-2   Ready    control-plane,master   ...
admin-cp-vm-3   Ready    control-plane,master   ...

7. Esegui il backup dei file

Ti consigliamo di eseguire il backup del file kubeconfig del cluster di amministrazione. Copia quindi il file kubeconfig dalla tua workstation di amministrazione in un'altra posizione. Quindi, se perdi l'accesso alla workstation di amministrazione o se il file kubeconfig sulla workstation di amministrazione viene eliminato per errore, hai comunque accesso al cluster di amministrazione.

Ti consigliamo inoltre di eseguire il backup della chiave SSH privata per il cluster di amministrazione. Se perdi l'accesso al cluster di amministrazione, puoi comunque utilizzare SSH per connetterti ai nodi del cluster di amministrazione. In questo modo potrai risolvere ed esaminare eventuali problemi di connettività al cluster di amministrazione.

Estrai la chiave SSH dal cluster di amministrazione in un file denominato admin-cluster-ssh-key:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n kube-system sshkeys \
    -o jsonpath='{.data.vsphere_tmp}' | base64 -d > admin-cluster-ssh-key

Ora puoi eseguire il backup di admin-cluster-ssh-key in un'altra posizione a tua scelta.

Criteri RBAC

Quando compili la sezione gkeConnect nel file di configurazione del cluster di amministrazione, il cluster viene registrato nel tuo parco risorse durante la creazione o l'aggiornamento. Per abilitare la funzionalità di gestione del parco risorse, Google Cloud esegue il deployment dell'agente Connect e crea un account di servizio Google che rappresenta il progetto in cui è registrato il cluster. L'agente Connect stabilisce una connessione con l'account di servizio per gestire le richieste al server API Kubernetes del cluster. Questo consente l'accesso alle funzionalità di gestione dei cluster e dei carichi di lavoro in Google Cloud, incluso l'accesso alla console Google Cloud, che consente di interagire con il cluster.

Il server API Kubernetes del cluster di amministrazione deve essere in grado di autorizzare le richieste dall'agente Connect. Per garantire ciò, nell'account di servizio sono configurati i seguenti criteri di controllo dell'accesso basato sui ruoli (RBAC):

• Un criterio di rappresentazione che autorizza l'agente Connect a inviare richieste al server API Kubernetes per conto dell'account di servizio.

• Un criterio di autorizzazione che specifica le operazioni consentite su altre risorse Kubernetes.

I criteri dell'account di servizio e del RBAC sono necessari per gestire il ciclo di vita dei cluster utente nella console Google Cloud.

Risoluzione dei problemi

Consulta Risoluzione dei problemi di creazione e upgrade del cluster.

Passaggi successivi

Crea un cluster utente