Esecuzione dei controlli preflight

Questo documento fornisce informazioni sui controlli preflight eseguiti quando crei o aggiorni un cluster in Google Distributed Cloud (solo software) per e VMware.

Rivedi 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. Controlli preflight lato server regole firewall aggiuntive. Nel Regole firewall per i cluster di amministrazione, cerca "Controlli preflight" e assicurati che tutte le regole firewall obbligatorie siano configurato.

gkectl check-config in esecuzione

Se prevedi di creare cluster utilizzando gkectl, esegui gkectl create-config per generare un file di configurazione. Il file di configurazione avvia l'installazione: si forniscono informazioni sull'ambiente vSphere, sulla rete e sul carico e l'aspetto desiderato dei cluster. Puoi generare un di configurazione del deployment prima o dopo la creazione di una workstation di amministrazione. Per determinati controlli per superare questi controlli devono essere eseguiti dalla workstation di amministrazione.

Dopo aver modificato il file per soddisfare le esigenze del tuo ambiente e di cluster, lo utilizzerai per creare i tuoi cluster nell'ambiente on-prem.

Prima di creare cluster utilizzando gkectl, esegui Da gkectl check-config a convalidare il file di configurazione con vari controlli preflight. Se il comando restituisce messaggi FAILURE, risolvi i problemi e convalidare nuovamente il file. Se una determinata convalida delle caratteristiche restituisce un avviso WARNING messaggi, devi risolvere i problemi sottostanti prima di poter utilizzare quella funzionalità.

Modalità di controllo preflight e possibilità di ignorare le convalide

gkectl check-config dispone di 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 di con le convalide, che possono richiedere più tempo.

  • In modalità veloce, il comando ignora i controlli che creano VM di test ed esegue solo controlli rapidi. Abiliti la modalità veloce passando il flag --fast.

Puoi saltare convalide specifiche passando da altri flag descritti a 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 in ascolto sulla porta 443 sulle porte del nodo specificate nel file di configurazione.

Alle VM di test vengono assegnati diversi indirizzi IP. Se il tuo file di configurazione indica che i nodi del cluster riceveranno gli indirizzi IP da un protocollo DHCP di destinazione, il controllo preflight utilizza un server DHCP per assegnare gli indirizzi IP le VM di test. Se il file di configurazione indica che i nodi del cluster indirizzi IP statici, il controllo preflight assegna indirizzi IP statici che hai specificato nel tuo File dei blocchi IP alle VM di test.

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

Quando devo eseguire i controlli preflight?

Come best practice, conviene eseguire i controlli preflight in anticipo e prima di tentare per la creazione dei cluster. Eseguire in anticipo i controlli preflight può aiutarti a verificare 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 della doppia esecuzione è che gkectl prepare carica il modello di VM dell'immagine del sistema operativo del nodo del cluster nell'ambiente vSphere. Il modello VM deve essere prima di eseguire l'intero set di convalide.

Nella versione 1.2.1 e successive, la VM viene caricata dal comando check-config 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 devi è necessario compilare ogni campo del file di configurazione per eseguire i controlli preflight rispetto al file; puoi invece convalidare il file in modo iterativo mentre lo compili i suoi campi. Ad esempio, se vuoi solo convalidare il tuo vCenter configurazione, puoi compilare solo i campi vcenter ed eseguire controlli rispetto quelli.

Ricorda che la configurazione diventa immutabile dopo la creazione cluster. L'esecuzione dei controlli preflight ti consente di scoprire e risolvere i problemi nel tuo prima di creare i cluster.

Preservazione della VM di test per il debug

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

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

Il valore predefinito di --cleanup è true.

Elenco dei controlli preflight

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

Categoria Descrizione
File di configurazione

In genere verifica che ogni campo e ogni specifica abbia i il formato e i valori previsti.

Ignorato con --skip-validation-config flag.

Ignora campo proxy convalida con flag --skip-validation-proxy.

Internet

Convalida l'accesso a internet per i domini richiesti. Convalida il proxy in base a dove viene eseguito gkectl.

Azione saltata con il flag --skip-validation-internet.

Immagine sistema operativo

Convalida l'esistenza delle immagini del sistema operativo.

Azione saltata con il flag --skip-validation-os-images.

Versione del sistema operativo Windows

Convalida la versione del sistema operativo Windows.

Verifica che la versione 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 è previsto alcun controllo preflight per Linux. Questa convalida inizia dalla versione 1.4.1.

Versione cluster

Verifica che la versione del cluster di amministrazione, la versione del cluster utente e gkectl versione corrispondente per la creazione e l'upgrade.

Azione saltata con il flag --skip-validation-cluster-version.

Integrità del cluster

Verifica che il cluster di amministrazione o il cluster utente sia integro prima dell'upgrade:

  • Cluster di amministrazione: il controllo include servizio Kubernetes, stato dei componenti, DaemonSet, di deployment, macchine e pod.
  • Cluster utente: il controllo include servizio Kubernetes, endpoint API del cluster, StatefulSet, deployment, deployment di macchine, macchine e pod.

Azione saltata con il flag --skip-validation-cluster-health.

In entrata Controlla se il cluster utente ha un oggetto Gateway Istio prima dell'upgrade.
IP riservato

Verifica che sia disponibile un numero sufficiente di indirizzi IP per la creazione upgrade.

Azione saltata con il flag --skip-validation-reserved-ips.

Google Cloud
ID progetto
[*].projectid
Convalida gli ID progetto forniti ai vari campi nella configurazione. Se l'ID progetto non è presente, la convalida è saltata.
Registra account di servizio
registerserviceaccountkeypath
Convalida che l'account di servizio contenga i valori richiesti i ruoli IAM. Verifica che le API richieste siano in un bucket con il controllo delle versioni attivo.
Connetti account di servizio
agentserviceaccountkeypath
Convalida che l'account di servizio contenga i valori richiesti i ruoli IAM. Verifica che le API richieste siano in un bucket con il controllo delle versioni attivo.
Account di servizio Google Cloud Observability
stackdriver.serviceaccountkeypath
Convalida che l'account di servizio contenga i valori richiesti i ruoli IAM. Verifica che le API richieste siano in un bucket con il controllo delle versioni attivo.
Azione saltata con il flag --skip-validation-gcp.
Accedi a gcr.io/gke-on-prem-release Convalida l'accesso al registro delle immagini container ospitato in e Container Registry.

Ignorato da --skip-validation-docker flag.

Registro Docker
privateregistryconfig
Se configurato, convalida l'accesso al Docker Registry.

Azione saltata con il flag --skip-validation-docker.

vCenter Controlla che tutti i campi vcenter siano presenti e verifica quanto segue:
Credenziali
vcenter.credentials.[*]
Convalida l'autenticazione in vCenter Server utilizzando credenziali utente.
Versione vSphere Convalida che versioni di vCenter ed ESXi sono supportati.
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 vSphere (VMDK) non esiste già in vSphere.
Pool di risorse
vcenter.resourcepool
Convalida l'esistenza del pool di risorse vSphere.
Rete
vcenter.network
Convalida l'esistenza della rete vSphere.

Azione saltata con il flag --skip-validation-infra.

Archiviazione
Driver CSI vSphere Verifica che il driver CSI vSphere sia abilitato se presente sono oggetti PersistentVolume intree o CSI vSphere. Vale a dire che nel file di configurazione del cluster utente, storage.vSphereCSIDisabled non è impostato su true.
Parametri StorageClass

Convalida che l'oggetto StorageClass non abbia seguenti parametri non supportati:

  • hostfailurestotolerate
  • provisioning forzato
  • prenotazione della cache
  • dischi
  • objectspacereservation
  • iopslimit
  • formatodisco

Se il tuo cluster presenta StorageClass con uno qualsiasi dei valori precedenti potrebbe essere necessario eseguire la migrazione dei volumi.

Per ulteriori informazioni, vedi Considerazioni sulla migrazione dei volumi vSphere In-Tree e la sezione relativa ai problemi noti sugli upgrade della versione 1.15.

Annotazioni in PersistentVolume e PersistentVolumeClaim in vSphere creati in modo statico

Prima dell'upgrade, controlla le annotazioni negli oggetti PersistentVolume in-tree di vSphere e vSphere PersistentVolumeClaim:

  • Gli oggetti PersistentVolume in-tree vSphere creati in modo statico presentano l'annotazione pv.kubernetes.io/provisioned-by: kubernetes.io/vsphere-volume
  • Gli oggetti vSphere PersistentVolumesClaim creati in modo statico presentano l'annotazione volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/vsphere-volume e volume.kubernetes.io/storage-provisioner: kubernetes.io/vsphere-volume

Se il cluster dispone di oggetti PersistentVolume in-tree vSphere o vSphere PersistentVolumeClaim senza queste annotazioni, devi annotare gli oggetti PersistentVolume gli oggetti PersistentVolumeClaim prima di continuare, Considerazioni per la migrazione dei volumi vSphere In-Tree.

Carico di lavoro CSI

Convalida che il cluster possa eseguire un carico di lavoro che utilizza un PersistentVolume di cui viene eseguito attraverso il driver CSI vSphere.

Questo controllo viene eseguito durante l'upgrade e solo se ci sono volumi vSphere in-tree e nessun volume CSI vSphere.

Questo controllo:

  1. Controlla che non siano rimaste risorse in sospeso da le esecuzioni precedenti della convalida.
  2. Trova o crea un oggetto StorageClass con il campo provisioner impostato su il campo provisioner impostato su "csi.vsfera.vmware.com".
    1. Nei cluster utente seleziona StorageClass CSI standard-rwo.
    2. Nei cluster di amministrazione trova un oggetto StorageClass con il campo provisioner impostato su csi.vsphere.vmware.com. Se questo oggetto StorageClass non è presente nel cluster, il test crea temporaneamente un nuovo oggetto StorageClass CSI e lo utilizza nel controllo.
  3. Crea un oggetto PersistentVolumeClaim nello spazio dei nomi predefinito utilizzando l'oggetto StorageClass trovato o creato nel passaggio precedente e attende il PersistentVolume creato dinamicamente per essere nella fase Bound.
  4. Crea un job writer nello spazio dei nomi predefinito installando il PersistentVolume creato sopra. Un pod dello scrittore è pianificato e all'avvio scrive una stringa in un file nel file system montato.
  5. Abbattere il job dello scrittore e il pod associato.
  6. Crea un job del lettore nello spazio dei nomi predefinito installando il PersistentVolume creato sopra. Un reader Pod è pianificato e all'avvio legge il file scritto dal pod dello writer, assicurandosi che che i dati scritti dal pod dello writer vengano letti correttamente.
  7. Distrugge il job del lettore e il pod associato.
  8. Abbattere l'oggetto PersistentVolumeClaim, di conseguenza viene eliminato anche il PersistentVolume.
  9. Elimina StorageClass se è stato creato durante il test.

Host per gruppi anti-affinità

Verifica che il numero di host vCenter fisici sia almeno tre se antiAffinityGroups è abilitato.

Per disabilitare antiAffinityGroups per un cluster, consulta antiAffinityGroups.enabled e questo può portare nota di rilascio.

Azione saltata 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 nel Specifiche admincluster e usercluster.
  • Se la modalità di bilanciamento del carico è manuale (lbmode: Manual), verifica che tutti i campi manuallbspec siano presenti in Specifiche admincluster e usercluster.
Bilanciamento del carico integrato
bigip.credentials.[*] Convalida le credenziali BIG-IP di F5.
bigip.partition Convalida l'esistenza della partizione fornita.
Ruolo utente BIG-IP F5 Verifica che l'utente BIG-IP F5 fornito contenga il Amministratore o Amministratore risorse.
bigip.vips.[*] Convalida i VIP forniti.

Azione saltata con --fast o --skip-validation-load-balancer flag.

Bilanciamento del carico manuale
Configurazione della rete Convalida VIP, IP dei nodi ecc.

Ignorato con --fast o --skip-validation-load-balancer e i flag facoltativi.

[*].manuallbspec.[*] Convalida le porte del nodo fornite.
Azione saltata con il flag --skip-validation-load-balancer.
Networking

Verifica che gli intervalli CIDR, i VIP e gli IP statici forniti (se configurate) sono disponibili. Controlla che gli indirizzi IP non si sovrappongano.

Azione saltata con il flag --skip-validation-net-config.

DNS

Convalida la disponibilità del server DNS fornito.

Azione saltata con il flag --skip-validation-dns.

NTP

Convalida la disponibilità del server NTP (Network Time Protocol) fornito.

Azione saltata 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, a indicare che il VIP previsto non è già in uso.

Ignorato con --skip-validation-vips flag.

IP dei nodi

Invia un ping agli indirizzi IP del nodo forniti. Questo controllo ha esito positivo se non riesce, il che indica che l'IP del nodo previsto non è già in uso.

Ignorato con --skip-validation-node-ips flag.

Risultati del controllo 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 relativo valore non hanno superato il controllo. Se un controllo restituisce un FAILURE, correggi i problemi e convalida di nuovo il file.
IGNORATO

La verifica è stata saltata, probabilmente perché l'assegno non è pertinente al tuo configurazione. Ad esempio, se utilizzi un server DHCP, verifica la presenza di I controlli DNS e degli IP dei nodi, relativi solo a una configurazione IP statico, vengono ignorati.

Se superi un flag che salta una convalida, il controllo ignorato non restituisce un risultato IGNORATO; la convalida non viene eseguita e non viene visualizzata nell'output comando.

SCONOSCIUTO

Lo skip ha restituito un codice diverso da zero. Puoi considerare UNKNOWN risultati come controlli non superati. UNKNOWN indica di solito che non è stato possibile eseguire il controllo un pacchetto di sistema, ad esempio l'impossibilità di eseguire nslookup o l'impossibilità di eseguire gcloud.

Disponibile a breve

I seguenti controlli preflight verranno aggiunti in una release futura:

  • Server NTP

Esecuzione dei controlli preflight

Puoi eseguire i controlli preflight con il comando seguente:

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à veloce" che ignora il convalide che creano VM temporanee di test, come il VIP con bilanciamento del carico convalide degli IP dei nodi. Per farlo, inserisci --fast:

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

Ignorare convalide specifiche

Puoi passare i flag per saltare in modo granulare convalide specifiche, come DNS, proxy e networking. Ogni flag di abbandono ha il prefisso --skip-[VALIDATION].

Per saperne di più sui flag di abbandono disponibili, esegui questo comando. Se vuoi, consulta il riferimento gkectl check-config:

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 in corso...

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

Pulizia di una VM di test

Se rimane una VM di test dopo il completamento dei controlli preflight, puoi eliminare VM di 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 fai clic su Alimentazione > Spegni

  2. Quando la VM è stata spenta, fai di nuovo clic con il tasto destro del mouse sulla VM e fai clic su Elimina dal disco.

Esempio

Di seguito è riportato un esempio dell'output del comando. In questo esempio, la configurazione in fase di convalida utilizza la modalità di bilanciamento del carico integrato e IP senza un Docker Registry 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 rapida, gkectl check-config --fast, per 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:

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

    Puoi eseguire un set completo di convalida solo se hai installato l'intero bundle. 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 ha esito negativo quando tenti di eseguire un set completo di convalide. Tuttavia, puoi eseguire un insieme più ridotto di convalide passando il flag --fast.

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

Passaggi successivi