Google Distributed Cloud (nur Software) für bekannte Probleme mit VMware

Auf dieser Seite werden alle bekannten Probleme mit Google Distributed Cloud on VMware aufgeführt. Diese Seite richtet sich an IT-Administratoren und Anwender, die den Lebenszyklus der zugrunde liegenden technischen Infrastruktur verwalten und auf Benachrichtigungen und Seiten reagieren, wenn Service Level Objectives (SLOs) nicht erfüllt werden oder Anwendungen ausfallen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud-Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und -Aufgaben.

Wenn Sie die bekannten Probleme nach einer Produktversion oder -kategorie filtern möchten, wählen Sie in den folgenden Drop-down-Menüs einfach die gewünschten Filter aus.

Wählen Sie Ihre Version von Google Distributed Cloud aus:

  • 1.30
  • 1.29
  • 1,28
  • 1.16
  • 1,15
  • 1.14
  • 1.13
  • 1.12

Wählen Sie die Problemkategorie aus:

  • Konfiguration
  • Installation
  • Upgrades
  • Updates
  • Vorgang
  • Logging und Monitoring
  • Netzwerk
  • Sicherheit
  • Speicher
  • Betriebssystem
  • VMware
  • Identität
  • Migration
  • Sonstiges

Oder suchen Sie nach Ihrem Problem:

Kategorie Erkannte Version(en) Problem und Workaround
Migration 1.29, 1.30

Die Migration eines Nutzerclusters zu Controlplane V2 schlägt fehl, wenn die Secrets-Verschlüsselung schon einmal aktiviert wurde.

Wenn die Always-On-Secrets-Verschlüsselung schon einmal aktiviert war, wird der Secret-Verschlüsselungsschlüssel bei der Migration eines Nutzerclusters zu Controlplane V2 nicht ordnungsgemäß verarbeitet. Aufgrund dieses Problems kann der neue Controlplane V2-Cluster keine Secrets entschlüsseln. Wenn die Ausgabe des folgenden Befehls nicht leer ist, wurde die Always-On-Secrets-Verschlüsselung irgendwann aktiviert und der Cluster ist von diesem Problem betroffen:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      get onpremusercluster USER_CLUSTER_NAME \
      -n USER_CLUSTER_NAME-gke-onprem-mgmt \
      -o jsonpath={.spec.secretsEncryption}

Wenn Sie die Migration bereits gestartet haben und sie fehlschlägt, wenden Sie sich an den Google-Support. Andernfalls müssen Sie die Always-On-Secrets-Verschlüsselung vor der Migration deaktivieren und Secrets entschlüsseln.

Migration 1.29.0–1.29.600, 1.30.0–1.30.100

Die Migration eines Administratorclusters von einem Cluster ohne Hochverfügbarkeit zu einem Cluster mit Hochverfügbarkeit schlägt fehl, wenn die Secrets-Verschlüsselung aktiviert ist.

Wenn die Always-On-Secrets-Verschlüsselung in der Version 1.14 oder in älteren Versionen für den Administratorcluster aktiviert wurde und ein Upgrade von alten Versionen auf die betroffenen Versionen 1.29 und 1.30 durchgeführt wurde, wird der Secret-Verschlüsselungsschlüssel bei der Migration des Administratorclusters von einem Cluster ohne Hochverfügbarkeit zu einem Cluster mit Hochverfügbarkeit nicht ordnungsgemäß verarbeitet. Aufgrund dieses Problems kann der neue hochverfügbare Administratorcluster keine Secrets entschlüsseln.

So prüfen Sie, ob der Cluster den alten formatierten Schlüssel verwendet:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret -n kube-system admin-master-component-options -o jsonpath='{.data.data}' | base64 -d | grep -oP '"GeneratedKeys":\[.*?\]'

Wenn die Ausgabe wie hier einen leeren Schlüssel enthält, ist der Cluster wahrscheinlich von diesem Problem betroffen:

    "GeneratedKeys":[{"KeyVersion":"1","Key":""}]

Wenn Sie die Migration bereits gestartet haben und sie fehlschlägt, wenden Sie sich an den Google-Support.

Andernfalls müssen Sie vor Beginn der Migration den Verschlüsselungsschlüssel rotieren.
Upgrades 1.16, 1.28, 1.29, 1.30

credential.yaml wurde beim Upgrade der Administratorworkstation fehlerhaft generiert.

Beim Upgrade der Administratorworkstation mit dem Befehl gkeadm upgrade admin-workstation wird die Datei credential.yaml fehlerhaft generiert. Die Felder für Nutzername und Passwort sind leer. Außerdem enthält der privateRegistry-Schlüssel einen Tippfehler.

Die gleiche Falschschreibung des privateRegistry-Schlüssels ist auch in der Datei admin-cluster.yaml enthalten.
Da die Datei credential.yaml während des Administratorcluster-Upgrades neu generiert wird, ist der Tippfehler auch dann vorhanden, wenn Sie ihn zuvor korrigiert haben.

Workaround:

  • Aktualisieren Sie den Schlüsselnamen der privaten Registry in credential.yaml, damit er mit dem Eintrag privateRegistry.credentials.fileRef.entry in admin-cluster.yaml übereinstimmt.
  • Aktualisieren Sie den Nutzernamen und das Passwort der privaten Registry in der credential.yaml.
Upgrades 1.16, 1.28

Das Upgrade des Nutzerclusters schlägt aufgrund eines Zeitüberschreitungsfehlers beim Abgleich vor dem Upgrade fehl.

Beim Upgrade eines Nutzerclusters kann der Abgleich vor dem Upgrade länger als die festgelegte Zeitüberschreitung dauern, was zu einem Upgradefehler führt. Die Fehlermeldung sieht in etwa so aus:

Failed to reconcile the user cluster before upgrade: the pre-upgrade reconcile failed, error message:
failed to wait for reconcile to complete: error: timed out waiting for the condition,
message: Cluster reconcile hasn't finished yet, please fix that before
rerun the upgrade.

Die Zeitüberschreitung für den Abgleich vor dem Upgrade beträgt 5 Minuten plus 1 Minute pro Knotenpool im Nutzercluster.

Workaround:

Sorgen Sie dafür, dass der Befehl gkectl diagnose cluster ohne Fehler ausgeführt wird.
Überspringen Sie den Abgleich vor dem Upgrade, indem Sie dem Befehl gkectl upgrade cluster das Flag --skip-reconcile-before-preflight hinzufügen. Beispiel:

gkectl upgrade cluster --skip-reconcile-before-preflight --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG_FILE
Updates 1.16, 1.28.0–1.28.800, 1.29.0–1.29.400, 1.30.0

Die Aktualisierung von DataplaneV2 ForwardMode löst nicht automatisch einen Neustart des DaemonSets anetd aus.

Wenn Sie das Feld dataplaneV2.forwardMode des Nutzerclusters mit gkectl update cluster aktualisieren, wird die Änderung nur in der ConfigMap aktualisiert. Das DaemonSet anetd übernimmt die Konfigurationsänderung nicht ohne einen Neustart und Ihre Änderungen werden nicht angewendet.

Workaround:

Wenn der Befehl gkectl update cluster ausgeführt wurde, wird die Ausgabe Done updating the user cluster angezeigt. Führen Sie daraufhin den folgenden Befehl aus, um das DaemonSet anetd neu zu starten, sodass die Konfigurationsänderung übernommen wird:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG rollout restart daemonset anetd

Prüfen Sie nach dem Neustart die DaemonSet-Bereitschaft:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get daemonset anetd

Prüfen Sie in der Ausgabe des vorherigen Befehls, ob die Zahl in der Spalte DESIRED mit der Zahl in der Spalte READY übereinstimmt.
Upgrades 1.16

Der Befehl etcdctl wurde während des Cluster-Upgrades in der Sicherungsphase des Administratorclusters nicht gefunden.

Während des Upgrades eines Nutzerclusters von 1.16 auf 1.28 wird der Administratorcluster gesichert. Dabei wird die Fehlermeldung „etcdctl: command not found“ (etcdctl: Befehl nicht gefunden) angezeigt. Das Upgrade des Nutzerclusters ist erfolgreich und der Administratorcluster bleibt in einem fehlerfreien Zustand. Das einzige Problem ist, dass die Metadatendatei im Administratorcluster nicht gesichert wird.

Die Ursache des Problems ist, dass das Binärprogramm etcdctl in Version 1.28 hinzugefügt wurde und auf Knoten mit Version 1.16 nicht verfügbar ist.

Die Sicherung des Administratorclusters umfasst mehrere Schritte, darunter die Erstellung eines etcd-Snapshots und das Schreiben der Metadatendatei für den Administratorcluster. Die etcd-Sicherung ist trotzdem erfolgreich, da etcdctl auch nach einer Ausführung im etcd-Pod ausgelöst werden kann. Das Schreiben der Metadatendatei schlägt jedoch fehl, da das Binärprogramm etcdctl noch auf dem Knoten installiert werden muss. Die Sicherung der Metadatendatei ist jedoch kein Hindernis für die Sicherung. Daher ist der Sicherungsvorgang wie auch das Upgrade des Nutzerclusters erfolgreich.

Workaround:

Wenn Sie eine Sicherung der Metadatendatei erstellen möchten, folgen Sie der Anleitung unter Administratorcluster mit gkectl sichern und wiederherstellen, um eine separate Sicherung des Administratorclusters mit der Version von gkectl auszulösen, die der Version Ihres Administratorclusters entspricht.
Installation 1.16–1.29

Fehler beim Erstellen eines Nutzerclusters mit manuellem Load Balancing

Beim Erstellen eines Nutzerclusters, der für manuelles Load-Balancing konfiguriert ist, tritt ein gkectl check-config-Fehler auf, der darauf hinweist, dass der ingressHTTPNodePort-Wert mindestens 30.000 sein muss, auch wenn der gebündelte eingehende Traffic deaktiviert ist.

Dieses Problem tritt unabhängig davon auf, ob die Felder ingressHTTPNodePort und ingressHTTPSNodePort festgelegt oder leer gelassen werden.

Workaround:

Um dieses Problem zu umgehen, ignorieren Sie das von gkectl check-config zurückgegebene Ergebnis. Informationen zum Deaktivieren des gebündelten eingehenden Traffics finden Sie unter Gebündelten eingehenden Traffic deaktivieren.
Updates 1.29.0

Das Problem mit dem PodDisruptionBudget (PDB) tritt auf, wenn Administratorcluster mit Hochverfügbarkeit (High Availability, HA) verwendet werden und nach der Migration 0 oder ein Administratorclusterknoten ohne Rolle vorhanden ist. Führen Sie den folgenden Befehl aus, um zu prüfen, ob Knotenobjekte ohne Rolle vorhanden sind:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes -o wide

Wenn nach der Migration zwei oder mehr Knotenobjekte ohne Rolle vorhanden sind, ist das PDB nicht falsch konfiguriert.

Symptome:

Die Ausgabe von Administratorclusterdiagnose enthält die folgenden Informationen

Checking all poddisruptionbudgets...FAILURE
  Reason: 1 pod disruption budget error(s).
  Unhealthy Resources:
  PodDisruptionBudget metrics-server: gke-managed-metrics-server/metrics-server might be configured incorrectly: the total replicas(1) should be larger than spec.MinAvailable(1).

Workaround:

Führen Sie den folgenden Befehl aus, um das PDB zu löschen:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete pdb metrics-server -n gke-managed-metrics-server
Installation, Upgrades und Updates 1.28.0-1.28.600,1.29.0-1.29.100

Unter seltenen Race-Bedingungen kann eine falsche Installationssequenz des Binärautorisierungs-Webhooks und des gke-connect-Pods dazu führen, dass die Erstellung des Nutzerclusters angehalten wird, da ein Knoten nicht den Bereitschaftszustand erreicht. In betroffenen Szenarien kann die Erstellung des Nutzerclusters verzögert werden, da ein Knoten nicht den Bereitschaftsstatus erreicht. In diesem Fall wird die folgende Meldung angezeigt:

     Node pool is not ready: ready condition is not true: CreateOrUpdateNodePool: 2/3 replicas are ready

Workaround:

  1. Entfernen Sie die Konfiguration der Binärautorisierung aus der Konfigurationsdatei. Eine Einrichtungsanleitung finden Sie in der Installationsanleitung für Tag 2 der Binärautorisierung für GKE on VMware.
  2. Wenn Sie die Blockierung eines fehlerhaften Knotens während der aktuellen Clustererstellung aufheben möchten, entfernen Sie vorübergehend die Webhook-Konfiguration für die Binärautorisierung im Nutzercluster mit dem folgenden Befehl. 
            kubectl --kubeconfig USER_KUBECONFIG delete ValidatingWebhookConfiguration binauthz-validating-webhook-configuration
    Wenn der Bootstrap-Vorgang abgeschlossen ist, können Sie die folgende Webhook-Konfiguration neu hinzufügen. 
    apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: binauthz-validating-webhook-configuration
webhooks:
- name: "binaryauthorization.googleapis.com"
  namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist
  objectSelector:
    matchExpressions:
    - key: "image-policy.k8s.io/break-glass"
      operator: NotIn
      values: ["true"]
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - CREATE
    - UPDATE
    resources:
    - pods
    - pods/ephemeralcontainers
  admissionReviewVersions:
  - "v1beta1"
  clientConfig:
    service:
      name: binauthz
      namespace: binauthz-system
      path: /binauthz
    # CA Bundle will be updated by the cert rotator.
    caBundle: Cg==
  timeoutSeconds: 10
  # Fail Open
  failurePolicy: "Ignore"
  sideEffects: None
Upgrades 1.16, 1.28, 1.29

Während eines Nutzerclusterupgrades kann der Upgradevorgang hängen bleiben, wenn das gespiegelte Maschinenobjekt im Nutzercluster ein deletionTimestamp enthält. Wenn das Upgrade hängen bleibt, wird die folgende Fehlermeldung angezeigt:

    machine is still in the process of being drained and subsequently removed

Dieses Problem kann auftreten, wenn Sie bereits versucht haben, den Knoten der Steuerungsebene des Nutzers zu reparieren, indem Sie gkectl delete machine für den gespiegelten Rechner im Nutzercluster ausgeführt haben.

Workaround:

  1. Rufen Sie das gespiegelte Rechnerobjekt ab und speichern Sie es zu Sicherungszwecken in einer lokalen Datei.
  2. Führen Sie den folgenden Befehl aus, um den Finalizer vom gespiegelten Computer zu löschen und zu warten, bis er aus dem Nutzercluster gelöscht wird. 
        kubectl --kubeconfig ADMIN_KUBECONFIG patch machine/MACHINE_OBJECT_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge
  3. Führen Sie die Schritte in Knoten der Steuerungsebene des Nutzerclusters der Steuerungsebene v2 aus, um die Knotenreparatur auf den Knoten der Steuerungsebene auszulösen, damit die korrekten Quellrechnerspezifikationen erneut in den Nutzercluster synchronisiert werden.
  4. gkectl upgrade cluster noch einmal ausführen, um das Upgrade fortzusetzen
Konfiguration, Installation 1.15, 1.16, 1.28, 1.29

Bei einem HA-Administratorcluster oder einem Steuerungsebene v2-Nutzercluster muss sich die VIP der Steuerungsebene im selben Subnetz wie andere Clusterknoten befinden. Andernfalls schlägt die Clustererstellung fehl, da kubelet nicht über die VIP der Steuerungsebene mit dem API-Server kommunizieren kann.

Workaround:

Prüfen Sie vor dem Erstellen des Clusters, ob die VIP der Steuerungsebene im selben Subnetz wie die anderen Clusterknoten konfiguriert wurde.
Installation, Upgrades, Updates 1.29.0 – 1.29.100

Das Erstellen/Upgrade von Clustern schlägt mit einem Fehler in vsphere CSI-Pods fehl, der darauf hinweist, dass der vCenter-Nutzername ungültig ist. Dies liegt daran, dass der verwendete Nutzername kein voll qualifizierter Domainname ist. Fehlermeldung im vsphere-csi-controller-Pod:

    GetCnsconfig failed with err: username is invalid, make sure it is a fully qualified domain username

Dieses Problem tritt nur in Version 1.29 und höher auf, da dem vSphere-CSI-Treiber eine Validierung hinzugefügt wurde, um die Verwendung voll qualifizierter Domain-Nutzernamen zu erzwingen.

Workaround:

Verwenden Sie in der Konfigurationsdatei für Anmeldedaten einen voll qualifizierten Domainnamen für den vCenter-Nutzernamen. Anstelle von „nutzername1“ sollten Sie beispielsweise „nutzername1@beispiel.de“ verwenden.
Konfiguration 1.29.0

Wenn Sie gkectl ausführen, um einen Cluster zu erstellen, zu aktualisieren oder zu upgraden, bei dem Dataplane V2 bereits aktiviert ist, wird die folgende falsche Warnmeldung ausgegeben:

WARNING: Your user cluster is currently running our original architecture with 
[DataPlaneV1(calico)]. To enable new and advanced features we strongly recommend
to update it to the newer architecture with [DataPlaneV2] once our migration 
tool is available.

Es gibt einen Fehler in gkectl, der dazu führt, dass diese Warnung immer angezeigt wird, solange dataplaneV2.forwardMode nicht verwendet wird, auch wenn Sie enableDataplaneV2: true bereits in Ihrer Cluster-Konfigurationsdatei festgelegt haben.

Workaround:

Sie können diese Warnung einfach ignorieren.
Konfiguration 1.28.0-1.28.400, 1.29.0

Wenn Sie einen Hochverfügbarkeits-Administratorcluster erstellen, zeigt die Preflight-Prüfung die folgende falsche Fehlermeldung:

- Validation Category: Network Configuration
    - [FAILURE] CIDR, VIP and static IP (availability and overlapping): needed
    at least X+1 IP addresses for admin cluster with X nodes

Die Anforderung ist für HA-Administratorcluster ab Version 1.28 nicht korrekt, da sie keine Add-on-Knoten mehr haben. Da die 3 IP-Adressen der Knoten der Steuerungsebene des Administratorclusters im Abschnitt network.controlPlaneIPBlock in der Konfigurationsdatei des Administratorclusters angegeben sind, werden die IP-Adressen in der IP-Blockdatei nur für die Knoten der Steuerungsebene des Nutzerclusters von kubeception benötigt.

Workaround:

Fügen Sie dem Befehl gkectl --skip-validation-net-config hinzu, um die falsche Preflight-Prüfung in einem nicht festen Release zu überspringen.
Vorgang 1.29.0-1.29.100

Wenn Sie von einem Nicht-HA-Administratorcluster zu einem HA-Administratorcluster migriert haben, verliert der Connect Agent im Administratorcluster die Verbindung zu gkeconnect.googleapis.com mit dem Fehler „Fehler bei der Prüfung der JWT-Signatur“. Das liegt daran, dass während der Migration der KSA-Signaturschlüssel geändert wird und daher eine erneute Registrierung erforderlich ist, um die OIDC JWKs zu aktualisieren.

Workaround:

Führen Sie die folgenden Schritte aus, um den Administratorcluster wieder mit Google Cloud zu verbinden und eine erneute Registrierung auszulösen:

Rufen Sie zuerst den Bereitstellungsnamen gke-connect ab:

kubectl --kubeconfig KUBECONFIG get deployment -n gke-connect

Löschen Sie das Deployment gke-connect:

kubectl --kubeconfig KUBECONFIG delete deployment GKE_CONNECT_DEPLOYMENT -n gke-connect

Lösen Sie einen erzwungenen Abgleich für onprem-admin-cluster-controller aus, indem Sie eine „force-reconcile“-Annotation zur onpremadmincluster CR hinzufügen:

kubectl --kubeconfig KUBECONFIG patch onpremadmincluster ADMIN_CLUSTER_NAME -n kube-system --type merge -p '
metadata:
  annotations:
    onprem.cluster.gke.io/force-reconcile: "true"
'

Der Gedanke dahinter ist, dass onprem-admin-cluster-controller die Bereitstellung von gke-connect und die Neuregistrierung des Clusters immer wieder neu vornimmt, wenn keine gke-connect-Bereitstellung vorhanden ist.

Nach der Problemumgehung (es kann einige Minuten dauern, bis der Controller den Abgleich abgeschlossen hat) können Sie überprüfen, ob der Fehler "Fehler beim Überprüfen der JWT-Signatur" 400 aus den gke-connect-agent-Logs verschwunden ist:

kubectl --kubeconfig KUBECONFIG logs GKE_CONNECT_POD_NAME -n gke-connect
Installation, Betriebssystem 1.28.0-1.28.500, 1.29.0

Google Distributed Cloud legt in der Docker-Konfiguration ein eigenes Subnetz, --bip=169.254.123.1/24, für die IP-Adresse der Docker-Brücke fest, um zu verhindern, dass das Standard-Subnetz 172.17.0.1/16 reserviert wird. In den Versionen 1.28.0-1.28.500 und 1.29.0 wurde der Docker-Dienst jedoch nicht neu gestartet, nachdem Google Distributed Cloud die Docker-Konfiguration aufgrund einer Regression im COS OS-Image angepasst hatte. Deshalb nutzt Docker das Standard-Subnetz 172.17.0.1/16 als Brücken-Subnetz für IP-Adressen. Dies kann zu einem Konflikt der IP-Adressen führen, wenn bereits Arbeitslast innerhalb dieses IP-Adressbereichs ausgeführt wird.

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

Hinweis: Diese Lösung bleibt bei der Neuerstellung von VMs nicht bestehen. Sie müssen diese Problemumgehung jedes Mal neu anwenden, wenn VMs neu erstellt werden.
update 1.28.0-1.28.400, 1.29.0-1.29.100

Die Standard-CNI-Binärprogramme bridge, ipvlan, vlan, macvlan, dhcp, tuning, host-local, ptp, portmap sind nicht in den Betriebssystem-Images der betroffenen Versionen enthalten. Diese CNI-Binärdateien werden nicht von der Data Plane v2 verwendet, können aber für zusätzliche Netzwerkschnittstellen im Rahmen der Funktion für mehrere Netzwerkschnittstellen genutzt 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

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

Wenn einige erforderliche Konfigurationen im Administratorcluster leer sind, weil Validierungen übersprungen wurden, kann das Hinzufügen dieser Konfigurationen durch den Administratorcluster-Webhook blockiert werden. Wenn zum Beispiel das Feld gkeConnect in einem bestehenden Administratorcluster nicht festgelegt war, kann das Hinzufügen mit dem Befehl gkectl update admin die folgende Fehlermeldung auslösen:

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 Administratorcluster der Version 1.15 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 Administratorcluster der Version 1.16 den Befehl gkectl update admin 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

Wenn Sie einen manuellen Load Balancer verwenden (loadBalancer.kind ist auf "ManualLB" eingestellt), sollten Sie den Abschnitt loadBalancer.manualLB in der Konfigurationsdatei für einen Administratorcluster mit hoher Verfügbarkeit (HA) in Version 1.16 und höher nicht konfigurieren müssen. Wenn dieser Abschnitt jedoch leer ist, weist Google Distributed Cloud allen NodePorts, einschließlich manualLB.controlPlaneNodePort, Standardwerte zu, was dazu führt, dass die Cluster-Erstellung 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 manualLB.controlPlaneNodePort: 0 in der Konfiguration des Administratorclusters für den Hochverfügbarkeits-Administratorcluster an:

loadBalancer:
  ...
  kind: ManualLB
  manualLB:
    controlPlaneNodePort: 0
  ...
Upgrades, Updates 1.15.0-1.15.7, 1.16.0-1.16.4, 1.28.0

Wenn ein Administratorcluster und ein Nutzercluster mit aktivierter Steuerungsebene v2 unterschiedliche vSphere-Anmeldedaten verwenden, z.B. nach einer Aktualisierung der vSphere-Anmeldedaten für den Administratorcluster, kann der clusterapi-controller nach einem Neustart möglicherweise keine Verbindung zum vCenter herstellen. Sehen Sie sich das Log des clusterapi-controllers an, 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 aktivierter Steuerungsebene v2 dieselben vSphere-Anmeldedaten verwenden.

Logging und Monitoring 1.14

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.

Führen Sie die folgenden Schritte aus, um zu prüfen, ob es sich bei dieser Benachrichtigung um ein falsch-positives Ergebnis handelt, das ignoriert werden kann:

  1. Prüfen Sie den Rohmesswert „grpc_server_handled_total“ mit dem in der Warnmeldung angegebenen grpc_method. In diesem Beispiel prüfen Sie das Label grpc_code auf Watch.

    Sie können diesen Messwert mit der folgenden MQL-Abfrage in Cloud Monitoring prüfen: 
    fetch
    k8s_container | metric 'kubernetes.io/anthos/grpc_server_handled_total' | align rate(1m) | every 1m
  2. Eine Benachrichtigung über alle anderen Codes als OK kann bedenkenlos ignoriert werden, wenn der Code nicht zu den folgenden gehört: 
    Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded

Workaround:

Wenn Sie Prometheus so konfigurieren möchten, dass falsch positive Benachrichtigungen ignoriert werden, prüfen Sie die folgenden Optionen:

  1. Warnung stummschalten auf der Benutzeroberfläche des Benachrichtigungsmanagers.
  2. Wenn die Benachrichtigung nicht stummgeschaltet werden kann, gehen Sie so vor, um falsch positive Ergebnisse zu unterdrücken:
    1. Skalieren Sie den Monitoring-Operator auf 0 Replikate herunter, damit damit die Änderungen dauerhaft bestehen.
    2. Ändern Sie die ConfigMap prometheus-config und fügen Sie etcdHighNumberOfFailedGRPCRequests der Benachrichtigungskonfiguration grpc_method!="Watch" hinzu, wie im folgenden Beispiel gezeigt:
      • Original: 
        rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code!="OK",job=~".*etcd.*"}[5m])
      • Geändert am: 
        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 das 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 die Logs von etcd und kube-apiserver, um weitere Fehler zu beheben.
Netzwerk 1.16.0-1.16.2, 1.28.0

NAT-Verbindungen für ausgehenden Traffic können nach 5 bis 10 Minuten nach dem Aufbau der Verbindung abgebrochen werden, wenn kein Traffic vorhanden ist.

Da Conntrack nur für die eingehende Richtung (externe Verbindungen zum Cluster) relevant ist, tritt dieses Problem nur auf, wenn die Verbindung eine Weile keine Informationen überträgt und dann etwas von der Zielseite übertragen wird. Wenn der Pod für ausgehenden NAT-Traffic immer die Benachrichtigung instanziiert, wird dieses Problem nicht auftreten.

Dieses Problem tritt auf, weil die automatische Speicherbereinigung von anetd versehentlich Conntrack-Einträge entfernt, die der Daemon als nicht verwendet betrachtet. Eine vorgelagerte Lösung wurde kürzlich in anetd integriert, um das Verhalten zu korrigieren.


Workaround:

Es gibt keine einfache Problemumgehung, und wir haben in Version 1.16 keine Probleme mit diesem Verhalten festgestellt. Wenn Sie feststellen, dass langlebige Verbindungen aufgrund dieses Problems getrennt wurden, verwenden Sie zur Problemumgehung eine Arbeitslast auf demselben Knoten wie die IP-Adresse für ausgehenden Traffic oder senden Sie Nachrichten konsistent über die TCP-Verbindung.
Vorgang 1.14, 1.15, 1.16

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

Workaround:

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

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 dem folgenden fehl:

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

Dieser Fehler tritt auf, weil gkectl während der Preflight-Prüfungen nach einer Load Balancer-Ingress-IP-Adresse sucht. Obwohl diese Prüfung nicht erforderlich ist, wenn gebündelter eingehenden Traffic deaktiviert wird, schlagen die gkectl Preflight-Prüfung fehl, wenn disableBundledIngress auf true festgelegt 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, Updates 1.13, 1.14, 1.15.0-1.15.6

Wenn Sie die CA-Zertifikate eines 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 aktualisieren, indem Sie das Flag --disable-update-from-checkpoint mit dem gkectl update admin-Befehl verwenden:

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 die Prüfpunktdatei während der Clusteraktualisierung nicht 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

Während der Preflight-Prüfung installiert die CSI-Workload-Validierungsprüfung einen Pod im Namespace default. Der CSI-Arbeitslast-Pod prüft, ob der vSphere CSI-Treiber installiert ist und dynamische Volume-Bereitstellung durchführen kann. Wenn dieser Pod nicht startet, schlägt die CSI-Prüfung der Arbeitslast 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 Cloud 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-Validierung ein Zeitüberschreitungsfehler 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 auf zu wenige festgelegte Pod-Ressourcen zurückzuführen ist. Führen Sie dazu den Befehl Befehl „anthos-csi-workload-writer-<run-id>“ aus, um den Jobstatus zu prüfen:

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

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

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-Einschleusung nicht gestartet wird, können Sie die automatische Istio-Sidecar-Einfügung vorübergehend im default-Namespace deaktivieren. Prüfen Sie die Labels des Namespace und verwenden Sie den folgenden Befehl, um das Label zu löschen, 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 Volume-Bereitstellung 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. Stellen Sie sicher, dass der Pod Daten auf das Volume lesen/schreiben kann.
  4. Entfernen Sie den Pod und den PVC, nachdem Sie den ordnungsgemäßen Betrieb geprü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

Wenn Sie bei einer nutzerverwalteten Administratorworkstation angemeldet sind, kann es vorkommen, dass der Befehl gkectl update cluster eine Zeitüberschreitung verursacht und der Nutzercluster nicht aktualisiert werden kann. Das passiert, wenn die Version des Administratorclusters 1.15 ist und Sie gkectl update admin ausführen, bevor Sie 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 der validation-controller, der die Preflight-Prüfungen auslöst, aus dem Cluster entfernt. Wenn Sie dann versuchen, den Nutzercluster zu aktualisieren, bleibt der Preflight-Check hängen, bis die Zeitüberschreitung erreicht ist.

Workaround:

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

Wenn Sie bei einer nutzerverwalteten Administratorworkstation angemeldet sind, kann es vorkommen, dass der Befehl gkectl create cluster eine Zeitüberschreitung verursacht und der Nutzercluster nicht erstellt werden kann. Das passiert, 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 validation-controller in 1.16 hinzugefügt wurde, fehlt bei Verwendung des 1.15-Administratorclusters die validation-controller, die für das Auslösen der Preflight-Prüfungen verantwortlich ist. Wenn Sie also versuchen, einen Nutzercluster zu erstellen, bleiben die Preflight-Prüfungen hängen, bis eine Zeitüberschreitung erreicht ist.

Workaround:

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

Wenn Sie einen Administratorcluster von Version 1.15.x auf 1.16.x upgraden oder connect-, stackdriver-, cloudAuditLogging- oder gkeOnPremAPI-Konfiguration hinzufügen, wenn Sie einen Administratorcluster aktualisieren, wird der Vorgang möglicherweise vom Administrator-Cluster-Webhook abgelehnt. Eine der folgenden Fehlermeldungen wird möglicherweise 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."

Eine Aktualisierung oder ein Upgrade des Administratorclusters erfordert, dass onprem-admin-cluster-controller den Administratorcluster in einem Kind-Cluster abgleicht. Wenn der Administratorcluster-Status im Administratorcluster wiederhergestellt wird, kann der Administratorcluster-Webhook nicht unterscheiden, ob das OnPremAdminCluster-Objekt für die Erstellung eines Administratorclusters oder für die Wiederaufnahme von Vorgängen für ein Update oder Upgrade bestimmt ist. Einige Validierungen, die nur für die Erstellung gelten, werden bei Aktualisierungen und Upgrades unerwartet aufgerufen.


Workaround:

Fügen Sie die Annotation onprem.cluster.gke.io/skip-project-location-sameness-validation: true zum OnPremAdminCluster-Objekt 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 onprem.cluster.gke.io/skip-project-location-sameness-validation: true-Annotation hinzu und speichern Sie die benutzerdefinierte Ressource.
  3. Führen Sie je nach Typ der Administratorcluster einen der folgende Schritte aus:
    • Für Nicht-HA-Administratorcluster mit einer Prüfpunktdatei fügen Sie den Parameter disable-update-from-checkpoint in den Update-Befehl ein, oder fügen Sie den Parameter „disable-upgrade-from-checkpoint“ in den Upgrade-Befehl ein. Diese Parameter werden nur für die nächste 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
    • Bei Hochverfügbarkeits-Administratorclustern oder falls eine Checkpoint-Datei deaktiviert ist: Administratorcluster wie gewohnt aktualisieren oder upgraden. Keine zusätzlichen Parameter sind für die Aktualisierungs- oder Upgradebefehle erforderlich.
Vorgang 1.16.0-1.16.2

Wenn Sie bei einer nutzerverwalteten Administratorworkstation angemeldet sind, kann es vorkommen, dass der Befehl gkectl delete cluster eine Zeitüberschreitung verursacht und der Nutzercluster nicht gelöscht werden kann. Dies geschieht, wenn Sie zuerst gkectl auf der nutzerverwalteten Workstation ausgeführt haben, um den Nutzercluster zu erstellen, zu aktualisieren oder ein Upgrade durchzuführen. Wenn dieser Fehler auftritt, erhalten Sie den folgenden Fehler, wenn Sie versuchen, den Cluster zu löschen: 

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

Dabei werden zuerst alle zugehörigen Objekte eines Clusters gelöscht. Das Löschen der Validierungsobjekte, die während der Erstellung, Aktualisierung oder des Upgrades erstellt wurden, bleiben in der Löschphase hängen. Das passiert, weil ein Finalizer das Löschen des Objekts blockiert, was dazu führt, dass 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 für den Nutzercluster wird automatisch abgeschlossen. Sie müssen nichts weiter tun.

Netzwerk 1.15, 1.16

Wenn sich der Quell-Pod und der Egress-NAT-Gateway-Pod auf zwei verschiedenen Worker-Knoten befinden, kann der Traffic vom Quell-Pod keine externen Dienste erreichen. Befinden sich die Pods auf demselben Host, 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, wobei nur aggregierter Traffic an bekannte VXLAN-Ports (4789) gesendet wird.


Workaround:

Ändern Sie den von Cilium verwendeten VXLAN-Port in 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 DaemonSet anetd neu:
    kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

Dieser Workaround wird mit jedem Upgrade des Clusters rückgängig gemacht. Sie muss nach jedem Upgrade neu konfiguriert werden. VMware muss das Problem in vSphere beheben, um eine dauerhafte Lösung zu finden.
Speicher 1.11-1.16

Google Distributed Cloud unterstützt kein Changed Block Tracking (CBT) auf Laufwerken. Einige Sicherungssoftware verwendet das CBT-Feature, um den Laufwerkstatus zu verfolgen und Sicherungen durchzuführen. Dies führt dazu, dass das Laufwerk keine Verbindung zu einer VM herstellen kann, auf der Google Distributed Cloud ausgeführt wird. Weitere Informationen finden Sie in der VMware-Wissensdatenbank


Workaround:

Sichern Sie die Google Distributed Cloud-VMs nicht, da Sicherungssoftware von Drittanbietern dazu führen kann, dass CBT auf ihren Laufwerken aktiviert wird. Es ist nicht notwendig, diese VMs zu sichern.

Aktivieren Sie CBT auf dem Knoten nicht, da diese Änderung nicht über Updates oder Upgrades hinweg beibehalten wird.

Wenn Sie bereits Laufwerke mit aktiviertem CBT haben, befolgen Sie die Schritte zur Lösung im VMware-Wissensdatenbank-Artikel, um CBT auf dem First-Class-Laufwerk zu deaktivieren.
Speicher 1.14, 1.15, 1.16

Wenn Sie Nutanix-Speicher-Arrays verwenden, um Ihren Hosts NFSv3-Freigaben zur Verfügung zu stellen, kann es zu Datenbeschädigungen kommen oder Pods werden möglicherweise nicht erfolgreich ausgeführt. Dieses Problem wird durch ein bekanntes Kompatibilitätsproblem zwischen bestimmten VMware- und Nutanix-Versionen verursacht. Weitere Informationen Informationen finden Sie im zugehörigen Artikel in der VMware-Wissensdatenbank.


Workaround:

Der VMware-KB-Artikel ist veraltet, da er darauf hinweist, dass es keine aktuelle Lösung gibt. Führen Sie zur Behebung dieses Problems ein Update auf die neueste Version von ESXi auf Ihren Hosts und auf die neueste Nutanix-Version auf Ihren Speicher-Arrays durch.
Betriebssystem 1.13.10, 1.14.6, 1.15.3

Bei bestimmten Google Distributed Cloud-Versionen verwendet das Kubelet, das auf den Knoten ausgeführt wird, eine andere Version als die Steuerungsebene von Kubernetes. Es liegt eine Abweichung vor, weil das auf dem Image des Betriebssystems vorinstallierte Kubelet-Binärprogramm eine andere Version verwendet.

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

Google Distributed Cloud-Version Kubelet-Version Kubernetes-Version
1.13.10 v1.24.11-gke.1200 v1.24.14-gke.2100
1.14.6 v1.25.8-gke.1500 v1.25.10-gke.1200
1.15.3 v1.26.2-gke.1001 v1.26.5-gke.2100

Workaround:

Sie müssen nichts tun. Die Inkonsistenz besteht nur zwischen den Kubernetes-Patch-Versionen und es wurden keine Probleme durch diese Versionsabweichung verursacht.

Vorgang 1.13, 1.14.0-1.14.8, 1.15.0-1.15.4, 1.16.0-1.16.1

Wenn ein Nicht-HA-Steuerungsebenencluster gelöscht wird, bleibt er beim Löschen des Knotens hängen, bis er das Zeitlimit überschreitet.

Workaround:

Wenn der Cluster ein StatefulSet mit kritischen Daten enthält, wenden Sie sich an Cloud Customer Care, um dieses 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 noch einmal das Löschen des Clusters: 
         gkectl delete cluster --cluster USER_CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG --force

Speicher 1.15.0+, 1.16.0+

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 das vSphere-CSI-Feature configMap 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 deployment vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
Speicher 1.16.0

Wenn ein Cluster integrierte nichtflüchtige vSphere-Volumes enthält, lösen die Befehle gkectl diagnose und gkectl upgrade beim Validieren der Cluster-Speichereinstellungen möglicherweise falsche Warnungen vor ihren Anforderungen an nichtflüchtigen Volumes (Persistent Volume Claims, PVCs) aus. Die Warnmeldung sieht 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 bedenkenlos 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, Updates 1.15.0+, 1.16.0+

Wenn Ihr Cluster keine private Registry verwendet und Ihre Dienstkontenschlüssel für den Komponentenzugriff und das Logging-Monitoring (oder Connect-Register) abgelaufen sind, schlägt gkectl update credentials bei der Rotation der Dienstkontenschlüssel mit einer Fehlermeldung ähnlich der folgenden fehl: 

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

Workaround:

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

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

Wenn Sie während eines Upgrades eines Nutzerclusters nach dem Upgrade des Nutzercluster-Controllers auf 1.16 andere Nutzercluster haben, die von demselben Administratorcluster verwaltet werden, kann es vorkommen, dass deren Master-Nutzercomputer unerwartet neu erstellt wird.

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: Führen Sie die folgenden Schritte aus:

  1. Fügen Sie die Annotation zum Wiederholen mit dem folgenden Befehl manuell hinzu: 
    kubectl edit onpremuserclusters USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt --kubeconfig ADMIN_KUBECONFIG

    Die Annotation zum Wiederholen lautet:

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

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 folgendem 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

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

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.`

Aufgrund eines Fehlers wird ein leerer Hostname bei der Preflight-Prüfung als Duplikat betrachtet.

Workaround:

Option 1: Verwenden Sie eine Version mit der Fehlerkorrektur.

Option 2: Diese Preflight-Prüfung durch Hinzufügen des Flags --skip-validation-net-config umgehen.

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

Bei einem Nicht-HA-Administratorcluster und einem Nutzercluster auf Steuerungsebene v1 kann es vorkommen, dass bei einem Upgrade oder einer Aktualisierung des Administratorclusters der Neustart des Administratorcluster-Mastercomputers gleichzeitig mit dem Neustart des Nutzercluster-Mastercomputers erfolgt, was zu einer Race-Bedingung führen kann. Dadurch können die Pods der Nutzercluster-Steuerungsebene nicht mit der Steuerungsebene des Administratorclusters kommunizieren. 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 verifizieren:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace USER_CLUSTER_NAME describe pod IMPACTED_POD_NAME
 Sie sehen dann folgende Ereignisse: 
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 Nutzercluster der Steuerungsebene v1 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 Stufe ordnungsgemäß rekonstruieren.
Upgrades, Updates 1.16.0

Während eines Upgrades oder Updates 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 auf die Erstellung des Knotens warten muss und sogar das Upgrade/Update ausfällt. In diesem Fall sieht die Ausgabe des Befehls gkectl upgrade/update ähnlich aus wie die folgende:

    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"...

Führen Sie den folgenden Befehl aus, um das Symptom zu identifizieren und die Logs 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 ausgefallenene 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. Führen Sie den Upgrade-/Update-Befehl noch einmal aus.
Vorgang 1.16

Das Upgrade eines 1.15-Clusters oder das Erstellen 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 keine externe IP-Adresse und Anbieter-ID im Knotenobjekt hinzufügen kann. Dadurch kommt es zu einer Zeitüberschreitung beim Upgrade/Erstellen des Clusters.

Rufen Sie zum Identifizieren des Problems die Pod-Logs des vSphere Cloud Controller-Managers für den Cluster ab. Welchen Befehl Sie verwenden, hängt 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 dupliziert ist, und bei Bedarf einen Workaround 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 -ausgaben: 
          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

Welche Lösung Sie wählen, hängt vom fehlgeschlagenen Vorgang ab.

Problemumgehung für Upgrades:

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

  • Nutzercluster:
    1. Ändern Sie den Hostnamen der betroffenen Maschine in „user-ip-block.yaml“ in 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 wiederholen
  • Administratorcluster:
    1. Ändern Sie den Hostnamen der betroffenen Maschine 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 einen 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 muss mit dem Wert übereinstimmen, den Sie in Schritt 1 in der Datei „admin-ip-block.yaml“ festgelegt haben.
                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. Führen Sie das Administratorcluster-Upgrade noch einmal mit deaktiviertem Prüfpunkt aus:
                gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --disable-upgrade-from-checkpoint

Workaround für 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

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

  • Upgrade eines 1.15-Nutzerclusters mit aktivierter Steuerungsebene V2 auf 1.16 ausführen
  • Upgrade eines 1.15-Hochverfügbarkeits-Administratorclusters auf 1.16 durchführen
  • Nutzercluster der Version 1.16 mit aktivierter Steuerungsebene V2 erstellen
  • 1.16-Hochverfügbarkeits-Administratorcluster erstellen

Verwenden Sie eine Version 1.16.4 oder höher von Google Distributed Cloud 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 -Passwort auf vCenter-Seite, um $ und ` zu entfernen.
  2. Aktualisieren Sie den vCenter-Nutzernamen oder das vCenter-Passwort in Ihrer Anmeldedaten-Konfigurationsdatei.
  3. Lösen Sie ein erzwungenes Update des Clusters aus.
    • 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

Workaround für Installationen:

  1. Ändern Sie den vCenter-Nutzernamen oder das -Passwort auf vCenter-Seite, um $ und ` zu entfernen.
  2. Aktualisieren Sie den vCenter-Nutzernamen oder das vCenter-Passwort in Ihrer Anmeldedaten-Konfigurationsdatei.
  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

Nachdem ein Knoten gelöscht und dann mit demselben Knotennamen neu erstellt wurde, besteht die Möglichkeit, dass die nachfolgende Erstellung von PersistentVolumeClaim (PVC) 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 deployment vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
Vorgang 1.16.0

Wenn Sie den Befehl gkectl repair admin-master für einen Hochverfügbarkeits-Administratorcluster 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 die VM-Namensvorlage, die mit dem Namen der zu reparierenden Maschine übereinstimmt, 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

Wenn Sie Seesaw als Load Balancer-Typ für Ihren Cluster verwenden und feststellen, dass eine Seesaw-VM ausfällt oder nicht mehr hochfährt, sehen Sie möglicherweise die folgende Fehlermeldung in der vSphere Console:

    GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd

Dieser Fehler deutet darauf hin, dass der Laufwerksspeicher auf der VM knapp ist, weil das auf der Seesaw-VM ausgeführte Fluent-Bit nicht mit der richtigen Log-Rotation konfiguriert ist.


Workaround:

Suchen Sie mit du -sh -- /var/lib/docker/containers/* | sort -rh nach den Logdateien, 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

Beim Versuch, ein Upgrade (gkectl upgrade admin) oder ein Update (gkectl update admin) eines Administratorclusters ohne Hochverfügbarkeit mit aktiviertem Prüfpunkt durchzuführen, kann das Upgrade oder Update mit Fehlern wie den folgenden fehlschlagen:

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 der Fehlerbehebung kein Upgrade auf eine Patchversion von Google Distributed Cloud 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

Wenn ein Administratorcluster in der GKE On-Prem API registriert ist, schlägt ein Upgrade des Administratorcluster auf die betroffenen Versionen möglicherweise fehl, da die Flottenmitgliedschaft nicht aktualisiert werden konnte. Wenn dieser Fehler auftritt, erhalten Sie den folgenden Fehler, wenn Sie versuchen, ein Upgrade für den Cluster auszufü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 wenn Sie einen Nutzercluster mit einem GKE On-Prem API-Client aktualisieren.


Workaround:

Heben Sie die Registrierung des Administratorclusters auf: 
    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
und setzen Sie das Upgrade des Administratorclusters fort. Möglicherweise sehen Sie vorübergehend die veraltete Fehlermeldung „Failed to register cluster“ (Cluster konnte nicht registriert werden). Nach einer Weile sollte er automatisch aktualisiert werden.
Upgrades, Updates 1.13.0-1.13.9, 1.14.0-1.14.4, 1.15.0

Wenn ein Administratorcluster bei der GKE On-Prem-API angemeldet wird, wird seine Ressource-Link-Annotation auf die benutzerdefinierte OnPremAdminCluster-Ressource angewendet, die bei späteren Administratorcluster-Aktualisierungen nicht erhalten bleibt, da der falsche Annotationsschlüssel verwendet wird. Dies kann dazu führen, dass der Administratorcluster sich versehentlich wieder bei der GKE On-Prem API registriert.

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


Workaround:

Heben Sie die Registrierung des Administratorclusters auf: 
    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 neu.
Upgrades, Updates 1.10, 1.11, 1.12, 1.13.0-1.13.7, 1.14.0-1.14.3

Bestimmte Race-Bedingungen können dazu führen, dass der OnPremAdminCluster-Status zwischen dem Prüfpunkt und der tatsächlichen Antwortvorlage nicht konsistent ist. Wenn das Problem auftritt, kann die folgende Fehlermeldung auftreten, wenn Sie den Administratorcluster nach dem Upgrade aktualisieren:

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 den Prüfpunkt entweder bearbeiten oder für das Upgrade/Update deaktivieren. Wenden Sie sich an unser Supportteam, um die Umgehung durchzuführen.
Vorgang 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

Google Distributed Cloud ändert die Admin-Zertifikate auf Administratorcluster-Steuerebenen bei jedem Abstimmungsprozess, z. B. bei einem Cluster-Upgrade. Dieses Verhalten erhöht das Risiko ungültiger Zertifikate für Ihren Administratorcluster, insbesondere bei Clustern der Version 1.15.

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

  • Ungültige Zertifikate können zu einer Zeitüberschreitung bei den folgenden Befehlen führen und Fehler zurückgeben:
    • 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 enthalten möglicherweise Fehler wie:
    Unable to authenticate the request" err="[x509: certificate has expired or is not yet valid...

Workaround:

Führen Sie ein Upgrade auf eine Version von Google Distributed Cloud mit der Fehlerbehebung durch: 1.13.10+, 1.14.6+, 1.15.2+. Wenn kein Upgrade möglich ist, wenden Sie sich an Cloud Customer Care, um das Problem zu beheben.
Netzwerk, Vorgang 1.10, 1.11, 1.12, 1.13, 1.14

Netzwerk-Gateway-Pods in kube-system können den Status Pending oder Evicted anzeigen, wie in der folgenden zusammengefassten 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 nicht geplant werden können aufgrund der Knotenressourcen. 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 ang-node DaemonSet, 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 manuell eine PriorityClass zu den Anthos Network Gateway-Komponenten zuweisen. Der Google Distributed Cloud-Controller überschreibt diese manuellen Änderungen während eines Abgleichs, z. B. während eines Clusterupgrades.

  • Weisen Sie die PriorityClass system-cluster-critical den ang-controller-manager- und autoscaler-Cluster Controller-Bereitstellungen zu.
  • Weisen Sie die PriorityClass system-node-critical dem ang-daemon-Knoten-DaemonSet zu.
Upgrades, Updates 1.12, 1.13, 1.14, 1.15.0-1.15.2

Nachdem Sie gcloud verwendet haben, um einen Administratorcluster mit einem nicht leeren gkeConnect-Abschnitt zu registrieren, wird beim Versuch, ein Upgrade für den Cluster durchzuführen, möglicherweise der folgende Fehler angezeigt:

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 Knoten des Clusters ausgeführt werden, nicht begrenzen

Dies hat keinen Einfluss auf die Funktionalität der Erstellung eines Snapshots des Clusters, da der Snapshot weiterhin alle Logs enthält, die standardmäßig durch die Ausführung von journalctl auf den Knoten des Clusters erfasst werden. Daher fehlen keine Debugging-Informationen.
Installation, Upgrades, Updates 1.9+, 1.10+, 1.11+, 1.12+

gkectl prepare windows kann Docker nicht auf Google Distributed Cloud-Versionen vor 1.13 installieren, weil MicrosoftDockerProvider eingestellt wurde.


Workaround:

In der Regel lässt sich dieses Problem durch ein Upgrade auf Google Distributed Cloud 1.13 und die Verwendung des 1.13 gkectl zur Erstellung einer Windows VM-Vorlage und der anschließenden Erstellung von Windows-Knotenpools umgehen. Es gibt zwei Möglichkeiten, um von Ihrer aktuellen Version zu Google Distributed Cloud 1.13 zu gelangen (siehe unten).

Hinweis: Wir haben verschiedene Möglichkeiten, dieses Problem in Ihrer aktuellen Version zu umgehen, ohne ein Upgrade auf Version 1.13 ausführen zu müssen. Dafür sind jedoch mehr manuelle Schritte erforderlich. Bitte wenden Sie sich an unser Supportteam, wenn Sie diese Option in Betracht ziehen.


Option 1: Blau/Grün-Upgrade

Sie können einen neuen Cluster mit Google Distributed Cloud Version 1.13 oder höher und Windows-Knotenpools erstellen und die Arbeitslasten auf den neuen Cluster migrieren und dann den aktuellen Cluster bereinigen. Es wird empfohlen, die neueste Google Distributed Cloud-Nebenversion zu verwenden.

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


Option 2: Windows-Knotenpools löschen und wieder hinzufügen, wenn ein Upgrade auf Google Distributed Cloud 1.13 durchgeführt wird.

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

  1. Löschen Sie die vorhandenen Windows-Knotenpools, indem Sie die Konfiguration der Windows-Knotenpools aus der Datei user-cluster.yaml entfernen, 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 gemäß dem Upgrade-Nutzerhandbuch für die entsprechende Ziel-Nebenversion durch.
  3. Vor dem Upgrade auf 1.13 sollten Sie darauf achten, dass enableWindowsDataplaneV2: true in der benutzerdefinierten Ressource OnPremUserCluster konfiguriert ist. Andernfalls verwendet der Cluster für Windows-Knotenpools weiterhin Docker, was nicht mit der neu erstellten Windows-VM-Vorlage von Version 1.13 kompatibel ist, auf der Docker nicht installiert ist. Wenn der Cluster nicht konfiguriert oder auf „false“ gesetzt ist, aktualisieren Sie ihn, indem Sie ihn in „user-cluster.yaml“ auf „true“ setzen. Führen Sie dann Folgendes aus: 
    gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  4. Führen Sie ein Upgrade der Linux-Administrator- und Nutzercluster auf 1.13 gemäß dem Upgrade-Nutzerhandbuch durch.
  5. Bereiten Sie die Windows-VM-Vorlage mit 1.13 gkectl 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 und legen Sie das Feld OSImage auf die neu erstellte Windows-VM-Vorlage fest.
  7. Cluster aktualisieren, um Windows-Knotenpools hinzuzufügen 
    gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
Installation, Upgrades, Updates 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

Auf den Knoten wird der Standardwert von 5 Sekunden für RootDistanceMaxSec verwendet, anstatt 20 Sekunden, was der erwarteten Konfiguration entsprechen sollte. Wenn Sie das Log für den Start des Knotens per SSH in der VM prüfen, das sich unter „/var/log/startup.log“ befindet, können Sie den folgenden Fehler finden:

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

Die Verwendung eines 5-Sekunden-RootDistanceMaxSec kann dazu führen, dass die Systemuhr nicht mehr mit dem NTP-Server synchronisiert ist, wenn die Abweichung der Uhr 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, Updates 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

Wenn Sie die Version 1.13 gkectl verwenden, um einen Administratorcluster der Version 1.12 zu aktualisieren, 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 Version 1.13- oder 1.14-Cluster verwenden, wird in der Antwort möglicherweise die folgende Meldung 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 Log von gkectl prüfen, sehen Sie möglicherweise, dass zu den mehrfachen Änderungen das Setzen von osImageType von einem leeren String auf ubuntu_containerd gehört.

Diese Aktualisierungsfehler sind darauf zurückzuführen, dass das Feld osImageType in der Administratorcluster-Konfiguration seit seiner Einführung in Version 1.9 nicht mehr korrekt ausgefüllt wurde.


Workaround:

Führen Sie ein Upgrade auf eine Version von Google Distributed Cloud mit der Fehlerbehebung durch. Wenn ein Upgrade für Sie nicht möglich ist, wenden Sie sich an den Cloud Customer Care, um dieses Problem zu lösen.
Installation, Sicherheit 1.13, 1.14, 1.15, 1.16

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 aktiviert ist ( enableControlplaneV2: true).


Workaround:

Bis ein Google Distributed Cloud-Patch mit der Fehlerbehebung verfügbar ist, sollten Sie, wenn Sie SNI verwenden müssen, die Steuerungsebene V2 deaktivieren (enableControlplaneV2: false).
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

Die Maschine der Administrator-Steuerungsebene kann nicht gestartet werden, wenn der Nutzername der privaten Registry $ enthält. Wenn Sie das /var/log/startup.log auf der Maschine der Administrator-Steuerungsebene prüfen, 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 privaten Registry-Nutzernamen ohne $ oder eine Version von Google Distributed Cloud mit der Fehlerbehebung.
Upgrades, Updates 1.12.0-1.12.4

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

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

Nach der Rotation der KSA-Signaturschlüssel und der anschließenden Aktualisierung der Nutzercluster 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 Ihrer KSA-Signaturschlüssel wieder auf 1, behalten Sie jedoch die neuesten Schlüsseldaten bei:
  1. Prüfen Sie das Secret im Administratorcluster im Namespace USER_CLUSTER_NAME und rufen Sie den Namen des Secrets „ksa-signing-key“ 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 „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 „ksa-signing-key“:
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME
  4. Ändern Sie das Feld data.data in der ConfigMap „ksa-signing-key-rotation-stage“ in '{"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 OnPremUserCluster-Ressource 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. Ändern Sie das Feld spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation in der benutzerdefinierten OnPremUserCluster-Ressource in 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 der KSA-Signaturschlüssel, bis für den Cluster ein Upgrade auf die Version mit der Korrektur durchgeführt wurde.
Vorgang 1.13.1+, 1.14, 1., 1.16

Wenn Sie Terraform zum Löschen eines Nutzerclusters mit einem F5 BIG-IP Load Balancer verwenden, werden die virtuellen F5 BIG-IP Server nach dem Löschen des Clusters nicht entfernt.


Workaround:

Führen Sie zum Entfernen der F5-Ressourcen die Schritte zum Bereinigen einer Nutzercluster-F5-Partition aus
Installation, Upgrades, Updates 1.13.8, 1.14.4

Wenn Sie einen Administratorcluster der Version 1.13.8 oder Version 1.14.4 erstellen oder ein Upgrade des Administratorclusters auf Version 1.13.8 oder 1.14.4 durchführen, ruft der Kind-Clusters folgende Container-Images aus docker.io ab:

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

    • Wenn Sie von Ihrer Administratorworkstation aus nicht auf docker.io zugreifen können, wird bei der Erstellung oder dem Upgrade des Administratorclusters der Kind-Cluster nicht gestartet. Wenn Sie den folgenden Befehl auf der Administratorworkstation ausführen, werden die entsprechenden Container mit ausstehendem ErrImagePull angezeigt:

    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 vorab in das Container-Image des Kind-Cluster geladen werden. Allerdings hat Kind v0.18.0 ein Problem mit den vorinstallierten Container-Images, wodurch sie versehentlich aus dem Internet geladen werden.


    Workaround:

    Führen Sie die folgenden Befehle auf der Administratorworkstation aus, während bei Ihrem Administratorcluster die Erstellung oder das Upgrade 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

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

    Die betroffenen Knoten können die virtuelle IP-Adresse der Steuerungsebene ping, jedoch wird es bei einer TCP-Verbindung zur virtuellen IP-Adresse der Steuerungsebene eine Zeitüberschreitung geben.


    Workaround:

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

    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

    Auch wenn die Clusterregistrierung während der Erstellung des Administratorclusters fehlschlägt, schlägt der Befehl gkectl create admin bei dem Fehler nicht fehl und wird möglicherweise erfolgreich sein. Mit anderen Worten, die Erstellung des Administratorclusters könnte „erfolgreich“ sein, ohne bei einer Flotte registriert zu sein.

    Um das Symptom zu ermitteln, können Sie im Protokoll von „gkectl create admin“ nach den folgenden Fehlermeldungen suchen: 
    Failed to register admin cluster

    Sie können auch prüfen, ob der Cluster in der Cloud Console unter Registrierte Cluster aufgeführt ist.

    Workaround:

    Folgen Sie bei Clustern, die mit Version 1.12 und höher erstellt wurden, nach der Clustererstellung der Anleitung zum erneuten Registrierungsversuch des Administratorclusters. 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, Updates 1.10, 1.11, 1.12, 1.13.0-1.13.1

    Wenn beim Upgrade des Administratorclusters 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 erneuten Registrierungsversuch überspringen. Folgen Sie bei Clustern, die auf Version 1.12 und höher aktualisiert wurden, der Anleitung zum Erneuten Versuch der Administratorclusterregistrierung nach der Clustererstellung. Bei Clustern, die auf frühere Versionen aktualisiert 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.

    Speicher 1.15, 1.16

    Unter bestimmten Umständen 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 ein neuer Satz von Knoten eine alte Gruppe von Knoten ersetzt (z. B. Cluster-Upgrade oder Knotenpool-Aktualisierung). Zustandsorientierte Arbeitslasten, die zuvor gut funktioniert haben, können möglicherweise nicht in ihre Volumes auf dem neuen Knotensatz schreiben.


    Workaround:

    1. Rufen Sie die UID des Pods ab, der nicht in das zugehörige Volume schreiben kann: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
    POD_NAME --namespace POD_NAMESPACE \
    -o=jsonpath='{.metadata.uid}{"\n"}'
    2. Rufen Sie mit dem PersistentVolumeClaim den Namen des PersistentVolume 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. Sie müssen PowerShell-Zugriff auf den Knoten haben, entweder über SSH oder über 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 Nummer 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 in etwa so aussehen: True.
    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. Für den Fall, dass der Pod auf einem neuen Knoten geplant wird, müssen Sie die vorangegangenen Schritte auf dem neuen Knoten wiederholen.

    Upgrades, 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 nach der Aktualisierung der Clusteranmeldedaten aktualisieren, verwendet vsphere-csi-secret im kube-system-Namespace im Administratorcluster möglicherweise weiterhin die alten Anmeldedaten.


    Workaround:

    1. Rufen Sie den Namen des Secrets vsphere-csi-secret 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 vorherigen Schritt abgerufen 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. Starten Sie vsphere-csi-controller neu:
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller
    4. So können Sie den Roll-out-Status verfolgen: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
       Nach der erfolgreichen Bereitstellung sollte der Controller das aktualisierte vsphere-csi-secret verwenden.
    Upgrades, Updates 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    audit-proxy kann aufgrund einer leeren --cluster-name in einer Absturzschleife landen. 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 Nutzercluster der Steuerungsebene v2 mit enableControlplaneV2: true eine SSH-Verbindung zum Rechner der Nutzer-Steuerebene 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 in dem Statefulset kube-apiserver, um --cluster_name=USER_CLUSTER_NAME hinzuzufügen:

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

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

    Das liegt daran, dass die Zertifikatsrotation der Steuerungsebene automatisch nach gkectl upgrade cluster passiert.

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


    Workaround:

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

    Google Distributed Cloud 1.12.7-gke.19 ist eine schlechte Version, die 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, Updates 1.12.0+, 1.13.0-1.13.7, 1.14.0-1.14.3

    Wenn Sie die Registry-Anmeldedaten 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

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

    Dieses Problem wird in Google Distributed Cloud-Releases 1.13.8, 1.14.4 und nachfolgenden Releases behoben.


    Workaround:

    Option 1: gke-connect-agent manuell neu bereitstellen:

    1. Löschen Sie den Namespace gke-connect: 
      kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect
    2. Stellen Sie gke-connect-agent mit dem ursprünglichen Schlüssel für die Registrierung von Dienstkonten wieder bereit (Sie müssen den Schlüssel nicht aktualisieren):

      Für den Administratorcluster: 
      gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG_FILE --admin-cluster
       Für den 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: Sie können das Standard-Image-Pull-Secret für Ihren Cluster in der Bereitstellung gke-connect-agent hinzufügen:

    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 Namen der Bereitstellung gke-connect-agent ab: 
      kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
    3. Fügen Sie der Bereitstellung gke-connect-agent das Standard-Secret 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

    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: Sie können die Patchversionen 1.13.7 und 1.14.4 verwenden, die die Fehlerbehebung enthalten.

    Option 2: Sie können denselben Befehl auch ausführen, um die Konfiguration zu validieren, aber die Validierung des Load-Balancers zu ü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, and 1.14

    Bei Clustern, auf denen etcd Version 3.4.13 oder früher ausgeführt wird, kann es zu einem Monitoringmangel und nicht operativer Ressourcenüberwachung kommen, was zu den folgenden Problemen führen kann:

    • Pod-Planung wird 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 Google Distributed Cloud-Versionen 1.12.7, 1.13.6, 1.14.3 und nachfolgenden Releases behoben. Diese neueren Releases verwenden die etcd-Version 3.4.21. Alle früheren Versionen von Google Distributed Cloud sind von diesem Problem betroffen.

    Problemumgehung

    Wenn Sie kein sofortiges Upgrade durchführen können, verringern Sie einen Clusterfehler durch Reduzieren der Knotenanzahl im Cluster. Entfernen Sie Knoten bis der etcd_network_client_grpc_sent_bytes_total-Messwert 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 und geben Sie Kubernetes Container in der Filterleiste ein und wählen Sie dann in den Untermenüs den Messwert aus:
      1. Wählen Sie im Menü Aktive Ressourcen den Eintrag 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, Updates 1.10, 1.11, 1.12, 1.13 und 1.14

    Bei Neustarts oder Upgrades von Clustern kann der GKE Identity Service mit Traffic überlastet werden, der aus abgelaufenen JWT-Tokens besteht, die von kube-apiserver an den GKE Identity Service über den Authentifizierungs-Webhook weitergeleitet werden. Obwohl der GKE Identity Service nicht in einer Absturzschleife endet, reagiert der Dienst nicht mehr und stellt die Bearbeitung weiterer Anfragen ein. Dieses Problem führt letztendlich zu höheren Latenzen der Steuerungsebene.

    Dieses Problem wurde in den folgenden Google Distributed Cloud-Releases behoben:

    • 1.12.6+
    • 1.13.6+
    • 1.14.2+

    So ermitteln Sie, ob Sie von diesem Problem betroffen sind:

    1. Prüfen Sie, ob der GKE Identity Service-Endpunkt 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 mit der virtuellen IP-Adresse der Steuerungsebene und dem 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 einen 400-Statuscode 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 wurde. Wenn Sie den Statuscode 000 erhalten, wurde das Problem behoben. Wird weiterhin der Statuscode 400 angezeigt, 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 Service-Log: 
        kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG

        Wenn das Log 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 den folgenden enthalten, dann 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 ermitteln und neu starten, um es zu umgehen:

    1. Erhöhen Sie den Ausführlichkeitsgrad 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. Suchen Sie im GKE Identity Service-Log nach dem ungültigen Tokenkontext: 
      kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG
    3. Um die mit jedem ungültigen Tokenkontext verknüpfte Token-Nutzlast abzurufen, parsen Sie jedes zugehörige Dienstkonto-Secret mit dem folgenden Befehl:
      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.9, 1.10, 1.11, 1.12, 1.13

    Sowohl der Cluster-Systemdiagnose-Controller als auch der gkectl diagnose cluster-Befehl 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
    Netzwerk 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    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 seesaw-gruppendatei bereits vorhanden ist. Die Preflight-Prüfung versucht, einen nicht vorhandenen Seesaw-Load-Balancer zu validieren.

    Workaround:

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

    Google Distributed Cloud Version 1.14 ist anfällig für Fehler beim Einfügen der Tabelle für das Verbindungs-Tracking (conntrack) von Netfilter, wenn Sie Images der Betriebssysteme Ubuntu oder COS verwenden. Einfügungsfehler führen zu Zeitüberschreitungen für Anwendungen und können auch dann auftreten, wenn in der Conntrack-Tabelle Platz für neue Einträge ist. Die Fehler werden durch Änderungen am Kernel 5.15 und höher verursacht, die das Einfügen von Tabellen basierend auf der Kettelänge einschränken.

    Ob Sie von diesem Problem betroffen sind, können Sie mit folgendem Befehl in den Systemstatistiken des Kernel-Verbindungstrackings 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 Größe der Tabellen 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. Wir empfehlen einen Wert, der dem 65.536-fachen der Anzahl der Kerne auf dem Knoten entspricht. Beispiel: Wenn Ihr Knoten acht Kerne hat, legen Sie die Tabellengröße auf 524288 fest.
    Netzwerk 1.13.0-1.13.2

    Mit Steuerungsebene v2 oder einem neuen Installationsmodell werden calico-typha oder anetd-operator möglicherweise für Windows-Knoten geplant und sie 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 1.13.3 oder höher durch oder führen Sie die folgenden Befehle aus, um das Deployment „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

    Entfernen Sie folgende 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

    Möglicherweise können Sie keinen Nutzercluster erstellen, wenn Sie den Abschnitt privateRegistry mit den Anmeldedaten fileRef angeben. Die Preflight-Prüfung 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 der Administratorcluster verwenden möchten, können Sie den Abschnitt privateRegistry in der Konfigurationsdatei des Nutzerclusters einfach entfernen oder kommentieren.
    • Wenn Sie für Ihren Nutzercluster bestimmte Anmeldedaten für die private Registry verwenden möchten, können Sie den Abschnitt privateRegistry vorübergehend so 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 sind bereits eingestellt. Verwenden Sie beim Upgrade auf 1.14.3 oder höher die Anmeldedatendatei.)

    Speicher 1.12+, 1.13.3

    kube-controller-manager kann beim Trennen von PV/PVCs nach 6 Minuten eine Zeitüberschreitung verursachen und die PV/PVCs erzwungenermaßen trennen. Detaillierte Logs von kube-controller-manager zeigen ähnliche Ereignisse an 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, Updates 1.12+, 1.13+, 1.14+

    Wenn Sie den CSI-Treiber eines Drittanbieters verwenden, können Sie einen Cluster möglicherweise nicht aktualisieren. 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 dem --skip-validation-all aus.
    Vorgang 1.10+, 1.11+, 1.12+, 1.13+, 1.14+

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

    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-Masterknoten herunter, folgen Sie 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+

    In systemd v244 hat systemd-networkd eine Standardverhaltensänderung in der KeepConfiguration-Konfiguration. Vor dieser Änderung haben VMs beim Herunterfahren oder Neustart 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 zugewiesen werden und/oder der VM eine andere IP-Adresse zugewiesen werden, was zu einem IP-Konflikt (auf Kubernetes-Ebene, 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.

    Zum Beispiel können die folgenden Symptome auftreten.

    • Die vCenter-UI zeigt an, dass keine VMs dieselbe IP 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 eines calico-node-Fehlers nicht gestartet werden
      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


    Workaround:

    Stellen Sie das folgende DaemonSet auf dem Cluster bereit, um die Änderung des systemd-networkd-Standardverhaltens rückgängig zu machen. Die VMs, auf denen dieses DaemonSet ausgeführt wird, geben die IP-Adressen beim Herunterfahren/Neustarten nicht für den DHCP-Server frei. Die IP-Adressen werden nach Ablauf der Freigaben 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

    Vorgang, Upgrades, Aktualisierungen 1.12.0-1.12.5, 1.13.0-1.13.5, 1.14.0-1.14.1

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

    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 geleert und gelöscht. Mit dem folgenden Befehl können Sie dies prüfen: 

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

    Nachdem der Schlüssel für das Dienstkonto für den Komponentenzugriff gelöscht wurde, schlägt die Installation neuer Nutzercluster oder die Aktualisierung bestehender Nutzercluster fehl. Im Folgenden finden Sie einige Fehlermeldungen, die auftreten können:

    • Langsamer Validierungs-Preflight-Fehler 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, schlägt der Befehl mit der Meldung fehl, wenn Sie gkectl update admin --enable-preview-user-cluster-central-upgrade ausführen, um den Upgrade-Platform-Controller bereitzustellen: "failed to download bundle to disk: dialing: unexpected end of JSON input" (Diese Meldung erscheint im Feld status in der Ausgabe von kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml).


    Workaround:

    Fügen Sie den Schlüssel des Dienstkontos für den Komponentenzugriff wieder manuell in das Secret ein, indem Sie den folgenden Befehl ausführen:

    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+

    Bei Nutzerclustern, die mit Steuerungsebene 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 Cluster-Autoscaling-Pods zeigt auch an, dass dessen Pods 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
    Sie können den Cluster Autoscaler-Pod mit den folgenden Befehlen finden. 
      > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
   get pods | grep cluster-autoscaler
cluster-autoscaler-5857c74586-txx2c                          4648017n    48076Ki    30s


    Workaround:

    Deaktivieren Sie das Autoscaling in allen Knotenpools mit „gkectl update cluster“, bis Sie ein Upgrade auf eine Version mit der Fehlerbehebung durchführen.
    Installation 1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

    Wenn Nutzer in der IP-Blockdatei CIDR 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


    Workaround:

    Nehmen Sie einzelne IP-Adressen in die IP-Blockdatei auf, bis ein Upgrade auf eine Version mit dieser Korrektur durchgeführt wird: 1.12.5, 1.13.4, 1.14.1+.
    Upgrades, Updates 1.14.0-1.14.1

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


    Workaround:

    Warten Sie nach Abschluss des Updates, bis die Maschinen der Nutzersteuerungsebene auch die Neuerstellung abschließen, indem Sie die Knoten-Betriebssystem-Image-Typen mit kubectl --kubeconfig USER_KUBECONFIG get nodes -owide überwachen. Wenn Sie z.B. von Ubuntu auf COS aktualisieren, sollten wir warten, bis alle Maschinen der Steuerungsebene nach Abschluss des Aktualisierungsbefehls vollständig von Ubuntu zu COS gewechselt sind.

    Vorgang 1.10, 1.11, 1.12, 1.13, 1.14.0

    Ein Problem mit Calico in Google Distributed Cloud 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 der Ausführung des Clusters auf, der mit Calico erstellt oder auf 1.14 aktualisiert wurde.

    Administratorcluster verwenden immer Calico. Für den Nutzercluster gibt es dagegen ein Konfigurationsfeld „enableDataPlaneV2“ in der Datei „user-cluster.yaml“, wenn dieses Feld auf „false“ gesetzt oder nicht angegeben ist, d. h. Sie nutzen Calico im Nutzercluster.

    Die Knoten des install-cni-Containers erstellt eine kubeconfig-Datei mit einem Token, das 24 Stunden lang gültig ist. Dieses Token muss regelmäßig durch den Pod calico-node verlängert werden. calico-node Der Pod 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 Google Distributed Cloud Version 1.14.1 behoben. Upgrade auf diese oder eine neuere Version.

    Wenn Sie das Upgrade nicht sofort durchführen können, wenden Sie den folgenden Patch auf dem calico-node DaemonSet 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: Pfad Ihrer Nutzercluster-Konfigurationsdatei.
    Installation 1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

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


    Workaround:

    Teilen Sie CIDRs in mehrere kleinere CIDR-Blöcke auf. 10.0.0.0/30 wird beispielsweise zu 10.0.0.0/31, 10.0.0.2/31. Solange es N+1 CIDRs gibt, wobei N die Anzahl der Knoten im Cluster ist, sollte dies ausreichen.

    Upgrades, Updates 1.11, 1.12

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

    Ab Version 1.12 werden GMP-Komponenten im Namespace gmp-system und CRDs durch das Objekt stackdriver verwaltet, wobei das enableGMPForApplications-Flag 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

    Im Szenario system enthält der Cluster-Snapshot keine Ressourcen im 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:

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

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

    • Der Administratorcluster verwendet seit Version 1.12.x den vSphere CSI-Treiber auf vSAN
    • Es sind keine PVC-/PV-Objekte vorhanden, die von integrierten vSphere-Plug-ins im Administrator- und Nutzercluster erstellt wurden.

    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ängen bleibt, 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

    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. Dies 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
       Dabei ist ADMIN_CLUSTER_KUBECONFIG die kubeconfig-Datei des Administratorclusters. Ein Beispiel für mögliche Fehlermeldungen: 
      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:

    Prüfen Sie, ob die Clusterrolle und die Clusterrollenbindung im Administratorcluster fehlen 

    • kubectl get clusterrolebindings --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler
       
    • kubectl get clusterrole --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler

    Wenden Sie die folgende clusterrole und clusterrolebinding auf den Administratorcluster an, falls diese fehlen. Fügen Sie der Clusterrolebinding für jeden Nutzercluster die Dienstkontoinhaber hinzu.

    • apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-autoscaler
rules:
- apiGroups: ["cluster.k8s.io"]
  resources: ["clusters"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["cluster.k8s.io"]
  resources: ["machinesets","machinedeployments", "machinedeployments/scale","machines"]
  verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups: ["onprem.cluster.gke.io"]
  resources: ["onpremuserclusters"]
  verbs: ["get", "list", "watch"]
- apiGroups:
  - coordination.k8s.io
  resources:
  - leases
  resourceNames: ["cluster-autoscaler"]
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
- apiGroups:
  - ""
  resources:
  - nodes
  verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups:
  - ""
  resources:
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups:
  - ""
  resources:
  - pods/eviction
  verbs: ["create"]
# read-only access to cluster state
- apiGroups: [""]
  resources: ["services", "replicationcontrollers", "persistentvolumes", "persistentvolumeclaims"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["daemonsets", "replicasets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["statefulsets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
  resources: ["jobs"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["policy"]
  resources: ["poddisruptionbudgets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses", "csinodes"]
  verbs: ["get", "list", "watch"]
# misc access
- apiGroups: [""]
  resources: ["events"]
  verbs: ["create", "update", "patch"]
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["create"]
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["cluster-autoscaler-status"]
  verbs: ["get", "update", "patch", "delete"]
       
    • apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: cluster-autoscaler
  name: cluster-autoscaler
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-autoscaler
subjects:
  - kind: ServiceAccount
  name: cluster-autoscaler
  namespace:  NAMESPACE_OF_USER_CLUSTER_1 
  - kind: ServiceAccount
  name: cluster-autoscaler
  namespace:  NAMESPACE_OF_USER_CLUSTER_2 
  ...
    Konfiguration 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    Beim Löschen eines Nutzerclusters wird auch das entsprechende clusterrole gelöscht. Das 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
       Dabei ist ADMIN_CLUSTER_KUBECONFIG die kubeconfig-Datei des Administratorclusters. Ein Beispiel für mögliche Fehlermeldungen: 
      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
       Dabei ist ADMIN_CLUSTER_KUBECONFIG die kubeconfig-Datei des Administratorclusters. Ein Beispiel für mögliche Fehlermeldungen: 
      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:

    Wenden Sie die folgende YAML-Datei auf den Administratorcluster an

    • Für vsphere-metrics-exporter
      • kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: vsphere-metrics-exporter
rules:
  - apiGroups:
      - cluster.k8s.io
    resources:
      - clusters
    verbs: [get, list, watch]
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs: [get, list, watch]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: vsphere-metrics-exporter
  name: vsphere-metrics-exporter
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: vsphere-metrics-exporter
subjects:
  - kind: ServiceAccount
    name: vsphere-metrics-exporter
    namespace: kube-system
    • Für cluster-health-controller
      • apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-health-controller-role
rules:
- apiGroups:
  - "*"
  resources:
  - "*"
  verbs:
  - "*"
    Konfiguration 1.12.1-1.12.3, 1.13.0-1.13.2

    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 der Ausführung von 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, Updates 1.11, 1.12, 1.13

    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:

    Damit das Update wirksam wird, müssen die Maschinen nach dem fehlgeschlagenen Update neu erstellt after werden.

    Zum Aktualisieren des Administratorclusters müssen Nutzermaster- und Administrator-Add-on-Knoten neu erstellt werden

    Für die Aktualisierung des Nutzerclusters müssen die Nutzer-Worker-Knoten neu erstellt werden.

    So erstellen Sie Nutzer-Worker-Knoten neu

    Option 1
    Führen Sie die Schritte zum Aktualisieren eines Knotenpools aus und ändern Sie die CPU oder den Arbeitsspeicher, um eine rollierende Neuerstellung der Knoten auszulösen.

    Option 2
    Verwenden Sie „kubectl delete“, um die Maschinen einzeln neu zu erstellen

    kubectl delete machines MACHINE_NAME --kubeconfig USER_KUBECONFIG

    Masterknoten des Nutzers neu erstellen

    Option 1
    Folgen Sie der Anleitung zum Anpassen der Größe der Steuerungsebene und ändern Sie die CPU oder den Arbeitsspeicher, um eine rollierende Neuerstellung der Knoten auszulösen.

    Option 2
    Verwenden Sie „kubectl delete“, um die Maschinen einzeln neu zu erstellen

    kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG

    So erstellen Sie Administrator-Add-on-Knoten neu

    Verwenden Sie "kubectl delete", um die Maschinen einzeln neu zu erstellen

    kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG
    Installation, Upgrades, Updates 1.13.0-1.13.8, 1.14.0-1.14.4, 1.15.0

    Die Knotenregistrierung schlägt bei der Cluster-Erstellung, dem Upgrade, der Aktualisierung und der automatischen Knotenreparatur fehl, wenn ipMode.type gleich static ist und der konfigurierte Hostname in der IP-Blockdatei einen oder mehrere Punkte enthält. In diesem Fall werden die Certificate Signing Requests (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 clusterapi-controller-manager-Container im clusterapi-controllers-Pod an:
      kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n kube-system \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    • Führen Sie folgenden Befehl aus, um dieselben Logs im Nutzercluster anzusehen:
      kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
       wobei:
      • ADMIN_CLUSTER_KUBECONFIG ist die kubeconfig-Datei des Administratorclusters.
      • USER_CLUSTER_NAME ist der Name des Nutzerclusters.
      Ein Beispiel für mögliche Fehlermeldungen: "msg"="failed to validate token id" "error"="failed to find machine for node node-worker-vm-1" "validate"="csr-5jpx9"
    • Rufen Sie die kubelet-Logs auf dem problematischen Knoten auf: 
      journalctl --u kubelet
       Ein Beispiel für mögliche Fehlermeldungen: "Error getting node" err="node \"node-worker-vm-1\" not found"

    Wenn Sie einen Domain-Namen im Feld Hostname einer IP-Adresse angeben, werden alle Zeichen nach dem ersten Punkt ignoriert. Wenn Sie beispielsweise als Hostname bob-vm-1.bank.plc angeben, werden der VM-Hostname und der Name des Knotens auf bob-vm-1 gesetzt.

    Wenn die Knoten-ID-Überprüfung aktiviert ist, vergleicht der CSR-Genehmiger den Knotenname mit dem Hostnamen in der Maschinenspezifikation. Der Abgleich mit dem Namen schlägt fehl. Der Genehmiger lehnt den CSR ab, und für den Knoten wird kein Bootstrap durchgeführt.


    Workaround:

    Nutzercluster

    So deaktivieren Sie die Knoten-ID-Überprüfung:

    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: Pfad Ihrer Nutzercluster-Konfigurationsdatei.

    Administratorcluster

    1. Öffnen Sie die benutzerdefinierte Ressource OnPremAdminCluster für die Bearbeitung:
      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 die Manifestdatei 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 dargestellt: 
        --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
    Networking 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    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 einer fehlenden Redundanz für Hochverfügbarkeit führen.

    Die Dataplane-Aktivität ist ansonsten nicht betroffen.

    Ein Konflikt auf dem networkgatewaygroup-Objekt führt dazu, dass einige Statusaktualisierungen aufgrund eines Fehlers bei der Bearbeitung von Wiederholungsversuchen fehlschlagen. Wenn zu viele Statusaktualisierungen fehlschlagen, sieht ang-controller-manager den Knoten als über sein Heartbeat-Zeitlimit hinaus und markiert den Knoten als NotHealthy.

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


    Workaround:

    Führen Sie gegebenenfalls ein Upgrade auf eine korrigierte Version durch.
    Upgrades, Updates 1.12.0-1.12.2, 1.13.0

    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 Finalizer nicht aus dem Maschinenobjekt entfernt werden kann. Dies wirkt sich auf alle Rolling Update-Vorgänge für Knotenpools aus.

    Das Symptom besteht darin, dass der Befehl gkectl eine Zeitüberschreitung mit folgender Fehlermeldung erfährt:

    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 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 wiederholt sich auf demselben Rechner mehrere Minuten lang bei erfolgreichen Ausführungen auch ohne dieses Problem. In den meisten Fällen kann er schnell behoben werden, aber in einigen seltenen Fällen kann er mehrere Stunden lang in dieser Race-Bedingung hängen bleiben.

    Das Problem besteht darin, dass die zugrunde liegende VM bereits in vCenter gelöscht wurde, das entsprechende Maschinenobjekt jedoch nicht entfernt werden kann. Es bleibt aufgrund sehr häufiger Updates von anderen Controllern beim Entfernen des Finalizers hängen. Dies kann dazu führen, dass beim Befehl gkectl eine Zeitüberschreitung auftritt, aber der Controller ständig den Cluster abgleicht, sodass der Upgrade- oder Aktualisierungsprozess abgeschlossen wird.


    Workaround:

    Wir haben verschiedene Optionen zur Schadensbegrenzung für dieses Problem vorbereitet, die von Ihrer Umgebung und Ihren Anforderungen abhängen.

    • Option 1: Warten, bis das Upgrade abgeschlossen ist

      Auf der Grundlage der Analyse und der Reproduktion in Ihrer Umgebung kann das Upgrade schließlich von selbst abgeschlossen werden, ohne dass ein manuelles Eingreifen erforderlich ist. Der Nachteil dieser Option ist, dass es nicht sicher ist, wie lange es dauert, bis die Entfernung des Finalizers für jedes Maschinenobjekt abgeschlossen ist. Mit etwas Glück läuft der Vorgang sofort ab. Er kann aber auch mehrere Stunden dauern, wenn die Abstimmung des Maschinensatz-Controllers zu schnell erfolgt und der Maschinensatz-Controller keine Gelegenheit hat, den Finalizer zwischen den Abstimmungen zu entfernen.

      Das Gute ist, dass Sie bei dieser Option nichts weiter tun müssen und die Arbeitslasten nicht unterbrochen werden. Es dauert nur etwas länger bis das Upgrade abgeschlossen ist.
    • Option 2: Automatische Reparatur-Annotation auf alle alten Maschinenobjekte anwenden.

      Der Maschinensatz-Controller filtert die Maschinen heraus, bei denen die Annotierung für die automatische Reparatur und der Zeitstempel für das Löschen ungleich Null sind, und führt für diese Maschinen keine Löschaufrufe mehr durch. Dadurch kann die Race-Bedingung vermieden werden.

      Der Nachteil ist, dass die Pods auf den Rechnern direkt gelöscht statt entfernt werden. Das bedeutet, dass die PDB-Konfiguration nicht beachtet wird, was zu Ausfallzeiten bei Ihren Arbeitslasten führen kann.

      Der Befehl zum Abrufen aller Maschinennamen: 
      kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
       Der Befehl zum Anwenden der Annotation zur automatischen Reparatur 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 auch nach längerer Zeit nicht abgeschlossen werden kann, wenden Sie sich an unser Supportteam.
    Installation, Upgrades, Updates 1.10.2, 1.11, 1.12, 1.13

    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 inkorrekte Validierung.


    Workaround:

    Führen Sie denselben Befehl mit einem zusätzlichen Flag --skip-validation-os-images aus.
    Installation 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    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 Secret-Schlüssels verwendet, der "/" oder ":" nicht unterstützt.


    Workaround:

    Entfernen Sie das Präfix https:// oder http:// aus dem Feld vCenter.Address im Administratorcluster oder der Datei „config yaml“ des Nutzerclusters.
    Installation, Upgrades, Updates 1.10, 1.11, 1.12, 1.13

    gkectl prepare kann mit dem folgenden Stacktrace zu „Panic“ führen:

    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 einer falschen Berechtigung erstellt hat.


    Workaround:

    Führen Sie die folgenden Befehle auf der Administratorworkstation 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, Updates 1.10, 1.11, 1.12, 1.13

    Führen Sie nach einem fehlgeschlagenen Upgrade des Administratorclusters nicht gkectl repair admin-master aus. Dies kann dazu führen, dass nachfolgende Upgrade-Versuche des Administrators fehlschlagen, z. B. weil der Administrator-Master nicht eingeschaltet werden kann oder die VM nicht erreichbar ist.


    Workaround:

    Wenn dieses Fehlerszenario bereits aufgetreten ist, wenden Sie sich an den Support.
    Betriebssystem 1.12, 1.13

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


    Workaround:

    Wir sind in Version 1.12.1 zurück zu cgroup v1 (Hybrid) gewechselt. Wenn Sie COS-Knoten verwenden, empfehlen wir Ihnen ein Upgrade auf Version 1.12.1, sobald diese veröffentlicht wird.
    Identität 1.10, 1.11, 1.12, 1.13

    gkectl update setzt alle manuellen Änderungen, die Sie an der benutzerdefinierten ClientConfig-Ressource vorgenommen haben, wieder zurück.


    Workaround:

    Es wird dringend empfohlen, die ClientConfig-Ressource nach jeder manuellen Änderung zu sichern.
    Installation 1.10, 1.11, 1.12, 1.13

    Die Validierung schlägt fehl, weil 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

    Möglicherweise tritt ein Installationsfehler aufgrund von cert-manager-cainjector in Absturzschleife auf, wenn der API-Server/etcd langsam ist:

    # 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:

    Führen Sie die folgenden Befehle aus, um das Problem zu beheben.

    Skalieren Sie zuerst monitoring-operator herunter, damit die Änderungen am cert-manager-Deployment nicht rückgängig gemacht werden:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
    scale deployment monitoring-operator --replicas=0

    Bearbeiten Sie als Nächstes das cert-manager-cainjector-Deployment, um die Leader-Auswahl zu deaktivieren, da nur ein Replikat ausgeführt wird. Es ist für ein einzelnes Replikat nicht erforderlich:

    # Add a command line flag for cainjector: `--leader-elect=false`
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit \
    -n kube-system deployment cert-manager-cainjector

    Das entsprechende YAML-Snippet für die cert-manager-cainjector-Bereitstellung sollte wie das folgende Beispiel aussehen:

    ...
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cert-manager-cainjector
  namespace: kube-system
...
spec:
  ...
  template:
    ...
    spec:
      ...
      containers:
      - name: cert-manager
        image: "gcr.io/gke-on-prem-staging/cert-manager-cainjector:v1.0.3-gke.0"
        args:
        ...
        - --leader-elect=false
...

    Behalten Sie monitoring-operator-Replikate bei 0 als Minderung bei, bis die Installation abgeschlossen ist. Andernfalls wird die Änderung rückgängig gemacht.

    Nachdem die Installation abgeschlossen ist und der Cluster ausgeführt wird, aktivieren Sie monitoring-operator für Tag-2-Vorgänge:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
    scale deployment monitoring-operator --replicas=1

    Nach jedem Upgrade werden die Änderungen rückgängig gemacht. Wiederholen Sie diese Schritte, um das Problem zu minimieren, bis es in einer zukünftigen Version behoben wird.
    VMware 1.10, 1.11, 1.12, 1.13

    Wenn das vCenter für Versionen unter 7.0U2 nach einem Upgrade oder anderweitig neu gestartet wird, ist der Netzwerkname in VM-Informationen von vCenter falsch und führt dazu, dass sich die Maschine im Zustand Unavailable befindet. Dies führt dazu, dass die Knoten automatisch repariert werden, um neue Knoten 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 > Verbindung trennen. Stellen Sie die Verbindung wieder her. Dadurch wird ein Update der Portgruppe der VM erzwungen.
    Betriebssystem 1.10, 1.11, 1.12, 1.13

    Für Google Distributed Cloud Version 1.7.2 und höher sind die Ubuntu OS Images mit CIS L1 Server Benchmark gehärtet.

    Um die CIS-Regel "5.2.16 Sicherstellen, dass das SSH-Zeitlimit für Inaktivität konfiguriert ist" zu erfüllen, hat /etc/ssh/sshd_config die folgenden Einstellungen:

    ClientAliveInterval 300
ClientAliveCountMax 0

    Bei diesen Einstellungen wird eine Clientsitzung nach 5 Minuten Inaktivität beendet. 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. wenn ein zeitaufwendiger Befehl ausgeführt wird. Ihr Befehl wird dann möglicherweise mit der folgenden Nachricht beendet:

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

    Workaround:

    Sie haben folgende Möglichkeiten:

    • Verwenden Sie nohup, um zu verhindern, dass Ihr Befehl beim Trennen der SSH-Verbindung 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 die Verwendung eines Werts unter 3: 
      sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' \
    /etc/ssh/sshd_config
sudo systemctl restart sshd

    Denken Sie daran, die SSH-Sitzung neu zu verbinden.
    Installation 1.10, 1.11, 1.12, 1.13

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

    Hinweis: Sie müssen diese Aufgabe nur einmal für jeden Cluster anwenden und die Änderungen bleiben beim Clusterupgrade erhalten.

    Hinweis: Ein häufiges Symptom bei der Installation eines eigenen cert-managers ist, dass die cert-manager-Version oder das Image (z. B. Version 1.7.2) auf die ältere Version zurückgesetzt wird. Dies wird dadurch verursacht, dass monitoring-operator versucht, cert-manager abzugleichen und dabei die Version zurücksetzt.

    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
    • Installieren Sie Ihre Version von cert-manager neu. Stellen Sie Ihre benutzerdefinierten Ressourcen wieder her, falls vorhanden.
    • Sie können diesen Schritt überspringen, wenn Sie die vorgelagerte Standardinstallation von cert-manager verwenden oder sicher sind, dass Ihr cert-manager im Namespace cert-manager installiert ist. Kopieren Sie andernfalls das cert-manager.io/v1-Zertifikat metrics-ca und die metrics-pki.cluster.local-Issuer-Ressourcen von cert-manager in den Clusterressourcen-Namespace des 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 auf der Steuerungsebene von Google Distributed Cloud 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. Wenn Sie Apigee-Kunde sind und cert-manager nur 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
    • Installieren Sie Ihre Version von cert-manager neu. Stellen Sie Ihre benutzerdefinierten Ressourcen wieder her, falls vorhanden.
    • Sie können diesen Schritt überspringen, wenn Sie die vorgelagerte Standardinstallation von cert-manager verwenden oder sicher sind, dass Ihr cert-manager im Namespace cert-manager installiert ist. Kopieren Sie andernfalls das cert-manager.io/v1-Zertifikat metrics-ca und die metrics-pki.cluster.local-Issuer-Ressourcen von cert-manager in den Clusterressourcen-Namespace des 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

    Docker, containerd und runc in den Ubuntu Betriebssystem-Images, die mit Google Distributed Cloud ausgeliefert werden, werden mithilfe des Ubuntu PPA an spezielle Versionen gepinnt. Dadurch wird sichergestellt, dass alle Änderungen an der Container-Laufzeit vor jeder Veröffentlichung von Google Distributed Cloud qualifiziert werden.

    Die speziellen Versionen sind jedoch im Ubuntu CVE-Tracker unbekannt. Er wird von den CVE-Scantools als Feeds für Sicherheitslücken verwendet. Daher werden falsch positive Ergebnisse beim Scannen auf Sicherheitslücken in Docker, Containerd und Runc angezeigt.

    Zum Beispiel können die folgenden falsch positiven Ergebnisse aus den CVE-Scanergebnissen angezeigt werden. Diese CVEs wurden im neuesten Patch von Google Distributed Cloud bereits behoben.

    Informationen zu CVE-Korrekturen finden Sie in den Versionshinweisen.


    Workaround:

    Das Problem ist Canonical bekannt und der Fehler wird unter https://github.com/canonical/sec-cvescan/issues/73 verfolgt.
    Upgrades, Updates 1.10, 1.11, 1.12, 1.13

    Wenn Sie ein Upgrade von Clustern ohne Hochverfügbarkeit von Version 1.9 auf 1.10 durchführen, werden Sie möglicherweise feststellen, dass kubectl exec, kubectl log und Webhook für Nutzercluster für eine kurze Zeit 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. Der Nutzer „kube-apiserver” ist ein Statefulset. In einem Nicht-HA-Cluster 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, zu HA-Clustern zu wechseln.
    Installation, Upgrades, Updates 1.10, 1.11, 1.12, 1.13

    Wenn Sie einen HA-Cluster erstellen oder aktualisieren und die Prüfung der Konnektivitätsbereitschaft bei der Clusterdiagnose fehlschlägt, wirkt sich dies in den meisten Fällen nicht auf die Funktionalität von Google Distributed Cloud (kubectl exec, kubectl log und Webhook) aus. Der Grund dafür ist, dass manchmal eine oder zwei der Konnektivitätsreplikate aufgrund eines instabilen Netzwerks oder anderer Probleme eine Zeit lang nicht einsatzbereit sind.


    Workaround:

    Die Konnektivität wird alleine wiederhergestellt. Warten Sie 30 Minuten bis eine Stunde und führen Sie die Clusterdiagnose noch einmal aus.
    Netzwerk 1.10, 1.11, 1.12, 1.13

    Wenn bei der Bereitstellung von Google Distributed Cloud Version 1.9 oder höher der gebündelte Seesaw-Load-Balancer der Bereitstellung in einer Umgebung mit zustandsorientierten verteilten NSX-T-Firewallregeln vorhanden ist, erstellt stackdriver-operator möglicherweise keine gke-metrics-agent-conf-ConfigMap und verursacht, dass gke-connect-agent-Pods in einer Absturzschleife landen.

    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 NSX-T-verteilten Firewallregeln wirken sich auf alle Google Distributed Cloud-Releases aus, die Seesaw verwenden. Möglicherweise treten bei Ihren eigenen Anwendungen ähnliche Verbindungsprobleme auf, wenn sie große Kubernetes-Objekte erstellen, deren Größe größer als 32 KB ist.


    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 Backend-Knotenfehler auftritt. Ohne diese Konfiguration reagieren Clients des Kubernetes API-Servers möglicherweise mehrere Minuten lang nicht, wenn eine Serverinstanz ausfällt.
    Logging und Monitoring 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    Bei den Google Distributed Cloud-Versionen 1.10 bis 1.15 haben einige Kunden auf der Seite Abrechnung eine unerwartet hohe Abrechnung für Metrics volume festgestellt. Dieses Problem betrifft Sie nur, wenn die beiden folgenden Umstände zutreffen:

    • Logging und Monitoring für Anwendungen ist aktiviert (enableStackdriverForApplications=true)
    • Anwendungs-Pods haben die Annotation prometheus.io/scrap=true. (Die Installation von Cloud Service Mesh kann auch diese Annotation hinzufügen.)

    Um festzustellen, 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 auch enableStackdriverForApplications in der Antwort von kubectl -n kube-system get stackdriver stackdriver -o yaml auf „true“ gesetzt ist, trifft dieses Problem auf Sie zu.


    Problemumgehung

    Wenn Sie von diesem Problem betroffen sind, empfehlen wir Ihnen, ein Upgrade Ihrer Cluster auf Version 1.12 oder höher durchzuführen, das enableStackdriverForApplications-Flag nicht mehr zu verwenden und zu einer neuen Lösung für das Anwendungsmonitoring managed-service-for-prometheus zu wechseln, die nicht mehr auf die prometheus.io/scrap=true-Annotation angewiesen 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 Sie und schließen Sie den Editor.

    Wenn Sie die annotationsbasierte Messwerterfassung nicht deaktivieren können, gehen Sie so vor:

    1. Suchen Sie die Quell-Pods und -Dienste mit den unerwünschten 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 Cloud Service Mesh hinzugefügt wird, prüfen Sie die Optionen, Cloud Service Mesh ohne Prometheus zu konfigurieren oder das Zusammenführen von Messwerten von Istio zu deaktivieren.
    Installation 1.11, 1.12, 1.13

    Das Google Distributed Cloud-Installationsprogramm kann fehlschlagen, wenn benutzerdefinierte Rollen auf der falschen 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. Um das Problem zu beheben, sollten Sie die benutzerdefinierte Rolle auf vSphere Vcenter-Ebene (Root) binden.


    Workaround:

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

    Weitere Informationen zum Erstellen von Rollen finden Sie unter vCenter-Nutzerkontenberechtigungen.
    Logging und Monitoring 1.11, 1.12, 1.13

    Wenn in Ihren OOTB-Dashboards eingestellte Messwerte verwendet werden, sehen Sie ein paar leere Diagramme. Um die veralteten Messwerte in den Monitoring-Dashboards zu finden, führen Sie die folgenden Befehle aus:

    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 verworfenen Messwerte sollten zu ihren Ersatzwerten migriert werden.

    VerworfenErsatz
    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:

    So ersetzen Sie die verworfenen Messwerte

    1. Löschen Sie den „GKE On-Prem-Knotenstatus” im Google Cloud Monitoring-Dashboard. Installieren Sie den „GKE On-Prem-Knotenstatus” neu. Folgen Sie dazu dieser Anleitung.
    2. Löschen Sie die GKE On-Prem-Knotenauslastung im Google Cloud Monitoring-Dashboard. Installieren Sie „GKE On-Prem-Knotenauslastung” neu. Folgen Sie dazu dieser Anleitung.
    3. Löschen Sie "GKE on-prem vSphere vm health" im Google Cloud Monitoring-Dashboard. Um „GKE on-prem vSphere vm health“ neu zu installieren, folgen Sie dieser Anleitung.

      4. Diese Abschaltung ist auf das Upgrade des kube-state-metrics-Agents von v1.9 auf v2.4 zurückzuführen, das für Kubernetes 1.22 erforderlich ist. Sie können alle eingestellten kube-state-metrics-Messwerte mit dem Präfix kube_ in Ihren benutzerdefinierten Dashboards oder Benachrichtigungsrichtlinien ersetzen.
    Logging und Monitoring 1.10, 1.11, 1.12, 1.13

    Ab Google Distributed Cloud Version 1.10 können die Daten für Cluster in Cloud Monitoring irrelevante zusammenfassende Messwerte-Einträge wie die folgenden enthalten:

    Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    Weitere Messwerttypen mit irrelevanten Zusammenfassungsmesswerten sind:

    :
    • 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 Messwerte des Zusammenfassungstyps sind zwar in der Messwertliste enthalten, werden jedoch derzeit nicht von gke-metrics-agent unterstützt.
    Logging und Monitoring 1.10, 1.11, 1.12, 1.13

    Möglicherweise stellen Sie fest, dass die folgenden Messwerte auf einigen, aber nicht auf allen Knoten fehlen:

    • 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:

    Führen Sie zur Behebung dieses Problems die folgenden Schritte aus: [Version 1.9.5 und höher, 1.10.2 und höher, 1.11.0]: Erhöhen Sie die CPU für gke-metrics-agent mit den Schritten 1 bis 4.

    1. Öffnen Sie die Ressource stackdriver zum Bearbeiten: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Fügen Sie dem Manifest stackdriver den folgenden Abschnitt resourceAttrOverride hinzu, um die CPU-Anfrage für gke-metrics-agent von 10m auf 50m und das CPU-Limit von 100m auf 200m zu erhöhen: 
      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. Führen Sie den folgenden Befehl aus, um zu prüfen, ob Ihre Änderungen wirksam geworden sind:
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset gke-metrics-agent -o yaml \
    | grep "cpu: 50m"
       Der Befehl sucht cpu: 50m, wenn Ihre Änderungen wirksam geworden sind.
    Logging und Monitoring 1.11.0-1.11.2, 1.12.0

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

    # 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 oder v1.13 oder höher durch.
    1.11.0-1.11.2, 1.12.0

    Wenn Ihr Nutzercluster von diesem Problem betroffen ist, fehlen Planer- und Controller-Manager-Messwerte. Diese beiden Messwerte fehlen:

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

    Workaround:

    Dieses Problem wurde in Google Distributed Cloud Version 1.13.0 und höher behoben. Aktualisieren Sie Ihren Cluster auf eine Version mit der Fehlerkorrektur.
    Installation, Upgrades, Updates 1.10, 1.11, 1.12, 1.13

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

    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:

    Wenn dieser Fehler auftritt, gehen Sie folgendermaßen vor, um das Problem mit der Clusterregistrierung zu beheben. Nachdem Sie dieses Problem behoben haben, können Sie ein Upgrade des Administratorclusters ausführen.

    1. Führen Sie gkectl update admin aus, um den Administratorcluster mit dem richtigen Dienstkontoschlüssel zu registrieren.
    2. Erstellen Sie ein dediziertes Dienstkonto zum Patchen der benutzerdefinierten Ressource OnPremAdminCluster. 
      export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG

# Create Service Account modify-admin
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: modify-admin
  namespace: kube-system
EOF

# Create ClusterRole
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: null
  name: modify-admin-role
rules:
- apiGroups:
  - "onprem.cluster.gke.io"
  resources:
  - "onpremadminclusters/status"
  verbs:
  - "patch"
EOF

# Create ClusterRoleBinding for binding the permissions to the modify-admin SA

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: null
  name: modify-admin-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: modify-admin-role
subjects:
- kind: ServiceAccount
  name: modify-admin
  namespace: kube-system
EOF
       Ersetzen Sie ADMIN_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Administratorclusters.
    3. Führen Sie diese Befehle aus, um die benutzerdefinierte Ressource OnPremAdminCluster zu aktualisieren. 
      export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG

SERVICE_ACCOUNT=modify-admin

SECRET=$(kubectl get serviceaccount ${SERVICE_ACCOUNT} \
    -n kube-system -o json \
    | jq -Mr '.secrets[].name | select(contains("token"))')

TOKEN=$(kubectl get secret ${SECRET} -n kube-system -o json \
    | jq -Mr '.data.token' | base64 -d)

kubectl get secret ${SECRET} -n kube-system -o json \
    | jq -Mr '.data["ca.crt"]' \
    | base64 -d > /tmp/ca.crt

APISERVER=https://$(kubectl -n default get endpoints kubernetes \
    --no-headers | awk '{ print $2 }')

# Find out the admin cluster name and gkeOnPremVersion from the OnPremAdminCluster CR
ADMIN_CLUSTER_NAME=$(kubectl get onpremadmincluster -n kube-system \
    --no-headers | awk '{ print $1 }')
GKE_ON_PREM_VERSION=$(kubectl get onpremadmincluster \
    -n kube-system $ADMIN_CLUSTER_NAME \
    -o=jsonpath='{.spec.gkeOnPremVersion}')

# Create the Status field and set the gkeOnPremVersion in OnPremAdminCluster CR
curl -H "Accept: application/json" \
    --header "Authorization: Bearer $TOKEN" -XPATCH \
    -H "Content-Type: application/merge-patch+json" \
    --cacert /tmp/ca.crt \
    --data '{"status": {"gkeOnPremVersion": "'$GKE_ON_PREM_VERSION'"}}' \
    $APISERVER/apis/onprem.cluster.gke.io/v1alpha1/namespaces/kube-system/onpremadminclusters/$ADMIN_CLUSTER_NAME/status
    4. Versuchen Sie noch einmal, den Administratorcluster mit dem Flag --disable-upgrade-from-checkpoint zu aktualisieren. 
      gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --disable-upgrade-from-checkpoint
       Ersetzen Sie ADMIN_CLUSTER_CONFIG durch den Pfad Ihrer Konfigurationsdatei für den Administratorcluster.
    Identität 1.10, 1.11, 1.12, 1.13

    Wenn Sie den GKE Identity-Dienst zur Verwaltung GKE Identity Service ClientConfig nutzen, wird der Connect Agent möglicherweise unerwartet neu gestartet.


    Workaround:

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

    • Deaktivieren Sie den GKE Identity Service. Wenn Sie den GKE Identity Service deaktivieren, wird die bereitgestellte GKE Identity Service-Binärdatei oder die GKE Identity Service-ClientConfig nicht entfernt. Führen Sie diesen 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 die Connect Agent-Version zu aktualisieren.
    Netzwerk 1.10, 1.11, 1.12, 1.13

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


    Workaround:

    Eine mögliche Problemumgehung besteht in der Deaktivierung des IP-Lernens. Fügen Sie dazu die Seesaw-IP-Adresse als virtuelle L4-L7-IP-Adresse zum Cisco Application Policy Infrastructure Controller (APIC) hinzu.

    Sie können die virtuelle IP-Adresse für L4-L7 unter Mandant > Anwendungsprofile > Anwendungs-EPGs oder uSeg-EPGs konfigurieren. Wird das IP-Lernen nicht deaktiviert, führt dies zu Flapping von IP-Endpunkten zwischen verschiedenen Standorten in der Cisco API-Fabric.
    VMware 1.10, 1.11, 1.12, 1.13

    VMWare hat vor Kurzem kritische Probleme in den folgenden vSphere 7.0 Update 3-Releases 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 ESXi und vCenter Server auf eine neuere Version aktualisieren.
    Betriebssystem 1.10, 1.11, 1.12, 1.13

    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. Es wird bereitgestellt als noexec und Sie erhalten die folgende Fehlermeldung: exec user process caused: permission denied. Sie sehen z. B. Folgendes: Fehlermeldung beim Bereitstellen des folgenden Test-Pods:

    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 als Option "noexec" angezeigt:

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

    Workaround:

    Wenden Sie eine DaemonSet-Ressource an. Beispiel:

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fix-cos-noexec
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fix-cos-noexec
  template:
    metadata:
      labels:
        app: fix-cos-noexec
    spec:
      hostIPC: true
      hostPID: true
      containers:
      - name: fix-cos-noexec
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          set -ex
          while true; do
            if ! $(nsenter -a -t 1 findmnt -l | grep -qe "^/var/lib/kubelet\s"); then
              echo "remounting /var/lib/kubelet with exec"
              nsenter -a -t 1 mount --bind /var/lib/kubelet /var/lib/kubelet
              nsenter -a -t 1 mount -o remount,exec /var/lib/kubelet
            fi
            sleep 3600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /
    Upgrades, Updates 1.10, 1.11, 1.12, 1.13

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


    Workaround:

    So entfernen Sie 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 aus der Maschinenbereitstellung des entsprechenden Knotenpools.
    Logging und Monitoring 1.11, 1.12, 1.13

    Ab Version 1.11 zeigen das Windows-Dashboard für den Pod-Status und das Windows-Dashboard für den Knoten-Status in den Standard-Dashboards auch Daten von Linux-Clustern an. Das liegt daran, dass die Windows-Knoten- und Pod-Messwerte auch in Linux-Clustern verfügbar sind.
    Logging und Monitoring 1.10, 1.11, 1.12

    Bei Google Distributed Cloud Version 1.10, 1.11 und 1.12 kann es beim stackdriver-log-forwarder-DaemonSet zu CrashLoopBackOff-Fehlern kommen, wenn auf dem Laufwerk defekte Logs im Zwischenspeicher vorhanden sind.


    Workaround:

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

    1. Skalieren Sie stackdriver-log-forwarder herunter, um das unerwartete Verhalten zu verhindern: 
      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. Mit den folgenden Befehlen können Sie prüfen, ob das Bereinigungs-DaemonSet alle Blöcke bereinigt hat. Die Ausgabe der beiden Befehle sollte Ihrer Knotennummer 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. Setzen Sie stackdriver-log-forwarder fort:
      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

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

    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 Logeingangsrate den Grenzwert des Logging-Agents, wodurch stackdriver-log-forwarder keine Logs sendet. Dieses Problem tritt in allen Google Distributed Cloud-Versionen auf.

    Behelfslösung:

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

    1. Öffnen Sie die Ressource stackdriver 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 stackdriver-Manifest den folgenden resourceAttrOverride-Abschnitt hinzu: 
      spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
       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:
    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. Führen Sie den folgenden Befehl aus, um zu prüfen, ob Ihre Änderungen wirksam geworden sind:
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
    | grep "cpu: 1200m"
       Der Befehl sucht cpu: 1200m, wenn Ihre Änderungen wirksam geworden sind.
    Sicherheit 1.13

    Es gibt einen kurzen Zeitraum, in dem der Knoten bereit ist, aber das Kubelet-Server-Zertifikat noch nicht vorliegt. kubectl exec und kubectl logs sind in dieser Zeit nicht verfügbar. Dies 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 hat keine Auswirkungen auf die Pod-Planung.
    Upgrades, Updates 1.12

    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.

    Der Administratorcluster wurde nicht vollständig aktualisiert und die Statusversion ist immer noch 1.10. Das Upgrade des Nutzerclusters auf 1.12 wird nicht durch eine Preflight-Prüfung blockiert und schlägt mit einer Versionsabweichung fehl.


    Workaround:

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

    Der Befehl gkectl diagnose cluster ist fehlgeschlagen: 

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

    Die Validierung des freien Speicherplatzes im Datenspeicher sollte nicht für vorhandene Clusterknotenpools verwendet werden und wurde gkectl diagnose cluster irrtümlicherweise hinzugefügt.


    Workaround:

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

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

    Der Vorgang zum Löschen des Nutzerclusters kann aus irgendeinem Grund hängen bleiben, was zu einer Entwertung der MatalLB-ConfigMap führt. Es ist nicht möglich, einen neuen Nutzercluster mit diesem Status hinzuzufügen.


    Workaround:

    Sie können das Löschen des Nutzerclusters erzwingen.
    Installation, Betriebssystem 1.10, 1.11, 1.12, 1.13

    Wenn osImageType für den Administratorcluster cos verwendet und gkectl check-config nach der Erstellung des Administratorclusters und vor der Erstellung des Nutzerclusters ausgeführt wird, kommt es zu einem Fehler:

    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 den gleichen osImageType wie der Administratorcluster. Derzeit ist die Test-VM noch nicht mit COS kompatibel.


    Workaround:

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

    Dieses Problem betrifft Kunden, die Grafana im Administratorcluster verwenden, um Nutzercluster in den Google Distributed Cloud Versionen 1.12.0 und 1.12.1 zu überwachen. Die Ursache ist eine Diskrepanz zwischen den Zertifikaten des Pushprox-Clients in den Nutzerclustern und der Zulassungsliste des Pushprox-Servers im Administratorcluster. Das Symptom ist, dass pushprox-client in Nutzerclustern Fehlerlogs wie die folgenden ausgibt:

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

    Workaround:

    Führen Sie diese Schritte aus:

    1. Skalieren Sie die Bereitstellung von Monitoring-Operatoren im Administratorcluster-Namespace kube-system herunter.
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy monitoring-operator \
    --replicas=0
    2. Bearbeiten Sie die ConfigMap pushprox-server-rbac-proxy-config im Administratorcluster-Namespace kube-system.
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --namespace kube-system edit cm pushprox-server-rbac-proxy-config
       Suchen Sie die Zeile principals für den Listener external-pushprox-server-auth-proxy und korrigieren Sie den principal_name für alle Nutzercluster. Entfernen Sie dazu den Teilstring kube-system aus pushprox-client.metrics-consumers.kube-system.cluster.. Die neue Konfiguration sollte so aussehen:
      permissions:
- or_rules:
    rules:
    - header: { name: ":path", exact_match: "/poll" }
    - header: { name: ":path", exact_match: "/push" }
principals: [{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster.local"}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster."}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.cluster."}}}]
    3. Starten Sie die Bereitstellung von pushprox-server im Administratorcluster und die Bereitstellung von pushprox-client in den betroffenen Nutzerclustern neu:
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-server
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-client
    4. Das Problem sollte mit den vorherigen Schritten behoben sein. Sobald der Cluster auf 1.12.2 oder höher aktualisiert wurde und das Problem behoben ist, skalieren Sie den Administratorcluster-Monitoring-Operator „kube-system“, damit er die Pipeline wieder verwalten kann. 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system scale deploy monitoring-operator --replicas=1
    Logging und Monitoring 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

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

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

    Workaround:

    Zum Beheben dieses Problems kann die Berechtigung durch Interaktion mit der Hub-Funktion cloudauditlogging eingerichtet werden:

    1. Prüfen Sie zuerst die vorhandenen Dienstkonten, die für Cloud-Audit-Logs in Ihrem Projekt auf die Zulassungsliste gesetzt wurden: 
      curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging
    2. Führen Sie je nach Antwort einen der folgenden Schritte aus:
      • Wenn Sie den Fehler 404 Not_found erhalten, ist für diese Projekt-ID kein Dienstkonto zugelassen. Sie können ein Dienstkonto auf die Zulassungsliste setzen, indem Sie die Hub-Funktion cloudauditlogging aktivieren: 
        curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features?feature_id=cloudauditlogging -d \
    '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
      • Wenn Sie eine Featurespezifikation erhalten haben, die "lifecycleState": "ENABLED" mit "code": "OK" und eine Liste der Dienstkonten in allowlistedServiceAccounts enthält, sind vorhandene Dienstkonten für dieses Projekt zulässig. Sie können entweder ein Dienstkonto aus dieser Liste in Ihrem Cluster verwenden oder ein neues Dienstkonto zur Zulassungsliste hinzufügen: 
        curl -X PATCH -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging?update_mask=spec.cloudauditlogging.allowlistedServiceAccounts -d \
    '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
      • Wenn Sie eine Featurespezifikation erhalten, die "lifecycleState": "ENABLED" mit "code": "FAILED" enthält, ist die Berechtigungseinrichtung nicht erfolgreich. Versuchen Sie, die Probleme im Feld description der Antwort zu beheben, oder sichern Sie die aktuelle Zulassungsliste, löschen Sie die Hub-Funktion cloudauditlogging und aktivieren Sie sie noch einmal gemäß Schritt 1 dieses Abschnitts. Sie können die Hub-Funktion cloudauditlogging auf folgende Weise löschen: 
        curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging

    Für obige Befehle gilt:
    Betriebssystem 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    /var/log/audit/ wird mit Audit-Logs gefüllt. Sie können die Laufwerksnutzung durch Ausführen von 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 Google Distributed Cloud v1.8 ist das Ubuntu-Image mit der CIS-Level-2-Benchmark gehärtet. Und eine der Complianceregeln, „4.1.2.2 Sicherstellen, dass Audit-Logs nicht automatisch gelöscht werden“, sorgt für die Auditd-Einstellung max_log_file_action = keep_logs Dies führt dazu, dass alle Audit-Regeln auf dem Laufwerk gespeichert werden.


    Workaround:

    Administratorworkstation

    Für die Administratorworkstation können Sie die auditd-Einstellungen manuell ändern, um die Logs automatisch zu rotieren, und dann den auditd-Dienst neu starten:

    sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
systemctl restart auditd

    Die obige Einstellung würde auditd dazu veranlassen, seine Logs automatisch zu rotieren, sobald es mehr als 250 Dateien (jede mit 8M Größe) erzeugt hat.

    Cluster-Knoten

    Führen Sie für Clusterknoten ein Upgrade auf 1.11.5+, 1.12.4+, 1.13.2+ oder 1.14+ durch. Wenn Sie noch kein Upgrade auf diese Versionen durchführen können, wenden Sie das folgende DaemonSet auf Ihren Cluster an:

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: change-auditd-log-action
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: change-auditd-log-action
  template:
    metadata:
      labels:
        app: change-auditd-log-action
    spec:
      hostIPC: true
      hostPID: true
      containers:
      - name: update-audit-rule
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          while true; do
            if $(grep -q "max_log_file_action = keep_logs" /etc/audit/auditd.conf); then
              echo "updating auditd max_log_file_action to rotate with a max of 250 files"
              sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
              sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
              echo "restarting auditd"
              systemctl restart auditd
            else
              echo "auditd setting is expected, skip update"
            fi
            sleep 600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /

    Beachten Sie, dass diese Änderung der auditd-Konfiguration gegen die CIS Level 2 Regel „4.1.2.2 Sicherstellen, dass Audit Logs nicht automatisch gelöscht werden“ verstoßen würde.
    Netzwerk 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    Nutzer können keine NetworkGatewayGroup-Objekte erstellen oder aktualisieren, weil der folgende Webhook-Fehler bei der Validierung auftritt:

    [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 sie als Knotenadresse in node.status.addresses melden. Der validierende Webhook prüft NetworkGatewayGroup Floating-IP-Adressen für alle node.status.addresses im Cluster und betrachtet dies als Konflikt.


    Workaround:

    In demselben Cluster, in dem die Erstellung oder Aktualisierung von NetworkGatewayGroup-Objekten fehlschlägt, deaktivieren Sie vorübergehend den ANG-Validierungs-Webhook und senden 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 den Eintrag vnetworkgatewaygroup.kb.io aus der Liste der Webhook-Konfigurationen und schließen Sie sie, um die Änderungen anzuwenden.
    4. Erstellen oder bearbeiten Sie das NetworkGatewayGroup-Objekt.
    5. Wenden Sie wieder die ursprüngliche Webhook-Konfiguration an: 
      kubectl -n kube-system apply -f webhook-config.yaml
    Netzwerk Alle Versionen vor 1.14.7, 1.15.0-1.15.3, 1.16.0

    Der regelmäßig alle 20 Sekunden von Seesaw gesendete GARP (Gratuitous ARP) legt die Ziel-IP-Adresse im ARP-Header nicht fest. Einige Netzwerke akzeptieren solche Pakete möglicherweise nicht (z. B. Cisco ACI). Dies kann zu längeren Ausfallzeiten der Dienste führen, nachdem ein Split-Brain (aufgrund von VRRP-Paketverlusten) wiederhergestellt wurde.

    Workaround:

    Lösen Sie ein Seesaw-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

    „staticPodPath“ wurde fälschlicherweise für Worker-Knoten festgelegt

    Workaround:

    Erstellen Sie den Ordner „/etc/kubernetes/manifests“ manuell
    Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.