Preflight-Prüfungen werden ausgeführt

Auf dieser Seite wird erläutert, wie Sie Preflight-Prüfungen für Ihre GKE on VMware-Konfigurationsdatei ausführen.

Überblick

Während der Installation führen Sie gkectl create-config aus, um eine Konfigurationsdatei für GKE on VMware zu generieren. Die Konfigurationsdatei steuert Ihre Installation: Sie stellen Informationen zu Ihrer vSphere-Umgebung, Ihrem Netzwerk und Ihrem Load-Balancer sowie zur gewünschten Clusterkonfiguration bereit. Sie können eine Konfigurationsdatei vor oder nach der Erstellung einer Administrator-Workstation anlegen. Damit bestimmte Prüfungen erfolgreich sind, müssen sie auf der Administrator-Workstation ausgeführt werden.

Nachdem Sie die Datei an die Anforderungen Ihrer Umgebung und Ihrer Cluster angepasst haben, verwenden Sie die Datei, um Ihre Cluster in Ihrer lokalen Umgebung zu erstellen.

Bevor Sie Cluster erstellen, führen Sie gkectl check-config aus, um die Konfigurationsdatei mithilfe mehrerer Preflight-Prüfungen zu validieren. Wenn der Befehl FAILURE-Meldungen zurückgibt, beheben Sie die Probleme und validieren Sie die Datei noch einmal. Wenn eine bestimmte Funktionsvalidierung Benachrichtigungen zurückgibt, müssen Sie die zugrunde liegenden Probleme beheben, bevor Sie diese Funktion verwenden können.

Preflight-Prüfmodi und Validierungen überspringen

gkectl check-config hat einen Standardmodus und einen Schnellmodus:

  • Im Standardmodus validiert der Befehl jedes Feld umfassend. Außerdem erstellt der Standardmodus temporäre virtuelle Maschinen (VMs) von vSphere als Teil seiner Validierungen, was mehr Zeit in Anspruch nehmen kann.

  • Im Schnellmodus überspringt der Befehl Prüfungen, die Test-VMs erstellen, und führt nur die schnellen Prüfungen aus. Wenn Sie das Flag --fast übergeben, wird der Schnellmodus aktiviert.

Sie können bestimmte Validierungen überspringen. Übergeben Sie dazu andere Flags, die unter gkectl check-config --help beschrieben werden.

Traffic zwischen der Administrator-Workstation und den Test-VMs

Im Standardmodus erstellt die Preflight-Prüfung Test-VMs für den Cluster. Jede Test-VM führt einen HTTP-Server aus, der Port 443 und Knotenports überwacht, die Sie in Ihrer Konfigurationsdatei angegeben haben.

Den Test-VMs sind mehrere IP-Adressen zugewiesen. Wenn Sie in Ihrer Konfigurationsdatei angegeben haben, dass Ihre Clusterknoten ihre IP-Adressen von einem DHCP-Server abrufen, verwendet die Preflight-Prüfung einen DHCP-Server, um den Test-VMs IP-Adressen zuzuweisen. Wenn Sie in Ihrer Konfigurationsdatei festgelegt haben, dass Ihren Clusterknoten statische IP-Adressen zugewiesen werden, dann weist die Preflight-Prüfung den Test-VMs statische IP-Adressen zu, die Sie in Ihren IP-Blockdateien angegeben haben.

Die Preflight-Prüfung, die auf der Administrator-Workstation ausgeführt wird, sendet HTTP-Anfragen an die Test-VMs unter Verwendung der verschiedenen IP-Adressen, die den VMs zugewiesen sind. Die Anfragen werden an Port 443 und an die Knotenports gesendet, die Sie in Ihrer Konfigurationsdatei angegeben haben.

Wann sollte ich Preflight-Prüfungen ausführen?

Sie sollten Preflight-Prüfungen früh und noch vor dem Erstellen von Clustern ausführen. Wenn Sie Preflight-Prüfungen frühzeitig ausführen, können Sie prüfen, ob Sie Ihre vSphere-Umgebung und Ihr Netzwerk korrekt konfiguriert haben.

Wenn Sie GKE on VMware Version 1.2.0-gke.6 verwenden, führen Sie gkectl check-config zweimal aus:

  1. Führen Sie gkectl check-config --fast aus.

  2. Führen Sie gkectl prepare aus.

  3. Führen Sie gkectl check-config noch einmal ohne das Flag --fast aus.

Der Grund für die zweimalige Ausführung ist, dass gkectl prepare die VM-Vorlage für das Betriebssystem-Image des Clusterknotens in Ihre vSphere-Umgebung hochlädt. Diese VM-Vorlage muss vorhanden sein, bevor Sie alle Validierungen ausführen können.

In GKE on VMware Version 1.2.1 und höher lädt der Befehl check-config selbst die VM-Vorlage hoch, sodass Sie alle Validierungen ausführen können, bevor Sie gkectl prepare ausführen:

  1. Führen Sie gkectl check-config ohne das Flag --fast aus.

  2. Führen Sie gkectl prepare aus.

Die Preflight-Prüfungen validieren die Werte, die Sie der Datei angegeben haben. Sie müssen nicht jedes Feld in der Konfigurationsdatei ausgefüllt haben, um Preflight-Prüfungen für die Datei durchzuführen. Vielmehr können Sie die Datei beim Ausfüllen ihrer Felder iterativ validieren. Wenn Sie beispielsweise nur Ihre vCenter-Konfiguration validieren möchten, können Sie nur die vcenter-Felder ausfüllen und Prüfungen für diese ausführen.

Die Konfiguration von GKE on VMware kann nach dem Erstellen der Cluster nicht mehr geändert werden. Durch Ausführen von Preflight-Prüfungen können Sie Probleme in Ihrer Konfiguration erkennen und beheben, bevor Sie Cluster erstellen.

Test-VM für das Debugging beibehalten

Ab GKE on VMware Version 1.2.1 hat der Befehl gkectl check-config das Flag --cleanup.

Wenn gkectl check-config einen vollständigen Satz von Validierungen durchführt, werden eine Test-VM und ein zugehöriger SSH-Schlüssel erstellt. Wenn Sie die Test-VM und den SSH-Schlüssel für Debugging-Zwecke beibehalten möchten, setzen Sie --cleanup auf "false".

Der Standardwert von --cleanup ist "true".

Liste der Preflight-Prüfungen

Die Preflight-Prüfungen validieren jedes Feld in der Konfigurationsdatei. Dies sind die aktuellen Überprüfungen:

Kategorie Beschreibung
Konfigurationsdatei

Validiert allgemein, dass jedes Feld und jede Spezifikation das erwartete Format und die erwarteten Werte aufweist.

Übersprungen mit dem Flag --skip-validation-config.

Überspringen Sie die Validierung des Feldes proxy mit dem Flag --skip-validation-proxy.

Internet

Prüft den Internetzugriff auf erforderliche Domains. Prüft die Proxykonfiguration hinsichtlich des Orts, an dem Sie gkectl ausführen.

Übersprungen mit dem Flag --skip-validation-internet.

Betriebssystem-Image

Überprüft, ob Betriebssystem-Images vorhanden sind.

Übersprungen mit dem Flag --skip-validation-os-images.

Windows-Betriebssystemversion

Prüft die Windows-Betriebssystemversion.

Überprüft, ob die Windows-Version beim Erstellen von Administrator-Workstations mit dem gkeadm-Befehlszeilentool unterstützt wird. Beachten Sie, dass das Tool gkeadm zwar für Windows 10, Windows Server 2019 und Linux verfügbar ist, für Linux jedoch keine Preflight-Prüfung vorhanden ist. Diese Validierung ist ab Version 1.4.1 verfügbar.

Clusterversion

Prüft, ob die Version des Administratorclusters, die Version des Nutzerclusters und die gkectl-Version zur Erstellung und zum Upgrade übereinstimmen.

Übersprungen mit dem Flag --skip-validation-cluster-version.

Clusterintegrität

Validiert vor dem Upgrade, dass der Administrator- oder Nutzercluster fehlerfrei ist:

  • Administratorcluster: Die Prüfung umfasst den Kubernetes-Dienst, den Komponentenstatus, die DaemonSets, Deployments, Maschinen und Pods.
  • Nutzercluster: Die Prüfung umfasst den Kubernetes-Dienst, Cluster-API-Endpunkte, StatefulSets, Deployments, Maschinenbereitstellungen, Maschinen und Pods.

Übersprungen mit dem Flag --skip-validation-cluster-health.

Eingehender Traffic Prüft, ob der Nutzercluster vor dem Upgrade ein Istio-Gateway-Objekt hat.
Reservierte IP

Prüft, ob genügend IP-Adressen zum Erstellen und zum Upgrade verfügbar sind.

Übersprungen mit dem Flag --skip-validation-reserved-ips.

Google Cloud
Projekt-ID
[*].projectid
Prüft die Projekt-IDs, die in verschiedenen Felder in der Konfiguration angegeben werden. Wenn die Projekt-ID fehlt, wird die Validierung übersprungen.
Dienstkonto registrieren
registerserviceaccountkeypath
Prüft, ob das Dienstkonto die erforderlichen IAM-Rollen enthält. Validiert, dass die erforderlichen APIs aktiviert sind.
Dienstkonto verbinden
agentserviceaccountkeypath
Prüft, ob das Dienstkonto die erforderlichen IAM-Rollen enthält. Validiert, dass die erforderlichen APIs aktiviert sind.
Google Cloud-Dienstkonto für Beobachtbarkeit
stackdriver.serviceaccountkeypath
Prüft, ob das Dienstkonto die erforderlichen IAM-Rollen enthält. Validiert, dass die erforderlichen APIs aktiviert sind.
Übersprungen mit dem Flag --skip-validation-gcp.
Zugriff auf gcr.io/gke-on-prem-release Prüft den Zugriff auf die Container-Image-Registry von GKE on VMware, die in Container Registry gehostet wird.

Übersprungen vom Flag --skip-validation-docker.

Docker-Registry
privateregistryconfig
Validiert den Zugriff auf die Docker-Registry, falls konfiguriert.

Übersprungen mit dem Flag --skip-validation-docker.

vCenter Prüft, ob alle vcenter-Felder vorhanden sind, und prüft außerdem Folgendes:
Anmeldedaten
vcenter.credentials.[*]
Prüft die Authentifizierung bei dem vCenter-Server mithilfe der angegebenen Nutzeranmeldedaten.
vSphere-Version Prüft, ob die Versionen von vCenter und ESXi unterstützt werden.
Rechenzentrum
vcenter.datacenter
Prüft das Vorhandensein des vSphere-Rechenzentrums.
Datastore
vcenter.datastore
Prüft, ob der vSphere-Datenspeicher vorhanden ist.
Datenlaufwerk
vcenter.datadisk
Validiert, dass das virtuelle VM-Laufwerk (VMDK) von vSphere nicht bereits in vSphere vorhanden ist.
Ressourcenpool
vcenter.resourcepool
Prüft, ob der vSphere-Ressourcenpool vorhanden ist.
Netzwerk
vcenter.network
Prüft das Vorhandensein des vSphere-Netzwerks.

Übersprungen mit dem Flag --skip-validation-infra.

Speicher
vSphere-CSI-Treiber Prüft, ob der vSphere-CSI-Treiber aktiviert ist, wenn integrierte oder CSI vSphere-Volumes vorhanden sind. Das heißt, in der Konfigurationsdatei des Nutzerclusters ist storage.vSphereCSIDisabled nicht auf true festgelegt.
Speicherklasse-Parameter

Validiert, dass die Speicherklasse keinen der folgenden nicht unterstützten Parameter enthält:

  • Hostfailurestolerate
  • Bereitstellung erzwingen
  • Cachereservation
  • Disktrips
  • Objektraumreservierung
  • iopslimit
  • Laufwerkformat

Wenn Ihr Cluster Speicherklassen mit einem der vorherigen Parameter hat, kann dies bedeuten, dass Sie Ihre Volumes migrieren müssen.

Weitere Informationen finden Sie unter Überlegungen zur Migration von In-Tree-vSphere-Volumes und im Abschnitt zu bekannten Problemen bei Upgrades in 1.15.

Annotationen in statisch erstelltem vSphere-In-Tree-Objekt und -VolumeClaims

Prüfen Sie vor dem Upgrade die Annotationen in integrierten vSphere-Volumes und vSphere PersistentClaims:

  • Die statisch erstellten integrierten vSphere-Volumes haben die Annotation pv.kubernetes.io/provisioned-by: kubernetes.io/vsphere-volume
  • Die statisch erstellten vSphere-Persistents-Claims haben die Annotationen volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/vsphere-volume und volume.kubernetes.io/storage-provisioner: kubernetes.io/vsphere-volume.

Wenn in Ihrem Cluster vSphere integrierte vSphere- oder vSphere-Volumes ohne diese Annotationen vorhanden sind, müssen Sie diese annotieren, bevor Sie fortfahren. Weitere Informationen finden Sie unter Überlegungen zur Migration von vSphere-Volumes im Baum.

CSI-Arbeitslast

Validiert, dass der Cluster erfolgreich eine Arbeitslast ausführen kann, die ein dynamisch bereitgestelltes nichtflüchtiges Volume verwendet, das über den vSphere CSI-Treiber erstellt wurde.

Diese Prüfung wird während des Upgrades und nur dann ausgeführt, wenn es integrierte vSphere-Volumes und keine vSphere-CSI-Volumes gibt.

Bei dieser Prüfung wird Folgendes überprüft:

  1. Prüft, ob aus vorherigen Ausführungen der Validierung keine Ressourcen mehr vorhanden sind.
  2. Findet oder erstellt eine Speicherklasse, wobei das Bereitsteller-Feld auf das Bereitsteller-Feld auf „csi.vsphere.vmware.com“ gesetzt ist.
    1. In Nutzerclustern wird die CSI-Speicherklasse standard-rwo ausgewählt.
    2. In Administratorclustern wird eine Speicherklasse gefunden, bei der das Feld für den Bereitsteller auf csi.vsphere.vmware.com gesetzt ist. Wenn eine solche Speicherklasse im Cluster nicht vorhanden ist, erstellt der Test vorübergehend eine neue CSI-Speicherklasse und verwendet sie für die Prüfung.
  3. Erstellt im Standard-Namespace mit der im vorherigen Schritt gefundenen oder erstellten Speicherklasse einen nichtflüchtiger Speicher und wartet, bis sich das dynamisch erstellte nichtflüchtige Volume in der Phase Bound befindet.
  4. Erstellt einen Schreibjob im Standard-Namespace, der das oben erstellte nichtflüchtige Volumen bereitstellt. Ein Schreiber-Pod wird geplant und schreibt beim Start einen String in eine Datei im bereitgestellten Dateisystem.
  5. Fährt den Schreiberjob und den zugehörigen Pod herunter.
  6. Erstellt einen Reader-Job im Standard-Namespace, der das oben erstellte StatefulSet bereitstellt. Ein Lese-Pod wird geplant und liest beim Start die vom Schreib-Pod geschriebene Datei, um sicherzustellen, dass die vom Schreiber-Pod geschriebenen Daten erfolgreich gelesen werden.
  7. Fährt den Reader-Job und den zugehörigen Pod herunter.
  8. Löscht das nichtflüchtige Speichermedium, sodass es ebenfalls gelöscht wird.
  9. Löscht die Speicherklasse, wenn sie während des Tests erstellt wurde.

Hosts für Anti-Affinitätsgruppen

Prüft, ob die Anzahl der physischen vCenter-Hosts mindestens drei beträgt, wenn antiAffinityGroups aktiviert ist.

Informationen zum Deaktivieren von antiAffinityGroups für einen Cluster finden Sie unter antiAffinityGroups.enabled und in diesem Versionshinweis.

Übersprungen mit dem Flag --skip-validation-infra.

Load-Balancer

Prüft die Load-Balancing-Konfiguration:

  • Bei Load-Balancing im integrierten Modus (lbmode: Integrated), wird geprüft, ob alle bigip-Felder in den Spezifikationen admincluster und usercluster vorhanden sind.
  • Bei Load-Balancing im manuellen Modus (lbmode: Manual), wird geprüft, ob alle manuallbspec-Felder in den Spezifikationen admincluster und usercluster vorhanden sind.
Integriertes Load-Balancing
bigip.credentials.[*] Prüft Ihre F5 BIG-IP-Anmeldedaten.
bigip.partition Prüft, ob die bereitgestellte Partition vorhanden ist.
F5 BIG-IP-Nutzerrolle Prüft, ob der angegebene F5 BIG-IP-Nutzer die Rolle "Administrator" oder "Ressourcenadministrator" hat.
bigip.vips.[*] Prüft die angegebenen VIPs.

Übersprungen mit dem Flag --fast oder --skip-validation-load-balancer.

Manuelles Load-Balancing
Netzwerkkonfiguration Validiert VIPs, Knoten-IP-Adressen usw.

Übersprungen mit dem Flag --fast oder --skip-validation-load-balancer.

[*].manuallbspec.[*] Prüft die angegebenen Knotenports.
Übersprungen mit dem Flag --skip-validation-load-balancer.
Netzwerk

Prüft, ob die angegebenen CIDR-Bereiche, VIPs und statischen IP-Adressen (falls konfiguriert) verfügbar sind. Prüft, ob sich die IP-Adressen nicht überschneiden.

Übersprungen mit dem Flag --skip-validation-net-config.

DNS

Prüft, ob der bereitgestellte DNS-Server verfügbar ist.

Übersprungen mit dem Flag --skip-validation-dns.

NTP

Prüft, ob der angegebene NTP-Server (Network Time Protocol) verfügbar ist.

Übersprungen mit dem Flag --skip-validation-tod.

VIPs

Sendet Pings an die VIPs. Diese Prüfung ist erfolgreich, wenn der Ping fehlschlägt, was darauf hinweist, dass die VIP nicht bereits verwendet wird.

Übersprungen mit dem Flag --skip-validation-vips.

Knoten-IP-Adressen

Pingt die angegebenen Knoten-IP-Adressen an. Diese Prüfung ist erfolgreich, wenn der Ping fehlschlägt. Dies zeigt an, dass die Knoten-IP-Adresse nicht bereits verwendet wird.

Übersprungen mit dem Flag --skip-validation-node-ips.

Ergebnisse der Preflight-Prüfung

Preflight-Prüfungen können folgende Ergebnisse liefern:

ERFOLGREICH
Das Feld und sein Wert haben die Prüfung bestanden.
FEHLER
Das Feld und/oder sein Wert haben die Prüfung nicht bestanden. Wenn eine Prüfung eine FAILURE-Nachricht zurückgibt, beheben Sie die Probleme und prüfen Sie die Datei noch einmal.
ÜBERSPRUNGEN

Die Prüfung wurde übersprungen, wahrscheinlich weil sie für Ihre Konfiguration nicht relevant ist. Wenn Sie beispielsweise einen DHCP-Server verwenden, werden Prüfungen für DNS- und Knoten-IP-Adressen, die nur für eine statische IP-Konfiguration relevant sind, übersprungen.

Wenn Sie ein Flag übergeben, das eine Validierung überspringt, gibt die übersprungene Prüfung nicht das Ergebnis ÜBERSPRUNGEN zurück. Stattdessen wird die Validierung nicht ausgeführt und erscheint überhaupt nicht in der Befehlsausgabe.

UNBEKANNT

Beim Überspringen wurde ein Code ungleich null zurückgegeben. Unbekannte Ergebnisse können als fehlgeschlagene Prüfungen angesehen werden. UNBEKANNT bedeutet in der Regel, dass bei der Prüfung ein Systempaket nicht ausgeführt werden konnte, z. B. wenn nslookup oder gcloud nicht ausgeführt werden konnte.

Demnächst verfügbar

Die folgenden Preflight-Prüfungen werden in einem zukünftigen Release hinzugefügt:

  • NTP-Server

Preflight-Prüfungen ausführen

Führen Sie mit dem folgenden Befehl Preflight-Prüfungen aus:

gkectl check-config --config [CONFIG]

Dabei ist [CONFIG] der Pfad zu Ihrer GKE on VMware-Konfigurationsdatei.

Im Schnellmodus ausführen

Sie können die Preflight-Prüfungen auch im "Schnellmodus" ausführen. Dadurch werden die Validierungen übersprungen, die temporäre Test-VMs erstellen, z. B. die Validierung der Load-Balancing-VIPs und der Knoten-IPs. Übergeben Sie dazu --fast:

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

Bestimmte Validierungen überspringen

Sie können Flags detailliert übergeben, um bestimmte Validierungen, wie DNS, Proxy und Netzwerke, zu überspringen. Jedes Flag zum Überspringen hat das Präfix --skip-[VALIDATION].

Führen Sie den folgenden Befehl aus, um mehr über die verfügbaren Flags zum Überspringen zu erfahren. Sehen Sie sich optional die Referenz zu gkectl check-config an:

gkectl check-config --help

So überspringen Sie beispielsweise die Load-Balancer-Validierungen:

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

Preflight-Prüfungen abbrechen

Wenn Sie mit der Durchführung von Preflight-Prüfungen begonnen haben und diese abbrechen möchten, drücken Sie zweimal Strg + C. Wenn eine Preflight-Prüfung eine Test-VM erstellt hat, sollte die VM ebenfalls automatisch gelöscht werden.

Test-VM bereinigen

Wenn eine Test-VM noch vorhanden ist, nachdem die Preflight-Prüfungen abgeschlossen sind, können Sie die VM aus vCenter löschen. Eine Test-VM hat den folgenden Namen:

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

So löschen Sie die VM:

  1. Klicken Sie mit der rechten Maustaste auf die VM und wählen Sie Power > Power Off aus.

  2. Nachdem die VM ausgeschaltet wurde, klicken Sie noch einmal mit der rechten Maustaste auf die VM und klicken Sie auf Delete from Disk.

Beispiel

Unten sehen Sie ein Beispiel für die Ausgabe des Befehls. In diesem Beispiel verwendet die validierte Konfiguration einen Load-Balancer im integrierten Modus und statische IP-Adressen ohne externe Docker-Registry:

- 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

Bekannte Probleme

  • Bei Version 1.3.0-gke.16:

    Sie müssen schnelle Validierungsprüfungen (gkectl check-config --fast) für Ihre Preflight-Prüfungen ausführen, wenn die beiden folgenden Bedingungen zutreffen:

    1. Sie haben GKE on VMware für die Verwendung eines Proxys konfiguriert.

    2. Sie haben eines der folgenden Bundles installiert:

      • Das /var/lib/gke/bundles/gke-onprem-vsphere-1.3.0-gke.16.tgz-Bundle von der Downloadseite.
      • Das /var/lib/gke/bundles/gke-onprem-vsphere-1.3.0-gke.16.tgz-Bundle von der Administrator-Workstation.

    Sie können den vollständigen Validierungssatz nur ausführen, wenn Sie das vollständige Bundle installiert haben. Beispiel: /var/lib/gke/bundles/gke-onprem-vsphere-1.3.0-gke.16-full.tgz

  • Für Version 1.2.0-gke.6:

    Wenn Sie verschachtelte Ressourcenpools oder den Standardressourcenpool verwenden, schlägt gkectl check-config fehl, wenn Sie versuchen, einen vollständigen Satz von Validierungen durchzuführen. Sie können jedoch einen kleineren Satz von Validierungen ausführen. Übergeben Sie dazu das Flag --fast.

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

Nächste Schritte