Bekannte Probleme mit GKE on VMware

Auf dieser Seite werden alle bekannten Probleme von GKE on VMware aufgeführt. Um die bekannten Probleme nach einer Produktversion oder Kategorie zu filtern, wählen Sie die gewünschten Filter aus den folgenden Drop-down-Menüs aus.

Wählen Sie Ihre GKE on VMware-Version aus:

Wählen Sie die Problemkategorie aus:

Sie können auch nach Ihrem Problem suchen:

Kategorie Erkannte Version(en) Problem und Problemumgehung
Installation, Betriebssystem 1.28.0–1.28.500, 1.29.0

IP-Adresse der Docker-Brücke verwendet 172.17.0.1/16 für Knoten der Steuerungsebene des COS-Clusters

GKE on VMware gibt in der Docker-Konfiguration das dedizierte Subnetz --bip=169.254.123.1/24 für die IP-Adresse der Docker-Brücke an, damit das 172.17.0.1/16-Standardsubnetz nicht reserviert wird. In den Versionen 1.28.0–1.28.500 und 1.29.0 wurde der Docker-Dienst jedoch nicht neu gestartet, nachdem die Docker-Konfiguration von GKE on VMware aufgrund einer Regression im COS OS-Image angepasst wurde. Daher wählt Docker die Standardeinstellung 172.17.0.1/16 als Subnetz der Bridge-IP-Adresse aus. Dies kann zu einem IP-Adresskonflikt führen, wenn Sie bereits eine Arbeitslast in diesem IP-Adressbereich ausführen.

Workaround:

Sie müssen den Docker-Dienst neu starten, um dieses Problem zu umgehen:

sudo systemctl restart docker

Prüfen Sie, ob Docker die richtige Brücken-IP-Adresse nutzt:

ip a | grep docker0

Diese Lösung bleibt bei der Neuerstellung von VMs nicht erhalten. Sie müssen diese Problemumgehung immer dann anwenden, wenn VMs neu erstellt werden.
update 1.28.0–1.28.400, 1.29.0

Die Verwendung mehrerer Netzwerkschnittstellen mit Standard-CNI funktioniert nicht

Die CNI-Standard-Binärdateien bridge, ipvlan, vlan, macvlan, dhcp, tuning, host-local, ptp, portmap sind nicht in den Betriebssystem-Images der betroffenen Versionen enthalten. Diese CNI-Binärprogramme werden von der Datenebene v2 nicht verwendet, können aber für zusätzliche Netzwerkschnittstellen in der Funktion für mehrere Netzwerkschnittstellen verwendet werden.

Mehrere Netzwerkschnittstellen mit diesen CNI-Plug-ins funktionieren nicht.

Workaround:

Führen Sie ein Upgrade auf die Version mit der Fehlerkorrektur durch, wenn Sie diese Funktion verwenden.
update 1,15, 1,16, 1,28

Netapp-trident-Abhängigkeiten beeinträchtigen den vSphere-CSI-Treiber

Bei der Installation von multipathd auf Clusterknoten wird der vSphere-CSI-Treiber beeinträchtigt, was dazu führt, dass Nutzerarbeitslasten nicht gestartet werden können.

Workaround:

  • multipathd deaktivieren
Updates 1,15; 1,16

Der Webhook des Administratorclusters blockiert möglicherweise Updates, wenn Sie erforderliche Konfigurationen hinzufügen

Wenn einige erforderliche Konfigurationen im Administratorcluster leer sind, da Validierungen übersprungen wurden, wird das Hinzufügen dieser Konfigurationen möglicherweise vom Webhook des Administratorclusters blockiert. Wenn beispielsweise das Feld gkeConnect nicht in einem vorhandenen Administratorcluster festgelegt wurde, kann beim Hinzufügen mit dem Befehl gkectl update admin die folgende Fehlermeldung angezeigt werden:

admission webhook "vonpremadmincluster.onprem.cluster.gke.io" denied the request: connect: Required value: GKE connect is required for user clusters

Workaround:

  • Führen Sie für 1.15-Administratorcluster den Befehl gkectl update admin mit dem Flag --disable-admin-cluster-webhook aus. Beispiel: 
            gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --disable-admin-cluster-webhook
  • Führen Sie für 1.16-Administratorcluster gkectl update admin-Befehle mit dem Flag --force aus. Beispiel: 
            gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --force
Konfiguration 1.15.0–1.15.10, 1.16.0–1.16.6, 1.28.0–1.28.200

Das Feld controlPlaneNodePort ist standardmäßig 30968, wenn die manualLB-Spezifikation leer ist

Wenn Sie einen manuellen Load-Balancer verwenden (loadBalancer.kind ist auf "ManualLB" gesetzt), sollten Sie den Abschnitt loadBalancer.manualLB in der Konfigurationsdatei nicht für einen Hochverfügbarkeits-Administratorcluster in den Versionen 1.16 und höher konfigurieren müssen. Wenn dieser Abschnitt jedoch leer ist, weist GKE on VMware allen NodePorts, einschließlich manualLB.controlPlaneNodePort, Standardwerte zu. Dies führt dazu, dass die Clustererstellung mit der folgenden Fehlermeldung fehlschlägt:

- Validation Category: Manual LB
  - [FAILURE] NodePort configuration: manualLB.controlPlaneNodePort must
   not be set when using HA admin cluster, got: 30968

Workaround:

Geben Sie in der Konfiguration des Administratorclusters manualLB.controlPlaneNodePort: 0 für den Hochverfügbarkeits-Administratorcluster an:

loadBalancer:
  ...
  kind: ManualLB
  manualLB:
    controlPlaneNodePort: 0
  ...
Speicher 1.28.0-1.28.100

nfs-common fehlt im Ubuntu-Betriebssystem-Image

nfs-common fehlt im Ubuntu-Betriebssystem-Image, was bei Kunden mit NFS-abhängigen Treibern wie NetApp Probleme verursachen kann.

Wenn das Log nach dem Upgrade auf 1.28 einen Eintrag wie den folgenden enthält, sind Sie von diesem Problem betroffen: 
Warning FailedMount 63s (x8 over 2m28s) kubelet MountVolume.SetUp failed for volume "pvc-xxx-yyy-zzz" : rpc error: code = Internal desc = error mounting NFS volume 10.0.0.2:/trident_pvc_xxx-yyy-zzz on mountpoint /var/lib/kubelet/pods/aaa-bbb-ccc/volumes/kubernetes.io~csi/pvc-xxx-yyy-zzz/mount: exit status 32".

Workaround:

Prüfen Sie, ob Ihre Knoten Pakete von Canonical herunterladen können.

Wenden Sie als Nächstes das folgende DaemonSet auf Ihren Cluster an, um nfs-common zu installieren:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: install-nfs-common
  labels:
    name: install-nfs-common
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: install-nfs-common
  minReadySeconds: 0
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 100%
  template:
    metadata:
      labels:
        name: install-nfs-common
    spec:
      hostPID: true
      hostIPC: true
      hostNetwork: true
      initContainers:
      - name: install-nfs-common
        image: ubuntu
        imagePullPolicy: IfNotPresent
        securityContext:
          privileged: true
        command:
        - chroot
        - /host
        - bash
        - -c
        args:
        - |
          apt install -y nfs-common
        volumeMounts:
        - name: host
          mountPath: /host
      containers:
      - name: pause
        image: gcr.io/gke-on-prem-release/pause-amd64:3.1-gke.5
        imagePullPolicy: IfNotPresent
      volumes:
      - name: host
        hostPath:
          path: /
Speicher 1.28.0-1.28.100

In der Konfigurationsvorlage des Administratorclusters fehlt das Speicherrichtlinienfeld

SPBM in Administratorclustern wird ab Version 1.28.0 unterstützt. In der Vorlage für die Konfigurationsdatei fehlt jedoch das Feld vCenter.storagePolicyName.

Workaround:

Fügen Sie das Feld „vCenter.storagePolicyName“ in die Konfigurationsdatei des Administratorclusters ein, wenn Sie die Speicherrichtlinie für den Administratorcluster konfigurieren möchten. Eine Anleitung dazu instructions.
Logging und Monitoring 1.28.0-1.28.100

VPC-SC wird von der Kubernetes Metadata API nicht unterstützt

Die kürzlich hinzugefügte API „kubernetesmetadata.googleapis.com“ unterstützt VPC-SC nicht. Das führt dazu, dass der Agent, der Metadaten erhebt, diese API unter VPC-SC nicht erreichen kann. Danach fehlen die Metadatenlabels der Messwerte.

Workaround:

Legen Sie im Namespace „kube-system“ die Antwortvorlage „Stackdriver“ fest und setzen Sie das Feld „featureGates.disableExperimentalMetadataAgent“ auf „true“, indem Sie folgenden Befehl ausführen:

`kubectl -n kube-system patch stackdriver stackdriver -p '{"spec":{"featureGates":{"disableExperimentalMetadataAgent":true}}}'`

und dann ausführen

`kubectl -n kube-system patch deployment stackdriver-operator -p '{"spec":{"template":{"spec":{"containers":[{"name":"stackdriver-operator","env":[{"name":"ENABLE_LEGACY_METADATA_AGENT","value":"true"}]}]}}}}'`

Upgrades und Updates 1.15.0–1.15.7, 1.16.0–1.16.4, 1.28.0

Der clusterapi-Controller kann abstürzen, wenn der Administratorcluster und ein Nutzercluster mit aktiviertem ControlPlane V2 unterschiedliche vSphere-Anmeldedaten verwenden.

Wenn ein Administratorcluster und ein Nutzercluster mit aktiviertem ControlPlane V2 unterschiedliche vSphere-Anmeldedaten verwenden, z.B. nach dem Aktualisieren der vSphere-Anmeldedaten für den Administratorcluster, kann der clusterapi-Controller nach dem Neustart möglicherweise keine Verbindung zu vCenter herstellen. Log des Clustersapi-Controllers ansehen, der im Namespace „kube-system“ des Administratorclusters ausgeführt wird

kubectl logs -f -l component=clusterapi-controllers -c vsphere-controller-manager \
    -n kube-system --kubeconfig KUBECONFIG
Wenn das Log einen Eintrag wie den folgenden enthält, sind Sie von diesem Problem betroffen: 
E1214 00:02:54.095668       1 machine_controller.go:165] Error checking existence of machine instance for machine object gke-admin-node-77f48c4f7f-s8wj2: Failed to check if machine gke-admin-node-77f48c4f7f-s8wj2 exists: failed to find datacenter "VSPHERE_DATACENTER": datacenter 'VSPHERE_DATACENTER' not found

Workaround:

Aktualisieren Sie vSphere-Anmeldedaten, damit der Administratorcluster und alle Nutzercluster mit aktiviertem Controlplane V2 dieselben vSphere-Anmeldedaten verwenden.

Logging und Monitoring 1,14

etcd: hohe Anzahl fehlgeschlagener GRPC-Anfragen in Prometheus Alert Manager

Prometheus kann Benachrichtigungen ähnlich wie die folgenden melden:

Alert Name: cluster:gke-admin-test1: Etcd cluster kube-system/kube-etcd: 100% of requests for Watch failed on etcd instance etcd-test-xx-n001.

Mit den folgenden Schritten können Sie prüfen, ob diese Benachrichtigung ein falsch positives Ergebnis ist, der ignoriert werden kann:

  1. Vergleichen Sie den unbearbeiteten Messwert grpc_server_handled_total mit dem in der Benachrichtigung angegebenen grpc_method. Prüfen Sie in diesem Beispiel das Label grpc_code auf Watch.

    Sie können diesen Messwert mithilfe von Cloud Monitoring mit der folgenden MQL-Abfrage prüfen: 
    fetch
    k8s_container | metric 'kubernetes.io/anthos/grpc_server_handled_total' | align rate(1m) | every 1m
  2. Eine Benachrichtigung für alle Codes außer OK kann ignoriert werden, wenn der Code nicht einer der folgenden ist: 
    Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded

Workaround:

Prüfen Sie die folgenden Optionen, um Prometheus so zu konfigurieren, dass diese falsch positiven Benachrichtigungen ignoriert werden:

  1. Über die Benutzeroberfläche des Benachrichtigungsmanagers können Sie die Benachrichtigung stummschalten.
  2. Wenn die Benachrichtigung nicht stummgeschaltet werden kann, führen Sie die folgenden Schritte aus, um falsch positive Ergebnisse zu unterdrücken:
    1. Skalieren Sie den Monitoring-Operator auf 0-Replikate herunter, damit die Änderungen beibehalten werden können.
    2. Ändern Sie die prometheus-config-Configmap und fügen Sie grpc_method!="Watch" der etcdHighNumberOfFailedGRPCRequests-Benachrichtigungskonfiguration hinzu, wie im folgenden Beispiel gezeigt:
      • Original: 
        rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code!="OK",job=~".*etcd.*"}[5m])
      • Geändert: 
        rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code=~"Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded",grpc_method!="Watch",job=~".*etcd.*"}[5m])
        Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Clusters.
    3. Starten Sie Prometheus und Alertmanager Statefulset neu, um die neue Konfiguration zu übernehmen.
  3. Wenn der Code in einen der problematischen Fälle fällt, prüfen Sie das etcd-Log und das kube-apiserver-Log, um weitere Fehlerbehebungen durchzuführen.
Netzwerk 1.16.0–1.16.2, 1.28.0

Langlebige NAT-Verbindungen für ausgehenden Traffic werden getrennt

Ausgehende NAT-Verbindungen können 5 bis 10 Minuten nach dem Aufbau einer Verbindung unterbrochen werden, wenn kein Traffic vorhanden ist.

Da der Conntrack nur in der eingehenden Richtung (externe Verbindungen zum Cluster) wichtig ist, tritt dieses Problem nur auf, wenn die Verbindung eine Zeit lang keine Informationen überträgt und dann die Zielseite etwas überträgt. Wenn der ausgehende NAT-Pod die Nachrichten immer instanziiert, tritt dieses Problem nicht auf.

Dieses Problem tritt auf, weil die automatische Speicherbereinigung versehentlich Conntrack-Einträge entfernt, die der Daemon für ungenutzt hält. Vor Kurzem wurde eine vorgelagerte Korrektur in anetd integriert, um das Verhalten zu korrigieren.


Workaround:

Es gibt keine einfache Problemumgehung. Wir haben in Version 1.16 keine entsprechenden Probleme festgestellt. Wenn Sie feststellen, dass langlebige Verbindungen aufgrund dieses Problems unterbrochen werden, können Sie das Problem umgehen, indem Sie eine Arbeitslast auf demselben Knoten wie die IP-Adresse des ausgehenden Traffics verwenden oder konsistent Nachrichten über die TCP-Verbindung senden.
Vorgang 1,14, 1,15, 1,16

Der CSR-Signer ignoriert spec.expirationSeconds beim Signieren von Zertifikaten

Wenn Sie eine CertificateSigningRequest (CSR) mit expirationSeconds erstellen, wird expirationSeconds ignoriert.

Workaround:

Wenn Sie von diesem Problem betroffen sind, können Sie Ihren Nutzercluster aktualisieren. Fügen Sie dazu disableNodeIDVerificationCSRSigning: true in die Konfigurationsdatei des Nutzerclusters ein und führen Sie den Befehl gkectl update cluster aus, um den Cluster mit dieser Konfiguration zu aktualisieren.
Netzwerk, Upgrades und Updates 1.16.0-1.16.3

Die Validierung des Nutzercluster-Load-Balancers für disable_bundled_ingress schlägt fehl

Wenn Sie versuchen, gebündelten eingehenden Traffic für einen vorhandenen Cluster zu deaktivieren, schlägt der Befehl gkectl update cluster mit einem Fehler wie im folgenden Beispiel fehl:

[FAILURE] Config: ingress IP is required in user cluster spec

Dieser Fehler tritt auf, weil gkectl während Preflight-Prüfungen nach einer eingehenden IP-Adresse des Load-Balancers sucht. Obwohl diese Prüfung beim Deaktivieren von gebündeltem eingehenden Traffic nicht erforderlich ist, schlägt die Preflight-Prüfung gkectl fehl, wenn disableBundledIngress auf true gesetzt ist.


Workaround:

Verwenden Sie den Parameter --skip-validation-load-balancer, wenn Sie den Cluster aktualisieren, wie im folgenden Beispiel gezeigt:

gkectl update cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG  \
  --skip-validation-load-balancer

Weitere Informationen finden Sie unter Gebündelten eingehenden Traffic für einen vorhandenen Cluster deaktivieren.
Upgrades und Updates 1.13, 1.14, 1.15.0–1.15.6

Administratorcluster-Updates schlagen nach CA-Rotation fehl

Wenn Sie die CA-Zertifikate des Administratorclusters rotieren, schlagen nachfolgende Versuche, den Befehl gkectl update admin auszuführen, fehl. Der zurückgegebene Fehler sieht in etwa so aus:

failed to get last CARotationStage: configmaps "ca-rotation-stage" not found

Workaround:

Wenn Sie von diesem Problem betroffen sind, können Sie Ihren Administratorcluster mithilfe des Flags --disable-update-from-checkpoint mit dem Befehl gkectl update admin aktualisieren:

gkectl update admin --config ADMIN_CONFIG_file \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --disable-update-from-checkpoint

Wenn Sie das Flag --disable-update-from-checkpoint verwenden, verwendet der Update-Befehl während der Clusteraktualisierung nicht die Checkpoint-Datei als „Source of Truth“. Die Checkpoint-Datei wird weiterhin für die zukünftige Verwendung aktualisiert.
Speicher 1.15.0–1.15.6, 1.16.0–1.16.2

Preflight-Prüfung der CSI-Arbeitslast schlägt aufgrund eines Pod-Startfehlers fehl

Während Preflight-Prüfungen installiert die CSI-Arbeitslastvalidierungsprüfung einen Pod im Namespace default. Der CSI-Arbeitslast-Pod prüft, ob der vSphere-CSI-Treiber installiert ist und dynamische Volume-Bereitstellung ausführen kann. Wenn dieser Pod nicht gestartet wird, schlägt die CSI-Arbeitslastvalidierungsprüfung fehl.

Es gibt einige bekannte Probleme, die verhindern können, dass dieser Pod gestartet wird:

  • Wenn für den Pod keine Ressourcenlimits angegeben sind, was bei einigen Clustern mit installierten Zulassungs-Webhooks der Fall ist, wird der Pod nicht gestartet.
  • Wenn Anthos Service Mesh im Cluster installiert ist und die automatische Istio-Sidecar-Injektion im Namespace default aktiviert ist, wird der CSI-Arbeitslast-Pod nicht gestartet.

Wenn der CSI-Arbeitslast-Pod nicht gestartet wird, wird während der Preflight-Validierungen ein Zeitlimitfehler wie der folgende angezeigt:

- [FAILURE] CSI Workload: failure in CSIWorkload validation: failed to create writer Job to verify the write functionality using CSI: Job default/anthos-csi-workload-writer-<run-id> replicas are not in Succeeded phase: timed out waiting for the condition

Prüfen Sie, ob der Fehler durch zu wenige festgelegte Pod-Ressourcen verursacht wird. Führen Sie dazu den folgenden Befehl aus, um den Jobstatus anthos-csi-workload-writer-<run-id> zu prüfen:

kubectl describe job anthos-csi-workload-writer-<run-id>

Wenn die Ressourcenlimits für den CSI-Arbeitslast-Pod nicht ordnungsgemäß festgelegt sind, enthält der Jobstatus eine Fehlermeldung wie die folgende:

CPU and memory resource limits is invalid, as it are not defined for container: volume-tester

Wenn der CSI-Arbeitslast-Pod aufgrund einer Istio-Sidecar-Einfügung nicht gestartet wird, können Sie die automatische Istio-Sidecar-Einfügung im Namespace default vorübergehend deaktivieren. Prüfen Sie die Labels des Namespace und löschen Sie mit dem folgenden Befehl das Label, das mit istio.io/rev beginnt:

kubectl label namespace default istio.io/rev-

Wenn der Pod falsch konfiguriert ist, prüfen Sie manuell, ob die dynamische Bereitstellung von Volumes mit dem vSphere-CSI-Treiber funktioniert:

  1. Erstellen Sie einen PVC, der die Speicherklasse standard-rwo verwendet.
  2. Erstellen Sie einen Pod, der den PVC verwendet.
  3. Prüfen Sie, ob der Pod Daten auf dem Volume lesen/schreiben kann.
  4. Entfernen Sie den Pod und den PVC, nachdem Sie den ordnungsgemäßen Betrieb überprüft haben.

Wenn die dynamische Volume-Bereitstellung mit dem vSphere-CSI-Treiber funktioniert, führen Sie gkectl diagnose oder gkectl upgrade mit dem Flag --skip-validation-csi-workload aus, um die CSI-Arbeitslastprüfung zu überspringen.

Vorgang 1.16.0-1.16.2

Zeitüberschreitungen für die Aktualisierung von Nutzerclustern bei Administratorclusterversion 1.15

Wenn Sie bei einer vom Nutzer verwalteten Administratorworkstation angemeldet sind, kann es durch den Befehl gkectl update cluster zu einer Zeitüberschreitung kommen und der Nutzercluster kann nicht aktualisiert werden. Dies geschieht, wenn die Administratorclusterversion 1.15 ist und Sie gkectl update admin vor dem gkectl update cluster ausführen. Wenn dieser Fehler auftritt, wird der folgende Fehler angezeigt, wenn Sie versuchen, den Cluster zu aktualisieren: 

      Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition

Während der Aktualisierung eines Administratorclusters mit Version 1.15 wird die validation-controller, die die Preflight-Prüfungen auslöst, aus dem Cluster entfernt. Wenn Sie dann versuchen, den Nutzercluster zu aktualisieren, bleibt die Preflight-Prüfung, bis das Zeitlimit erreicht ist.

Workaround:

  1. Führen Sie den folgenden Befehl aus, um validation-controller noch einmal bereitzustellen: 
          gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
  2. Führen Sie nach Abschluss der Vorbereitung gkectl update cluster noch einmal aus, um den Nutzercluster zu aktualisieren
Vorgang 1.16.0-1.16.2

Zeitüberschreitungen beim Erstellen von Nutzerclustern, wenn die Administratorclusterversion 1.15 ist

Wenn Sie bei einer vom Nutzer verwalteten Administratorworkstation angemeldet sind, kann es durch den Befehl gkectl create cluster zu einer Zeitüberschreitung kommen und der Nutzercluster kann nicht erstellt werden. Dies geschieht, wenn die Version des Administratorclusters 1.15 ist. Wenn dieser Fehler auftritt, wird beim Erstellen des Clusters der folgende Fehler angezeigt: 

      Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition

Da die validation-controller in 1.16 hinzugefügt wurde, fehlt bei Verwendung des 1.15-Administratorclusters die validation-controller, die zum Auslösen der Preflight-Prüfungen verantwortlich ist. Daher bleiben beim Erstellen eines Nutzerclusters die Preflight-Prüfungen hängen, bis das Zeitlimit erreicht ist.

Workaround:

  1. Führen Sie den folgenden Befehl aus, um validation-controller bereitzustellen: 
          gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
  2. Führen Sie nach Abschluss der Vorbereitung gkectl create cluster noch einmal aus, um den Nutzercluster zu erstellen
Upgrades und Updates 1.16.0-1.16.2

Das Aktualisieren oder Upgrade des Administratorclusters schlägt fehl, wenn die Projekte oder Standorte von Add-on-Diensten nicht übereinstimmen

Wenn Sie einen Administratorcluster von Version 1.15.x auf 1.16.x upgraden oder beim Aktualisieren eines Administratorclusters eine connect-, stackdriver-, cloudAuditLogging- oder gkeOnPremAPI-Konfiguration hinzufügen, wird der Vorgang möglicherweise vom Administratorcluster-Webhook abgelehnt. Eine der folgenden Fehlermeldungen wird angezeigt:

  • "projects for connect, stackdriver and cloudAuditLogging must be the same when specified during cluster creation."
  • "locations for connect, gkeOnPremAPI, stackdriver and cloudAuditLogging must be in the same region when specified during cluster creation."
  • "locations for stackdriver and cloudAuditLogging must be the same when specified during cluster creation."

Für die Aktualisierung oder das Upgrade eines Administratorclusters muss onprem-admin-cluster-controller den Administratorcluster in einer Art Cluster abgleichen. Wenn der Status des Administratorclusters im Typcluster wiederhergestellt wird, kann der Administratorcluster-Webhook nicht erkennen, ob das Objekt OnPremAdminCluster zum Erstellen eines Administratorclusters vorgesehen ist oder Vorgänge für eine Aktualisierung oder ein Upgrade fortgesetzt werden soll. Einige Validierungen, die nur die Erstellung betreffen, werden bei unerwarteten Aktualisierungen und Upgrades aufgerufen.


Workaround:

Fügen Sie dem Objekt OnPremAdminCluster die Annotation onprem.cluster.gke.io/skip-project-location-sameness-validation: true hinzu:

  1. Bearbeiten Sie die Clusterressource onpremadminclusters: 
    kubectl edit onpremadminclusters ADMIN_CLUSTER_NAME -n kube-system –kubeconfig ADMIN_CLUSTER_KUBECONFIG
    Ersetzen Sie Folgendes:
    • ADMIN_CLUSTER_NAME: der Name des Administratorclusters.
    • ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters.
  2. Fügen Sie die Annotation onprem.cluster.gke.io/skip-project-location-sameness-validation: true hinzu und speichern Sie die benutzerdefinierte Ressource.
  3. Führen Sie je nach Typ der Administratorcluster einen der folgenden Schritte aus:
    • Für Nicht-HA-Administratorcluster mit einer Checkpoint-Datei:Fügen Sie den Parameter disable-update-from-checkpoint im Aktualisierungsbefehl oder den Parameter „disable-upgrade-from-checkpoint“ im Upgradebefehl hinzu. Diese Parameter werden nur bei der nächsten Ausführung des Befehls update oder upgrade benötigt: 
      • gkectl update admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --disable-update-from-checkpoint

      • gkectl upgrade admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --disable-upgrade-from-checkpoint
    • Für Hochverfügbarkeits-Administratorcluster oder eine Checkpoint-Datei ist deaktiviert: Aktualisieren oder führen Sie ein Upgrade des Administratorclusters wie gewohnt durch. Für die Aktualisierungs- oder Upgradebefehle sind keine zusätzlichen Parameter erforderlich.
Vorgang 1.16.0-1.16.2

Der Nutzercluster kann nicht gelöscht werden, wenn eine vom Nutzer verwaltete Administratorworkstation verwendet wird

Wenn Sie bei einer vom Nutzer verwalteten Administratorworkstation angemeldet sind, kann es durch den Befehl gkectl delete cluster zu einer Zeitüberschreitung kommen und der Nutzercluster kann nicht gelöscht werden. Dies geschieht, wenn Sie gkectl zuerst auf der vom Nutzer verwalteten Workstation ausgeführt haben, um den Nutzercluster zu erstellen, zu aktualisieren oder zu aktualisieren. Wenn dieser Fehler auftritt, wird beim Löschen des Clusters der folgende Fehler angezeigt: 

      failed to wait for user cluster management namespace "USER_CLUSTER_NAME-gke-onprem-mgmt"
      to be deleted: timed out waiting for the condition

Während des Löschens werden zuerst alle zugehörigen Objekte eines Clusters gelöscht. Das Löschen der Validierungsobjekte, die beim Erstellen, Aktualisieren oder Upgraden erstellt wurden, bleibt in der Löschphase. Dies geschieht, da ein Finaler das Löschen des Objekts blockiert, wodurch das Löschen des Clusters fehlschlägt.

Workaround:

  1. Rufen Sie die Namen aller Validierungsobjekte ab: 
             kubectl  --kubeconfig ADMIN_KUBECONFIG get validations \
           -n USER_CLUSTER_NAME-gke-onprem-mgmt
  2. Führen Sie für jedes Validierungsobjekt den folgenden Befehl aus, um den Finalizer aus dem Validierungsobjekt zu entfernen: 
          kubectl --kubeconfig ADMIN_KUBECONFIG patch validation/VALIDATION_OBJECT_NAME \
        -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge

    Nachdem der Finalizer aus allen Validierungsobjekten entfernt wurde, werden die Objekte entfernt und der Löschvorgang des Nutzerclusters automatisch abgeschlossen. Sie müssen nichts weiter tun.

Netzwerk 1,15; 1,16

Ausgehender NAT-Gateway-Traffic zu externem Server schlägt fehl

Wenn sich der Quell-Pod und der Ausgangs-NAT-Gateway-Pod auf zwei verschiedenen Worker-Knoten befinden, kann der Traffic vom Quell-Pod keine externen Dienste erreichen. Wenn sich die Pods auf demselben Host befinden, ist die Verbindung zum externen Dienst oder zur externen Anwendung erfolgreich.

Dieses Problem wird dadurch verursacht, dass vSphere VXLAN-Pakete löscht, wenn die Tunnelaggregation aktiviert ist. Es gibt ein bekanntes Problem mit NSX und VMware, das aggregierten Traffic nur über bekannte VXLAN-Ports (4789) sendet.


Workaround:

Ändern Sie den von Cilium verwendeten VXLAN-Port zu 4789:

  1. Bearbeiten Sie die ConfigMap cilium-config:
    kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
  2. Fügen Sie der ConfigMap cilium-config Folgendes hinzu:
    tunnel-port: 4789
  3. Starten Sie das anetd-DaemonSet neu: 
    kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

Diese Problemumgehung wird bei jedem Upgrade des Clusters rückgängig gemacht. Sie müssen sie nach jedem Upgrade neu konfigurieren. VMware muss das Problem in vSphere beheben, um es dauerhaft zu beheben.
Upgrades 1.15.0-1.15.4

Das Upgrade eines Administratorclusters mit aktivierter Always-on-Secret-Verschlüsselung schlägt fehl

Das Upgrade des Administratorclusters von 1.14.x auf 1.15.x mit aktivierter Always-On-Secret-Verschlüsselung schlägt aufgrund einer Diskrepanz zwischen dem Controller-generierten Verschlüsselungsschlüssel und dem Schlüssel, der auf dem Administrator-Master-Datenlaufwerk bestehen bleibt, fehl. Die Ausgabe von gkectl upgrade admin enthält die folgende Fehlermeldung: 

      E0926 14:42:21.796444   40110 console.go:93] Exit with error:
      E0926 14:42:21.796491   40110 console.go:93] Failed to upgrade the admin cluster: failed to create admin cluster: failed to wait for OnPremAdminCluster "admin-cluster-name" to become ready: failed to wait for OnPremAdminCluster "admin-cluster-name" to be ready: error: timed out waiting for the condition, message: failed to wait for OnPremAdminCluster "admin-cluster-name" to stay in ready status for duration "2m0s": OnPremAdminCluster "non-prod-admin" is not ready: ready condition is not true: CreateOrUpdateControlPlane: Creating or updating credentials for cluster control plane

Die Ausführung von kubectl get secrets -A --kubeconfig KUBECONFIG` schlägt mit folgendem Fehler fehl: 

      Internal error occurred: unable to transform key "/registry/secrets/anthos-identity-service/ais-secret": rpc error: code = Internal desc = failed to decrypt: unknown jwk

Problemumgehung

Wenn Sie eine Sicherung des Administratorclusters haben, führen Sie die folgenden Schritte aus, um den Upgradefehler zu umgehen:

  1. Deaktivieren Sie secretsEncryption in der Konfigurationsdatei des Administratorclusters und aktualisieren Sie den Cluster mit dem folgenden Befehl: 
    gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
  2. Nachdem die neue Administrator-Master-VM erstellt wurde, stellen Sie eine SSH-Verbindung zur Administrator-Master-VM her und ersetzen Sie den neuen Schlüssel auf dem Datenlaufwerk durch den alten Schlüssel aus der Sicherung. Der Schlüssel befindet sich im Administrator-Master unter /opt/data/gke-k8s-kms-plugin/generatedkeys.
  3. Aktualisieren Sie das statische Pod-Manifest kms-plugin.yaml in /etc/kubernetes/manifests, um --kek-id so zu aktualisieren, dass es mit dem Feld kid im ursprünglichen Verschlüsselungsschlüssel übereinstimmt.
  4. Starten Sie den statischen Pod „kms-plugin“ neu. Verschieben Sie dazu /etc/kubernetes/manifests/kms-plugin.yaml in ein anderes Verzeichnis und dann zurück.
  5. Setzen Sie das Administratorupgrade fort, indem Sie gkectl upgrade admin noch einmal ausführen.

Upgradefehler verhindern

Wenn Sie noch kein Upgrade auf 1.15.0-1.15.4 durchgeführt haben, empfehlen wir Ihnen, kein Upgrade durchzuführen. Wenn Sie ein Upgrade auf eine betroffene Version durchführen müssen, führen Sie die folgenden Schritte aus, bevor Sie den Administratorcluster upgraden:

  1. Administratorcluster sichern
  2. Deaktivieren Sie secretsEncryption in der Konfigurationsdatei des Administratorclusters und aktualisieren Sie den Cluster mit dem folgenden Befehl: 
    gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
  3. Führen Sie ein Upgrade des Administratorclusters durch.
  4. Aktivieren Sie die Always-on-Secret-Verschlüsselung wieder.
Speicher 1.11.–1.16.

Laufwerkfehler und Fehler beim Anhängen, wenn Changed Block Tracking (CBT) verwendet wird

GKE on VMware unterstützt Changed Block Tracking (CBT) auf Laufwerken nicht. Einige Sicherungssoftware verwendet das CBT-Feature, um den Laufwerkstatus zu verfolgen und Sicherungen durchzuführen. Dadurch kann das Laufwerk keine Verbindung zu einer VM herstellen, auf der GKE on VMware ausgeführt wird. Weitere Informationen finden Sie im VMware-KB-Artikel.


Workaround:

Sichern Sie keine GKE on VMware-VMs, da die Sicherungssoftware von Drittanbietern dazu führen kann, dass CBT auf ihren Laufwerken aktiviert wird. Es ist nicht erforderlich, diese VMs zu sichern.

Aktivieren Sie CBT auf dem Knoten nicht, da diese Änderung bei Updates oder Upgrades nicht erhalten bleibt.

Wenn Sie bereits Laufwerke mit aktiviertem CBT haben, folgen Sie den Lösungsschritten im VMware-KB-Artikel, um CBT auf dem First Class-Laufwerk zu deaktivieren.
Speicher 1,14, 1,15, 1,16

Datenbeschädigung unter NFSv3, wenn parallele Anfügungen an eine freigegebene Datei von mehreren Hosts aus ausgeführt werden

Wenn Sie Nutanix-Speicherarrays verwenden, um Ihren Hosts NFSv3-Freigaben bereitzustellen, können Daten beschädigt werden oder Pods können nicht erfolgreich ausgeführt werden. Dieses Problem wird durch ein bekanntes Kompatibilitätsproblem zwischen bestimmten VMware- und Nutanix-Versionen verursacht. Weitere Informationen finden Sie im zugehörigen VMware-KB-Artikel.


Workaround:

Der VMware-KB-Artikel ist veraltet und weist darauf hin, dass keine aktuelle Lösung verfügbar ist. Aktualisieren Sie auf Ihren Hosts auf die neueste ESXi-Version und in Ihren Speicherarrays auf die neueste Nutanix-Version, um dieses Problem zu beheben.
Betriebssystem 1.13.10, 1.14.6, 1.15.3

Versionsabweichung zwischen Kubelet und der Kubernetes-Steuerungsebene

Bei bestimmten GKE on VMware-Releases verwendet das auf den Knoten ausgeführte Kubelet eine andere Version als die Kubernetes-Steuerungsebene. Es gibt eine Abweichung, da die auf das Betriebssystem-Image vorinstallierte kubelet-Binärdatei eine andere Version verwendet.

In der folgenden Tabelle sind die erkannten nicht übereinstimmenden Versionen aufgeführt:

GKE on VMware-Version Kubelet-Version Kubernetes-Version
1.13.10 Version 1.24.11-gke.1200 Version 1.24.14-gke.2100
1.14.6 Version 1.25.8-gke.1500 Version 1.25.10-gke.1200
1.15.3 Version 1.26.2-gke.1001 Version 1.26.5-gke.2100

Workaround:

Sie müssen nichts tun. Die Inkonsistenz tritt nur zwischen den Kubernetes-Patchversionen auf und es wurden keine Probleme durch diese Versionsabweichung verursacht.

Upgrades und Updates 1.15.0-1.15.4

Das Upgrade oder Aktualisieren eines Administratorclusters mit einer CA-Version höher als 1 schlägt fehl

Wenn ein Administratorcluster eine Version der Zertifizierungsstelle (Certificate Authority, CA) höher als 1 hat, schlägt eine Aktualisierung oder ein Upgrade aufgrund der CA-Versionsprüfung im Webhook fehl. Die Ausgabe des Upgrades/Updates von gkectl enthält die folgende Fehlermeldung: 

    CAVersion must start from 1

Workaround:

  • Skalieren Sie das Deployment auto-resize-controller im Administratorcluster herunter, um die automatische Größenanpassung von Knoten zu deaktivieren. Dies ist erforderlich, da ein neues Feld, das in 1.15 für die benutzerdefinierte Ressource des Administratorclusters eingeführt wurde, einen NULL-Zeiger-Fehler in auto-resize-controller verursachen kann. 
     kubectl scale deployment auto-resize-controller -n kube-system --replicas=0 --kubeconfig KUBECONFIG
  • Führen Sie gkectl-Befehle mit dem Flag --disable-admin-cluster-webhook aus.Beispiel: 
            gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG --disable-admin-cluster-webhook
Vorgang 1.13, 1.14.0–1.14.8, 1.15.0–1.15.4, 1.16.0–1.16.1

Löschen des Clusters der V2-Steuerungsebene ohne Hochverfügbarkeit bleibt bis zum Zeitlimit hängen

Wenn ein V2-Cluster der Steuerungsebene ohne Hochverfügbarkeit gelöscht wird, bleibt er beim Löschen des Knotens hängen, bis eine Zeitüberschreitung auftritt.

Workaround:

Wenn der Cluster ein StatefulSet mit kritischen Daten enthält, wenden Sie sich an Cloud Customer Care, um das Problem zu beheben.

Andernfalls gehen Sie so vor:

  • Löschen Sie alle Cluster-VMs aus vSphere. Sie können die VMs über die vSphere-UI löschen oder den folgenden Befehl ausführen: 
          govc vm.destroy
    .
  • Erzwingen Sie das Löschen des Clusters noch einmal: 
         gkectl delete cluster --cluster USER_CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG --force

Speicher 1.15.0+, 1.16.0+

Nach dem Upgrade auf Version 1.15 oder höher werden für integrierte PVC/PV-Aufgaben konstante CNS-AttachVolume-Aufgaben pro Minute angezeigt

Wenn ein Cluster integrierte nichtflüchtige vSphere-Volumes enthält (z. B. PVCs, die mit der Speicherklasse standard erstellt wurden), beobachten Sie com.vmware.cns.tasks.attachvolume-Aufgaben, die jede Minute von vCenter ausgelöst werden.


Workaround:

Bearbeiten Sie die configMap für das vSphere-CSI-Feature und setzen Sie list-volumes auf „false“:

     kubectl edit configmap internal-feature-states.csi.vsphere.vmware.com -n kube-system --kubeconfig KUBECONFIG

Starten Sie die vSphere CSI-Controller-Pods neu:

     kubectl rollout restart vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
Speicher 1.16.0

Falsche Warnungen gegen PVCs

Wenn ein Cluster integrierte nichtflüchtige vSphere-Volumes enthält, können die Befehle gkectl diagnose und gkectl upgrade beim Validieren der Clusterspeichereinstellungen falsche Warnungen zu ihren Anforderungen an nichtflüchtige Volumes (Persistent Volume Claims, PVCs) ausgeben. Die Warnmeldung sieht in etwa so aus: 

    CSIPrerequisites pvc/pvc-name: PersistentVolumeClaim pvc-name bounds to an in-tree vSphere volume created before CSI migration enabled, but it doesn't have the annotation pv.kubernetes.io/migrated-to set to csi.vsphere.vmware.com after CSI migration is enabled

Workaround:

Führen Sie den folgenden Befehl aus, um die Annotationen eines PVC mit der obigen Warnung zu prüfen:

    kubectl get pvc PVC_NAME -n PVC_NAMESPACE -oyaml --kubeconfig KUBECONFIG

Wenn das Feld annotations in der Ausgabe Folgendes enthält, können Sie die Warnung ignorieren:

      pv.kubernetes.io/bind-completed: "yes"
      pv.kubernetes.io/bound-by-controller: "yes"
      volume.beta.kubernetes.io/storage-provisioner: csi.vsphere.vmware.com
Upgrades und Updates 1.15.0+, 1.16.0+

Die Rotation des Dienstkontoschlüssels schlägt fehl, wenn mehrere Schlüssel abgelaufen sind

Wenn Ihr Cluster keine private Registry verwendet und der Dienstkontoschlüssel für den Komponentenzugriff sowie die Dienstkontoschlüssel für Logging-Monitoring (oder Connect-Register) abgelaufen sind, schlägt gkectl update credentials beim Rotieren der Dienstkontoschlüssel mit einem Fehler wie dem folgenden fehl: 

Error: reconciliation failed: failed to update platform: ...

Workaround:

Rotieren Sie zuerst den Dienstkontoschlüssel für den Komponentenzugriff. Obwohl die gleiche Fehlermeldung angezeigt wird, sollten Sie die anderen Schlüssel nach der Rotation des Dienstkontoschlüssels für den Komponentenzugriff rotieren können.

Wenn das Update weiterhin nicht erfolgreich ist, wenden Sie sich an Cloud Customer Care, um das Problem zu beheben.
Upgrades 1.16.0-1.16.5

1.15 Beim Upgrade des Nutzercluster-Controllers auf 1.16 kommt es zu einer unerwarteten Neuerstellung der Nutzermastermaschine

Wenn während eines Nutzerclusterupgrades ein Upgrade des Nutzerclustercontrollers auf 1.16 durchgeführt wurde und Sie weitere 1, 15 Nutzercluster haben, die vom selben Administratorcluster verwaltet werden, wird deren Nutzermastercomputer möglicherweise unerwartet neu erstellt.

Im Nutzercluster-Controller der Version 1.16 liegt ein Fehler vor, der die Neuerstellung der Nutzermaster-Maschine in Version 1.15 auslösen kann.

Die Problemumgehung hängt davon ab, wie das Problem auftritt.

Problemumgehung beim Upgrade des Nutzerclusters über die Google Cloud Console:

Option 1: Verwenden Sie Version 1.16.6 oder höher von GKE on VMware mit der Lösung.

Option 2: Gehen Sie so vor:

  1. Fügen Sie die Annotation für die erneute Ausführung mit dem folgenden Befehl manuell hinzu: 
    kubectl edit onpremuserclusters USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt --kubeconfig ADMIN_KUBECONFIG

    Die Annotation für die erneute Ausführung lautet:

    onprem.cluster.gke.io/server-side-preflight-rerun: true
  2. Überwachen Sie den Upgradefortschritt, indem Sie das Feld status des OnPremUserClusters anklicken.

Problemumgehung beim Upgrade des Nutzerclusters mit Ihrer eigenen Administratorworkstation:

Option 1: Verwenden Sie Version 1.16.6 oder höher von GKE on VMware mit der Lösung.

Option 2: Gehen Sie so vor:

  1. Fügen Sie die Build-Infodatei /etc/cloud/build.info mit dem folgenden Inhalt hinzu. Dadurch werden die Preflight-Prüfungen lokal auf Ihrer Administratorworkstation und nicht auf dem Server ausgeführt. 
    gke_on_prem_version: GKE_ON_PREM_VERSION
    Beispiel: 
    gke_on_prem_version: 1.16.0-gke.669
  2. Führen Sie den Upgradebefehl noch einmal aus.
  3. Löschen Sie nach Abschluss des Upgrades die Datei „build.info“.
Erstellen 1.16.0–1.16.5, 1.28.0–1.28.100

Die Preflight-Prüfung schlägt fehl, wenn der Hostname nicht in der IP-Blockdatei enthalten ist.

Wenn Sie bei der Clustererstellung nicht für jede IP-Adresse in der IP-Blockdatei einen Hostnamen angeben, schlägt die Preflight-Prüfung fehl und die folgende Fehlermeldung wird angezeigt: 

multiple VMs found by DNS name  in xxx datacenter. Anthos Onprem doesn't support duplicate hostname in the same vCenter and you may want to rename/delete the existing VM.`

Die Preflight-Prüfung enthält einen Fehler, der einen leeren Hostnamen als Duplikat voraussetzt.

Workaround:

Option 1: Version mit der Korrektur verwenden

Option 2: Sie können diese Preflight-Prüfung umgehen, indem Sie das Flag --skip-validation-net-config hinzufügen.

Option 3: Geben Sie für jede IP-Adresse in der IP-Blockdatei einen eindeutigen Hostnamen an.
Upgrades und Updates 1.16

Volume-Bereitstellungsfehler beim Upgrade/Aktualisieren des Administratorclusters, wenn der Administratorcluster ohne Hochverfügbarkeit und der v1-Nutzercluster der Steuerungsebene verwendet wird

Wenn Sie bei einem Administratorcluster ohne Hochverfügbarkeit und einem v1-Nutzercluster der Steuerungsebene ein Upgrade oder eine Aktualisierung des Administratorclusters durchführen, kann die Wiederherstellung des Administratorclusters der Mastermaschine gleichzeitig mit dem Neustart der Mastermaschine des Nutzerclusters erfolgen, was zu einer Race-Bedingung führen kann. Dies führt dazu, dass die Pods der Nutzercluster-Steuerungsebene nicht mit der Steuerungsebene des Administratorclusters kommunizieren können. Dies führt zu Problemen beim Anhängen von Volumes für „kube-etcd“ und „kube-apiserver“ auf der Steuerungsebene des Nutzerclusters.

Führen Sie die folgenden Befehle für den betroffenen Pod aus, um das Problem zu prüfen:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace USER_CLUSTER_NAME describe pod IMPACTED_POD_NAME
Daraufhin werden folgende Ereignisse angezeigt: 
Events:
  Type     Reason       Age                  From               Message
  ----     ------       ----                 ----               -------
  Warning  FailedMount  101s                 kubelet            Unable to attach or mount volumes: unmounted volumes=[kube-audit], unattached volumes=[], failed to process volumes=[]: timed out waiting for the condition
  Warning  FailedMount  86s (x2 over 3m28s)  kubelet            MountVolume.SetUp failed for volume "pvc-77cd0635-57c2-4392-b191-463a45c503cb" : rpc error: code = FailedPrecondition desc = volume ID: "bd313c62-d29b-4ecd-aeda-216648b0f7dc" does not appear staged to "/var/lib/kubelet/plugins/kubernetes.io/csi/csi.vsphere.vmware.com/92435c96eca83817e70ceb8ab994707257059734826fedf0c0228db6a1929024/globalmount"

Workaround:

  1. Stellen Sie eine SSH-Verbindung zu einem Knoten der Nutzersteuerungsebene her. Da es sich um einen v1-Nutzercluster der Steuerungsebene handelt, befindet sich der Knoten der Nutzersteuerungsebene im Administratorcluster.
  2. Starten Sie das Kubelet mit dem folgenden Befehl neu: 
        sudo systemctl restart kubelet
    Nach dem Neustart kann das Kubelet die globale Bereitstellung der Phase korrekt rekonstruieren.
Upgrades und Updates 1.16.0

Knoten der Steuerungsebene kann nicht erstellt werden

Während eines Upgrades oder einer Aktualisierung eines Administratorclusters kann eine Race-Bedingung dazu führen, dass der vSphere Cloud Controller-Manager unerwartet einen neuen Knoten der Steuerungsebene löscht. Dies führt dazu, dass der clusterapi-Controller beim Erstellen des Knotens hängen bleibt und sogar beim Upgrade/Update eine Zeitüberschreitung auftritt. In diesem Fall sieht die Ausgabe des gkectl-Befehls „upgrade/update“ in etwa so aus:

    controlplane 'default/gke-admin-hfzdg' is not ready: condition "Ready": condition is not ready with reason "MachineInitializing", message "Wait for the control plane machine "gke-admin-hfzdg-6598459f9zb647c8-0\" to be rebooted"...

Um das Symptom zu identifizieren, führen Sie den folgenden Befehl aus, um das Protokoll im vSphere Cloud Controller Manager im Administratorcluster abzurufen:

    kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
    kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n kube-system

Hier ist ein Beispiel für eine Fehlermeldung des obigen Befehls:

    node name: 81ff17e25ec6-qual-335-1500f723 has a different uuid. Skip deleting this node from cache.

Workaround:

  1. Starten Sie die fehlgeschlagene Maschine neu, um das gelöschte Knotenobjekt neu zu erstellen.
  2. Stellen Sie eine SSH-Verbindung zu jedem Knoten der Steuerungsebene her und starten Sie den statischen Pod des vSphere Cloud-Controller-Managers neu: 
          sudo crictl ps | grep vsphere-cloud-controller-manager | awk '{print $1}'
      sudo crictl stop PREVIOUS_COMMAND_OUTPUT
  3. Upgrade-/Aktualisierungsbefehl noch einmal ausführen.
Vorgang 1.16

Doppelter Hostname im selben Rechenzentrum führt zu Fehlern beim Upgrade- oder Erstellen von Clustern

Ein Upgrade eines 1.15-Clusters oder eines 1.16-Clusters mit statischen IP-Adressen schlägt fehl, wenn im selben Rechenzentrum doppelte Hostnamen vorhanden sind. Dieser Fehler tritt auf, weil der vSphere Cloud Controller-Manager dem Knotenobjekt keine externe IP-Adresse und Anbieter-ID hinzufügen kann. Dies führt zu einer Zeitüberschreitung beim Upgrade/Erstellen des Clusters.

Um das Problem zu identifizieren, rufen Sie die Pod-Logs des vSphere Cloud Controller Managers für den Cluster ab. Der verwendete Befehl hängt wie folgt vom Clustertyp ab:

  • Administratorcluster: 
          kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
      kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n kube-system
  • Nutzercluster (kubeception): 
          kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME | grep vsphere-cloud-controller-manager
      kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME
  • Nutzercluster: (Controlplane V2): 
          kubectl get pods --kubeconfig USER_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
      kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig USER_KUBECONFIG -n kube-system

Hier ist ein Beispiel für eine Fehlermeldung:

    I1003 17:17:46.769676       1 search.go:152] Finding node admin-vm-2 in vc=vcsa-53598.e5c235a1.asia-northeast1.gve.goog and datacenter=Datacenter
    E1003 17:17:46.771717       1 datacenter.go:111] Multiple vms found VM by DNS Name. DNS Name: admin-vm-2

Prüfen Sie, ob der Hostname im Rechenzentrum doppelt vorhanden ist:

Mit dem folgenden Ansatz können Sie prüfen, ob der Hostname doppelt vorhanden ist, und bei Bedarf eine Problemumgehung anwenden. 
          export GOVC_DATACENTER=GOVC_DATACENTER
          export GOVC_URL=GOVC_URL
          export GOVC_USERNAME=GOVC_USERNAME
          export GOVC_PASSWORD=GOVC_PASSWORD
          export GOVC_INSECURE=true
          govc find . -type m -guest.hostName HOSTNAME
Beispielbefehle und -ausgabe: 
          export GOVC_DATACENTER=mtv-lifecycle-vc01
          export GOVC_URL=https://mtv-lifecycle-vc01.anthos/sdk
          export GOVC_USERNAME=xxx
          export GOVC_PASSWORD=yyy
          export GOVC_INSECURE=true
          govc find . -type m -guest.hostName f8c3cd333432-lifecycle-337-xxxxxxxz
          ./vm/gke-admin-node-6b7788cd76-wkt8g
          ./vm/gke-admin-node-6b7788cd76-99sg2
          ./vm/gke-admin-master-5m2jb

Die Problemumgehung hängt davon ab, welcher Vorgang fehlgeschlagen ist.

Problemumgehung für Upgrades:

Führen Sie die Problemumgehung für den entsprechenden Clustertyp aus.

  • Nutzercluster:
    1. Aktualisieren Sie den Hostnamen des betroffenen Computers in user-ip-block.yaml auf einen eindeutigen Namen und lösen Sie ein erzwungenes Update aus:
                gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config NEW_USER_CLUSTER_CONFIG --force
    2. gkectl upgrade cluster noch einmal ausführen
  • Administratorcluster:
    1. Ändern Sie den Hostnamen des betroffenen Computers in „admin-ip-block.yaml“ in einen eindeutigen Namen und lösen Sie ein erzwungenes Update aus:
                gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config NEW_ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check
    2. Wenn es sich um einen Administratorcluster ohne Hochverfügbarkeit handelt und Sie feststellen, dass die Administrator-Master-VM doppelten Hostnamen verwendet, müssen Sie außerdem Folgendes tun:
      Name der Administrator-Master-Maschine abrufen 
                kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A
      Administrator-Master-Maschinenobjekt aktualisieren
      Hinweis: Der NEW_ADMIN_MASTER_HOSTNAME sollte mit den Angaben in der Datei "admin-ip-block.yaml" in Schritt 1 übereinstimmen.
                kubectl patch machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG --type='json' -p '[{"op": "replace", "path": "/spec/providerSpec/value/networkSpec/address/hostname", "value":"NEW_ADMIN_MASTER_HOSTNAME"}]'
      Prüfen Sie, ob der Hostname im Administrator-Master-Maschinenobjekt aktualisiert wurde:
                kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -oyaml
          kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -o jsonpath='{.spec.providerSpec.value.networkSpec.address.hostname}'
    3. Upgrade des Administratorclusters noch einmal mit deaktiviertem Prüfpunkt ausführen:
                gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --disable-upgrade-from-checkpoint

Problemumgehung bei Installationen:

Führen Sie die Problemumgehung für den entsprechenden Clustertyp aus.
Vorgang 1.16.0, 1.16.1, 1.16.2, 1.16.3

$ und ` werden im vSphere-Nutzernamen oder ‐Passwort nicht unterstützt

Die folgenden Vorgänge schlagen fehl, wenn der vSphere-Nutzername oder das Passwort $ oder ` enthält:

  • Upgrade eines Nutzerclusters von 1.15 mit aktiviertem Controlplane V2 auf 1.16 durchführen
  • Upgrade eines Hochverfügbarkeits-Administratorclusters mit 1.15 auf 1.16 wird durchgeführt
  • Nutzercluster der Version 1.16 mit aktiviertem Controlplane V2 erstellen
  • 1,16-HA-Administratorcluster erstellen

Verwenden Sie mindestens Version 1.16.4 von GKE on VMware mit der Fehlerbehebung oder führen Sie die folgende Problemumgehung durch. Die Problemumgehung hängt davon ab, welcher Vorgang fehlgeschlagen ist.

Problemumgehung für Upgrades:

  1. Ändern Sie den vCenter-Nutzernamen oder das vCenter-Passwort auf der vCenter-Seite, um $ und ` zu entfernen.
  2. Aktualisieren Sie den vCenter-Nutzernamen oder das Passwort in der Konfigurationsdatei für Anmeldedaten.
  3. Erzwungene Aktualisierung des Clusters auslösen.
    • Nutzercluster: 
              gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG --force
    • Administratorcluster: 
              gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check

Problemumgehung bei Installationen:

  1. Ändern Sie den vCenter-Nutzernamen oder das vCenter-Passwort auf der vCenter-Seite, um $ und ` zu entfernen.
  2. Aktualisieren Sie den vCenter-Nutzernamen oder das Passwort in der Konfigurationsdatei für Anmeldedaten.
  3. Führen Sie die Problemumgehung für den entsprechenden Clustertyp aus.
Speicher 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16

Fehler bei der PVC-Erstellung, nachdem der Knoten mit demselben Namen neu erstellt wurde

Nachdem ein Knoten gelöscht und dann mit demselben Knotennamen neu erstellt wurde, besteht die geringe Wahrscheinlichkeit, dass eine nachfolgende PVC-Erstellung (VolumeClaim) mit einem Fehler wie dem folgenden fehlschlägt:

    The object 'vim.VirtualMachine:vm-988369' has already been deleted or has not been completely created

Dies wird durch eine Race-Bedingung verursacht, in der der vSphere CSI-Controller eine entfernte Maschine nicht aus dem Cache löscht.


Workaround:

Starten Sie die vSphere CSI-Controller-Pods neu:

    kubectl rollout restart vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
Vorgang 1.16.0

gkectl-Reparatur-admin-master gibt kubeconfig-Unmarshall-Fehler zurück

Wenn Sie den Befehl gkectl repair admin-master in einem Administratorcluster mit Hochverfügbarkeit ausführen, gibt gkectl die folgende Fehlermeldung zurück: 

  Exit with error: Failed to repair: failed to select the template: failed to get cluster name from kubeconfig, please contact Google support. failed to decode kubeconfig data: yaml: unmarshal errors:
    line 3: cannot unmarshal !!seq into map[string]*api.Cluster
    line 8: cannot unmarshal !!seq into map[string]*api.Context

Workaround:

Fügen Sie dem Befehl das Flag --admin-master-vm-template= hinzu und geben Sie die VM-Vorlage der zu reparierenden Maschine an: 

  gkectl repair admin-master --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --config ADMIN_CLUSTER_CONFIG_FILE \
      --admin-master-vm-template=/DATA_CENTER/vm/VM_TEMPLATE_NAME

So finden Sie die VM-Vorlage der Maschine:

  1. Rufen Sie im vSphere-Client die Seite Hosts und Cluster auf.
  2. Klicken Sie auf VM-Vorlagen und filtern Sie nach dem Namen des Administratorclusters.

    Sie sollten die drei VM-Vorlagen für den Administratorcluster sehen.

  3. Kopieren Sie den Namen der VM-Vorlage, der dem Namen der zu reparierenden Maschine entspricht, und verwenden Sie den Vorlagennamen im Reparaturbefehl.
  gkectl repair admin-master \
      --config=/home/ubuntu/admin-cluster.yaml \
      --kubeconfig=/home/ubuntu/kubeconfig \
      --admin-master-vm-template=/atl-qual-vc07/vm/gke-admin-98g94-zx...7vx-0-tmpl
Netzwerk 1.10.0+, 1.11.0+, 1.12.0+, 1.13.0+, 1.14.0–1.14.7, 1.15.0–1.15.3, 1.16.0

Seesaw-VM aufgrund von wenig Speicherplatz fehlerhaft

Wenn Sie Seesaw als Load-Balancer-Typ für Ihren Cluster verwenden und feststellen, dass eine Seesaw-VM nicht verfügbar ist oder weiterhin nicht gestartet werden kann, wird möglicherweise die folgende Fehlermeldung in der vSphere-Konsole angezeigt:

    GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd

Dieser Fehler weist darauf hin, dass nur noch wenig Speicherplatz auf der VM verfügbar ist, da das auf der Seesaw-VM ausgeführte fließende Bit nicht mit der richtigen Logrotation konfiguriert ist.


Workaround:

Suchen Sie mit du -sh -- /var/lib/docker/containers/* | sort -rh nach den Protokolldateien, die den meisten Speicherplatz belegen. Bereinigen Sie die Logdatei mit der größten Größe und starten Sie die VM neu.

Hinweis:Wenn auf die VM nicht zugegriffen werden kann, hängen Sie das Laufwerk an eine funktionierende VM an (z.B. Administratorworkstation), entfernen Sie die Datei vom angehängten Laufwerk und hängen Sie das Laufwerk wieder an die ursprüngliche Seesaw-VM an.

Damit das Problem nicht noch einmal auftritt, stellen Sie eine Verbindung zur VM her und ändern die Datei /etc/systemd/system/docker.fluent-bit.service. Fügen Sie im Docker-Befehl --log-opt max-size=10m --log-opt max-file=5 hinzu und führen Sie dann systemctl restart docker.fluent-bit.service aus
Vorgang 1.13; 1.14.0–1.14.6, 1.15

Fehler beim öffentlichen SSH-Schlüssel des Administrators nach Upgrade oder Update des Administratorclusters

Wenn Sie versuchen, einen Administratorcluster ohne Hochverfügbarkeit mit aktiviertem Checkpoint zu aktualisieren (gkectl upgrade admin) oder zu aktualisieren (gkectl update admin), schlägt das Upgrade oder Update möglicherweise mit folgenden Fehlern fehl: 

Checking admin cluster certificates...FAILURE
    Reason: 20 admin cluster certificates error(s).
Unhealthy Resources:
    AdminMaster clusterCA bundle: failed to get clusterCA bundle on admin master, command [ssh -o IdentitiesOnly=yes -i admin-ssh-key -o StrictHostKeyChecking=no -o ConnectTimeout=30 ubuntu@AdminMasterIP -- sudo cat /etc/kubernetes/pki/ca-bundle.crt] failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
    ubuntu@AdminMasterIP: Permission denied (publickey).

failed to ssh AdminMasterIP, failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
    ubuntu@AdminMasterIP: Permission denied (publickey)

error dialing ubuntu@AdminMasterIP: failed to establish an authenticated SSH connection: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey]...


Workaround:

Wenn Sie mit dieser Fehlerbehebung kein Upgrade auf eine Patchversion von GKE on VMware durchführen können, wenden Sie sich an den Google-Support.
Upgrades 1.13.0–1.13.9, 1.14.0–1.14.6, 1.15.1–1.15.2

Das Upgrade eines Administratorclusters, der in der GKE On-Prem API registriert ist, kann fehlschlagen

Wenn ein Administratorcluster in der GKE On-Prem API registriert ist, kann das Upgrade des Administratorclusters auf die betroffenen Versionen fehlschlagen, da die Flottenmitgliedschaft nicht aktualisiert werden konnte. Wenn dieser Fehler auftritt, wird der folgende Fehler angezeigt, wenn Sie versuchen, das Clusterupgrade durchzuführen:

    failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.on_prem_cluster.resource_link: field cannot be updated

Ein Administratorcluster wird in der API registriert, wenn Sie den Cluster explizit registrieren oder einen Nutzercluster mit einem GKE On-Prem API-Client upgraden.


Workaround:

Melden Sie den Administratorcluster ab: 
    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
und fahren Sie mit dem Upgrade des Administratorclusters fort. Möglicherweise wird der veraltete Fehler „Cluster konnte nicht registriert werden“ vorübergehend angezeigt. Nach einer Weile sollte sie automatisch aktualisiert werden.
Upgrades und Updates 1.13.0–1.13.9, 1.14.0–1.14.4, 1.15.0

Wenn ein Administratorcluster in der GKE On-Prem API registriert ist, wird seine Ressourcenlink-Annotation auf die benutzerdefinierte Ressource OnPremAdminCluster angewendet. Diese wird bei späteren Aktualisierungen des Administratorclusters nicht beibehalten, da der falsche Annotationsschlüssel verwendet wird. Dies kann dazu führen, dass der Administratorcluster versehentlich wieder in der GKE On-Prem API registriert wird.

Ein Administratorcluster wird in der API registriert, wenn Sie den Cluster explizit registrieren oder einen Nutzercluster mit einem GKE On-Prem API-Client upgraden.


Workaround:

Melden Sie den Administratorcluster ab: 
    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
und registrieren Sie den Administratorcluster noch einmal.
Netzwerk 1.15.0-1.15.2

CoreDNS orderPolicy nicht erkannt

OrderPolicy wird nicht als Parameter erkannt und nicht verwendet. Stattdessen verwendet GKE on VMware immer Random.

Dieses Problem tritt auf, weil die CoreDNS-Vorlage nicht aktualisiert wurde. Dadurch wird orderPolicy ignoriert.


Workaround:

Aktualisieren Sie die CoreDNS-Vorlage und wenden Sie die Korrektur an. Diese Problembehebung bleibt bis zu einem Upgrade bestehen.

  1. Bearbeiten Sie die vorhandene Vorlage: 
    kubectl edit cm -n kube-system coredns-template
    Ersetzen Sie den Inhalt der Vorlage durch Folgendes: 
    coredns-template: |-
  .:53 {
    errors
    health {
      lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
{{- if .PrivateGoogleAccess }}
    import zones/private.Corefile
{{- end }}
{{- if .RestrictedGoogleAccess }}
    import zones/restricted.Corefile
{{- end }}
    prometheus :9153
    forward . {{ .UpstreamNameservers }} {
      max_concurrent 1000
      {{- if ne .OrderPolicy "" }}
      policy {{ .OrderPolicy }}
      {{- end }}
    }
    cache 30
{{- if .DefaultDomainQueryLogging }}
    log
{{- end }}
    loop
    reload
    loadbalance
}{{ range $i, $stubdomain := .StubDomains }}
{{ $stubdomain.Domain }}:53 {
  errors
{{- if $stubdomain.QueryLogging }}
  log
{{- end }}
  cache 30
  forward . {{ $stubdomain.Nameservers }} {
    max_concurrent 1000
    {{- if ne $.OrderPolicy "" }}
    policy {{ $.OrderPolicy }}
    {{- end }}
  }
}
{{- end }}
Upgrades und Updates 1.10, 1.11, 1.12, 1.13.0–1.13.7, 1.14.0–1.14.3

OnPremAdminCluster-Status zwischen Prüfpunkt und tatsächlicher Antwortvorlage inkonsistent

Bestimmte Race-Bedingungen können dazu führen, dass der OnPremAdminCluster-Status zwischen dem Checkpoint und der tatsächlichen Antwortvorlage inkonsistent ist. Wenn das Problem auftritt, kann beim Aktualisieren des Administratorclusters nach dem Upgrade der folgende Fehler auftreten:

Exit with error:
E0321 10:20:53.515562  961695 console.go:93] Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated
Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated
Um dieses Problem zu umgehen, müssen Sie entweder den Checkpoint bearbeiten oder für ein Upgrade/Update deaktivieren. Wenden Sie sich an unser Supportteam, um mit der Problemumgehung fortzufahren.
Vorgang 1.13.0–1.13.9, 1.14.0–1.14.5, 1.15.0–1.15.1

Änderungen an Administratorzertifikaten für Administratorcluster beim Abgleichsprozess

GKE on VMware ändert die Administratorzertifikate auf Steuerungsebenen von Administratorclustern mit jedem Abgleichsprozess, z. B. während eines Clusterupgrades. Dieses Verhalten erhöht die Wahrscheinlichkeit, dass ungültige Zertifikate für Ihren Administratorcluster ausgegeben werden, insbesondere für Cluster der Version 1.15.

Wenn Sie von diesem Problem betroffen sind, können Probleme wie die folgenden auftreten:

  • Ungültige Zertifikate können bei den folgenden Befehlen zu einer Zeitüberschreitung und zu Fehlermeldungen führen:
    • gkectl create admin
    • gkectl upgrade amdin
    • gkectl update admin

    Diese Befehle können Autorisierungsfehler wie die folgenden zurückgeben:

    Failed to reconcile admin cluster: unable to populate admin clients: failed to get admin controller runtime client: Unauthorized
  • Die kube-apiserver-Logs für Ihren Administratorcluster können Fehler wie die folgenden enthalten: 
    Unable to authenticate the request" err="[x509: certificate has expired or is not yet valid...

Workaround:

Führen Sie ein Upgrade auf eine GKE on VMware-Version mit der folgenden Fehlerbehebung durch: 1.13.10 oder höher, 1.14.6 oder höher, 1.15.2 oder höher. Wenn kein Upgrade für Sie möglich ist, wenden Sie sich an Cloud Customer Care, um das Problem zu beheben.
Netzwerk, Betrieb 1,10, 1,11, 1,12, 1,13, 1,14

Anthos Network Gateway-Komponenten wurden aufgrund fehlender Prioritätsklasse entfernt oder ausstehend

Netzwerk-Gateway-Pods in kube-system können den Status Pending oder Evicted anzeigen, wie in der folgenden komprimierten Beispielausgabe gezeigt:

$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc     2/2     Running     0     5d2h
ang-node-mw8cq     0/2     Evicted     0     6m5s
ang-node-zsmq7     0/2     Pending     0     7h

Diese Fehler weisen auf Bereinigungsereignisse hin oder darauf, dass Pods aufgrund von Knotenressourcen nicht geplant werden können. Da Anthos Network Gateway-Pods keine PriorityClass haben, haben sie dieselbe Standardpriorität wie andere Arbeitslasten. Wenn Knoten ressourcenbeschränkt sind, werden die Netzwerk-Gateway-Pods möglicherweise entfernt. Dieses Verhalten ist besonders schlecht für das DaemonSet ang-node, da diese Pods auf einem bestimmten Knoten geplant werden müssen und nicht migriert werden können.


Workaround:

Führen Sie ein Upgrade auf Version 1.15 oder höher aus.

Als kurzfristige Lösung können Sie den Anthos Network Gateway-Komponenten manuell eine PriorityClass zuweisen. Der GKE on VMware-Controller überschreibt diese manuellen Änderungen während eines Abgleichsprozesses, z. B. während eines Clusterupgrades.

  • Weisen Sie den Clustercontroller-Deployments ang-controller-manager und autoscaler die PriorityClass system-cluster-critical zu.
  • Weisen Sie dem DaemonSet des Knotens ang-daemon die PriorityClass system-node-critical zu.
Upgrades und Updates 1.12, 1.13, 1.14, 1.15.0–1.15.2

Administratorclusterupgrade schlägt nach der Registrierung des Clusters bei gcloud fehl

Nachdem Sie gcloud zum Registrieren eines Administratorclusters mit dem nicht leeren Abschnitt gkeConnect verwendet haben, wird möglicherweise der folgende Fehler angezeigt, wenn Sie versuchen, den Cluster zu aktualisieren:

failed to register cluster: failed to apply Hub Mem\
bership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.o\
n_prem_cluster.admin_cluster: field cannot be updated

Löschen Sie den Namespace gke-connect: 

kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG
Rufen Sie den Namen des Administratorclusters ab: 
kubectl get onpremadmincluster -n kube-system --kubeconfig=ADMIN_KUBECONFIG
Löschen Sie die Flottenmitgliedschaft: 
gcloud container fleet memberships delete ADMIN_CLUSTER_NAME
und setzen Sie das Upgrade des Administratorclusters fort.
Vorgang 1.13.0–1.13.8, 1.14.0–1.14.5, 1.15.0–1.15.1

gkectl diagnose snapshot --log-since kann das Zeitfenster für journalctl-Befehle, die auf den Clusterknoten ausgeführt werden, nicht begrenzen

Dies wirkt sich nicht auf die Funktion zum Erstellen eines Cluster-Snapshots aus, da der Snapshot weiterhin alle Logs enthält, die standardmäßig durch Ausführen von journalctl auf den Clusterknoten erfasst werden. Daher werden keine Informationen zur Fehlerbehebung übersehen.
Installation, Upgrades und Updates 1.9+, 1.10+, 1.11+, 1.12+

gkectl prepare windows fehlgeschlagen

gkectl prepare windows kann Docker in GKE in VMware-Versionen vor 1.13 nicht installieren, da MicrosoftDockerProvider verworfen wurde.


Workaround:

Die allgemeine Idee zur Umgehung dieses Problems besteht darin, ein Upgrade auf GKE on VMware 1.13 durchzuführen und mit dem gkectl von 1.13 eine Windows-VM-Vorlage und dann Windows-Knotenpools zu erstellen. Sie haben zwei Möglichkeiten, von Ihrer aktuellen Version zu GKE on VMware 1.13 zu gelangen (siehe unten).

Hinweis: Wir haben Möglichkeiten, dieses Problem in der aktuellen Version zu umgehen, ohne ein Upgrade auf Version 1.13 durchführen zu müssen. Es sind jedoch weitere manuelle Schritte erforderlich. Wenden Sie sich an unser Supportteam, wenn Sie diese Option in Betracht ziehen möchten.


Option 1:Blau/Grün-Upgrade

Sie können einen neuen Cluster mit GKE on VMware Version 1.13 oder höher mit Windows-Knotenpools erstellen, Ihre Arbeitslasten zum neuen Cluster migrieren und dann den aktuellen Cluster herunterfahren. Es wird empfohlen, die neueste Nebenversion von GKE on VMware zu verwenden.

Hinweis: Dies erfordert zusätzliche Ressourcen für die Bereitstellung des neuen Clusters, aber weniger Ausfallzeiten und Unterbrechungen bei vorhandenen Arbeitslasten.


Option 2: Beim Upgrade auf GKE on VMware 1.13 Windows-Knotenpools löschen und wieder hinzufügen

Hinweis: Bei dieser Option können die Windows-Arbeitslasten erst dann ausgeführt werden, wenn der Cluster auf 1.13 aktualisiert wurde und die Windows-Knotenpools wieder hinzugefügt wurden.

  1. Löschen Sie vorhandene Windows-Knotenpools. Entfernen Sie dazu die Konfiguration für Windows-Knotenpools aus der Datei user-cluster.yaml und führen Sie dann den folgenden Befehl aus: 
    gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  2. Führen Sie ein Upgrade der Linux-Administrator- und Nutzercluster auf 1.12 durch. Folgen Sie dazu dem Nutzerhandbuch für das Upgrade für die entsprechende Ziel-Nebenversion.
  3. (Führen Sie diesen Schritt vor dem Upgrade auf 1.13 aus.) Achten Sie darauf, dass enableWindowsDataplaneV2: true in der Antwortvorlage OnPremUserCluster konfiguriert ist. Andernfalls verwendet der Cluster weiterhin Docker für Windows-Knotenpools. Diese sind nicht mit der neu erstellten Windows-VM-Vorlage 1.13 kompatibel, auf der Docker nicht installiert ist. Wenn die Datei nicht konfiguriert oder auf „false“ gesetzt ist, aktualisieren Sie den Cluster in „user-cluster.yaml“ auf „true“ und führen Sie dann folgenden Befehl aus: 
    gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  4. Führen Sie ein Upgrade der Linux-Administrator- und Nutzercluster auf Version 1.13 durch. Folgen Sie dazu dem Nutzerhandbuch für das Upgrade.
  5. Bereiten Sie die Windows-VM-Vorlage mit gkectl 1.13 vor: 
    gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG
  6. Fügen Sie die Windows-Knotenpoolkonfiguration wieder in user-cluster.yaml ein, wobei das Feld OSImage auf die neu erstellte Windows-VM-Vorlage gesetzt ist.
  7. Cluster aktualisieren, um Windows-Knotenpools hinzuzufügen 
    gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
Installation, Upgrades und Updates 1.13.0–1.13.9, 1.14.0–1.14.5, 1.15.0–1.15.1

RootDistanceMaxSec-Konfiguration wird für ubuntu Knoten nicht wirksam

Auf den Knoten wird der Standardwert von 5 Sekunden für RootDistanceMaxSec verwendet, anstelle von 20 Sekunden, wie dies die erwartete Konfiguration sein sollte. Wenn Sie das Startlog des Knotens prüfen, indem Sie eine SSH-Verbindung zur VM herstellen, die sich in „/var/log/startup.log“ befindet, wird der folgende Fehler angezeigt:

+ has_systemd_unit systemd-timesyncd
/opt/bin/master.sh: line 635: has_systemd_unit: command not found

Die Verwendung eines RootDistanceMaxSec-Werts von 5 Sekunden kann dazu führen, dass die Systemuhr mit dem NTP-Server nicht synchron ist, wenn die Zeitverschiebung größer als 5 Sekunden ist.


Workaround:

Wenden Sie das folgende DaemonSet auf Ihren Cluster an, um RootDistanceMaxSec zu konfigurieren:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: change-root-distance
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: change-root-distance
  template:
    metadata:
      labels:
        app: change-root-distance
    spec:
      hostIPC: true
      hostPID: true
      tolerations:
      # Make sure pods gets scheduled on all nodes.
      - effect: NoSchedule
        operator: Exists
      - effect: NoExecute
        operator: Exists
      containers:
      - name: change-root-distance
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          while true; do
            conf_file="/etc/systemd/timesyncd.conf.d/90-gke.conf"
            if [ -f $conf_file ] && $(grep -q "RootDistanceMaxSec=20" $conf_file); then
              echo "timesyncd has the expected RootDistanceMaxSec, skip update"
            else
              echo "updating timesyncd config to RootDistanceMaxSec=20"
              mkdir -p /etc/systemd/timesyncd.conf.d
              cat > $conf_file << EOF
          [Time]
          RootDistanceMaxSec=20
          EOF
              systemctl restart systemd-timesyncd
            fi
            sleep 600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /
Upgrades und Updates 1.12.0–1.12.6, 1.13.0–1.13.6, 1.14.0–1.14.2

gkectl update admin schlägt aufgrund eines leeren Feldes osImageType fehl

Wenn Sie Version 1.13 gkectl zum Aktualisieren eines Administratorclusters der Version 1.12 verwenden, wird möglicherweise der folgende Fehler angezeigt:

Failed to update the admin cluster: updating OS image type in admin cluster
is not supported in "1.12.x-gke.x"

Wenn Sie gkectl update admin für Cluster der Version 1.13 oder 1.14 verwenden, wird möglicherweise die folgende Meldung in der Antwort angezeigt:

Exit with error:
Failed to update the cluster: the update contains multiple changes. Please
update only one feature at a time

Wenn Sie das gkectl-Log prüfen, sehen Sie möglicherweise, dass zu den mehreren Änderungen die Einstellung osImageType von einem leeren String in ubuntu_containerd gehört.

Diese Aktualisierungsfehler sind auf einen fehlerhaften Backfill des Felds osImageType in der Administratorclusterkonfiguration seit der Einführung in Version 1.9 zurückzuführen.


Workaround:

Führen Sie ein Upgrade auf eine Version von GKE on VMware durch, um das Problem zu beheben. Wenn für Sie kein Upgrade möglich ist, wenden Sie sich an Cloud Customer Care, um das Problem zu beheben.
Installation, Sicherheit 1,13, 1,14, 1,15, 1,16

SNI funktioniert nicht auf Nutzerclustern mit Controlplane V2

Die Möglichkeit, ein zusätzliches Bereitstellungszertifikat für den Kubernetes API-Server eines Nutzerclusters mit authentication.sni bereitzustellen, funktioniert nicht, wenn die Steuerungsebene V2 ( enableControlplaneV2: true) aktiviert ist.


Workaround:

Deaktivieren Sie Controlplane V2 (enableControlplaneV2: false), bis ein GKE on VMware-Patch mit der Lösung verfügbar ist, wenn Sie SNI verwenden müssen.
Installation 1.0–1.11, 1.12, 1.13.0–1.13.9, 1.14.0–1.14.5, 1.15.0–1.15.1

$ im Nutzernamen der privaten Registry verursacht einen Fehler beim Starten der Maschine der Administrator-Steuerungsebene

Die Maschine der Administrator-Steuerungsebene kann nicht gestartet werden, wenn der Nutzername der privaten Registry $ enthält. Beim Prüfen von /var/log/startup.log auf der Maschine der Administrator-Steuerungsebene wird der folgende Fehler angezeigt: 

++ REGISTRY_CA_CERT=xxx
++ REGISTRY_SERVER=xxx
/etc/startup/startup.conf: line 7: anthos: unbound variable

Workaround:

Verwenden Sie einen Nutzernamen für die private Registry ohne $ oder eine Version von GKE on VMware mit der Lösung.
Upgrades und Updates 1.12.0-1.12.4

Falsch positive Warnungen zu nicht unterstützten Änderungen während der Aktualisierung des Administratorclusters

Wenn Sie Administratorcluster aktualisieren, sehen Sie die folgenden falsch positiven Warnungen im Log und können sie ignorieren. 

    console.go:47] detected unsupported changes: &v1alpha1.OnPremAdminCluster{
      ...
      - 		CARotation:        &v1alpha1.CARotationConfig{Generated: &v1alpha1.CARotationGenerated{CAVersion: 1}},
      + 		CARotation:        nil,
      ...
    }
Upgrades und Updates 1.13.0–1.13.9, 1.14.0–1.14.5, 1.15.0–1.15.1

Aktualisieren des Nutzerclusters ist nach der Rotation des KSA-Signaturschlüssels fehlgeschlagen

Nachdem Sie KSA-Signaturschlüssel rotiert und anschließend einen Nutzercluster aktualisiert haben, schlägt gkectl update möglicherweise mit der folgenden Fehlermeldung fehl: 

Failed to apply OnPremUserCluster 'USER_CLUSTER_NAME-gke-onprem-mgmt/USER_CLUSTER_NAME':
admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request:
requests must not decrement *v1alpha1.KSASigningKeyRotationConfig Version, old version: 2, new version: 1"


Workaround:

Ändern Sie die Version Ihres KSA-Signaturschlüssels wieder in 1, behalten Sie jedoch die neuesten Schlüsseldaten bei:
  1. Prüfen Sie das Secret im Administratorcluster unter dem Namespace USER_CLUSTER_NAME und rufen Sie den Namen des Secrets für den ksa-signing-key-Schlüssel ab: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
  2. Kopieren Sie das Secret „ksa-signing-key“ und nennen Sie es den Namen „service-account-cert“: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secret KSA-KEY-SECRET-NAME -oyaml | \
sed 's/ name: .*/ name: service-account-cert/' | \
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME apply -f -
  3. Löschen Sie das vorherige Secret des KSA-Signaturschlüssels: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME
  4. Aktualisieren Sie das Feld data.data in der configmap von ksa-signing-key-rotation-stage auf '{"tokenVersion":1,"privateKeyVersion":1,"publicKeyVersions":[1]}': 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME \
edit configmap ksa-signing-key-rotation-stage
  5. Deaktivieren Sie den Validierungs-Webhook, um die Versionsinformationen in der benutzerdefinierten Ressource „OnPremUserCluster“ zu bearbeiten: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    resources:
    - onpremuserclusters
'
  6. Aktualisieren Sie in Ihrer benutzerdefinierten Ressource „OnPremUserCluster“ das Feld spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation auf 1: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
edit onpremusercluster USER_CLUSTER_NAME
  7. Warten Sie, bis der Zielnutzercluster bereit ist. So können Sie den Status prüfen: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
  8. Stellen Sie den Validierungs-Webhook für den Nutzercluster wieder her: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremuserclusters
'
  9. Vermeiden Sie eine weitere Rotation des KSA-Signaturschlüssels, bis der Cluster auf die Version mit der Fehlerkorrektur aktualisiert wurde.
Vorgang 1.13.1+, 1.14, 1., 1.16

Virtuelle F5 BIG-IP-Server werden nicht bereinigt, wenn Nutzercluster in Terraform gelöscht werden

Wenn Sie Terraform verwenden, um einen Nutzercluster mit einem F5 BIG-IP-Load-Balancer zu löschen, werden die virtuellen F5 BIG-IP-Server nach dem Löschen des Clusters nicht entfernt.


Workaround:

Folgen Sie der Anleitung zum Bereinigen der F5-Partition eines Nutzerclusters , um die F5-Ressourcen zu entfernen.
Installation, Upgrades und Updates 1.13.8, 1.14.4

Der Typcluster ruft Container-Images aus docker.io ab

Wenn Sie einen Administratorcluster der Version 1.13.8 oder Version 1.14.4 erstellen oder einen Administratorcluster auf Version 1.13.8 oder 1.14.4 upgraden, ruft der Typcluster die folgenden Container-Images aus docker.io ab:

  • docker.io/kindest/kindnetd
  • docker.io/kindest/local-path-provisioner
  • docker.io/kindest/local-path-helper

    • Wenn docker.io über Ihre Administratorworkstation nicht zugänglich ist, kann der Typcluster beim Erstellen oder Upgrade des Administratorclusters nicht aufgerufen werden. Wenn Sie den folgenden Befehl auf der Administratorworkstation ausführen, werden die entsprechenden Container angezeigt, die mit ErrImagePull ausstehen:

    docker exec gkectl-control-plane kubectl get pods -A

    Die Antwort enthält Einträge wie die folgenden:

    ...
kube-system         kindnet-xlhmr                             0/1
    ErrImagePull  0    3m12s
...
local-path-storage  local-path-provisioner-86666ffff6-zzqtp   0/1
    Pending       0    3m12s
...

    Diese Container-Images sollten in das Container-Image der Art des Clusters vorab geladen werden. Allerdings hat Art v0.18.0 ein Problem mit den vorinstallierten Container-Images, wodurch sie versehentlich aus dem Internet abgerufen werden.


    Workaround:

    Führen Sie die folgenden Befehle auf der Administratorworkstation aus, während die Erstellung oder das Upgrade des Administratorclusters aussteht:

    docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner:v0.0.23-kind.0
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501
    Vorgang 1.13.0–1.13.7, 1.14.0–1.14.4, 1.15.0

    Fehlgeschlagener Failover auf dem Nutzercluster und dem Administratorcluster der HA Controlplane V2, wenn das Netzwerk doppelte GARP-Anfragen herausfiltert

    Wenn Ihre Cluster-VMs mit einem Switch verbunden sind, der doppelte GARP-Anfragen (Gratuitous ARP) herausfiltert, kann bei der Keepalive-Lead-Auswahl eine Race-Bedingung auftreten, was dazu führt, dass einige Knoten falsche ARP-Tabelleneinträge enthalten.

    Die betroffenen Knoten können die virtuelle IP-Adresse der Steuerungsebene ping, allerdings kommt es bei einer TCP-Verbindung zur virtuellen IP-Adresse der Steuerungsebene zu einer Zeitüberschreitung.


    Workaround:

    Führen Sie den folgenden Befehl auf jedem Knoten der Steuerungsebene des betroffenen Clusters aus: 
        iptables -I FORWARD -i ens192 --destination CONTROL_PLANE_VIP -j DROP
    Upgrades und Updates 1.13.0–1.13.7, 1.14.0–1.14.4, 1.15.0

    vsphere-csi-controller muss nach der vCenter-Zertifikatsrotation neu gestartet werden

    vsphere-csi-controller sollte nach der vCenter-Zertifikatrotation sein vCenter-Secret aktualisieren. Das aktuelle System startet jedoch die Pods von vsphere-csi-controller nicht ordnungsgemäß neu, wodurch vsphere-csi-controller nach der Rotation abstürzt.

    Workaround:

    Folgen Sie für Cluster, die mit 1.13 und höher erstellt wurden, der Anleitung unten, um vsphere-csi-controller neu zu starten 

    kubectl --kubeconfig=ADMIN_KUBECONFIG rollout restart deployment vsphere-csi-controller -n kube-system
    Installation 1.10.3–1.10.7, 1.11, 1.12, 1.13.0–1.13.1

    Das Erstellen des Administratorclusters schlägt bei Clusterregistrierungsfehlern nicht fehl

    Selbst wenn die Clusterregistrierung während der Erstellung des Administratorclusters fehlschlägt, schlägt der Befehl gkectl create admin nicht bei dem Fehler fehl und ist möglicherweise erfolgreich. Das heißt, die Erstellung des Administratorclusters könnte „erfolgreich“ sein, ohne bei einer Flotte registriert zu sein.

    Zum Identifizieren des Symptoms können Sie im Log von „gkectl create admin“ nach den folgenden Fehlermeldungen suchen: 
    Failed to register admin cluster

    Sie können auch prüfen, ob der Cluster unter registrierten Clustern in der Cloud Console angezeigt wird.

    Workaround:

    Folgen Sie bei Clustern, die mit 1.12 und höher erstellt wurden, der Anleitung zum erneuten Registrierungsversuch des Administratorclusters nach der Clustererstellung. Bei Clustern, die mit früheren Versionen erstellt wurden,

    1. Hängen Sie ein falsches Schlüssel/Wert-Paar wie „foo: bar“ an Ihre Connect-Register-SA-Schlüsseldatei an
    2. Führen Sie gkectl update admin aus, um den Administratorcluster noch einmal zu registrieren.

    Upgrades und Updates 1.10, 1.11, 1.12, 1.13.0–1.13.1

    Die erneute Registrierung des Administratorclusters wird beim Upgrade des Administratorclusters möglicherweise übersprungen

    Wenn während des Administratorclusterupgrades eine Zeitüberschreitung beim Upgrade von Knoten der Nutzersteuerungsebene auftritt, wird der Administratorcluster nicht noch einmal mit der aktualisierten Version des Connect-Agents registriert.


    Workaround:

    Prüfen Sie, ob der Cluster unter registrierten Clustern angezeigt wird. Optional können Sie sich nach dem Einrichten der Authentifizierung beim Cluster anmelden. Wenn der Cluster noch registriert ist, können Sie die folgende Anleitung für einen neuen Registrierungsversuch überspringen. Folgen Sie bei Clustern, die auf Version 1.12 und höher aktualisiert wurden, nach der Clustererstellung der Anleitung zum erneuten Registrierungsversuch des Administratorclusters. Für Cluster, für die ein Upgrade auf frühere Versionen durchgeführt wurde:
    1. Hängen Sie ein falsches Schlüssel/Wert-Paar wie „foo: bar“ an Ihre Connect-Register-SA-Schlüsseldatei an
    2. Führen Sie gkectl update admin aus, um den Administratorcluster noch einmal zu registrieren.

    Konfiguration 1.15.0

    Falsche Fehlermeldung zu vCenter.dataDisk

    Bei einem Hochverfügbarkeits-Administratorcluster zeigt gkectl prepare diese falsche Fehlermeldung an:

    vCenter.dataDisk must be present in the AdminCluster spec

    Workaround:

    Sie können diese Fehlermeldung ignorieren.
    VMware 1.15.0

    Knotenpoolerstellung aufgrund redundanter VM-Host-Affinitätsregeln fehlgeschlagen

    Beim Erstellen eines Knotenpools mit VM-Host-Affinität kann eine Race-Bedingung dazu führen, dass mehrere VM-Host-Affinitätsregeln mit demselben Namen erstellt werden. Dies kann dazu führen, dass das Erstellen des Knotenpools fehlschlägt.


    Workaround:

    Entfernen Sie die alten redundanten Regeln, damit die Knotenpoolerstellung fortgesetzt werden kann. Diese Regeln haben den Namen [USER_CLUSTER_NAME]–[HASH].
    Vorgang 1.15.0

    gkectl repair admin-master kann aus folgendem Grund fehlschlagen: failed to delete the admin master node object and reboot the admin master VM

    Der Befehl gkectl repair admin-master kann aufgrund einer Race-Bedingung mit dem folgenden Fehler fehlschlagen. 

    Failed to repair: failed to delete the admin master node object and reboot the admin master VM


    Workaround:

    Dieser Befehl ist idempotent. Es kann sicher noch einmal ausgeführt werden, bis der Befehl erfolgreich ausgeführt wurde.
    Upgrades und Updates 1.15.0

    Pods verbleiben nach der Neuerstellung oder Aktualisierung eines Knotens der Steuerungsebene im Status „Fehlgeschlagen“

    Nachdem Sie einen Knoten der Steuerungsebene neu erstellt oder aktualisiert haben, behalten bestimmte Pods aufgrund eines Fehlers des NodeAffinity-Prädikats möglicherweise den Status Failed bei. Diese fehlgeschlagenen Pods haben keine Auswirkungen auf normale Clustervorgänge oder -integrität.


    Workaround:

    Sie können die fehlgeschlagenen Pods bedenkenlos ignorieren oder manuell löschen.
    Sicherheit, Konfiguration 1.15.0-1.15.1

    OnPremUserCluster ist aufgrund von Anmeldedaten der privaten Registry nicht bereit

    Wenn Sie vorbereitete Anmeldedaten und eine private Registry verwenden, aber keine vorbereiteten Anmeldedaten für Ihre private Registry konfiguriert haben, ist der OnPremUserCluster möglicherweise nicht bereit und Sie sehen die folgende Fehlermeldung: 

    failed to check secret reference for private registry …


    Workaround:

    Bereiten Sie die Anmeldedaten der privaten Registry für den Nutzercluster gemäß der Anleitung unter Vorbereitete Anmeldedaten konfigurieren vor.

    Upgrades und Updates 1.15.0

    gkectl upgrade admin schlägt mit StorageClass standard sets the parameter diskformat which is invalid for CSI Migration fehl

    Während des gkectl upgrade admin wird durch die Preflight-Prüfung für Speicher für die CSI-Migration bestätigt, dass die StorageClasses keine Parameter haben, die nach der CSI-Migration ignoriert werden. Wenn beispielsweise eine Speicherklasse mit dem Parameter diskformat vorhanden ist, markiert gkectl upgrade admin die Speicherklasse und meldet einen Fehler bei der Preflight-Validierung. Administratorcluster, die in GKE unter VMware 1.10 und davor erstellt wurden, haben eine Speicherklasse mit diskformat: thin, die diese Validierung nicht besteht. Diese Speicherklasse funktioniert jedoch auch nach der CSI-Migration weiterhin einwandfrei. Diese Fehler sollten stattdessen als Warnungen interpretiert werden.

    Weitere Informationen finden Sie im Abschnitt mit den Speicherklassenparametern unter In-Tree vSphere-Volumes zum vSphere Container Storage-Plug-in migrieren.


    Workaround:

    Nachdem Sie geprüft haben, ob der Cluster eine Speicherklasse mit Parametern hat, die nach der CSI-Migration ignoriert werden, führen Sie gkectl upgrade admin mit dem Flag --skip-validation-cluster-health aus.
    Speicher 1,15; 1,16

    Migrierte integrierte vSphere-Volumes, die das Windows-Dateisystem verwenden, können nicht mit dem vSphere-CSI-Treiber verwendet werden

    Unter bestimmten Bedingungen können Laufwerke schreibgeschützt an Windows-Knoten angehängt werden. Dies führt dazu, dass das entsprechende Volume in einem Pod schreibgeschützt ist. Dieses Problem tritt eher auf, wenn eine neue Gruppe von Knoten eine alte Gruppe von Knoten ersetzt (z. B. ein Clusterupgrade oder ein Knotenpoolupdate). Zustandsorientierte Arbeitslasten, die zuvor einwandfrei funktioniert haben, können möglicherweise nicht auf ihre Volumes auf dem neuen Knotensatz schreiben.


    Workaround:

    1. Rufen Sie die UID des Pods ab, der nicht auf sein Volume schreiben kann: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
    POD_NAME --namespace POD_NAMESPACE \
    -o=jsonpath='{.metadata.uid}{"\n"}'
    2. Rufen Sie mit PersistentClaim den Namen des Persistentes ab: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
    PVC_NAME --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.volumeName}{"\n"}'
    3. Ermitteln Sie den Namen des Knotens, auf dem der Pod ausgeführt wird: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
    --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.nodeName}{"\n"}'
    4. Fordern Sie PowerShell-Zugriff auf den Knoten an, entweder über SSH oder die vSphere-Weboberfläche.
    5. Legen Sie Umgebungsvariablen fest: 
      PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID
    6. Ermitteln Sie die Laufwerksnummer des Laufwerks, das mit dem PersistentVolume verknüpft ist: 
      PS C:\Users\administrator> disknum=(Get-Partition -Volume (Get-Volume -UniqueId ("\\?\"+(Get-Item (Get-Item
"C:\var\lib\kubelet\pods\$podid\volumes\kubernetes.io~csi\$pvname\mount").Target).Target))).DiskNumber
    7. Prüfen Sie, ob das Laufwerk readonly ist: 
      PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
      Das Ergebnis sollte True sein.
    8. Setzen Sie readonly auf false. 
      PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
    9. Löschen Sie den Pod, damit er neu gestartet wird: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
    --namespace POD_NAMESPACE
    10. Der Pod sollte für denselben Knoten geplant werden. Falls der Pod jedoch für einen neuen Knoten geplant wird, müssen Sie möglicherweise die vorherigen Schritte auf dem neuen Knoten wiederholen.

    Upgrades und Updates 1.12, 1.13.0–1.13.7, 1.14.0–1.14.4

    vsphere-csi-secret wird nach dem gkectl update credentials vsphere --admin-cluster nicht mehr aktualisiert

    Wenn Sie die vSphere-Anmeldedaten für einen Administratorcluster aktualisieren, nachdem Sie die Clusteranmeldedaten aktualisiert haben, verwendet vsphere-csi-secret im Namespace kube-system im Administratorcluster möglicherweise weiterhin die alten Anmeldedaten.


    Workaround:

    1. Rufen Sie den Namen des vsphere-csi-secret-Secrets ab: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
    2. Aktualisieren Sie die Daten des Secrets vsphere-csi-secret, das Sie im obigen Schritt erhalten haben: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system patch secret CSI_SECRET_NAME -p \
  "{\"data\":{\"config\":\"$( \
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets CSI_SECRET_NAME -ojsonpath='{.data.config}' \
      | base64 -d \
      | sed -e '/user/c user = \"VSPHERE_USERNAME_TO_BE_UPDATED\"' \
      | sed -e '/password/c password = \"VSPHERE_PASSWORD_TO_BE_UPDATED\"' \
      | base64 -w 0 \
    )\"}}"
    3. vsphere-csi-controller neu starten: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller
    4. Sie können den Roll-out-Status mit folgenden Elementen verfolgen: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
      Nachdem die Bereitstellung erfolgreich eingeführt wurde, sollte die aktualisierte vsphere-csi-secret vom Controller verwendet werden.
    Upgrades und Updates 1.10, 1.11, 1.12.0–1.12.6, 1.13.0–1.13.6, 1.14.0–1.14.2

    Absturzschleife von audit-proxy beim Aktivieren von Cloud-Audit-Logs mit gkectl update cluster

    audit-proxy könnte aufgrund einer leeren --cluster-name in einer Absturzschleife erscheinen. Dieses Verhalten wird durch einen Fehler in der Aktualisierungslogik verursacht, bei dem der Clustername nicht an den Audit-Proxy-Pod / das Containermanifest weitergegeben wird.


    Workaround:

    Stellen Sie bei einem v2-Nutzercluster der Steuerungsebene mit enableControlplaneV2: true über SSH eine Verbindung zum Computer der Nutzersteuerungsebene her und aktualisieren Sie /etc/kubernetes/manifests/audit-proxy.yaml mit --cluster_name=USER_CLUSTER_NAME.

    Bearbeiten Sie bei einem v1-Nutzercluster der Steuerungsebene den Container audit-proxy im Zustandsorientierten kube-apiserver, um --cluster_name=USER_CLUSTER_NAME hinzuzufügen:

    kubectl edit statefulset kube-apiserver -n USER_CLUSTER_NAME --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
    Upgrades und Updates 1.11, 1.12, 1.13.0–1.13.5, 1.14.0–1.14.1

    Zusätzliche erneute Bereitstellung der Steuerungsebene direkt nach gkectl upgrade cluster

    Direkt nach gkectl upgrade cluster werden die Pods der Steuerungsebene möglicherweise noch einmal bereitgestellt. Der Clusterstatus von gkectl list clusters wird von RUNNING in RECONCILING geändert. Bei Anfragen an den Nutzercluster kann es zu einer Zeitüberschreitung kommen.

    Dieses Verhalten ist darauf zurückzuführen, dass die Zertifikatsrotation der Steuerungsebene nach gkectl upgrade cluster automatisch erfolgt.

    Dieses Problem tritt nur bei Nutzerclustern auf, die die Steuerungsebene v2 NICHT verwenden.


    Workaround:

    Warten Sie, bis der Clusterstatus in gkectl list clusters wieder in RUNNING geändert wird, oder führen Sie ein Upgrade auf Versionen mit dieser Fehlerkorrektur durch: 1.13.6+, 1.14.2+ oder 1.15+.
    Upgrades und Updates 1.12.7

    Der fehlerhafte Release 1.12.7-gke.19 wurde entfernt

    GKE on VMware 1.12.7-gke.19 ist ein fehlerhafter Release, den Sie nicht verwenden sollten. Die Artefakte wurden aus dem Cloud Storage-Bucket entfernt.

    Workaround:

    Verwenden Sie stattdessen den Release 1.12.7-gke.20.
    Upgrades und Updates 1.12.0+, 1.13.0–1.13.7, 1.14.0–1.14.3

    gke-connect-agent verwendet nach der Aktualisierung der Registrierungsanmeldedaten weiterhin das ältere Image

    Wenn Sie die Anmeldedaten für die Registrierung mit einer der folgenden Methoden aktualisieren:

    • gkectl update credentials componentaccess, wenn keine private Registry verwendet wird
    • gkectl update credentials privateregistry, wenn Sie eine private Registry verwenden

    Möglicherweise verwendet gke-connect-agent weiterhin das ältere Image oder die gke-connect-agent-Pods können aufgrund von ImagePullBackOff nicht abgerufen werden.

    Dieses Problem wird in den GKE on VMware-Releases 1.13.8, 1.14.4 und nachfolgenden Releases behoben.


    Workaround:

    Option 1: Stellen Sie gke-connect-agent manuell noch einmal bereit:

    1. Löschen Sie den Namespace gke-connect: 
      kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect
    2. Stellen Sie gke-connect-agent noch einmal mit dem ursprünglichen Dienstkontoschlüssel für die Registrierung bereit (Schlüssel muss nicht aktualisiert werden):

      Für Administratorcluster: 
      gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG_FILE --admin-cluster
      Für Nutzercluster: 
      gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

    Option 2: Sie können die Daten des Image-Pull-Secrets regcred, das von der gke-connect-agent-Bereitstellung verwendet wird, manuell ändern:

    kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch secrets regcred -p "{\"data\":{\".dockerconfigjson\":\"$(kubectl --kubeconfig=KUBECONFIG -n=kube-system get secrets private-registry-creds -ojsonpath='{.data.\.dockerconfigjson}')\"}}"

    Option 3: So fügen Sie das Standard-Image-Pull-Secret für Ihren Cluster im gke-connect-agent-Deployment hinzu:

    1. Kopieren Sie das Standard-Secret in den Namespace gke-connect: 
      kubectl --kubeconfig=KUBECONFIG -n=kube-system get secret private-registry-creds -oyaml | sed 's/ namespace: .*/ namespace: gke-connect/' | kubectl --kubeconfig=KUBECONFIG -n=gke-connect apply -f -
    2. Rufen Sie den gke-connect-agent-Bereitstellungsnamen ab: 
      kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
    3. Fügen Sie das Standard-Secret der gke-connect-agent-Bereitstellung hinzu: 
      kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch deployment DEPLOYMENT_NAME -p '{"spec":{"template":{"spec":{"imagePullSecrets": [{"name": "private-registry-creds"}, {"name": "regcred"}]}}}}'
    Installation 1,13, 1,14

    Fehler bei der manuellen Prüfung der Konfiguration des Load-Balancers

    Wenn Sie die Konfiguration validieren, bevor Sie einen Cluster mit manuellem Load-Balancer erstellen, indem Sie gkectl check-config ausführen, schlägt der Befehl mit den folgenden Fehlermeldungen fehl.

     - Validation Category: Manual LB    Running validation check for "Network 
configuration"...panic: runtime error: invalid memory address or nil pointer 
dereference

    Workaround:

    Option 1: Du kannst die Patchversion 1.13.7 und 1.14.4 verwenden, die die Korrektur enthalten.

    Option 2: Sie können auch denselben Befehl ausführen, um die Konfiguration zu validieren, aber die Validierung des Load-Balancers überspringen.

    gkectl check-config --skip-validation-load-balancer
    Vorgang 1,0, 1,1, 1,2, 1,3, 1,4, 1,5, 1,6, 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13 und 1,14

    EZD-Smartwatch-Aushunger

    Bei Clustern, auf denen die etcd-Version 3.4.13 oder niedriger ausgeführt wird, kann es zu einem Watch-Mangel und nicht operativen Ressourcen-Uhren kommen, was zu folgenden Problemen führen kann:

    • Pod-Planung ist unterbrochen
    • Knoten können nicht registriert werden
    • Kubelet beobachtet keine Pod-Änderungen

    Diese Probleme können dazu führen, dass der Cluster nicht mehr funktioniert.

    Dieses Problem wurde in den GKE on VMware-Releases 1.12.7, 1.13.6, 1.14.3 und nachfolgenden Releases behoben. Diese neueren Releases verwenden die etcd-Version 3.4.21. Von diesem Problem sind alle früheren Versionen von GKE on VMware betroffen.

    Problemumgehung

    Wenn Sie kein sofortiges Upgrade durchführen können, können Sie das Risiko eines Clusterausfalls verringern, indem Sie die Anzahl der Knoten im Cluster reduzieren. Entfernen Sie Knoten, bis der Messwert etcd_network_client_grpc_sent_bytes_total unter 300 Mbit/s liegt.

    So rufen Sie diesen Messwert im Metrics Explorer auf:

    1. Rufen Sie in der Google Cloud Console den Metrics Explorer auf:

      Zum Metrics Explorer

    2. Wählen Sie den Tab Konfiguration aus.
    3. Maximieren Sie Messwert auswählen, geben Sie Kubernetes Container in die Filterleiste ein und wählen Sie dann über die Untermenüs den Messwert aus:
      1. Wählen Sie im Menü Aktive Ressourcen die Option Kubernetes-Container aus.
      2. Wählen Sie im Menü Aktive Messwertkategorien die Option Anthos aus.
      3. Wählen Sie im Menü Aktive Messwerte die Option etcd_network_client_grpc_sent_bytes_total aus.
      4. Klicken Sie auf „Anwenden“.
    Upgrades und Updates 1.10, 1.11, 1.12, 1.13 und 1.14

    GKE Identity Service kann Latenzen der Steuerungsebene verursachen.

    Bei Clusterneustarts oder ‐upgrades kann der GKE Identity Service mit Traffic überlastet werden, der aus abgelaufenen JWT-Tokens besteht, die über den Authentifizierungs-Webhook von kube-apiserver an GKE Identity Service weitergeleitet werden. Der GKE Identity Service führt zwar keine Absturzschleife durch, reagiert jedoch nicht mehr und stellt keine weiteren Anfragen mehr bereit. Dieses Problem führt letztendlich zu höheren Latenzen der Steuerungsebene.

    Dieses Problem wurde in den folgenden GKE on VMware-Releases behoben:

    • 1.12.6+
    • 1.13.6+
    • 1.14.2+

    So finden Sie heraus, ob Sie von diesem Problem betroffen sind:

    1. Prüfen Sie, ob der Endpunkt des GKE Identity Service extern erreichbar ist: 
      curl -s -o /dev/null -w "%{http_code}" \
    -X POST https://CLUSTER_ENDPOINT/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'

      Ersetzen Sie CLUSTER_ENDPOINT durch die virtuelle IP-Adresse der Steuerungsebene und den Load-Balancer-Port der Steuerungsebene für Ihren Cluster (z. B. 172.16.20.50:443).

      Wenn Sie von diesem Problem betroffen sind, gibt der Befehl den Statuscode 400 zurück. Wenn das Zeitlimit für die Anfrage überschritten wird, starten Sie den Pod ais neu und führen Sie den Befehl curl noch einmal aus, um zu sehen, ob das Problem dadurch behoben wird. Wenn Sie den Statuscode 000 erhalten, wurde das Problem behoben und Sie sind fertig. Wenn Sie weiterhin den Statuscode 400 erhalten, wird der HTTP-Server des GKE Identity Service nicht gestartet. Fahren Sie in diesem Fall fort.

    2. Prüfen Sie die Logs von GKE Identity Service und kube-apiserver:
      1. Prüfen Sie das GKE Identity-Dienstlog: 
        kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG

        Wenn das Protokoll einen Eintrag wie den folgenden enthält, sind Sie von diesem Problem betroffen:

        I0811 22:32:03.583448      32 authentication_plugin.cc:295] Stopping OIDC authentication for ???. Unable to verify the OIDC ID token: JWT verification failed: The JWT does not appear to be from this identity provider. To match this provider, the 'aud' claim must contain one of the following audiences:
      2. Prüfen Sie die kube-apiserver-Logs für Ihre Cluster:

        In den folgenden Befehlen ist KUBE_APISERVER_POD der Name des Pods kube-apiserver im angegebenen Cluster.

        Administratorcluster:

        kubectl --kubeconfig ADMIN_KUBECONFIG logs \
    -n kube-system KUBE_APISERVER_POD kube-apiserver

        Nutzercluster:

        kubectl --kubeconfig ADMIN_KUBECONFIG logs \
    -n USER_CLUSTER_NAME KUBE_APISERVER_POD kube-apiserver

        Wenn die kube-apiserver-Logs Einträge wie die folgenden enthalten, sind Sie von diesem Problem betroffen:

        E0811 22:30:22.656085       1 webhook.go:127] Failed to make webhook authenticator request: error trying to reach service: net/http: TLS handshake timeout
E0811 22:30:22.656266       1 authentication.go:63] "Unable to authenticate the request" err="[invalid bearer token, error trying to reach service: net/http: TLS handshake timeout]"

    Problemumgehung

    Wenn Sie Ihre Cluster nicht sofort aktualisieren können, um das Problem zu beheben, können Sie die betroffenen Pods identifizieren und neu starten:

    1. Erhöhen Sie die Ausführlichkeitsstufe des GKE Identity Service auf 9: 
      kubectl patch deployment ais -n anthos-identity-service --type=json \
    -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", \
    "value":"--vmodule=cloud/identity/hybrid/charon/*=9"}]' \
    --kubeconfig KUBECONFIG
    2. Prüfen Sie das GKE Identity Service-Log auf den ungültigen Tokenkontext: 
      kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG
    3. Parsen Sie jedes zugehörige Dienstkonto-Secret mit dem folgenden Befehl, um die Tokennutzlast abzurufen, die mit jedem ungültigen Tokenkontext verknüpft ist:
      kubectl -n kube-system get secret SA_SECRET \
    --kubeconfig KUBECONFIG \
    -o jsonpath='{.data.token}' | base64 --decode
    4. Um das Token zu decodieren und den Namen und den Namespace des Quell-Pods aufzurufen, kopieren Sie das Token in den Debugger unter jwt.io.
    5. Starten Sie die in den Tokens identifizierten Pods neu.
    Vorgang 1,8, 1,9, 1,10

    Die Speichernutzung erhöht das Problem von etcd-wartungs-Pods

    Die etcd-Wartungs-Pods, die das Image etcddefrag:gke_master_etcddefrag_20210211.00_p0 verwenden, sind betroffen. Mit dem Container „etcddefrag“ wird während jedes Defragmentierungszyklus eine neue Verbindung zum etcd-Server hergestellt. Die alten Verbindungen werden nicht bereinigt.


    Workaround:

    Option 1: Führen Sie ein Upgrade auf die neueste Patchversion von 1.8 auf 1.11 durch, die die Fehlerkorrektur enthält.

    Option 2: Wenn Sie eine Patchversion vor 1.9.6 und 1.10.3 verwenden, müssen Sie den etcd-Wartungs-Pod für Administrator- und Nutzercluster herunterskalieren:

    kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n kube-system --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    Vorgang 1,9, 1,10, 1,11, 1,12, 1,13

    Systemdiagnosen von Pods der Steuerungsebene des Nutzerclusters fehlen

    Sowohl der Cluster-Zustandscontroller als auch der Befehl gkectl diagnose cluster führen eine Reihe von Systemdiagnosen aus, einschließlich der Systemdiagnosen der Pods in den Namespaces. Allerdings beginnen sie damit, die Pods der Nutzersteuerungsebene versehentlich zu überspringen. Wenn Sie den v2-Modus der Steuerungsebene verwenden, hat dies keine Auswirkungen auf den Cluster.


    Workaround:

    Dies hat keine Auswirkungen auf die Arbeitslast- oder Clusterverwaltung. Wenn Sie die Integrität der Pods der Steuerungsebene prüfen möchten, können Sie die folgenden Befehle ausführen:

    kubectl get pods -owide -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    Upgrades und Updates 1.6+, 1.7+

    Upgrades von Administratorclustern auf 1.6 und 1.7 können von der Weiterleitung von k8s.gcr.io nach registry.k8s.io betroffen sein

    Kubernetes hat den Traffic am 20.03.2023 von k8s.gcr.io zu registry.k8s.io umgeleitet. In GKE on VMware 1.6.x und 1.7.x verwenden die Upgrades des Administratorclusters das Container-Image k8s.gcr.io/pause:3.2. Wenn Sie einen Proxy für Ihre Administratorworkstation verwenden und der Proxy registry.k8s.io nicht zulässt und das Container-Image k8s.gcr.io/pause:3.2 nicht lokal im Cache gespeichert wird, schlagen die Upgrades des Administratorclusters fehl, wenn das Container-Image abgerufen wird.


    Workaround:

    Fügen Sie registry.k8s.io der Zulassungsliste des Proxys für Ihre Administratorworkstation hinzu.
    Netzwerk 1.10, 1.11, 1.12.0–1.12.6, 1.13.0–1.13.6, 1.14.0–1.14.2

    Seesaw-Validierungsfehler beim Erstellen des Load-Balancers

    gkectl create loadbalancer schlägt mit folgender Fehlermeldung fehl:

    - Validation Category: Seesaw LB - [FAILURE] Seesaw validation: xxx cluster lb health check failed: LB"xxx.xxx.xxx.xxx" is not healthy: Get "http://xxx.xxx.xxx.xxx:xxx/healthz": dial tcpxxx.xxx.xxx.xxx:xxx: connect: no route to host

    Dies liegt daran, dass die Wippengruppendatei bereits vorhanden ist. Die Preflight-Prüfung versucht, einen nicht vorhandenen Wiederherstellungs-Load-Balancer zu validieren.

    Workaround:

    Entfernen Sie die vorhandene Seesaw-Gruppendatei für diesen Cluster. Der Dateiname lautet seesaw-for-gke-admin.yaml für den Administratorcluster und seesaw-for-{CLUSTER_NAME}.yaml für einen Nutzercluster.
    Netzwerk 1,14

    Anwendungszeitüberschreitungen, die durch Fehler beim Einfügen von Conntrack-Tabellen verursacht werden

    GKE on VMware Version 1.14 ist anfällig für Fehler beim Einfügen von Tabellen mit Netfilter-Verbindungsverfolgung (Conntrack), wenn Sie Ubuntu- oder COS-Betriebssystem-Images verwenden. Einfügungsfehler führen zu zufälligen Anwendungszeitüberschreitungen und können auch dann auftreten, wenn in der Conntrack-Tabelle Platz für neue Einträge vorhanden ist. Die Fehler werden durch Änderungen in Kernel 5.15 und höher verursacht, die das Einfügen von Tabellen je nach Kettenlänge einschränken.

    Um herauszufinden, ob Sie von diesem Problem betroffen sind, können Sie mit dem folgenden Befehl die Systemstatistiken des Kernel-Verbindungs-Tracking-Systems auf jedem Knoten überprüfen:

    sudo conntrack -S

    Die Antwort sieht so aus:

    cpu=0       found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 
cpu=1       found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 
cpu=2       found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 
cpu=3       found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 
cpu=4       found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 
cpu=5       found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0 
...

    Wenn ein chaintoolong-Wert in der Antwort eine Zahl ungleich null ist, sind Sie von diesem Problem betroffen.

    Problemumgehung

    Zur vorläufigen Abhilfe können Sie die Größe der Netfiler-Hash-Tabelle (nf_conntrack_buckets) und der Netfilter-Verbindungs-Tracking-Tabelle (nf_conntrack_max) erhöhen. Verwenden Sie die folgenden Befehle auf jedem Clusterknoten, um die Tabellengröße zu erhöhen:

    sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE
sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE

    Ersetzen Sie TABLE_SIZE durch die neue Größe in Byte. Der Standardwert für die Tabellengröße ist 262144. Es empfiehlt sich, einen Wert festzulegen, der dem 65.536-Fachen der Anzahl der Kerne auf dem Knoten entspricht. Wenn Ihr Knoten beispielsweise acht Kerne hat, legen Sie die Tabellengröße auf 524288 fest.
    Netzwerk 1.13.0-1.13.2

    Absturzschleife des Calico-Typha- oder anetd-Operators auf Windows-Knoten mit Controlplane v2

    Mit Steuerungsebene v2 oder einem neuen Installationsmodell wird calico-typha oder anetd-operator möglicherweise für Windows-Knoten geplant und geraten in eine Absturzschleife.

    Der Grund ist, dass die beiden Bereitstellungen alle Markierungen tolerieren, auch die Windows-Knotenmarkierung.


    Workaround:

    Führen Sie entweder ein Upgrade auf Version 1.13.3 oder höher aus oder führen Sie die folgenden Befehle aus, um die Bereitstellung „calico-typha“ oder „anetd-operator“ zu bearbeiten:

        # If dataplane v2 is not used.
    kubectl edit deployment -n kube-system calico-typha --kubeconfig USER_CLUSTER_KUBECONFIG
    # If dataplane v2 is used.
    kubectl edit deployment -n kube-system anetd-operator --kubeconfig USER_CLUSTER_KUBECONFIG

    Entferne die folgenden spec.template.spec.tolerations:

        - effect: NoSchedule
      operator: Exists
    - effect: NoExecute
      operator: Exists

    Fügen Sie außerdem die folgende Toleranz hinzu:

        - key: node-role.kubernetes.io/master
      operator: Exists
    Konfiguration 1.14.0-1.14.2

    Die Datei mit den Anmeldedaten der privaten Registry des Nutzerclusters kann nicht geladen werden

    Sie können möglicherweise keinen Nutzercluster erstellen, wenn Sie den Abschnitt privateRegistry mit den Anmeldedaten fileRef angeben. Das Preflight kann mit der folgenden Meldung fehlschlagen: 

    [FAILURE] Docker registry access: Failed to login.


    Workaround:

    • Wenn Sie das Feld nicht angeben wollten oder dieselben Anmeldedaten für die private Registry wie den Administratorcluster verwenden möchten, können Sie in der Konfigurationsdatei des Nutzerclusters einfach den Abschnitt privateRegistry entfernen oder kommentieren.
    • Wenn Sie für Ihren Nutzercluster bestimmte Anmeldedaten einer privaten Registry verwenden möchten, können Sie den Abschnitt privateRegistry vorübergehend folgendermaßen angeben:
      privateRegistry:
  address: PRIVATE_REGISTRY_ADDRESS
  credentials:
    username: PRIVATE_REGISTRY_USERNAME
    password: PRIVATE_REGISTRY_PASSWORD
  caCertPath: PRIVATE_REGISTRY_CACERT_PATH
      (HINWEIS: Dies ist nur eine vorübergehende Lösung. Diese Felder wurden bereits verworfen. Sie sollten beim Upgrade auf Version 1.14.3 oder höher die Datei mit den Anmeldedaten verwenden.)

    Operations 1.10+

    Anthos Service Mesh und andere Service Meshes, die nicht mit Dataplane v2 kompatibel sind

    Dataplane V2 übernimmt das Load-Balancing und erstellt einen Kernel-Socket anstelle eines paketbasierten DNAT. Dies bedeutet, dass Anthos Service Mesh keine Paketprüfung durchführen kann, da der Pod umgangen wird und nie IPTables verwendet.

    Dies zeigt sich im kostenlosen kube-proxy-Modus durch Verbindungsverlust oder falsches Traffic-Routing für Dienste mit Anthos Service Mesh, da der Sidecar keine Paketprüfung durchführen kann.

    Dieses Problem tritt in allen Versionen von GKE on Bare Metal 1.10 auf. Für einige neuere Versionen von 1.10 (1.10.2+) gibt es jedoch eine Problemumgehung.


    Workaround:

    Führen Sie entweder ein Upgrade auf Version 1.11 aus, um die vollständige Kompatibilität zu erhalten, oder führen Sie bei Ausführung von Version 1.10.2 oder höher folgenden Befehl aus:

        kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG

    Fügen Sie der configmap bpf-lb-sock-hostns-only: true hinzu und starten Sie dann das anetd-Daemonset neu:

          kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

    Speicher 1.12+, 1.13.3

    kube-controller-manager trennt nichtflüchtige Volumes möglicherweise nach 6 Minuten erzwungen

    Bei kube-controller-manager kann es zu einer Zeitüberschreitung kommen, wenn PV/PVCs nach 6 Minuten getrennt werden und die Verknüpfung erzwungen wird. Detaillierte Logs von kube-controller-manager enthalten Ereignisse wie die folgenden:

    $ cat kubectl_logs_kube-controller-manager-xxxx | grep "DetachVolume started" | grep expired

kubectl_logs_kube-controller-manager-gke-admin-master-4mgvr_--container_kube-controller-manager_--kubeconfig_kubeconfig_--request-timeout_30s_--namespace_kube-system_--timestamps:2023-01-05T16:29:25.883577880Z W0105 16:29:25.883446       1 reconciler.go:224] attacherDetacher.DetachVolume started for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f"
This volume is not safe to detach, but maxWaitForUnmountDuration 6m0s expired, force detaching

    Melden Sie sich beim Knoten an und führen Sie die folgenden Befehle aus, um das Problem zu prüfen:

    # See all the mounting points with disks
lsblk -f

# See some ext4 errors
sudo dmesg -T

    Im Kubelet-Log werden Fehler wie die folgenden angezeigt:

    Error: GetDeviceMountRefs check failed for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f" :
the device mount path "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount" is still mounted by other references [/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount

    Workaround:

    Stellen Sie über SSH eine Verbindung zum betroffenen Knoten her und starten Sie den Knoten neu.
    Upgrades und Updates 1.12+, 1.13+, 1.14+

    Clusterupgrade hängt, wenn CSI-Treiber eines Drittanbieters verwendet werden

    Sie können einen Cluster möglicherweise nicht upgraden, wenn Sie den CSI-Treiber eines Drittanbieters verwenden. Der Befehl gkectl cluster diagnose gibt möglicherweise den folgenden Fehler zurück:

    "virtual disk "kubernetes.io/csi/csi.netapp.io^pvc-27a1625f-29e3-4e4f-9cd1-a45237cc472c" IS NOT attached to machine "cluster-pool-855f694cc-cjk5c" but IS listed in the Node.Status"


    Workaround:

    Führen Sie das Upgrade mit der Option --skip-validation-all aus.
    Vorgang 1.10+, 1.11+, 1.12+, 1.13+, 1.14+

    gkectl repair admin-master erstellt die Administrator-Master-VM, ohne ein Upgrade der VM-Hardwareversion durchzuführen.

    Der über gkectl repair admin-master erstellte Administrator-Master-Knoten verwendet möglicherweise eine niedrigere VM-Hardwareversion als erwartet. Wenn das Problem auftritt, wird der Fehler im gkectl diagnose cluster-Bericht angezeigt. 

    CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue.


    Workaround:

    Fahren Sie den Administrator-Master-Knoten herunter und folgen Sie der Anleitung unter https://kb.vmware.com/s/article/1003746, um den Knoten auf die in der Fehlermeldung beschriebene erwartete Version zu aktualisieren, und starten Sie dann den Knoten.
    Betriebssystem 1.10+, 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16+

    VM gibt beim Herunterfahren/Neustarten das DHCP-Lease unerwartet frei, was zu IP-Änderungen führen kann

    In systemd v244 hat systemd-networkd eine Standardverhaltensänderung in der KeepConfiguration-Konfiguration. Vor dieser Änderung haben VMs beim Herunterfahren oder Neustarten keine DHCP-Lease-Release-Nachricht an den DHCP-Server gesendet. Nach dieser Änderung senden VMs eine solche Nachricht und geben die IP-Adressen an den DHCP-Server zurück. Daher kann die freigegebene IP-Adresse einer anderen VM neu zugewiesen und/oder der VM eine andere IP-Adresse zugewiesen werden, was zu einem IP-Konflikt (auf Kubernetes-, nicht auf vSphere-Ebene) und/oder einer IP-Änderung auf den VMs führt, wodurch die Cluster auf verschiedene Weise beeinträchtigt werden können.

    Es können beispielsweise die folgenden Symptome angezeigt werden.

    • Die vCenter-Benutzeroberfläche zeigt, dass keine VMs dieselbe IP-Adresse verwenden, aber kubectl get nodes -o wide gibt Knoten mit doppelten IP-Adressen zurück. 
      NAME   STATUS    AGE  VERSION          INTERNAL-IP    EXTERNAL-IP    OS-IMAGE            KERNEL-VERSION    CONTAINER-RUNTIME
node1  Ready     28h  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
node2  NotReady  71d  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
    • Neue Knoten können aufgrund des calico-node-Fehlers 
      2023-01-19T22:07:08.817410035Z 2023-01-19 22:07:08.817 [WARNING][9] startup/startup.go 1135: Calico node 'node1' is already using the IPv4 address 10.180.85.130.
2023-01-19T22:07:08.817514332Z 2023-01-19 22:07:08.817 [INFO][9] startup/startup.go 354: Clearing out-of-date IPv4 address from this node IP="10.180.85.130/24"
2023-01-19T22:07:08.825614667Z 2023-01-19 22:07:08.825 [WARNING][9] startup/startup.go 1347: Terminating
2023-01-19T22:07:08.828218856Z Calico node failed to start
      nicht gestartet werden


    Workaround:

    Stellen Sie das folgende DaemonSet auf dem Cluster bereit, um die Änderung des Standardverhaltens für systemd-networkd rückgängig zu machen. Die VMs, auf denen dieses DaemonSet ausgeführt wird, geben die IP-Adressen beim Herunterfahren/Neustart nicht für den DHCP-Server frei. Die IP-Adressen werden nach Ablauf der Leases automatisch vom DHCP-Server freigegeben. 

          apiVersion: apps/v1
      kind: DaemonSet
      metadata:
        name: set-dhcp-on-stop
      spec:
        selector:
          matchLabels:
            name: set-dhcp-on-stop
        template:
          metadata:
            labels:
              name: set-dhcp-on-stop
          spec:
            hostIPC: true
            hostPID: true
            hostNetwork: true
            containers:
            - name: set-dhcp-on-stop
              image: ubuntu
              tty: true
              command:
              - /bin/bash
              - -c
              - |
                set -x
                date
                while true; do
                  export CONFIG=/host/run/systemd/network/10-netplan-ens192.network;
                  grep KeepConfiguration=dhcp-on-stop "${CONFIG}" > /dev/null
                  if (( $? != 0 )) ; then
                    echo "Setting KeepConfiguration=dhcp-on-stop"
                    sed -i '/\[Network\]/a KeepConfiguration=dhcp-on-stop' "${CONFIG}"
                    cat "${CONFIG}"
                    chroot /host systemctl restart systemd-networkd
                  else
                    echo "KeepConfiguration=dhcp-on-stop has already been set"
                  fi;
                  sleep 3600
                done
              volumeMounts:
              - name: host
                mountPath: /host
              resources:
                requests:
                  memory: "10Mi"
                  cpu: "5m"
              securityContext:
                privileged: true
            volumes:
            - name: host
              hostPath:
                path: /
            tolerations:
            - operator: Exists
              effect: NoExecute
            - operator: Exists
              effect: NoSchedule

    Betrieb, Upgrades und Updates 1.12.0–1.12.5, 1.13.0–1.13.5, 1.14.0–1.14.1

    Der Dienstkontoschlüssel für den Komponentenzugriff wurde nach dem Upgrade des Administratorclusters von 1.11.x gelöscht

    Dieses Problem betrifft nur Administratorcluster, die von 1.11.x aktualisiert wurden, und keine Administratorcluster, die nach 1.12 neu erstellt werden.

    Nach dem Upgrade eines Clusters von 1.11.x auf 1.12.x wird das Feld component-access-sa-key im Secret admin-cluster-creds gelöscht. Sie können dies mit dem folgenden Befehl prüfen: 

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -o yaml | grep 'component-access-sa-key'
    Wenn Sie feststellen, dass die Ausgabe leer ist, wurde der Schlüssel gelöscht.

    Nachdem der Dienstkontoschlüssel für den Komponentenzugriff gelöscht wurde, können keine neuen Nutzercluster installiert oder vorhandene Nutzercluster aktualisiert werden. Im Folgenden finden Sie einige Fehlermeldungen, die auftreten können:

    • Preflight-Fehler bei der langsamen Validierung mit Fehlermeldung: "Failed to create the test VMs: failed to get service account key: service account is not configured."
    • Fehler bei der Vorbereitung durch gkectl prepare und Fehlermeldung: "Failed to prepare OS images: dialing: unexpected end of JSON input"
    • Wenn Sie einen Nutzercluster der Version 1.13 mit der Google Cloud Console oder der gcloud CLI aktualisieren und gkectl update admin --enable-preview-user-cluster-central-upgrade ausführen, um den Upgrade-Plattform-Controller bereitzustellen, schlägt der Befehl mit der Meldung "failed to download bundle to disk: dialing: unexpected end of JSON input" fehl. Sie sehen diese Meldung im Feld status in der Ausgabe von kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml.


    Problemumgehung:

    Fügen Sie den Dienstkontoschlüssel für den Komponentenzugriff manuell wieder in das Secret ein. Führen Sie dazu den folgenden Befehl aus: 

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -ojson | jq --arg casa "$(cat COMPONENT_ACESS_SERVICE_ACOOUNT_KEY_PATH | base64 -w 0)" '.data["component-access-sa-key"]=$casa' | kubectl --kubeconfig ADMIN_KUBECONFIG apply -f -
    Vorgang 1.13.0+, 1.14.0+

    Cluster-Autoscaling funktioniert nicht, wenn Controlplane V2 aktiviert ist

    Bei Nutzerclustern, die mit Controlplane V2 oder einem neuen Installationsmodell erstellt wurden, verwenden Knotenpools mit aktiviertem Autoscaling immer ihre autoscaling.minReplicas in der Datei user-cluster.yaml. Das Log des Clusters für Cluster-Autoscaling-Pods zeigt ebenfalls, dass sie fehlerhaft sind. 

      > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
  logs $CLUSTER_AUTOSCALER_POD --container_cluster-autoscaler
 TIMESTAMP  1 gkeonprem_provider.go:73] error getting onpremusercluster ready status: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
 TIMESTAMP 1 static_autoscaler.go:298] Failed to get node infos for groups: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
    Der Cluster-Autoscaling-Pod kann durch Ausführen der folgenden Befehle ermittelt werden. 
      > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
   get pods | grep cluster-autoscaler
cluster-autoscaler-5857c74586-txx2c                          4648017n    48076Ki    30s


    Problemumgehung:

    Deaktivieren Sie Autoscaling in allen Knotenpools mit „gkectl update cluster“, bis Sie ein Upgrade auf eine Version mit dieser Fehlerbehebung ausführen
    Installation 1.12.0–1.12.4, 1.13.0–1.13.3, 1.14.0

    CIDR ist in der IP-Blockdatei nicht zulässig

    Wenn Nutzer CIDR in der IP-Blockdatei verwenden, schlägt die Konfigurationsvalidierung mit dem folgenden Fehler fehl: 

    - Validation Category: Config Check
    - [FAILURE] Config: AddressBlock for admin cluster spec is invalid: invalid IP:
172.16.20.12/30


    Problemumgehung:

    Nehmen Sie einzelne IP-Adressen in die IP-Blockdatei auf, bis Sie ein Upgrade auf eine Version mit dieser Fehlerbehebung ausführen: 1.12.5, 1.13.4, 1.14.1+.
    Upgrades und Updates 1.14.0-1.14.1

    Beim Aktualisieren des Betriebssystem-Image-Typs in der Datei „admin-cluster.yaml“ wird nicht darauf gewartet, dass Maschinen der Nutzersteuerungsebene neu erstellt werden

    Wenn Sie in der Datei „admin-cluster.yaml“ den Betriebssystem-Image-Typ der Steuerungsebene aktualisieren und der entsprechende Nutzercluster über Controlplane V2 erstellt wurde, wird die Neuerstellung der Maschinen der Nutzersteuerungsebene möglicherweise nicht abgeschlossen, wenn der Befehl „gkectl“ abgeschlossen ist.


    Problemumgehung:

    Warten Sie nach Abschluss des Updates, bis die Maschinen der Nutzersteuerungsebene ebenfalls neu erstellt wurden. Überwachen Sie dazu die Image-Typen des Knotenbetriebs mit kubectl --kubeconfig USER_KUBECONFIG get nodes -owide. Wenn Sie beispielsweise ein Update von Ubuntu auf COS durchführen, sollten wir warten, bis alle Maschinen der Steuerungsebene vollständig von Ubuntu zu COS gewechselt sind, auch wenn der Aktualisierungsbefehl abgeschlossen ist.

    Vorgang 1.10, 1.11, 1.12, 1.13, 1.14.0

    Fehler beim Erstellen oder Löschen von Pods aufgrund eines Problems mit dem Authentifizierungstoken für das Calico CNI-Dienstkonto

    Ein Problem mit Calico in GKE on VMware 1.14.0 führt dazu, dass das Erstellen und Löschen von Pods mit der folgenden Fehlermeldung in der Ausgabe von kubectl describe pods fehlschlägt:

      error getting ClusterInformation: connection is unauthorized: Unauthorized

    Dieses Problem tritt erst 24 Stunden nach dem Erstellen oder Aktualisieren des Clusters mit Calico auf 1.14 auf.

    Administratorcluster verwenden immer Calico, während für Nutzercluster das Konfigurationsfeld „enableDataPlaneV2“ in der Datei „user-cluster.yaml“ vorhanden ist. Wenn dieses Feld auf „false“ gesetzt oder nicht angegeben ist, bedeutet dies, dass Sie Calico im Nutzercluster verwenden.

    Der install-cni-Container des Knotens erstellt eine kubeconfig-Datei mit einem Token, das 24 Stunden lang gültig ist. Dieses Token muss regelmäßig vom Pod calico-node erneuert werden. Der Pod calico-node kann das Token nicht verlängern, da er keinen Zugriff auf das Verzeichnis hat, das die kubeconfig-Datei auf dem Knoten enthält.


    Workaround:

    Dieses Problem wurde in GKE on VMware Version 1.14.1 behoben. Führen Sie ein Upgrade auf diese oder eine höhere Version durch.

    Wenn Sie nicht sofort ein Upgrade durchführen können, wenden Sie den folgenden Patch auf das DaemonSet calico-node in Ihrem Administrator- und Nutzercluster an:

      kubectl -n kube-system get daemonset calico-node \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f -

  kubectl -n kube-system get daemonset calico-node \
    --kubeconfig USER_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f -
    Ersetzen Sie Folgendes:
    • ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters.
    • USER_CLUSTER_CONFIG_FILE: der Pfad Ihrer Nutzercluster-Konfigurationsdatei.
    Installation 1.12.0–1.12.4, 1.13.0–1.13.3, 1.14.0

    IP-Block-Validierung schlägt bei Verwendung von CIDR fehl

    Der Cluster kann nicht erstellt werden, obwohl der Nutzer die richtige Konfiguration hat. Der Nutzer sieht, dass die Erstellung fehlschlägt, weil der Cluster nicht genügend IP-Adressen hat.


    Problemumgehung:

    Teilen Sie CIDRs in mehrere kleinere CIDR-Blöcke auf, z. B. aus 10.0.0.0/30 zu 10.0.0.0/31, 10.0.0.2/31. Es sollte ausreichend sein, solange N+1 CIDRs vorhanden sind, wobei N die Anzahl der Knoten im Cluster ist.

    Betrieb, Upgrades und Updates 1.11.0–1.11.1, 1.10.0–1.10.4, 1.9.0–1.9.6

    Die Sicherung des Administratorclusters enthält nicht die Verschlüsselungsschlüssel und Konfiguration von Always-on-Secrets

    Wenn das Feature zur Verschlüsselung von immer aktiven Secrets zusammen mit der Clustersicherung aktiviert ist, enthält die Sicherung des Administratorclusters nicht die Verschlüsselungsschlüssel und die Konfiguration, die für die Verschlüsselung durch immer aktive Secrets erforderlich sind. Daher führt das Reparieren des Admin-Masters mit dieser Sicherung mit gkectl repair admin-master --restore-from-backup zu folgendem Fehler:

    Validating admin master VM xxx ...
Waiting for kube-apiserver to be accessible via LB VIP (timeout "8m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "13m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "18m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master

    Betrieb, Upgrades und Updates 1.10+

    Die Administrator-Master-VM mit einem neuen Bootlaufwerk (z.B. gkectl repair admin-master) schlägt fehl, wenn das Feature zur Verschlüsselung von immer aktiven Secrets mit dem Befehl „gkectl update“ aktiviert wird.

    Wenn das Feature zur Verschlüsselung von immer aktiven Secrets beim Erstellen des Clusters nicht, aber später mit dem gkectl update-Vorgang aktiviert ist, kann gkectl repair admin-master den Knoten der Steuerungsebene des Administratorclusters nicht reparieren. Es wird empfohlen, das Feature zur Verschlüsselung von immer aktiven Secrets bei der Clustererstellung zu aktivieren. Es gibt derzeit keine Abhilfe.

    Upgrades und Updates 1.10

    Durch ein Upgrade des ersten Nutzerclusters von 1.9 auf 1.10 werden Knoten in anderen Nutzerclustern neu erstellt

    Durch ein Upgrade des ersten Nutzerclusters von 1.9 auf 1.10 könnten Knoten in anderen Nutzerclustern unter demselben Administratorcluster neu erstellt werden. Die Neuerstellung erfolgt rollierend.

    Das disk_label wurde aus MachineTemplate.spec.template.spec.providerSpec.machineVariables entfernt, wodurch unerwartet ein Update für alle MachineDeployment ausgelöst wurde.


    Workaround:
    Upgrades und Updates 1.10.0

    Docker wird nach dem Clusterupgrade häufig neu gestartet

    Ein Upgrade des Nutzerclusters auf 1.10.0 kann zu häufigen Docker-Neustarts führen.

    Sie können dieses Problem erkennen, indem Sie kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG ausführen

    Eine Knotenbedingung zeigt an, ob der Docker häufig neu gestartet wird. Hier ist eine Beispielausgabe:

    Normal   FrequentDockerRestart    41m (x2 over 141m)     systemd-monitor  Node condition FrequentDockerRestart is now: True, reason: FrequentDockerRestart

    Um die Ursache zu verstehen, müssen Sie eine SSH-Verbindung zu dem Knoten herstellen, auf dem das Symptom auftritt, und Befehle wie sudo journalctl --utc -u docker oder sudo journalctl -x ausführen.


    Workaround:
    Upgrades und Updates 1,11, 1,12

    Selbst bereitgestellte GMP-Komponenten werden nach dem Upgrade auf Version 1.12 nicht beibehalten

    Wenn Sie eine GKE on VMware-Version unter 1.12 verwenden und manuell Komponenten von Google-verwaltetem Prometheus (GMP) im Namespace gmp-system für Ihren Cluster eingerichtet haben, werden die Komponenten beim Upgrade auf Version 1.12.x nicht beibehalten.

    Ab Version 1.12 werden GMP-Komponenten im gmp-system-Namespace und in CRDs vom stackdriver-Objekt verwaltet, wobei das Flag enableGMPForApplications standardmäßig auf false gesetzt ist. Wenn Sie vor dem Upgrade auf 1.12 GMP-Komponenten im Namespace manuell bereitstellen, werden die Ressourcen von stackdriver gelöscht.


    Workaround:
    Vorgang 1.11, 1.12, 1.13.0–1.13.1

    Fehlende ClusterAPI-Objekte im Cluster-Snapshot-Szenario system

    Im system-Szenario enthält der Cluster-Snapshot keine Ressourcen unter dem Namespace default.

    Einige Kubernetes-Ressourcen wie Cluster API-Objekte, die sich unter diesem Namespace befinden, enthalten jedoch nützliche Informationen zur Fehlerbehebung. Der Cluster-Snapshot sollte sie enthalten.


    Workaround:

    Sie können die folgenden Befehle manuell ausführen, um die Informationen zur Fehlerbehebung zu erfassen.

    export KUBECONFIG=USER_CLUSTER_KUBECONFIG
kubectl get clusters.cluster.k8s.io -o yaml
kubectl get controlplanes.cluster.k8s.io -o yaml
kubectl get machineclasses.cluster.k8s.io -o yaml
kubectl get machinedeployments.cluster.k8s.io -o yaml
kubectl get machines.cluster.k8s.io -o yaml
kubectl get machinesets.cluster.k8s.io -o yaml
kubectl get services -o yaml
kubectl describe clusters.cluster.k8s.io
kubectl describe controlplanes.cluster.k8s.io
kubectl describe machineclasses.cluster.k8s.io
kubectl describe machinedeployments.cluster.k8s.io
kubectl describe machines.cluster.k8s.io
kubectl describe machinesets.cluster.k8s.io
kubectl describe services
    , wobei:

    USER_CLUSTER_KUBECONFIG ist die kubeconfig-Datei des Nutzerclusters.
    Upgrades und Updates 1.11.0–1.11.4, 1.12.0–1.12.3, 1.13.0–1.13.1

    Das Löschen von Nutzerclustern bleibt im Knotenausgleich für die vSAN-Einrichtung hängen

    Beim Löschen, Aktualisieren oder Aktualisieren eines Nutzerclusters kann der Knotenausgleich in den folgenden Szenarien hängen bleiben:

    • Der Administratorcluster verwendet den vSphere-CSI-Treiber seit Version 1.12.x unter vSAN und
    • Im Administrator- und Nutzercluster werden keine PVC/PV-Objekte von integrierten vSphere-Plug-ins erstellt.

    Führen Sie den folgenden Befehl aus, um das Symptom zu identifizieren:

    kubectl logs clusterapi-controllers-POD_NAME_SUFFIX  --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAMESPACE

    Hier ist ein Beispiel für eine Fehlermeldung des obigen Befehls:

    E0920 20:27:43.086567 1 machine_controller.go:250] Error deleting machine object [MACHINE]; Failed to delete machine [MACHINE]: failed to detach disks from VM "[MACHINE]": failed to convert disk path "kubevols" to UUID path: failed to convert full path "ds:///vmfs/volumes/vsan:[UUID]/kubevols": ServerFaultCode: A general system error occurred: Invalid fault

    kubevols ist das Standardverzeichnis für den integrierten vSphere-Treiber. Wenn keine PVC/PV-Objekte erstellt werden, tritt möglicherweise der Fehler auf, dass der Knotenausgleich beim Ermitteln von kubevols hängt, da die aktuelle Implementierung davon ausgeht, dass kubevols immer vorhanden ist.


    Workaround:

    Erstellen Sie das Verzeichnis kubevols im Datenspeicher, in dem der Knoten erstellt wird. Dies wird im Feld vCenter.datastore in den Dateien user-cluster.yaml oder admin-cluster.yaml definiert.
    Konfiguration 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13, 1,14

    Cluster Autoscaler Clusterrolebinding und clusterrole werden nach dem Löschen eines Nutzerclusters gelöscht.

    Beim Löschen eines Nutzerclusters werden die entsprechenden clusterrole und clusterrolebinding für Cluster-Autoscaling ebenfalls gelöscht. Dies wirkt sich auf alle anderen Nutzercluster im selben Administratorcluster mit aktiviertem Cluster-Autoscaling aus. Das liegt daran, dass dieselbe clusterrole und clusterrolebinding für alle Cluster-Autoscaling-Pods innerhalb desselben Administratorclusters verwendet werden.

    Die Symptome sind folgende:

    • cluster-autoscaler-Logs
      • kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler
      , wobei ADMIN_CLUSTER_KUBECONFIG die kubeconfig-Datei des Administratorclusters ist. Hier ein Beispiel für Fehlermeldungen, die möglicherweise angezeigt werden: 
      2023-03-26T10:45:44.866600973Z W0326 10:45:44.866463       1 reflector.go:424] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
2023-03-26T10:45:44.866646815Z E0326 10:45:44.866494       1 reflector.go:140] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: Failed to watch *unstructured.Unstructured: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope

    Workaround:

    Konfiguration 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13

    Administratorcluster cluster-health-controller und vsphere-metrics-exporter funktionieren nach dem Löschen des Nutzerclusters nicht

    Beim Löschen eines Nutzerclusters wird auch der entsprechende clusterrole gelöscht. Dies führt dazu, dass die automatische Reparatur und der Export von vSphere-Messwerten nicht funktioniert.

    Die Symptome sind folgende:

    • cluster-health-controller-Logs
      • kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller
      , wobei ADMIN_CLUSTER_KUBECONFIG die kubeconfig-Datei des Administratorclusters ist. Hier ein Beispiel für Fehlermeldungen, die möglicherweise angezeigt werden: 
      error retrieving resource lock default/onprem-cluster-health-leader-election: configmaps "onprem-cluster-health-leader-election" is forbidden: User "system:serviceaccount:kube-system:cluster-health-controller" cannot get resource "configmaps" in API group "" in the namespace "default": RBAC: clusterrole.rbac.authorization.k8s.io "cluster-health-controller-role" not found
    • vsphere-metrics-exporter-Logs
      • kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
vsphere-metrics-exporter
      , wobei ADMIN_CLUSTER_KUBECONFIG die kubeconfig-Datei des Administratorclusters ist. Hier ein Beispiel für Fehlermeldungen, die möglicherweise angezeigt werden: 
      vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default"

    Workaround:

    Konfiguration 1.12.1–1.12.3, 1.13.0–1.13.2

    gkectl check-config schlägt bei der Betriebssystem-Image-Validierung fehl

    Ein bekanntes Problem, bei dem die gkectl check-config fehlschlagen kann, ohne gkectl prepare auszuführen. Das ist verwirrend, da wir empfehlen, den Befehl vor dem gkectl prepare auszuführen.

    Das Symptom ist, dass der Befehl gkectl check-config mit der folgenden Fehlermeldung fehlschlägt:

    Validator result: {Status:FAILURE Reason:os images [OS_IMAGE_NAME] don't exist, please run `gkectl prepare` to upload os images. UnhealthyResources:[]}

    Workaround:

    Option 1: Führen Sie gkectl prepare aus, um die fehlenden Betriebssystem-Images hochzuladen.

    Option 2: Verwenden Sie gkectl check-config --skip-validation-os-images, um die Validierung der Betriebssystem-Images zu überspringen.
    Upgrades und Updates 1,11, 1,12, 1,13

    gkectl update admin/cluster kann Anti-Affinitätsgruppen nicht aktualisieren

    Ein bekanntes Problem, bei dem der gkectl update admin/cluster beim Aktualisieren von anti affinity groups fehlschlägt.

    Das Symptom ist, dass der Befehl gkectl update mit der folgenden Fehlermeldung fehlschlägt:

    Waiting for machines to be re-deployed...  ERROR
Exit with error:
Failed to update the cluster: timed out waiting for the condition

    Workaround:
    Installation, Upgrades und Updates 1.13.0–1.13.8, 1.14.0–1.14.4, 1.15.0

    Knoten werden nicht registriert, wenn der konfigurierte Hostname einen Punkt enthält

    Die Knotenregistrierung schlägt während der Clustererstellung, des Upgrades, der Aktualisierung und der automatischen Knotenreparatur fehl, wenn ipMode.type den Wert static hat und der konfigurierte Hostname in der IP-Blockdatei einen oder mehrere Punkte enthält. In diesem Fall werden Zertifikatsignierungsanfragen (Certificate Signing Request, CSR) für einen Knoten nicht automatisch genehmigt.

    Führen Sie den folgenden Befehl aus, um die ausstehenden CSRs für einen Knoten anzuzeigen:

    kubectl get csr -A -o wide

    Prüfen Sie die folgenden Logs auf Fehlermeldungen:

    • Sehen Sie sich die Logs im Administratorcluster für den Container clusterapi-controller-manager im Pod clusterapi-controllers an: 
      kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n kube-system \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    • Führen Sie den folgenden Befehl aus, um dieselben Logs im Nutzercluster aufzurufen: 
      kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
      Dabei gilt:
      • ADMIN_CLUSTER_KUBECONFIG ist die kubeconfig-Datei des Administratorclusters.
      • USER_CLUSTER_NAME ist der Name des Nutzerclusters.
      Hier ein Beispiel für Fehlermeldungen, die möglicherweise angezeigt werden: "msg"="failed to validate token id" "error"="failed to find machine for node node-worker-vm-1" "validate"="csr-5jpx9"
    • Sehen Sie sich die kubelet-Logs auf dem problematischen Knoten an: 
      journalctl --u kubelet
      Hier ein Beispiel für Fehlermeldungen, die möglicherweise angezeigt werden: "Error getting node" err="node \"node-worker-vm-1\" not found"

    Wenn Sie im Feld für den Hostnamen einer IP-Blockdatei einen Domainnamen angeben, werden alle Zeichen nach dem ersten Punkt ignoriert. Wenn Sie den Hostnamen beispielsweise als bob-vm-1.bank.plc angeben, werden der VM-Hostname und der Knotenname auf bob-vm-1 festgelegt.

    Wenn die Knoten-ID-Überprüfung aktiviert ist, vergleicht der CSR-Genehmiger den Knotennamen mit dem Hostnamen in der Maschinenspezifikation und kann den Namen nicht abgleichen. Der Genehmiger lehnt die CSR ab und der Knoten kann kein Bootstrapping durchführen.


    Workaround:

    Nutzercluster

    Deaktivieren Sie die Überprüfung der Knoten-ID, indem Sie die folgenden Schritte ausführen:

    1. Fügen Sie der Konfigurationsdatei des Nutzerclusters die folgenden Felder hinzu: 
      disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
    2. Speichern Sie die Datei und aktualisieren Sie den Nutzercluster mit dem folgenden Befehl: 
      gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
      Ersetzen Sie Folgendes:
      • ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters.
      • USER_CLUSTER_CONFIG_FILE: der Pfad Ihrer Nutzercluster-Konfigurationsdatei.

    Administratorcluster

    1. Öffnen Sie die benutzerdefinierte Ressource OnPremAdminCluster zum Bearbeiten:
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit onpremadmincluster -n kube-system
    2. Fügen Sie der benutzerdefinierten Ressource die folgende Annotation hinzu:
      features.onprem.cluster.gke.io/disable-node-id-verification: enabled
    3. Bearbeiten Sie das Manifest kube-controller-manager in der Steuerungsebene des Administratorclusters:
      1. Stellen Sie eine SSH-Verbindung zum Knoten der Steuerungsebene des Administratorclusters her.
      2. Öffnen Sie das Manifest kube-controller-manager zum Bearbeiten:
        sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
      3. Rufen Sie die Liste der controllers auf: 
        --controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
      4. Aktualisieren Sie diesen Abschnitt wie unten gezeigt: 
        --controllers=*,bootstrapsigner,tokencleaner
    4. Öffnen Sie den Deployment Cluster API-Controller zum Bearbeiten:
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit deployment clusterapi-controllers -n kube-system
    5. Ändern Sie die Werte von node-id-verification-enabled und node-id-verification-csr-signing-enabled in false: 
      --node-id-verification-enabled=false
--node-id-verification-csr-signing-enabled=false
    Installation, Upgrades und Updates 1.11.0-1.11.4

    Startfehler beim Starten der Maschine der Administrator-Steuerungsebene, verursacht durch ein Zertifikatspaket der privaten Registry

    Das Erstellen bzw. Upgrade des Administratorclusters hängt dauerhaft im folgenden Log fest und kommt schließlich zu einer Zeitüberschreitung:

    Waiting for Machine gke-admin-master-xxxx to become ready...

    Das Cluster API-Controller-Log im externen Cluster-Snapshot enthält das folgende Log:

    Invalid value 'XXXX' specified for property startup-data

    Hier ist ein Beispieldateipfad für das Cluster API-Controller-Log:

    kubectlCommands/kubectl_logs_clusterapi-controllers-c4fbb45f-6q6g6_--container_vsphere-controller-manager_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--request-timeout_30s_--namespace_kube-system_--timestamps
    
    VMware has a 64k vApp property size limit. In the identified versions,
    the data passed via vApp property is close to the limit. When the private
    registry certificate contains a certificate bundle, it may cause the final
    data to exceed the 64k limit.
    
    
    Workaround:
    
    
    Only include the required certificates in the private registry
    certificate file configured in privateRegistry.caCertPath in
    the admin cluster config file.
    
    
    Or upgrade to a version with the fix when available.
    Networking 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    NetworkGatewayNodes marked unhealthy from concurrent status update conflict

    In networkgatewaygroups.status.nodes, some nodes switch between NotHealthy and Up.

    Logs for the ang-daemon Pod running on that node reveal repeated errors: 

    2022-09-16T21:50:59.696Z ERROR ANGd Failed to report status {"angNode": "kube-system/my-node", "error": "updating Node CR status: sending Node CR update: Operation cannot be fulfilled on networkgatewaynodes.networking.gke.io \"my-node\": the object has been modified; please apply your changes to the latest version and try again"}

    Der Status NotHealthy verhindert, dass der Controller dem Knoten zusätzliche Floating-IP-Adressen zuweist. Dies kann zu einer höheren Belastung anderer Knoten oder zu fehlender Redundanz für Hochverfügbarkeit führen.

    Die Dataplane-Aktivität ist ansonsten nicht betroffen.

    Ein Konflikt bezüglich des networkgatewaygroup-Objekts führt aufgrund eines Fehlers bei der Wiederholungsverarbeitung dazu, dass einige Statusaktualisierungen fehlschlagen. Wenn zu viele Statusaktualisierungen fehlschlagen, erkennt ang-controller-manager für den Knoten das Zeitlimit für den Heartbeat und markiert den Knoten als NotHealthy.

    Der Fehler bei der Wiederholungsbehandlung wurde in späteren Versionen behoben.


    Workaround:

    Führen Sie ein Upgrade auf eine korrigierte Version aus, falls verfügbar.
    Upgrades und Updates 1.12.0–1.12.2, 1.13.0

    Die Race-Bedingung verhindert das Löschen von Maschinenobjekten während eines Updates oder eines Upgrades

    Ein bekanntes Problem, das dazu führen kann, dass das Clusterupgrade oder -update beim Warten auf das Löschen des alten Maschinenobjekts hängen bleibt. Das liegt daran, dass der Finalierer nicht aus dem Maschinenobjekt entfernt werden kann. Dies wirkt sich auf jeden Rolling Update-Vorgang für Knotenpools aus.

    Das Problem besteht darin, dass der Befehl gkectl mit der folgenden Fehlermeldung das Zeitlimit überschreitet:

    E0821 18:28:02.546121   61942 console.go:87] Exit with error:
E0821 18:28:02.546184   61942 console.go:87] error: timed out waiting for the condition, message: Node pool "pool-1" is not ready: ready condition is not true: CreateOrUpdateNodePool: 1/3 replicas are updated
Check the status of OnPremUserCluster 'cluster-1-gke-onprem-mgmt/cluster-1' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

    In den clusterapi-controller-Pod-Logs sehen die Fehler so aus:

    $ kubectl logs clusterapi-controllers-[POD_NAME_SUFFIX] -n cluster-1
    -c vsphere-controller-manager --kubeconfig [ADMIN_KUBECONFIG]
    | grep "Error removing finalizer from machine object"
[...]
E0821 23:19:45.114993       1 machine_controller.go:269] Error removing finalizer from machine object cluster-1-pool-7cbc496597-t5d5p; Operation cannot be fulfilled on machines.cluster.k8s.io "cluster-1-pool-7cbc496597-t5d5p": the object has been modified; please apply your changes to the latest version and try again

    Der Fehler wird bei erfolgreichen Ausführungen für dieselbe Maschine mehrere Minuten lang wiederholt, auch ohne dieses Problem. In den meisten Fällen kann er schnell verarbeitet werden, aber in einigen seltenen Fällen kann er mehrere Stunden lang in dieser Race-Bedingung hängen.

    Das Problem ist, dass die zugrunde liegende VM bereits in vCenter gelöscht ist, das entsprechende Maschinenobjekt jedoch nicht entfernt werden kann. Es bleibt beim Entfernen des Finalizers aufgrund sehr häufiger Aktualisierungen von anderen Controllern hängen. Dies kann dazu führen, dass der Befehl gkectl zu einer Zeitüberschreitung führt, der Controller gleicht den Cluster jedoch weiter ab, sodass das Upgrade oder Aktualisierungsvorgang schließlich abgeschlossen wird.


    Workaround:

    Wir haben verschiedene Möglichkeiten zur Minderung dieses Problems vorbereitet, die von Ihrer Umgebung und Ihren Anforderungen abhängen.

    • Option 1: Warten Sie, bis das Upgrade irgendwann von selbst abgeschlossen ist.

      Basierend auf der Analyse und Reproduktion Ihrer Umgebung kann das Upgrade irgendwann ohne manuelles Eingreifen von selbst abgeschlossen werden. Diese Option ist jedoch nicht sicher, wie lange es dauert, bis der Finalierer für jedes Maschinenobjekt entfernt wurde. Sie kann bei Glück sofort durchgeführt werden oder mehrere Stunden andauern, wenn der Abgleich des Maschinensatz-Controllers zu schnell ist und der Maschinencontroller keine Möglichkeit hat, den Finalizer zwischen den Abgleichen zu entfernen.

      Der Vorteil ist, dass Sie bei dieser Option keine Maßnahmen ergreifen müssen und die Arbeitslasten nicht unterbrochen werden. Es dauert nur etwas länger, bis das Upgrade abgeschlossen ist.
    • Option 2: Sie wenden die Anmerkung zur automatischen Reparatur auf alle alten Maschinenobjekte an.

      Der Maschinensatz-Controller filtert die Maschinen heraus, bei denen die Anmerkung zur automatischen Reparatur und der Zeitstempel für die Löschung ungleich null sind, und sendet auf diesen Maschinen keine weiteren Löschaufrufe. Dies kann dazu beitragen, die Race-Bedingung zu vermeiden.

      Der Nachteil ist, dass die Pods auf den Maschinen direkt gelöscht und nicht entfernt werden. Die PDB-Konfiguration wird also nicht berücksichtigt. Dies kann zu Ausfallzeiten für Ihre Arbeitslasten führen.

      Der Befehl zum Abrufen aller Maschinennamen: 
      kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
      Der Befehl zum Anwenden der automatischen Reparatur-Annotation für jede Maschine: 
      kubectl annotate --kubeconfig CLUSTER_KUBECONFIG \
    machine MACHINE_NAME \
    onprem.cluster.gke.io/repair-machine=true

    Wenn dieses Problem auftritt und das Upgrade oder Update nach langer Zeit immer noch nicht abgeschlossen werden kann, wenden Sie sich an unser Supportteam, um Unterstützung zu erhalten.
    Installation, Upgrades und Updates 1.10.2, 1.11, 1.12, 1.13

    gkectl: Preflight-Fehler bei der Vorbereitung des Betriebssystem-Image-Validierungs

    Befehl gkectl prepare fehlgeschlagen mit:

    - Validation Category: OS Images
    - [FAILURE] Admin cluster OS images exist: os images [os_image_name] don't exist, please run `gkectl prepare` to upload os images.

    Die Preflight-Prüfungen von gkectl prepare enthielten eine falsche Validierung.


    Workaround:

    Führen Sie denselben Befehl mit dem zusätzlichen Flag --skip-validation-os-images aus.
    Installation 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13

    Die vCenter-URL mit dem Präfix https:// oder http:// kann zu einem Fehler beim Starten des Clusters führen

    Fehler beim Erstellen des Administratorclusters:

    Exit with error:
Failed to create root cluster: unable to apply admin base bundle to external cluster: error: timed out waiting for the condition, message:
Failed to apply external bundle components: failed to apply bundle objects from admin-vsphere-credentials-secret 1.x.y-gke.z to cluster external: Secret "vsphere-dynamic-credentials" is invalid:
[data[https://xxx.xxx.xxx.username]: Invalid value: "https://xxx.xxx.xxx.username": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+'), data[https://xxx.xxx.xxx.password]:
Invalid value: "https://xxx.xxx.xxx.password": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')]

    Die URL wird als Teil eines geheimen Schlüssels verwendet, der „/“ oder ":" nicht unterstützt.


    Workaround:

    Entfernen Sie das Präfix https:// oder http:// aus dem Feld vCenter.Address in der YAML-Konfigurationsdatei für Administratorcluster oder Nutzercluster.
    Installation, Upgrades und Updates 1,10, 1,11, 1,12, 1,13

    gkectl prepare Panik auf util.CheckFileExists

    Bei gkectl prepare kann bei dem folgenden Stacktrace eine Panik ausgelöst werden:

    panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xde0dfa]

goroutine 1 [running]:
gke-internal.googlesource.com/syllogi/cluster-management/pkg/util.CheckFileExists(0xc001602210, 0x2b, 0xc001602210, 0x2b) pkg/util/util.go:226 +0x9a
gke-internal.googlesource.com/syllogi/cluster-management/gkectl/pkg/config/util.SetCertsForPrivateRegistry(0xc000053d70, 0x10, 0xc000f06f00, 0x4b4, 0x1, 0xc00015b400)gkectl/pkg/config/util/utils.go:75 +0x85
...

    Das Problem ist, dass gkectl prepare das private Registry-Zertifikatsverzeichnis mit der falschen Berechtigung erstellt hat.


    Workaround:

    Führen Sie die folgenden Befehle auf der Administrator-Workstation aus, um dieses Problem zu beheben:

    sudo mkdir -p /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
sudo chmod 0755 /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
    Upgrades und Updates 1,10, 1,11, 1,12, 1,13

    gkectl repair admin-master und fortsetzbares Administratorupgrade funktionieren nicht zusammen

    Führen Sie nach einem fehlgeschlagenen Upgrade des Administratorclusters nicht gkectl repair admin-master aus. Dies kann dazu führen, dass nachfolgende Administratorupgrades fehlgeschlagen sind und Probleme wie der Einschaltfehler des Administrator-Masters oder der Zugriff auf die VM auftreten.


    Workaround:

    Wenn dieses Fehlerszenario bereits aufgetreten ist, wenden Sie sich an den Support.
    Upgrades und Updates 1,10; 1,11

    Ein fortgesetztes Upgrade des Administratorclusters kann dazu führen, dass die VM-Vorlage der Administrator-Steuerungsebene fehlt

    Wenn die Maschine der Administrator-Steuerungsebene nach einem fortgesetzten Upgrade-Versuch der Administrator-Steuerungsebene nicht neu erstellt wird, wird die VM-Vorlage der Administrator-Steuerungsebene gelöscht. Die VM-Vorlage der Administrator-Steuerungsebene ist die Vorlage des Administrator-Masters, die zum Wiederherstellen der Maschine der Steuerungsebene mit gkectl repair admin-master verwendet wird.


    Workaround:

    Die VM-Vorlage der Administrator-Steuerungsebene wird beim nächsten Upgrade des Administratorclusters neu generiert.
    Betriebssystem 1,12, 1,13

    cgroup v2 kann sich auf Arbeitslasten auswirken

    In Version 1.12.0 ist cgroup v2 (unified) standardmäßig für Knoten mit Container-Optimized OS (COS) aktiviert. Dies kann zu Instabilität für Ihre Arbeitslasten in einem COS-Cluster führen.


    Workaround:

    Wir sind in Version 1.12.1 wieder auf cgroup v1 (hybrid) umgestellt. Wenn Sie COS-Knoten verwenden, empfehlen wir ein Upgrade auf Version 1.12.1, sobald diese veröffentlicht wird.
    Identität 1,10, 1,11, 1,12, 1,13

    Benutzerdefinierte ClientConfig-Ressource

    gkectl update macht alle manuellen Änderungen rückgängig, die Sie an der benutzerdefinierten ClientConfig-Ressource vorgenommen haben.


    Workaround:

    Es wird dringend empfohlen, die ClientConfig-Ressource nach jeder manuellen Änderung zu sichern.
    Installation 1,10, 1,11, 1,12, 1,13

    gkectl check-config-Validierung schlägt fehl: F5 BIG-IP-Partitionen können nicht gefunden werden

    Die Validierung schlägt fehl, da F5 BIG-IP-Partitionen nicht gefunden werden können, obwohl sie vorhanden sind.

    Ein Problem mit der F5 BIG-IP API kann dazu führen, dass die Validierung fehlschlägt.


    Workaround:

    Versuchen Sie, gkectl check-config noch einmal auszuführen.
    Installation 1.12

    Die Installation des Nutzerclusters ist aufgrund eines Problems mit der Leader-Auswahl von cert-manager/ca-Injektor fehlgeschlagen

    Wenn apiserver/etcd langsam ist, wird möglicherweise ein Installationsfehler aufgrund von cert-manager-cainjector in der Absturzschleife angezeigt:

    # These are logs from `cert-manager-cainjector`, from the command
# `kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system
  cert-manager-cainjector-xxx`

I0923 16:19:27.911174       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition

E0923 16:19:27.911110       1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core:
  Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded

I0923 16:19:27.911593       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition

E0923 16:19:27.911629       1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"

    Workaround:
    VMware 1,10, 1,11, 1,12, 1,13

    vCenter für Versionen unter 7.0U2 neu starten oder aktualisieren

    Wenn vCenter bei Versionen vor 7.0U2 nach einem Upgrade oder anderweitig neu gestartet wird, ist der Netzwerkname in den VM-Informationen von vCenter falsch und die Maschine befindet sich im Status Unavailable. Dies führt schließlich dazu, dass die Knoten automatisch repariert werden, um neue zu erstellen.

    Ähnlicher govmomi-Fehler.


    Workaround:

    Diese Problemumgehung wird vom VMware-Support bereitgestellt:

    1. Das Problem wurde in vCenter-Version 7.0U2 und höher behoben.
    2. Klicken Sie bei niedrigeren Versionen mit der rechten Maustaste auf den Host und wählen Sie Verbindung > Trennen aus. Stellen Sie als Nächstes die Verbindung wieder her. Dadurch wird eine Aktualisierung der Portgruppe der VM erzwungen.
    Betriebssystem 1,10, 1,11, 1,12, 1,13

    SSH-Verbindung durch Remote-Host geschlossen

    Bei GKE on VMware Version 1.7.2 und höher werden die Ubuntu-Betriebssystem-Images mit CIS L1 Server Benchmark gehärtet.

    Damit die CIS-Regel „5.2.16 Sicherstellen, dass das SSH-Leerlaufzeitintervall konfiguriert ist“, hat /etc/ssh/sshd_config die folgenden Einstellungen:

    ClientAliveInterval 300
ClientAliveCountMax 0

    Diese Einstellungen dienen dazu, eine Clientsitzung nach 5 Minuten Inaktivität zu beenden. Der Wert ClientAliveCountMax 0 führt jedoch zu unerwartetem Verhalten. Wenn Sie die SSH-Sitzung auf der Administratorworkstation oder einem Clusterknoten verwenden, wird die SSH-Verbindung möglicherweise getrennt, auch wenn Ihr SSH-Client nicht inaktiv ist, z. B. beim Ausführen eines zeitaufwendigen Befehls. Der Befehl könnte mit der folgenden Meldung beendet werden:

    Connection to [IP] closed by remote host.
Connection to [IP] closed.

    Workaround:

    Sie haben folgende Möglichkeiten:

    • Verwenden Sie nohup, um zu verhindern, dass der Befehl bei der SSH-Trennung beendet wird,
      nohup gkectl upgrade admin --config admin-cluster.yaml \
    --kubeconfig kubeconfig
    • Aktualisieren Sie sshd_config so, dass ein ClientAliveCountMax-Wert ungleich null verwendet wird. Die CIS-Regel empfiehlt, einen Wert kleiner als 3 zu verwenden:
      sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' \
    /etc/ssh/sshd_config
sudo systemctl restart sshd

    Achten Sie darauf, die SSH-Sitzung neu zu verbinden.
    Installation 1,10, 1,11, 1,12, 1,13

    In Konflikt stehende cert-manager-Installation

    In Releases von 1.13 installiert monitoring-operator cert-manager im Namespace cert-manager. Wenn Sie aus bestimmten Gründen einen eigenen Cert-Manager installieren müssen, folgen Sie der folgenden Anleitung, um Konflikte zu vermeiden:

    Sie müssen diese Problemumgehung nur einmal auf jeden Cluster anwenden. Die Änderungen werden über das Clusterupgrade hinweg beibehalten.

    Hinweis: Ein häufiges Symptom bei der Installation eines eigenen cert-managers besteht darin, dass die cert-manager-Version oder das Image (z. B. v1.7.2) möglicherweise auf die ältere Version zurückgesetzt wird. Dies wird verursacht, wenn monitoring-operator versucht, cert-manager abzugleichen, und dabei die Version zurücksetzen.

    Workaround:

    <pKonflikte während des Upgrades vermeiden

    1. Deinstallieren Sie Ihre Version von cert-manager. Wenn Sie Ihre eigenen Ressourcen definiert haben, sollten Sie diese sichern .
    2. Führen Sie das Upgrade aus.
    3. Folgen Sie der Anleitung, um Ihren eigenen cert-manager wiederherzustellen.

    Eigenen cert-manager in Nutzerclustern wiederherstellen

    • Skalieren Sie das monitoring-operator-Deployment auf 0: 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n USER_CLUSTER_NAME \
    scale deployment monitoring-operator --replicas=0
    • Skalieren Sie die von monitoring-operator verwalteten cert-manager-Deployments auf 0: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-cainjector\
    --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook --replicas=0
    • Installiere deine Version von cert-manager neu. Stellen Sie Ihre benutzerdefinierten Ressourcen wieder her, falls vorhanden.
    • Sie können diesen Schritt überspringen, wenn Sie eine Upstream-Standardinstallation für cert-manager verwenden oder sich sicher sind, dass Ihr cert-manager im Namespace cert-manager installiert ist. Kopieren Sie andernfalls das Zertifikat metrics-ca cert-manager.io/v1 und die Ausstellerressourcen metrics-pki.cluster.local von cert-manager in den Clusterressourcen-Namespace Ihres installierten cert-managers. 
      relevant_fields='
{
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
    name: .metadata.name,
    namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
}
'
f1=$(mktemp)
f2=$(mktemp)
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get issuer -n cert-manager metrics-pki.cluster.local -o json \
    | jq "${relevant_fields}" > $f1
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get certificate -n cert-manager metrics-ca -o json \
    | jq "${relevant_fields}" > $f2
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2

    Eigenen cert-manager in Administratorclustern wiederherstellen

    Im Allgemeinen sollten Sie cert-manager in Administratorclustern nicht neu installieren müssen, da Administratorcluster nur Arbeitslasten der Steuerungsebene von GKE on VMware ausführen. In den seltenen Fällen, in denen Sie auch Ihren eigenen cert-manager in Administratorclustern installieren müssen, folgen Sie der folgenden Anleitung, um Konflikte zu vermeiden. Hinweis: Wenn Sie Apigee-Kunde sind und nur den cert-manager für Apigee benötigen, müssen Sie die Befehle des Administratorclusters nicht ausführen.

    • Skalieren Sie das monitoring-operator-Deployment auf 0. 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n kube-system scale deployment monitoring-operator --replicas=0
    • Skalieren Sie die von monitoring-operator verwalteten cert-manager-Deployments auf 0. 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager \
    --replicas=0

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     -n cert-manager scale deployment cert-manager-cainjector \
     --replicas=0

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook \
    --replicas=0
    • Installiere deine Version von cert-manager neu. Stellen Sie Ihre benutzerdefinierten Ressourcen wieder her, falls vorhanden.
    • Sie können diesen Schritt überspringen, wenn Sie eine Upstream-Standardinstallation für cert-manager verwenden oder sich sicher sind, dass Ihr cert-manager im Namespace cert-manager installiert ist. Kopieren Sie andernfalls das Zertifikat metrics-ca cert-manager.io/v1 und die Ausstellerressourcen metrics-pki.cluster.local von cert-manager in den Clusterressourcen-Namespace Ihres installierten cert-managers. 
      relevant_fields='
{
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
    name: .metadata.name,
    namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
}
'
f3=$(mktemp)
f4=$(mktemp)
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \n
    get issuer -n cert-manager metrics-pki.cluster.local -o json \
    | jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    get certificate -n cert-manager metrics-ca -o json \
    | jq "${relevant_fields}" > $f4
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4
    </p
    Betriebssystem 1,10, 1,11, 1,12, 1,13

    Falsch positive Ergebnisse beim Scannen auf Sicherheitslücken in Docker, Containerd und Runc

    Die Docker-, containerd- und runc-Images in den mit GKE on VMware enthaltenen Ubuntu-Betriebssystem-Images sind mit Ubuntu PPA an spezielle Versionen angepinnt. Dadurch wird sichergestellt, dass alle Änderungen an der Containerlaufzeit vor jedem Release von GKE on VMware qualifiziert werden.

    Die speziellen Versionen sind jedoch dem Ubuntu CVE-Tracker unbekannt, der von verschiedenen CVE-Scantools als Feeds für Sicherheitslücken verwendet wird. Daher werden in Docker-, containerd- und runc-Scans auf Sicherheitslücken falsch positive Meldungen ausgegeben.

    In den CVE-Scanergebnissen können beispielsweise die folgenden falsch positiven Ergebnisse angezeigt werden. Diese CVEs wurden bereits in den neuesten Patchversionen von GKE on VMware behoben.

    Weitere Informationen zu CVE-Korrekturen finden Sie in den Versionshinweisen.


    Workaround:

    Canonical ist sich dieses Problem bekannt. Die Fehlerbehebung ist unter https://github.com/canonical/sec-cvescan/issues/73 einsehbar.
    Upgrades und Updates 1,10, 1,11, 1,12, 1,13

    Die Netzwerkverbindung zwischen Administrator- und Nutzercluster ist während eines Clusterupgrades ohne Hochverfügbarkeit möglicherweise für kurze Zeit nicht verfügbar

    Wenn Sie Cluster ohne Hochverfügbarkeit von 1.9 auf 1.10 aktualisieren, stellen Sie möglicherweise fest, dass kubectl exec, kubectl log und der Webhook für Nutzercluster kurzzeitig nicht verfügbar sind. Diese Ausfallzeit kann bis zu einer Minute betragen. Dies liegt daran, dass die eingehende Anfrage (kubectl exec, kubectl log und Webhook) von kube-apiserver für den Nutzercluster verarbeitet wird. Nutzer „kube-apiserver“ ist ein Statefulset. In einem Cluster ohne Hochverfügbarkeit gibt es nur ein Replikat für das Statefulset. Während des Upgrades kann es also sein, dass der alte kube-apiserver nicht verfügbar ist, während der neue kube-apiserver noch nicht bereit ist.


    Workaround:

    Diese Ausfallzeit findet nur während des Upgrades statt. Wenn Sie während des Upgrades eine kürzere Ausfallzeit wünschen, empfehlen wir den Wechsel zu Hochverfügbarkeitsclustern.
    Installation, Upgrades und Updates 1,10, 1,11, 1,12, 1,13

    Prüfung der Konnectivity-Bereitschaft in der Hochverfügbarkeitsclusterdiagnose nach der Clustererstellung oder dem Upgrade fehlgeschlagen

    Wenn Sie einen Hochverfügbarkeitscluster erstellen oder upgraden und feststellen, dass die Konnectivity Readiness Check in der Clusterdiagnose fehlgeschlagen ist, wirkt sich dies in den meisten Fällen nicht auf die Funktionalität von GKE on VMware aus (kubectl exec, kubectl log und Webhook). Dies liegt daran, dass manchmal ein oder zwei der Konnktivitätsreplikate aufgrund von instabiler Netzwerkverbindung oder anderen Problemen für einen bestimmten Zeitraum unlesbar sind.


    Workaround:

    Die Konnektivität wird alleine wiederhergestellt. Warten Sie 30 Minuten bis eine Stunde und führen Sie die Clusterdiagnose noch einmal aus.
    Betriebssystem 1,7, 1,8, 1,9, 1,10, 1,11

    /etc/cron.daily/aide-CPU- und Speicherspitzenproblem

    Ab Version 1.7.2 von GKE on VMware werden die Ubuntu-Betriebssystem-Images mit CIS L1 Server Benchmark gehärtet.

    Daher wurde das Cron-Skript /etc/cron.daily/aide installiert, sodass eine aide-Prüfung geplant wird, um sicherzustellen, dass die CIS L1-Serverregel „1.4.2 Sicherstellen, dass die Dateisystemintegrität regelmäßig überprüft wird“ eingehalten wird.

    Der Cronjob wird täglich um 6:25 Uhr (UTC) ausgeführt. Abhängig von der Anzahl der Dateien im Dateisystem können zu dieser Zeit Spitzen bei der CPU- und Arbeitsspeichernutzung auftreten, die durch diesen aide-Prozess verursacht werden.


    Workaround:

    Wenn die Spitzen Ihre Arbeitslast beeinträchtigen, können Sie den täglichen Cronjob deaktivieren:

    sudo chmod -x /etc/cron.daily/aide
    Netzwerk 1,10, 1,11, 1,12, 1,13

    Load-Balancer und zustandsorientierte verteilte NSX-T-Firewallregeln interagieren unvorhersehbar

    Beim Bereitstellen von GKE auf VMware Version 1.9 oder höher, wenn das Deployment den gebündelten Seesaw-Load-Balancer in einer Umgebung enthält, die zustandsorientierte verteilte NSX-T-Firewallregeln verwendet, kann stackdriver-operator die ConfigMap gke-metrics-agent-conf möglicherweise nicht erstellen und dazu führen, dass gke-connect-agent-Pods in einer Absturzschleife vorkommen.

    Das zugrunde liegende Problem besteht darin, dass die zustandsorientierten verteilten NSX-T-Firewallregeln die Verbindung von einem Client zum Nutzercluster-API-Server über den Seesaw-Load-Balancer beenden, da Seesaw asymmetrische Verbindungsflüsse verwendet. Die Integrationsprobleme mit verteilten NSX-T-Firewallregeln wirken sich auf alle GKE on VMware-Releases aus, die Seesaw verwenden. Bei Ihren eigenen Anwendungen können ähnliche Verbindungsprobleme auftreten, wenn diese große Kubernetes-Objekte mit einer Größe von mehr als 32.000 KB erstellen.


    Workaround:

    Folgen Sie dieser Anleitung, um verteilte NSX-T-Firewallregeln zu deaktivieren oder zustandslose verteilte Firewallregeln für Seesaw-VMs zu verwenden.

    Wenn Ihre Cluster einen manuellen Load-Balancer verwenden, folgen Sie dieser Anleitung, um Ihren Load-Balancer so zu konfigurieren, dass Clientverbindungen zurückgesetzt werden, wenn ein Back-End-Knotenfehler erkannt wird. Ohne diese Konfiguration reagieren Clients des Kubernetes API-Servers möglicherweise mehrere Minuten lang, wenn eine Serverinstanz ausfällt.
    Logging und Monitoring 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

    Unerwartetes Monitoring der Abrechnung

    Bei den Versionen 1.10 bis 1.15 von GKE on VMware stellten einige Kunden auf der Seite Abrechnung eine unerwartet hohe Abrechnung für Metrics volume fest. Dieses Problem betrifft Sie nur, wenn alle der folgenden Umstände zutreffen:

    • Logging und Monitoring von Anwendungen sind aktiviert (enableStackdriverForApplications=true)
    • Anwendungs-Pods haben die Annotation prometheus.io/scrap=true. (Bei der Installation von Anthos Service Mesh kann diese Annotation auch hinzugefügt werden.)

    Wenn Sie prüfen möchten, ob Sie von diesem Problem betroffen sind, Listen Sie Ihre benutzerdefinierten Messwerte auf. Wenn Sie die Abrechnung unerwünschter Messwerte mit dem Namenspräfix external.googleapis.com/prometheus sehen und außerdem enableStackdriverForApplications in der Antwort von kubectl -n kube-system get stackdriver stackdriver -o yaml auf „true“ gesetzt ist, betrifft Sie dieses Problem.


    Problemumgehung

    Wenn Sie von diesem Problem betroffen sind, empfehlen wir Ihnen, Ihre Cluster auf Version 1.12 oder höher zu aktualisieren, das Flag enableStackdriverForApplications nicht mehr zu verwenden und zur neuen Anwendungsmonitoringlösung managed-service-for-prometheus zu wechseln, die nicht mehr von der Annotation prometheus.io/scrap=true abhängig ist. Mit der neuen Lösung können Sie die Erfassung von Logs und Messwerten für Ihre Anwendungen auch separat über das Flag enableCloudLoggingForApplications bzw. enableGMPForApplications steuern.

    Wenn Sie das Flag enableStackdriverForApplications nicht mehr verwenden möchten, öffnen Sie das Stackdriver-Objekt zur Bearbeitung:

    kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG --namespace kube-system edit stackdriver stackdriver

    Entfernen Sie die Zeile enableStackdriverForApplications: true, speichern und schließen Sie den Editor.

    Wenn Sie die anmerkungsbasierte Messwerterfassung nicht verlassen können, gehen Sie so vor:

    1. Ermitteln Sie die Quell-Pods und -Dienste mit den unerwünschten abgerechneten Messwerten. 
      kubectl --kubeconfig KUBECONFIG \
  get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
  services -A -o yaml | grep 'prometheus.io/scrape: "true"'
    2. Entfernen Sie die Annotation prometheus.io/scrap=true aus dem Pod oder Dienst. Wenn die Annotation von Anthos Service Mesh hinzugefügt wird, sollten Sie Anthos Service Mesh ohne die Prometheus-Option konfigurieren oder das Zusammenführen von Istio-Messwerten deaktivieren.
    Installation 1,11, 1,12, 1,13

    Installation schlägt beim Erstellen des vSphere-Datenlaufwerks fehl

    Das Installationsprogramm für GKE on VMware kann fehlschlagen, wenn benutzerdefinierte Rollen an die falsche Berechtigungsebene gebunden sind.

    Wenn die Rollenbindung falsch ist, bleibt das Erstellen eines vSphere-Datenlaufwerks mit govc hängen und das Laufwerk wird mit einer Größe von 0 erstellt. Zum Beheben des Problems sollten Sie die benutzerdefinierte Rolle auf der vSphere vCenter-Ebene (Root) binden.


    Workaround:

    Wenn Sie die benutzerdefinierte Rolle auf der DC-Ebene (oder niedriger als die Root-Ebene) binden möchten, müssen Sie die schreibgeschützte Rolle auch an den Nutzer auf der vCenter-Stammebene binden.

    Weitere Informationen zum Erstellen von Rollen finden Sie unter vCenter-Nutzerkontoberechtigungen.
    Logging und Monitoring 1.9.0–1.9.4, 1.10.0–1.10.1

    Hoher Netzwerktraffic zu „monitoring.googleapis.com“

    Unter Umständen wird auch in einem neuen Cluster ohne Nutzerarbeitslasten hoher Netzwerkverkehr zu monitoring.googleapis.com angezeigt.

    Dieses Problem betrifft die Versionen 1.10.0-1.10.1 und 1.9.0-1.9.4. Dieses Problem wurde in den Versionen 1.10.2 und 1.9.5 behoben.


    Workaround:
    Logging und Monitoring 1,10; 1,11

    gke-metrics-agent hat häufige CrashLoopBackOff-Fehler

    Bei GKE in VMware Version 1.10 und höher weist das DaemonSet „gke-metrics-agent“ häufig CrashLoopBackOff-Fehler auf, wenn „enableStackdriverForApplications“ im Objekt „Stackdriver“ auf „true“ gesetzt ist.


    Workaround:

    Um dieses Problem zu beheben, deaktivieren Sie die Erfassung von Anwendungsmesswerten, indem Sie die folgenden Befehle ausführen. Diese Befehle deaktivieren die Erfassung von Anwendungslogs nicht.

    1. Wenn Sie verhindern möchten, dass die folgenden Änderungen rückgängig gemacht werden, skalieren Sie stackdriver-operator herunter: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy stackdriver-operator \
    --replicas=0
      Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.
    2. Öffnen Sie die ConfigMap gke-metrics-agent-conf zum Bearbeiten:
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit configmap gke-metrics-agent-conf
    3. Kommentieren Sie unter services.pipelines den gesamten Abschnitt metrics/app-metrics aus: 
      services:
  pipelines:
    #metrics/app-metrics:
    #  exporters:
    #  - googlecloud/app-metrics
    #  processors:
    #  - resource
    #  - metric_to_resource
    #  - infer_resource
    #  - disk_buffer/app-metrics
    #  receivers:
    #  - prometheus/app-metrics
    metrics/metrics:
      exporters:
      - googlecloud/metrics
      processors:
      - resource
      - metric_to_resource
      - infer_resource
      - disk_buffer/metrics
      receivers:
      - prometheus/metrics
    4. Schließen Sie die Bearbeitungssitzung.
    5. Starten Sie das DaemonSet gke-metrics-agent neu:
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system rollout restart daemonset gke-metrics-agent
    Logging und Monitoring 1,11, 1,12, 1,13

    Verworfene Messwerte im Dashboard ersetzen

    Wenn in Ihren OOTB-Dashboards verworfene Messwerte verwendet werden, werden einige leere Diagramme angezeigt. Führen Sie die folgenden Befehle aus, um verworfene Messwerte in den Monitoring-Dashboards zu finden:

    gcloud monitoring dashboards list > all-dashboard.json

# find deprecated metrics
cat all-dashboard.json | grep -E \
  'kube_daemonset_updated_number_scheduled\
    |kube_node_status_allocatable_cpu_cores\
    |kube_node_status_allocatable_pods\
    |kube_node_status_capacity_cpu_cores'

    Die folgenden eingestellten Messwerte sollten ersetzt werden.

    Eingestellte FunktionenErsetzen
    kube_daemonset_updated_number_scheduled kube_daemonset_status_updated_number_scheduled
    kube_node_status_allocatable_cpu_cores
    kube_node_status_allocatable_memory_bytes
    kube_node_status_allocatable_pods    		 kube_node_status_allocatable
    kube_node_status_capacity_cpu_cores
    kube_node_status_capacity_memory_bytes
    kube_node_status_capacity_pods    		 kube_node_status_capacity
    kube_hpa_status_current_replicas kube_horizontalpodautoscaler_status_current_replicas

    Workaround:

    Um die eingestellten Messwerte zu ersetzen

    1. Löschen Sie den „GKE On-Prem-Knotenstatus“ im Google Cloud Monitoring-Dashboard. Installieren Sie den „GKE On-Prem-Knotenstatus“ anhand dieser Anleitung neu.
    2. Löschen Sie „GKE On-Prem-Knotenauslastung“ im Google Cloud Monitoring-Dashboard. Installieren Sie die „GKE On-Prem-Knotenauslastung“ anhand dieser Anleitung neu.
    3. Löschen Sie den Zustand der GKE On-Prem-vSphere-VM im Google Cloud Monitoring-Dashboard. Installieren Sie den Zustand der GKE On-Prem-vSphere-VM anhand dieser Anleitung neu.

      4. Diese Einstellung ist auf das Upgrade des Agents kube-state-metrics von Version 1.9 auf Version 2.4 zurückzuführen, die für Kubernetes 1.22 erforderlich ist. Sie können alle verworfenen Messwerte vom Typ kube-state-metrics, die das Präfix kube_ haben, in Ihren benutzerdefinierten Dashboards oder Benachrichtigungsrichtlinien ersetzen.
    Logging und Monitoring 1,10, 1,11, 1,12, 1,13

    Unbekannte Messwertdaten in Cloud Monitoring

    Ab Version 1.10 von GKE on VMware enthalten die Daten für Cluster in Cloud Monitoring möglicherweise irrelevante zusammenfassende Messwerteinträge wie die folgenden:

    Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    Andere Messwerttypen, die irrelevante zusammenfassende Messwerte enthalten können, sind beispielsweise

    :
    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    Diese zusammenfassenden Messwerte befinden sich zwar in der Messwertliste, werden von gke-metrics-agent derzeit aber nicht unterstützt.
    Logging und Monitoring 1,10, 1,11, 1,12, 1,13

    Fehlende Messwerte auf einigen Knoten

    Möglicherweise fehlen die folgenden Messwerte auf einigen, aber nicht auf allen Knoten:

    • kubernetes.io/anthos/container_memory_working_set_bytes
    • kubernetes.io/anthos/container_cpu_usage_seconds_total
    • kubernetes.io/anthos/container_network_receive_bytes_total

    Workaround:

    Um das Problem zu beheben, führen Sie die folgenden Schritte aus. Für [Version 1.9.5+, 1.10.2+, 1.11.0]: Erhöhen Sie die CPU für den gke-metrics-agent. Führen Sie dazu die Schritte 1–4 aus.

    1. Öffnen Sie Ihre stackdriver-Ressource zum Bearbeiten: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Wenn Sie die CPU-Anfrage für gke-metrics-agent von 10m auf 50m erhöhen und das CPU-Limit von 100m auf 200m erhöhen möchten, fügen Sie dem stackdriver-Manifest den folgenden resourceAttrOverride-Abschnitt hinzu: 
      spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 10m
        memory: 200Mi
      Ihre bearbeitete Ressource sollte in etwa so aussehen: 
      spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 200m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
    3. Speichern Sie die Änderungen und schließen Sie den Texteditor.
    4. Prüfen Sie mit dem folgenden Befehl, ob Ihre Änderungen übernommen wurden: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset gke-metrics-agent -o yaml \
    | grep "cpu: 50m"
      Der Befehl findet cpu: 50m, wenn Ihre Änderungen übernommen wurden.
    Logging und Monitoring 1.11.0–1.11.2, 1.12.0

    Fehlende Messwerte für Planer und Controller-Manager im Administratorcluster

    Wenn Ihr Administratorcluster von diesem Problem betroffen ist, fehlen die Messwerte zum Planer und Controller-Manager. Diese beiden Messwerte fehlen beispielsweise

    # scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

    Workaround:

    Führen Sie ein Upgrade auf v1.11.3 oder höher, v1.12.1 oder höher bzw. v1.13 oder höher durch.
    1.11.0–1.11.2, 1.12.0

    Messwerte für Planer und Controller-Manager im Nutzercluster fehlen

    Wenn Ihr Nutzercluster von diesem Problem betroffen ist, fehlen die Messwerte für Planer und Controller-Manager. Zum Beispiel fehlen die folgenden beiden Messwerte:

    # scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

    Workaround:

    Dieses Problem wurde in GKE on VMware Version 1.13.0 und höher behoben. Aktualisieren Sie Ihren Cluster auf eine Version mit der Lösung.
    Installation, Upgrades und Updates 1,10, 1,11, 1,12, 1,13

    Fehler beim Registrieren des Administratorclusters während der Erstellung

    Wenn Sie einen Administratorcluster für Version 1.9.x oder 1.10.0 erstellen und sich der Administratorcluster während seiner Erstellung nicht mit der angegebenen gkeConnect-Spezifikation registrieren kann, wird der folgende Fehler zurückgegeben.

    Failed to create root cluster: failed to register admin cluster: failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error:  ode = PermissionDenied desc = Permission 'gkehub.memberships.get' denied on PROJECT_PATH

    Sie können diesen Administratorcluster weiterhin verwenden, erhalten jedoch die folgende Fehlermeldung, wenn Sie später versuchen, den Administratorcluster auf Version 1.10.y zu aktualisieren.

    failed to migrate to first admin trust chain: failed to parse current version "": invalid version: "" failed to migrate to first admin trust chain: failed to parse current version "": invalid version: ""

    Workaround:
    Identität 1,10, 1,11, 1,12, 1,13

    Die Verwendung von GKE Identity Service kann dazu führen, dass der Connect Agent unerwartet neu gestartet wird.

    Wenn Sie das Feature GKE Identity Service zum Verwalten von GKE Identity Service ClientConfig verwenden, wird der Connect-Agent möglicherweise unerwartet neu gestartet.


    Workaround:

    Wenn dieses Problem bei einem vorhandenen Cluster auftritt, können Sie einen der folgenden Schritte ausführen:

    • Deaktivieren Sie den GKE Identity Service. Wenn Sie den GKE Identity Service deaktivieren, wird weder das bereitgestellte GKE Identity Service-Binärprogramm noch die GKE Identity Service ClientConfig entfernt. Führen Sie den folgenden Befehl aus, um den GKE Identity Service zu deaktivieren: 
      gcloud container fleet identity-service disable \
    --project PROJECT_ID
      Ersetzen Sie PROJECT_ID durch die ID des Flotten-Hostprojekts des Clusters.
    • Aktualisieren Sie den Cluster auf Version 1.9.3 oder höher oder auf Version 1.10.1 oder höher, um ein Upgrade der Connect Agent-Version durchzuführen.
    Netzwerk 1,10, 1,11, 1,12, 1,13

    Cisco ACI funktioniert nicht mit Direct Server Return (DSR)

    Seesaw wird im DSR-Modus ausgeführt und funktioniert aufgrund des IP-Lernens auf der Datenebene nicht in Cisco ACI.


    Workaround:

    Sie können das Problem umgehen, indem Sie das IP-Lernen deaktivieren. Fügen Sie dazu die Seesaw-IP-Adresse als virtuelle L4-L7-IP-Adresse im Cisco Application Policy Infrastructure Controller (APIC) hinzu.

    Sie können die Option für virtuelle L4-L7-IP-Adressen konfigurieren. Rufen Sie dazu Mandant > Anwendungsprofile > Anwendungs-EPGs oder uSeg-EPGs auf. Wenn die IP-Lernung nicht deaktiviert wird, flappt der IP-Endpunkt zwischen verschiedenen Standorten in der Cisco API-Struktur.
    VMware 1,10, 1,11, 1,12, 1,13

    Probleme mit dem vSphere 7.0 Update 3

    VMware hat vor Kurzem kritische Probleme mit den folgenden Releases von vSphere 7.0 Update 3 identifiziert:

    • vSphere ESXi 7.0 Update 3 (Build 18644231)
    • vSphere ESXi 7.0 Update 3a (Build 18825058)
    • vSphere ESXi 7.0 Update 3b (Build 18905247)
    • vSphere vCenter 7.0 Update 3b (Build 18901211)

    Workaround:

    VMWare hat diese Releases seitdem entfernt. Sie sollten die ESXi- und vCenter-Server auf eine neuere Version aktualisieren.
    Betriebssystem 1,10, 1,11, 1,12, 1,13

    Fehler beim Bereitstellen des emptyDir-Volumes als exec in einem auf COS-Knoten ausgeführten Pod

    Für Pods, die auf Knoten ausgeführt werden, die Container-Optimized OS-Images (COS) verwenden, können Sie das Volume emptyDir nicht als exec bereitstellen. Sie wird als noexec bereitgestellt und Sie erhalten den folgenden Fehler: exec user process caused: permission denied. Diese Fehlermeldung wird beispielsweise angezeigt, wenn Sie den folgenden Test-Pod bereitstellen:

    apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: test
  name: test
spec:
  containers:
  - args:
    - sleep
    - "5000"
    image: gcr.io/google-containers/busybox:latest
    name: test
    volumeMounts:
      - name: test-volume
        mountPath: /test-volume
    resources:
      limits:
        cpu: 200m
        memory: 512Mi
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  volumes:
    - emptyDir: {}
      name: test-volume

    Wenn Sie im Test-Pod mount | grep test-volume ausführen, wird die Option noexec angezeigt:

    /dev/sda1 on /test-volume type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30)

    Workaround:
    Upgrades und Updates 1,10, 1,11, 1,12, 1,13

    Die Aktualisierung des Clusterknotenpools funktioniert nicht, nachdem Autoscaling für den Knotenpool deaktiviert wurde

    Knotenpoolreplikate werden nicht aktualisiert, nachdem Autoscaling für einen Knotenpool aktiviert und deaktiviert wurde.


    Workaround:

    Die Annotationen cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size und cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size werden aus der Maschinenbereitstellung des entsprechenden Knotenpools entfernt.
    Logging und Monitoring 1,11, 1,12, 1,13

    Windows-Monitoring-Dashboards zeigen Daten aus Linux-Clustern

    Ab Version 1.11 zeigen das Windows Pod-Statusdashboard und das Windows-Knotenstatus-Dashboard in den vorkonfigurierten Monitoring-Dashboards auch Daten von Linux-Clustern an. Das liegt daran, dass die Windows-Knoten- und Pod-Messwerte auch auf Linux-Clustern verfügbar gemacht werden.
    Logging und Monitoring 1.10, 1.11, 1.12

    stackdriver-log-forwarder in konstantem CrashLoopBackOff

    Bei GKE on VMware Version 1.10, 1.11 und 1.12 kann das stackdriver-log-forwarder-DaemonSet CrashLoopBackOff-Fehler haben, wenn sich auf dem Laufwerk fehlerhafte zwischengespeicherte Logs befinden.


    Workaround:

    Um dieses Problem zu beheben, müssen wir die zwischengespeicherten Logs auf dem Knoten bereinigen.

    1. Reduzieren Sie stackdriver-log-forwarder, um das unerwartete Verhalten zu vermeiden: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
      Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.
    2. Stellen Sie das Bereinigungs-DaemonSet bereit, um fehlerhafte Blöcke zu bereinigen: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF
    3. Sie können die folgenden Befehle ausführen, damit das Bereinigungs-DaemonSet alle Blöcke bereinigt hat. Die Ausgabe der beiden Befehle sollte Ihrer Knotenzahl im Cluster entsprechen:
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
    4. Löschen Sie das Bereinigungs-DaemonSet:
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system delete ds fluent-bit-cleanup
    5. stackdriver-log-forwarder fortsetzen: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    Logging und Monitoring 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16

    stackdriver-log-forwarder sendet keine Logs an Cloud Logging

    Wenn in Cloud Logging keine Logs Ihrer Cluster angezeigt werden und Sie den folgenden Fehler in Ihren Logs feststellen: 

    2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk
    . Wahrscheinlich überschreitet die Eingaberate des Logs das Limit des Logging-Agents, sodass stackdriver-log-forwarder keine Logs sendet. Dieses Problem tritt bei allen Versionen von GKE on VMware auf.

    Behelfslösung:

    Sie müssen das Ressourcenlimit für den Logging-Agent erhöhen, um dieses Problem zu beheben.

    1. Öffnen Sie Ihre stackdriver-Ressource zum Bearbeiten: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Um die CPU-Anfrage für stackdriver-log-forwarder zu erhöhen, fügen Sie dem Manifest stackdriver den folgenden Abschnitt resourceAttrOverride hinzu: 
      spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
      Die bearbeitete Ressource sollte in etwa so aussehen: 
      spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
    3. Speichern Sie die Änderungen und schließen Sie den Texteditor.
    4. Prüfen Sie mit dem folgenden Befehl, ob Ihre Änderungen übernommen wurden: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
    | grep "cpu: 1200m"
      Der Befehl findet cpu: 1200m, wenn Ihre Änderungen übernommen wurden.
    Sicherheit 1.13

    Der Kubelet-Dienst ist nach NodeReady vorübergehend nicht verfügbar

    Es gibt einen kurzen Zeitraum, in dem der Knoten bereit ist, aber das kubelet-Serverzertifikat nicht bereit ist. kubectl exec und kubectl logs sind in diesem Zeitraum nicht verfügbar. Das liegt daran, dass es einige Zeit dauert, bis der neue Genehmiger des Serverzertifikats die aktualisierten gültigen IP-Adressen des Knotens sieht.

    Dieses Problem betrifft nur das kubelet-Serverzertifikat und nicht die Pod-Planung.
    Upgrades und Updates 1.12

    Teilweises Upgrade des Administratorclusters blockiert kein späteres Upgrade des Nutzerclusters

    Fehler beim Upgrade des Nutzerclusters:

    .LBKind in body is required (Check the status of OnPremUserCluster 'cl-stg-gdl-gke-onprem-mgmt/cl-stg-gdl' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

    Das Upgrade des Administratorclusters wurde nicht vollständig durchgeführt und die Statusversion ist immer noch 1.10. Das Upgrade des Nutzerclusters auf 1.12 wird von keiner Preflight-Prüfung blockiert und schlägt aufgrund eines Versionsverzerrungsproblems fehl.


    Workaround:

    Führen Sie ein Upgrade des Administratorclusters auf 1.11 und dann ein Upgrade des Nutzerclusters auf 1.12 durch.
    Speicher 1.10.0–1.10.5, 1.11.0–1.11.2, 1.12.0

    Datastore meldet fälschlicherweise unzureichenden freien Speicherplatz

    Der Befehl gkectl diagnose cluster ist fehlgeschlagen mit:

    Checking VSphere Datastore FreeSpace...FAILURE
    Reason: vCenter datastore: [DATASTORE_NAME] insufficient FreeSpace, requires at least [NUMBER] GB

    Die Validierung des freien Datenspeichers sollte nicht für vorhandene Clusterknotenpools verwendet werden und wurde versehentlich in gkectl diagnose cluster hinzugefügt.


    Workaround:

    Sie können die Fehlermeldung ignorieren oder die Validierung mit --skip-validation-infra überspringen.
    Betrieb, Netzwerk 1.11, 1.12.0–1.12.1

    Fehler beim Hinzufügen eines neuen Nutzerclusters, wenn der Administratorcluster MetalLB-Load-Balancer verwendet

    Sie können möglicherweise keinen neuen Nutzercluster hinzufügen, wenn Ihr Administratorcluster mit einer MetalLB-Load-Balancer-Konfiguration eingerichtet ist.

    Das Löschen des Nutzerclusters kann aus irgendeinem Grund hängen bleiben, was zu einer Entwertung der MatalLB-ConfigMap führt. Mit diesem Status kann kein neuer Nutzercluster hinzugefügt werden.


    Workaround:

    Sie können das Löschen des Nutzerclusters erzwingen.
    Installation, Betriebssystem 1,10, 1,11, 1,12, 1,13

    Fehler bei Verwendung von Container-Optimized OS (COS) für Nutzercluster

    Wenn osImageType cos für den Administratorcluster verwendet und gkectl check-config nach dem Erstellen des Administratorclusters und vor dem Erstellen des Nutzerclusters ausgeführt wird, schlägt die Ausführung bei:

    Failed to create the test VMs: VM failed to get IP addresses on the network.

    Die für den Nutzercluster check-config erstellte Test-VM verwendet standardmäßig dieselbe osImageType des Administratorclusters. Derzeit ist die Test-VM noch nicht mit COS kompatibel.


    Workaround:

    Verwenden Sie gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --fast, um die langsame Preflight-Prüfung zu vermeiden, die die Test-VM erstellt.
    Logging und Monitoring 1.12.0-1.12.1

    Grafana im Administratorcluster kann Nutzercluster nicht erreichen

    Dieses Problem betrifft Kunden, die mit Grafana im Administratorcluster Nutzercluster in GKE on VMware in den Versionen 1.12.0 und 1.12.1 überwachen. Er beruht auf einer Diskrepanz zwischen Pushprox-Clientzertifikaten in Nutzerclustern und der Zulassungsliste auf dem pushprox-Server im Administratorcluster. Das Symptom ist pushprox-client in Nutzerclustern, die Fehlerlogs wie die folgenden ausgeben:

    level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\""

    Workaround:
    Sonstiges 1.11.3

    gkectl repair admin-master stellt nicht die VM-Vorlage bereit, die für die Wiederherstellung verwendet werden soll

    Der Befehl gkectl repair admin-master ist fehlgeschlagen mit:

    Failed to repair: failed to select the template: no VM templates is available for repairing the admin master (check if the admin cluster version >= 1.4.0 or contact support

    gkectl repair admin-master kann die VM-Vorlage, die zum Reparieren der VM der Administrator-Steuerungsebene verwendet werden soll, nicht abrufen, wenn der Name der VM der Administrator-Steuerungsebene mit den Zeichen t, m, p oder l endet.


    Workaround:

    Führen Sie den Befehl mit --skip-validation noch einmal aus.
    Logging und Monitoring 1,11, 1,12, 1,13, 1,14, 1,15, 1,16

    Cloud-Audit-Logging aufgrund abgelehnter Berechtigung fehlgeschlagen

    Cloud-Audit-Logs erfordern eine spezielle Berechtigungseinrichtung, die derzeit nur über GKE Hub automatisch für Nutzercluster ausgeführt wird. Es wird empfohlen, mindestens einen Nutzercluster zu haben, der dieselbe Projekt-ID und dasselbe Dienstkonto wie der Administratorcluster für Cloud-Audit-Logs verwendet, damit der Administratorcluster die erforderliche Berechtigung hat.

    In Fällen, in denen der Administratorcluster eine andere Projekt-ID oder ein anderes Dienstkonto als ein Nutzercluster verwendet, können Audit-Logs des Administratorclusters jedoch nicht in Google Cloud eingeschleust werden. Das Symptom ist eine Reihe von Permission Denied-Fehlern im Pod audit-proxy im Administratorcluster.

    Workaround:
    Betrieb, Sicherheit 1.11

    Fehler beim Prüfen von Zertifikaten von gkectl diagnose

    Wenn Ihre Workstation keinen Zugriff auf Worker-Knoten des Nutzerclusters hat, werden beim Ausführen von gkectl diagnose die folgenden Fehler ausgegeben:

    Checking user cluster certificates...FAILURE
    Reason: 3 user cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

    Wenn Ihre Workstation keinen Zugriff auf Worker-Knoten des Administratorclusters oder Worker-Knoten des Administratorclusters hat, treten beim Ausführen von gkectl diagnose die folgenden Fehler auf:

    Checking admin cluster certificates...FAILURE
    Reason: 3 admin cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

    Workaround:

    Wenn keine Gefahr besteht, diese Nachrichten zu ignorieren.
    Betriebssystem 1,8, 1,9, 1,10, 1,11, 1,12, 1,13

    /var/log/audit/ füllt Speicherplatz auf VMs aus

    /var/log/audit/ enthält Audit-Logs. Sie können die Laufwerksnutzung mit sudo du -h -d 1 /var/log/audit prüfen.

    Bestimmte gkectl-Befehle auf der Administratorworkstation, z. B. gkectl diagnose snapshot, tragen zur Speicherplatznutzung bei.

    Seit Version 1.8 von GKE on VMware ist das Ubuntu-Image mit CIS Level 2-Benchmark gehärtet. Und durch eine der Complianceregeln (4.1.2.2 Sicherstellen, dass Audit-Logs nicht automatisch gelöscht werden) die Auditd-Einstellung max_log_file_action = keep_logs. Dies führt dazu, dass alle Audit-Regeln auf dem Laufwerk beibehalten werden.


    Workaround:
    Netzwerk 1.10, 1.11.0–1.11.3, 1.12.0–1.12.2, 1.13.0

    NetworkGatewayGroup Floating-IP steht in Konflikt mit Knotenadresse

    Nutzer können aufgrund des folgenden Fehlers bei der Validierung des Webhooks keine NetworkGatewayGroup-Objekte erstellen oder aktualisieren:

    [1] admission webhook "vnetworkgatewaygroup.kb.io" denied the request: NetworkGatewayGroup.networking.gke.io "default" is invalid: [Spec.FloatingIPs: Invalid value: "10.0.0.100": IP address conflicts with node address with name: "my-node-name"

    In betroffenen Versionen kann das Kubelet fälschlicherweise an eine Floating-IP-Adresse gebunden werden, die dem Knoten zugewiesen ist, und es als Knotenadresse in node.status.addresses melden. Der überprüfende Webhook prüft NetworkGatewayGroup Floating-IP-Adressen mit allen node.status.addresses im Cluster und betrachtet dies als Konflikt.


    Workaround:

    Deaktivieren Sie im selben Cluster, in dem das Erstellen oder Aktualisieren von NetworkGatewayGroup-Objekten fehlschlägt, den ANG-Validierungs-Webhook vorübergehend und senden Sie Ihre Änderung:

    1. Speichern Sie die Webhook-Konfiguration, damit sie am Ende wiederhergestellt werden kann: 
      kubectl -n kube-system get validatingwebhookconfiguration \
    ang-validating-webhook-configuration -o yaml > webhook-config.yaml
    2. Bearbeiten Sie die Webhook-Konfiguration:
      kubectl -n kube-system edit validatingwebhookconfiguration \
    ang-validating-webhook-configuration
    3. Entfernen Sie das vnetworkgatewaygroup.kb.io-Element aus der Webhook-Konfigurationsliste und schließen Sie es, um die Änderungen zu übernehmen.
    4. Erstellen oder bearbeiten Sie das NetworkGatewayGroup-Objekt.
    5. Wenden Sie die ursprüngliche Webhook-Konfiguration noch einmal an:
      kubectl -n kube-system apply -f webhook-config.yaml
    Installation, Upgrades und Updates 1.10.0-1.10.2

    Zeitlimit für Administratorcluster erstellen oder upgraden

    Während eines Upgradeversuchs des Administratorclusters kann die VM der Administrator-Steuerungsebene während der Erstellung hängen bleiben. Die VM der Administrator-Steuerungsebene geht während des Startvorgangs in eine endlose Warteschleife und in der Datei /var/log/cloud-init-output.log wird der folgende Endlosschleifenfehler angezeigt:

    + echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ head -n 1
+++ grep -v 192.168.231.1
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
++ echo
+ '[' -n '' ']'
+ sleep 1
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
+++ grep -v 192.168.231.1
+++ head -n 1
++ echo
+ '[' -n '' ']'
+ sleep 1

    Das liegt daran, dass GKE on VMware versucht, die IP-Adresse des Knotens im Startskript abzurufen, verwendet grep -v ADMIN_CONTROL_PLANE_VIP, um die virtuelle IP-Adresse der Steuerungsebene des Administratorclusters zu überspringen, die auch der NIC zugewiesen werden kann. Beim Befehl werden jedoch auch alle IP-Adressen übersprungen, die das Präfix der virtuellen IP-Adresse der Steuerungsebene haben. Dies führt dazu, dass sich das Startskript aufhängt.

    Angenommen, die virtuelle IP-Adresse der Steuerungsebene des Administratorclusters lautet 192.168.1.25. Wenn die IP-Adresse der VM der Steuerungsebene des Administratorclusters das gleiche Präfix hat, z. B. 192.168.1.254, bleibt die VM der Steuerungsebene während der Erstellung hängen. Dieses Problem kann auch ausgelöst werden, wenn die Broadcastadresse dasselbe Präfix wie die virtuelle IP-Adresse der Steuerungsebene hat, z. B. 192.168.1.255.


    Workaround:

    • Wenn das Zeitlimit für das Zeitlimit beim Erstellen des Administratorclusters auf die Broadcast-IP-Adresse zurückzuführen ist, führen Sie den folgenden Befehl auf der VM der Steuerungsebene des Administratorclusters aus: 
      ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
      Dadurch wird eine Zeile ohne Broadcastadresse erstellt und der Startvorgang wird aufgehoben. Nachdem die Blockierung des Startskripts aufgehoben wurde, entfernen Sie die hinzugefügte Zeile mit dem folgenden Befehl:
      ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
    • Wenn der Grund für das Zeitlimit beim Erstellen des Administratorclusters jedoch auf die IP-Adresse der VM der Steuerungsebene zurückzuführen ist, können Sie die Blockierung des Startskripts nicht aufheben. Wechseln Sie zu einer anderen IP-Adresse und erstellen Sie eine neue Version oder führen Sie ein Upgrade auf Version 1.10.3 oder höher aus.
    Betriebssystem, Upgrades und Updates 1.10.0-1.10.2

    Der Status des Administratorclusters, der das COS-Image verwendet, geht beim Upgrade des Administratorclusters oder der Reparatur des Administratormasters verloren

    DataDisk kann auf dem Masterknoten des Administratorclusters nicht korrekt bereitgestellt werden, wenn das COS-Image verwendet wird. Außerdem geht der Status des Administratorclusters, der das COS-Image verwendet, beim Upgrade des Administratorclusters oder der Reparatur des Administratorclusters verloren. (Administratorcluster mit COS-Image ist eine Vorabversion)


    Workaround:

    Administratorcluster mit osImageType auf ubuntu_containerd neu erstellen

    Nachdem Sie den Administratorcluster erstellt haben und osImageType auf „cos“ gesetzt ist, rufen Sie den SSH-Schlüssel des Administratorclusters und SSH im Administrator-Master-Knoten ab. Das Ergebnis df -h enthält /dev/sdb1 98G 209M 93G 1% /opt/data. Und lsblk Ergebnis enthält „-sdb1 8:17 0 100G 0 part /opt/data“
    Betriebssystem 1.10

    systemd-resolved schlug beim DNS-Lookup auf .local-Domains fehl

    In GKE on VMware Version 1.10.0 werden Namensauflösungen unter Ubuntu standardmäßig an das lokale systemd aufgelöste Monitoring auf 127.0.0.53 weitergeleitet. Der Grund dafür ist, dass auf dem in Version 1.10.0 verwendeten Ubuntu 20.04-Image /etc/resolv.conf mit /run/systemd/resolve/stub-resolv.conf sym verknüpft ist, das auf den localhost-DNS-Stub 127.0.0.53 verweist.

    Daher verweigert die Auflösung der lokalen DNS-Namen die Prüfung der in /run/systemd/resolve/resolv.conf angegebenen vorgelagerten DNS-Server auf Namen mit dem Suffix .local, es sei denn, die Namen werden als Suchdomains angegeben.

    Dies führt dazu, dass alle Lookups nach .local-Namen fehlschlagen. Beispielsweise schlägt kubelet beim Hochfahren des Knotens fehl, wenn Images mit dem Suffix .local aus einer privaten Registry abgerufen werden. Das Angeben einer vCenter-Adresse mit dem Suffix .local funktioniert nicht auf einer Administratorworkstation.


    Workaround:

    Sie können dieses Problem für Clusterknoten vermeiden, wenn Sie das Feld searchDomainsForDNS in der Konfigurationsdatei des Administratorclusters und die Konfigurationsdatei des Nutzerclusters angeben, um die Domains einzuschließen.

    Derzeit unterstützt gkectl update das Aktualisieren des Felds searchDomainsForDNS noch nicht.

    Wenn Sie dieses Feld nicht vor der Clustererstellung eingerichtet haben, müssen Sie eine SSH-Verbindung zu den Knoten herstellen und den lokalen, vom System aufgelösten Stub umgehen. Dazu ändern Sie den Symlink von /etc/resolv.conf von /run/systemd/resolve/stub-resolv.conf (enthält den lokalen Stub 127.0.0.53) in /run/systemd/resolve/resolv.conf (der auf das tatsächliche Upstream-DNS verweist):

    sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

    Bei der Administratorworkstation unterstützt gkeadm keine Angabe von Suchdomains. Daher muss dieses Problem mit diesem manuellen Schritt umgangen werden.

    Diese Lösung für bleibt bei der Neuerstellung von VMs nicht bestehen. Sie müssen diese Problemumgehung immer dann anwenden, wenn VMs neu erstellt werden.
    Installation, Betriebssystem 1.10

    IP-Adresse der Docker-Brücke verwendet 172.17.0.1/16 anstelle von 169.254.123.1/24

    GKE on VMware gibt ein dediziertes Subnetz für die IP-Adresse der Docker-Bridge an, das --bip=169.254.123.1/24 verwendet, sodass das Standardsubnetz 172.17.0.1/16 nicht reserviert wird. In Version 1.10.0 gab es jedoch einen Fehler im Ubuntu-Betriebssystem-Image, der dazu führte, dass die benutzerdefinierte Docker-Konfiguration ignoriert wurde.

    Daher wählt Docker die Standardeinstellung 172.17.0.1/16 als Subnetz der Bridge-IP-Adresse aus. Dies kann zu einem IP-Adresskonflikt führen, wenn bereits eine Arbeitslast in diesem IP-Adressbereich ausgeführt wird.


    Workaround:

    Zur Umgehung dieses Problems müssen Sie die folgende systemd-Konfigurationsdatei für dockerd umbenennen und dann den Dienst neu starten:

    sudo mv /etc/systemd/system/docker.service.d/50-cloudimg-settings.cfg \
    /etc/systemd/system/docker.service.d/50-cloudimg-settings.conf

sudo systemctl daemon-reload

sudo systemctl restart docker

    Prüfen Sie, ob Docker die richtige Brücken-IP-Adresse nutzt:

    ip a | grep docker0

    Diese Lösung bleibt bei der Neuerstellung von VMs nicht erhalten. Sie müssen diese Problemumgehung immer dann anwenden, wenn VMs neu erstellt werden.
    Upgrades und Updates 1.11

    Upgrade auf 1.11 durch Stackdriver-Bereitschaft blockiert

    In GKE on VMware Version 1.11.0 gibt es Änderungen an der Definition von benutzerdefinierten Ressourcen im Zusammenhang mit Logging und Monitoring:

    • Gruppenname der benutzerdefinierten Ressource stackdriver von addons.sigs.k8s.io zu addons.gke.io geändert;
    • Der Gruppenname der benutzerdefinierten Ressourcen monitoring und metricsserver wurde von addons.k8s.io zu addons.gke.io geändert.
    • Die Spezifikationen der oben genannten Ressourcen werden nun gegen das Schema abgewägt. Insbesondere für die Spezifikation „resourceAttrOverride“ und „storageSizeOverride“ in der benutzerdefinierten Ressource stackdriver muss ein Stringtyp in den Werten für CPU-, Arbeitsspeicher- und Speichergrößenanforderungen und ‐limits festgelegt werden.

    Die Änderungen des Gruppennamens werden gemäß den CustomResourceDefinition-Updates in Kubernetes 1.22 vorgenommen.

    Wenn Sie keine zusätzliche Logik haben, die die betroffenen benutzerdefinierten Ressourcen anwendet oder bearbeitet, müssen Sie nichts weiter tun. Der Upgradeprozess für GKE on VMware übernimmt die Migration der betroffenen Ressourcen und behält ihre vorhandenen Spezifikationen nach der Änderung des Gruppennamens bei.

    Wenn Sie jedoch eine Logik ausführen, die die betroffenen Ressourcen anwendet oder bearbeitet, ist besondere Aufmerksamkeit erforderlich. Zuerst muss mit dem neuen Gruppennamen in der Manifestdatei auf sie verwiesen werden. Beispiel:

    apiVersion: addons.gke.io/v1alpha1  ## instead of `addons.sigs.k8s.io/v1alpha1`
kind: Stackdriver

    Außerdem müssen die Spezifikationswerte resourceAttrOverride und storageSizeOverride vom Typ „String“ sein. Beispiel:

    spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder
      limits:
        cpu: 1000m # or "1"
        # cpu: 1 # integer value like this would not work 
        memory: 3000Mi

    Andernfalls werden die Änderungen nicht übernommen und können zu einem unerwarteten Status in Logging- und Monitoring-Komponenten führen. Mögliche Symptome sind:

    • Abgleichsfehlerlogs in onprem-user-cluster-controller, z. B.: 
      potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1}
    • Fehler in kubectl edit stackdriver stackdriver, z. B. 
      Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found

    Wenn die oben genannten Fehler auftreten, bedeutet dies, dass ein nicht unterstützter Typ in der Stackdriver-CR-Spezifikation bereits vor dem Upgrade vorhanden war. Als Behelfslösung können Sie die Stackdriver-CR unter dem alten Gruppennamen kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver manuell bearbeiten und so vorgehen:

    1. Ändern Sie die Ressourcenanforderungen und -limits in den Stringtyp.
    2. Entfernen Sie alle addons.gke.io/migrated-and-deprecated: true-Annotationen, sofern vorhanden.
    Setzen Sie dann den Upgradeprozess fort oder starten Sie ihn neu.

    Betriebssystem 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16

    COS-VMs zeigen keine IP-Adressen an, wenn VMs durch nicht ordnungsgemäßes Herunterfahren des Hosts verschoben werden

    Wenn auf einem ESXi-Server ein Fehler auftritt und die vCenter-Funktion für Hochverfügbarkeit für den Server aktiviert wurde, lösen alle VMs auf dem fehlerhaften ESXi-Server den vMotion-Mechanismus aus und werden auf einen anderen normalen ESXi-Server verschoben. Migrierte COS-VMs würden ihre IP-Adressen verlieren.

    Workaround:

    VM neu starten
    Netzwerk alle Versionen vor 1.14.7, 1.15.0 bis 1.15.3, 1.16.0

    Für GARP-Antwort von Seesaw wird keine Ziel-IP festgelegt

    Der regelmäßig alle 20 Sekunden von Seesaw gesendete GARP (Gratuitous ARP) legt die Ziel-IP-Adresse nicht im ARP-Header fest. Einige Netzwerke (wie Cisco ACI) akzeptieren solche Pakete möglicherweise nicht. Dies kann zu längeren Ausfallzeiten des Dienstes führen, nachdem ein Split Brain (aufgrund von VRRP-Paketverlusten) wiederhergestellt wurde.

    Workaround:

    Lösen Sie ein Seeaw-Failover aus, indem Sie sudo seesaw -c failover auf einer der Seesaw-VMs ausführen. Dadurch sollte der Traffic wiederhergestellt werden.
    Betriebssystem 1.16, 1.28.0-1.28.200

    Kubelet wird mit Logs überschwemmt, die besagen, dass „/etc/kubernetes/manifests“ auf den Worker-Knoten nicht vorhanden ist

    "staticPodPath" wurde fälschlicherweise für Worker-Knoten festgelegt

    Workaround:

    Ordner „/etc/kubernetes/manifests“ manuell erstellen
    Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.