Esecuzione dei controlli preflight

Questo documento fornisce informazioni sui controlli preflight eseguiti quando crei o esegui l'upgrade di un cluster in Google Distributed Cloud (solo software) per VMware.

Esamina le regole firewall

Nella versione 1.29 e successive, i controlli preflight lato server sono abilitati per impostazione predefinita quando crei, aggiorni ed esegui l'upgrade dei cluster. 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.

Sto eseguendo gkectl check-config

Se prevedi di creare cluster utilizzando gkectl, esegui gkectl create-config per generare un file di configurazione. Il file di configurazione guida l'installazione: fornisci informazioni sul tuo ambiente vSphere, sulla tua rete e sul bilanciatore del carico, nonché sull'aspetto che vuoi dare ai tuoi cluster. Puoi generare un file di configurazione prima o dopo aver creato una workstation di amministrazione. Per superare determinati controlli, questi devono essere eseguiti dalla workstation di amministrazione.

Dopo aver modificato il file per soddisfare le esigenze del tuo ambiente e dei tuoi cluster, utilizza il file per creare i cluster nel tuo ambiente on-prem.

Prima di creare i cluster utilizzando gkectl, esegui gkectl check-config per convalidare il file di configurazione con diversi controlli preflight. Se il comando restituisce messaggi FAILURE, risolvi i problemi e convalida nuovamente il file. Se la convalida di una determinata funzionalità restituisce messaggi di AVVISO, devi risolvere i problemi sottostanti prima di poter utilizzare la funzionalità.

Avviso: gkectl check-config deve essere utilizzato solo prima della creazione del cluster. L'esecuzione su un cluster già esistente genererà messaggi FAILURE imprevisti.

Avviso: alcuni campi nel file di configurazione sono stati ritirati. Se esegui gkectl check-config su un file con un campo deprecato, il comando potrebbe non riuscire. Per un esempio, consulta questa nota di rilascio.

Modalità di controllo preflight e salto delle convalide

gkectl check-config ha una modalità predefinita e una modalità veloce:

• In modalità predefinita, il comando convalida in modo completo ogni campo. Inoltre, la modalità predefinita crea macchine virtuali (VM) vSphere temporanee nell'ambito delle sue convalide, il che può richiedere più tempo.

• In modalità rapida, il comando ignora i controlli che creano VM di test ed esegue solo i controlli rapidi. Per attivare la modalità rapida, passa il flag --fast.

Puoi saltare convalide specifiche passando altri flag, descritti in gkectl check-config --help.

Traffico tra la workstation di amministrazione e le VM di test

In modalità predefinita, il controllo preflight crea VM di test per il cluster. Ogni VM di test esegue un server HTTP che ascolta sulla porta 443 e sulle porte dei nodi specificate nel file di configurazione.

Alle VM di test sono assegnati diversi indirizzi IP. Se il file di configurazione indica che i nodi del cluster riceveranno i propri indirizzi IP da un server DHCP, il controllo preflight utilizza un server DHCP per assegnare gli indirizzi IP alle VM di test. Se il file di configurazione indica che ai nodi del cluster verranno assegnati indirizzi IP statici, il controllo preflight assegna alle VM di test gli indirizzi IP statici specificati nei file di blocchi IP.

Il controllo preflight, in esecuzione sulla workstation di amministrazione, invia richieste HTTP alle VM di test utilizzando i vari indirizzi IP assegnati alle VM. Le richieste vengono inviate alla porta 443 e alle porte dei nodi specificate nel file di configurazione.

Quando devo eseguire i controlli preflight?

È una best practice eseguire i controlli preflight in anticipo e prima di tentare di creare i cluster. L'esecuzione anticipata dei controlli preflight può aiutarti a verificare di aver configurato correttamente l'ambiente vSphere e la rete.

Se utilizzi la versione 1.2.0-gke.6, esegui gkectl check-config due volte:

1. Esegui gkectl check-config --fast.

2. Esegui gkectl prepare.

3. Esegui di nuovo gkectl check-config, senza il flag --fast.

Il motivo per cui l'esecuzione viene eseguita due volte è che gkectl prepare carica il template VM per l'immagine sistema operativo del nodo del cluster nel tuo ambiente vSphere. Il modello di VM deve essere presente prima di eseguire l'intero set di convalide.

Nella versione 1.2.1 e successive, il comando check-config stesso carica il modello VM, in modo da poter eseguire l'intero set di convalide prima di eseguire gkectl prepare:

1. Esegui gkectl check-config, senza il flag --fast.

2. Esegui gkectl prepare.

I controlli preflight convalidano i valori che hai fornito al file. Non è necessario compilare tutti i campi del file di configurazione per eseguire i controlli preflight sul file. Puoi invece convalidare il file in modo iterativo man mano che compili i campi. Ad esempio, se vuoi convalidare solo la configurazione di vCenter, puoi compilare solo i campi vcenter ed eseguire i controlli su questi campi.

Tieni presente che la configurazione diventa immutabile dopo aver creato i cluster. L'esecuzione dei controlli preflight ti aiuta a scoprire e risolvere i problemi di configurazione prima di creare i cluster.

Conservazione della VM di test per il debug

A partire dalla versione 1.2.1, il comando gkectl check-config ha un flag --cleanup.

Quando gkectl check-config esegue un set completo di convalide, crea una VM di test e una chiave SSH associata. Se vuoi conservare la VM di test e la chiave SSH per il debug, imposta --cleanup su false.

Il valore predefinito di --cleanup è true.

Elenco dei controlli preflight

I controlli preflight convalidano ogni campo nel file di configurazione. Ecco i controlli attuali:

Categoria	Descrizione
File di configurazione	In genere, verifica che ogni campo e specifica abbia il formato e i valori previsti. Saltato con il flag --skip-validation-config. Salta la convalida del campo proxy con il flag --skip-validation-proxy.
Internet	Convalida l'accesso a internet ai domini richiesti. Convalida la configurazione del proxy in base alla posizione in cui esegui gkectl. Saltato con il flag --skip-validation-internet.
Immagine sistema operativo	Convalida l'esistenza delle immagini sistema operativo. Saltato con il flag --skip-validation-os-images.
Versione del sistema operativo Windows	Convalida la versione del sistema operativo Windows. Convalida che la versione di Windows sia supportata durante la creazione di workstation di amministrazione con lo strumento a riga di comando gkeadm. Tieni presente che, sebbene lo strumento gkeadm sia disponibile per Windows 10, Windows Server 2019 e Linux, non esiste un controllo preflight per Linux. Questa convalida inizia dalla versione di release 1.4.1.
Versione cluster	Convalida che la versione del cluster di amministrazione, la versione del cluster utente e la versione di gkectl corrispondano per la creazione e l'upgrade. Saltato con il flag --skip-validation-cluster-version.
Integrità del cluster	Verifica che il cluster di amministrazione o utente sia integro prima dell'upgrade: Cluster di amministrazione: il controllo include il servizio Kubernetes, lo stato dei componenti, i DaemonSet, i deployment, le macchine e i pod. Cluster utente: il controllo include il servizio Kubernetes, gli endpoint API del cluster, i set stateful, i deployment, i deployment delle macchine, le macchine e i pod. Saltato con il flag --skip-validation-cluster-health.
In entrata	Controlla se il cluster utente ha un oggetto Istio Gateway prima dell'upgrade.
IP riservato	Verifica che siano disponibili indirizzi IP sufficienti per la creazione e l'upgrade. Saltato con il flag --skip-validation-reserved-ips.
Google Cloud	ID progetto [*].projectid Convalida gli ID progetto forniti ai vari campi della configurazione. Se l'ID progetto non è presente, la convalida viene saltata. Registra account di servizio registerserviceaccountkeypath Convalida che il account di servizio disponga dei ruoli IAM richiesti. Convalida che le API richieste siano abilitate. Connetti account di servizio agentserviceaccountkeypath Convalida che il account di servizio disponga dei ruoli IAM richiesti. Convalida che le API richieste siano abilitate. Account di servizio Google Cloud Observability stackdriver.serviceaccountkeypath Convalida che il account di servizio disponga dei ruoli IAM richiesti. Convalida che le API richieste siano abilitate. Saltato con il flag --skip-validation-gcp.
Accedi a gcr.io/gke-on-prem-release	Convalida l'accesso al registry delle immagini container ospitato in Artifact Registry. Ignorato dal flag --skip-validation-docker.
Docker Registry	privateregistryconfig Se configurato, convalida l'accesso al registry Docker. Saltato con il flag --skip-validation-docker.
vCenter	Verifica che tutti i campi vcenter siano presenti e controlla anche quanto segue: Credenziali vcenter.credentials.[*] Convalida l'autenticazione al server vCenter utilizzando le credenziali utente fornite. Versione vSphere Convalida che le versioni di vCenter ed ESXi siano supportate. Data center vcenter.datacenter Convalida l'esistenza del data center vSphere. Datastore vcenter.datastore Convalida l'esistenza del datastore vSphere. Disco dati vcenter.datadisk Convalida che il disco della macchina virtuale (VMDK) vSphere non esista già in vSphere. Pool di risorse vcenter.resourcepool Verifica che il pool di risorse vSphere esista. Rete vcenter.network Convalida l'esistenza della rete vSphere. Saltato con il flag --skip-validation-infra.
Archiviazione	Driver CSI vSphere Verifica che il driver CSI vSphere sia abilitato se sono presenti PersistentVolume vSphere intree o CSI. In altre parole, nel file di configurazione del cluster utente, storage.vSphereCSIDisabled non è impostato su true. Parametri StorageClass Verifica che StorageClass non abbia nessuno dei seguenti parametri non supportati: hostfailurestotolerate forceprovisioning cachereservation diskstripes objectspacereservation iopslimit diskformat Se il tuo cluster ha StorageClass con uno dei parametri precedenti, potrebbe essere necessario eseguire la migrazione dei volumi. Per ulteriori informazioni, consulta Considerazioni per la migrazione dei volumi vSphere in-tree e la sezione sui problemi noti relativi agli upgrade nella versione 1.15. Annotazioni in PersistentVolume e PersistentVolumeClaim in-tree di vSphere creati staticamente Prima dell'upgrade, controlla le annotazioni nei PersistentVolume in-tree di vSphere e nei PersistentVolumeClaim di vSphere: I PersistentVolume in-tree di vSphere creati in modo statico hanno l'annotazione pv.kubernetes.io/provisioned-by: kubernetes.io/vsphere-volume I PersistentVolumeClaim di vSphere creati in modo statico hanno l'annotazione volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/vsphere-volume e volume.kubernetes.io/storage-provisioner: kubernetes.io/vsphere-volume Se il tuo cluster ha PersistentVolume in-tree vSphere o PersistentVolumeClaim vSphere senza queste annotazioni, devi annotare i PersistentVolume e i PersistentVolumeClaim prima di continuare. Consulta Considerazioni per la migrazione dei volumi vSphere in-tree.
Workload CSI	Convalida che il cluster possa eseguire correttamente un workload che utilizza un PersistentVolume di cui è stato eseguito il provisioning dinamico creato tramite il driver CSI vSphere. Questo controllo viene eseguito durante l'upgrade e solo se sono presenti volumi vSphere in-tree e nessun volume CSI vSphere. Questo controllo: Controlla che non siano rimaste risorse residue dalle esecuzioni precedenti della convalida. Trova o crea una classe StorageClass con il campo provisioner impostato su "csi.vsphere.vmware.com". Nei cluster utente, seleziona la classe di archiviazione CSI standard-rwo. Nei cluster di amministrazione, trova un oggetto StorageClass con il campo provisioner impostato su csi.vsphere.vmware.com. Se nel cluster non è presente un oggetto StorageClass di questo tipo, il test crea temporaneamente un nuovo oggetto StorageClass CSI e lo utilizza nel controllo. Crea un PersistentVolumeClaim nello spazio dei nomi predefinito utilizzando la StorageClass trovata o creata nel passaggio precedente e attende che il PersistentVolume creato dinamicamente sia nella fase Bound. Crea un job di scrittura nello spazio dei nomi predefinito montando il PersistentVolume creato sopra. Viene pianificato un pod writer che, all'avvio, scrive una stringa in un file nel file system montato. Elimina il job del writer e il pod associato. Crea un job di lettura nello spazio dei nomi predefinito montando il PersistentVolume creato sopra. Un pod del lettore viene pianificato e, all'avvio, legge il file scritto dal pod del writer, assicurandosi che i dati scritti dal pod del writer vengano letti correttamente. Elimina il job del lettore e il pod associato. Elimina l'oggetto PersistentVolumeClaim, di conseguenza viene eliminato anche l'oggetto PersistentVolume. Elimina la classe StorageClass se è stata creata durante il test.
Host per gruppi anti-affinità	Verifica che il numero di host vCenter fisici sia almeno tre se antiAffinityGroups è abilitato. Per disattivare antiAffinityGroups per un cluster, consulta antiAffinityGroups.enabled e questa nota di rilascio. Saltato con il flag --skip-validation-infra.
Bilanciatore del carico	Convalida la configurazione del bilanciamento del carico: Se la modalità di bilanciamento del carico è integrata (lbmode: Integrated), verifica che tutti i campi bigip siano presenti nelle specifiche admincluster e usercluster. Se la modalità di bilanciamento del carico è manuale (lbmode: Manual), verifica che tutti i campi manuallbspec siano presenti nelle specifiche admincluster e usercluster. Bilanciamento del carico integrato bigip.credentials.[*] Convalida le tue credenziali F5 BIG-IP. bigip.partition Convalida l'esistenza della partizione fornita. Ruolo utente F5 BIG-IP Verifica che l'utente F5 BIG-IP fornito abbia il ruolo di amministratore o amministratore delle risorse. bigip.vips.[*] Convalida i VIP forniti. Ignorato con i flag --fast o --skip-validation-load-balancer. Bilanciamento manuale del carico Configurazione della rete Convalida i VIP, gli IP dei nodi e così via. Ignorato con i flag --fast o --skip-validation-load-balancer. [*].manuallbspec.[*] Convalida le porte dei nodi fornite. Saltato con il flag --skip-validation-load-balancer.
Networking	Convalida la disponibilità degli intervalli CIDR, dei VIP e degli IP statici (se configurati) forniti. Verifica che gli indirizzi IP non si sovrappongano. Saltato con il flag --skip-validation-net-config.
DNS	Verifica che il server DNS fornito sia disponibile. Saltato con il flag --skip-validation-dns.
NTP	Verifica che il server NTP (Network Time Protocol) fornito sia disponibile. Saltato con il flag --skip-validation-tod.
VIP	Invia un ping ai VIP forniti. Questo controllo ha esito positivo se il ping non va a buon fine, indicando che il VIP previsto non è già occupato. Operazione ignorata con il flag --skip-validation-vips.
IP dei nodi	Invia un ping agli indirizzi IP dei nodi forniti. Questo controllo ha esito positivo se il ping non va a buon fine, a indicare che l'IP del nodo previsto non è già stato utilizzato. Ignorato con il flag --skip-validation-node-ips.

Risultati dei controlli preflight

I controlli preflight possono restituire i seguenti risultati:

SUCCESS

Il campo e il relativo valore hanno superato il controllo.

FAILURE

Il campo e/o il suo valore non hanno superato il controllo. Se un controllo restituisce un messaggio FAILURE, risolvi i problemi e convalida nuovamente il file.

IGNORATO

Il controllo è stato ignorato, probabilmente perché non è pertinente alla tua configurazione. Ad esempio, se utilizzi un server DHCP, i controlli per i DNS e gli IP dei nodi, pertinenti solo per una configurazione IP statica, vengono saltati.

Se passi un flag che salta una convalida, il controllo saltato non restituisce un risultato SKIPPED, ma la convalida non viene eseguita e non viene visualizzata nell'output comando.

SCONOSCIUTO

Il salto ha restituito un codice diverso da zero. Puoi considerare i risultati UNKNOWN come controlli non riusciti. UNKNOWN di solito indica che il controllo non è riuscito a eseguire un pacchetto di sistema, ad esempio non è riuscito a eseguire nslookup o gcloud.

Disponibile a breve

I seguenti controlli preflight verranno aggiunti in una release futura:

• Server NTP

Esecuzione dei controlli preflight

Esegui i controlli preflight con questo comando:

gkectl check-config --config [CONFIG]

dove [CONFIG] è il percorso del file di configurazione

Esecuzione in modalità veloce

Se preferisci, puoi eseguire i controlli preflight in "modalità rapida", che salta le convalide che creano VM di test temporanee, come le convalide del VIP di bilanciamento del carico e dell'IP del nodo. Per farlo, passa --fast:

gkectl check-config --config [CONFIG] --fast

Saltare convalide specifiche

Puoi passare i flag per saltare in modo granulare convalide specifiche, come DNS, proxy e networking. Ogni flag di salto è preceduto da --skip-[VALIDATION].

Per scoprire i flag di salto disponibili, esegui questo comando:

gkectl check-config --help

Ad esempio, per saltare le convalide del bilanciatore del carico:

gkectl check-config --config my-config.yaml --skip-validation-load-balancer 

Annullamento dei controlli preflight

Se hai iniziato a eseguire i controlli preflight e vuoi annullarli, premi CTRL + C due volte. Se un controllo preflight ha creato una VM di test, l'annullamento dovrebbe anche eseguire automaticamente la pulizia della VM.

Pulizia di una VM di test

Se una VM di test rimane dopo il completamento dei controlli preflight, puoi eliminarla da vCenter. Una VM di test ha un nome simile al seguente:

check-config-[dhcp|static]-[random number]

Per eliminare la VM:

1. Fai clic con il tasto destro del mouse sulla VM e poi su Alimentazione > Spegni.

2. Dopo aver spento la VM, fai di nuovo clic con il tasto destro del mouse sulla VM e poi su Elimina dal disco.

Esempio

Di seguito è riportato un esempio di output del comando. In questo esempio, la configurazione in fase di convalida utilizza la modalità di bilanciamento del carico integrata e gli IP statici senza un registry Docker esterno:

- Validation Category: Config Check
    - [SUCCESS] Config

- Validation Category: Internet Access
    - [SUCCESS] Internet access to required domains

- Validation Category: GCP
    - [SUCCESS] GCP Service
    - [SUCCESS] GCP Service Account

- Validation Category: Docker Registry
    - [SUCCESS] gcr.io/gke-on-prem-release access

- Validation Category: vCenter
    - [SUCCESS] Credentials
    - [SUCCESS] Version
    - [SUCCESS] Datacenter
    - [SUCCESS] Datastore
    - [SUCCESS] Data Disk
    - [SUCCESS] Resource Pool
    - [SUCCESS] Network
    - [SUCCESS] VSphere CSI Driver

- Validation Category: F5 BIG-IP
    - [SUCCESS] Admin Cluster F5 (credentials, partition and user role)
    - [SUCCESS] User Cluster F5 (credentials, partition and user role)

- Validation Category: Network Configuration
    - [SUCCESS] CIDR, VIP and static IP (availability and overlapping)

- Validation Category: DNS
    - [SUCCESS] DNS (availability)

- Validation Category: VIPs
    - [SUCCESS] ping (availability)

- Validation Category: Node IPs
    - [SUCCESS] ping (availability)

Now running slow validation checks. ...

Reusing VM template "gke-on-prem-osimage-xxx" that already exists in vSphere.
Creating test VMs with admin cluster configuration...  DONE
Waiting to get IP addresses from test VMs...  DONE
Waiting for test VMs to become ready...  DONE

Reusing VM template "gke-on-prem-osimage-xxx" that already exists in vSphere.
Creating test VMs with user cluster configuration...  DONE
Waiting to get IP addresses from test VMs...  DONE
Waiting for test VMs to become ready...  DONE

- Validation Category: F5 BIG-IP
    - [SUCCESS] Admin Cluster VIP and NodeIP
    - [SUCCESS] Admin Cluster F5 Access
    - [SUCCESS] User Cluster VIP and NodeIP
    - [SUCCESS] User Cluster F5 Access

- Validation Category: Internet Access
    - [SUCCESS] Internet access to required domains

- Validation Category: vCenter on test VMs
    - [SUCCESS] Test VM: VCenter Access and Permission

- Validation Category: DNS on test VMs
    - [SUCCESS] Test VM: DNS Availability

- Validation Category: TOD on test VMs
    - [SUCCESS] Test VM: TOD Availability

- Validation Category: Docker Registry
    - [SUCCESS] gcr.io/gke-on-prem-release access

Deleting test VMs with admin cluster configuration...  DONE
Deleting test VMs with user cluster configuration...  DONE

Problemi noti

• Per la versione 1.3.0-gke.16:

  Devi eseguire controlli di convalida rapidi, gkectl check-config --fast, per i controlli preflight se si applicano entrambe le seguenti condizioni:

  1. Hai configurato Google Distributed Cloud per l'utilizzo di un proxy.

  2. Hai installato uno dei seguenti bundle:

     • Il bundle /var/lib/gke/bundles/gke-onprem-vsphere-1.3.0-gke.16.tgz dalla pagina Download.
     • Il bundle /var/lib/gke/bundles/gke-onprem-vsphere-1.3.0-gke.16.tgz dalla workstation di amministrazione.

  Puoi eseguire l'intero set di convalide solo se hai installato il bundle completo. Ad esempio: /var/lib/gke/bundles/gke-onprem-vsphere-1.3.0-gke.16-full.tgz

• Per la versione 1.2.0-gke.6:

  Se utilizzi pool di risorse nidificati o il pool di risorse predefinito, gkectl check-config non riesce quando tenti di eseguire un set completo di convalide. Tuttavia, puoi eseguire un insieme più piccolo di convalide passando il flag --fast.

  gkectl check-config --config [CONFIG] --fast

Passaggi successivi

• Crea un cluster di amministrazione
• Crea un cluster utente