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-Nutzerrollen und ‑Aufgaben.

Wenn Sie am Google-Entwicklerprogramm teilnehmen, speichern Sie diese Seite, um Benachrichtigungen zu erhalten, wenn eine Versionsanmerkung zu dieser Seite veröffentlicht wird. Weitere Informationen finden Sie unter Gespeicherte Seiten.

Zum Filtern der bekannten Probleme nach einer Produktversion oder -kategorie wählen Sie in den folgenden Drop-down-Menüs die gewünschten Filter aus.

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

Wählen Sie die Problemkategorie aus:

Oder suchen Sie nach Ihrem Problem:

Kategorie Identifizierte Version(en) Problem und Problemumgehung
Updates 1.32.0-1.32.600, 1.33.0-1.33.100

Wenn Sie mit gkectl update einen Nutzercluster ohne Hochverfügbarkeit (nicht HA) auf einen erweiterten Cluster mit einer HA-Steuerungsebene aktualisieren, schlägt der Vorgang fehl und es wird die folgende Fehlermeldung angezeigt:

Failed to generate diff summary: failed to get desired onprem user cluster and node pools from seed config with dry-run webhooks:
failed to apply validating webhook to OnPremUserCluster:
masterNode.replcias: Forbidden: the field must not be mutated, diff (-before, +after): int64(- 1,+ 3)

Workaround:

Verwenden Sie den Befehl gkectl upgrade, um ein Upgrade des Non-HA-Nutzerclusters auf einen HA-Advanced-Cluster durchzuführen.
Updates 1.30, 1.31

Windows-Pods bleiben nach der Migration von ControlPlaneV2 aufgrund eines ungültigen TLS-Zertifikats im Status „Pending“ (Ausstehend)

Während eines Google Distributed Cloud-Updates, das eine ControlPlaneV2-Migration von Version 1.30.x zu 1.31.x umfasst, können Windows-Pods nicht geplant werden und bleiben im Status Pending. Dieses Problem äußert sich als TLS-Zertifikatvalidierungsfehler für den Mutating Admission-Webhook windows-webhook. Das Problem tritt auf, weil der alternative Antragstellername (Subject Alternative Name, SAN) des Zertifikats fälschlicherweise einen Wert beibehält, der für die alte Kubeception-Architektur gültig ist, anstatt für den neuen kube-system.svc-Endpunkt neu generiert zu werden.

Möglicherweise wird die folgende Fehlermeldung angezeigt: failed calling webhook "windows.webhooks.gke.io": failed to call webhook: Post "https://windows-webhook.kube-system.svc:443/pod?timeout=10s": tls: failed to verify certificate: x509. Diese Situation kann durch die Migration von ControlPlaneV2 entstehen, bei der etcd-Inhalte kopiert werden. Dadurch wird das alte Zertifikat ohne ordnungsgemäße Neuerstellung übertragen. Windows-Knotenpools sind ein eingestelltes Feature und in Google Distributed Cloud 1.33 und höher nicht mehr verfügbar.

Workaround:

  1. Sichern Sie das Secret user-component-options im Namespace des Nutzerclusters:

        kubectl get secret user-component-options -n USER_CLUSTER_NAME -oyaml > backup.yaml

  2. Löschen Sie das Secret user-component-options:

        kubectl delete secret user-component-options -n USER_CLUSTER_NAME

  3. Bearbeiten Sie die onpremusercluster-Ressource, um die Abstimmung auszulösen, indem Sie die Annotation onprem.cluster.gke.io/reconcile: "true" hinzufügen:

        kubectl edit onpremusercluster USER_CLUSTER_NAME -n USER_CLUSTER_MGMT_NAMESPACE

Ersetzen Sie USER_CLUSTER_NAME durch den Namen Ihres Nutzerclusters.
Upgrades, Updates 1.32.0-1.32.500, 1.33.0

Das Upgrade auf einen erweiterten Cluster schlägt fehl, wenn stackdriver nicht konfiguriert ist.

Beim Upgrade/Aktualisieren eines nicht erweiterten Clusters auf einen erweiterten Cluster reagiert der Prozess möglicherweise nicht mehr, wenn Stackdriver nicht aktiviert ist.

Workaround:

  • Wenn der Cluster noch nicht aktualisiert wurde, müssen Sie die folgenden Schritte ausführen, um stackdriver zu aktivieren:
    1. Fügen Sie der Clusterkonfigurationsdatei den Abschnitt stackdriver hinzu.
    2. Führen Sie gkectl update aus, um stackdriver zu aktivieren.
  • Wenn ein Upgrade bereits läuft, gehen Sie so vor:
    1. Bearbeiten Sie das Secret user-cluster-creds im Namespace USER_CLUSTER_NAME-gke-onprem-mgmt mit dem folgenden Befehl: 
      kubectl --kubeconfig ADMIN_KUBECONFIG \
  patch secret user-cluster-creds \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  --type merge -p "{\"data\":{\"stackdriver-service-account-key\":\"$(cat STACKDRIVER_SERVICE_ACCOUNT_KEY_FILE | base64 | tr -d '\n')\"}}"
    2. Aktualisieren Sie die benutzerdefinierte Ressource OnPremUserCluster mit dem Feld „stackdriver“. Verwenden Sie dasselbe Projekt mit demselben Projektspeicherort und demselben Dienstkontoschlüssel wie „cloudauditlogging“, wenn Sie die Funktion aktiviert haben. 
      kubectl --kubeconfig ADMIN_KUBECONFIG \
    patch onpremusercluster USER_CLUSTER_NAME \
    -n USER_CLUSTER_NAME-gke-onprem-mgmt --type merge -p '
    spec:
      stackdriver:
        clusterLocation: PROJECT_LOCATION
        providerID: PROJECT_ID
        serviceAccountKey:
          kubernetesSecret:
            keyName: stackdriver-service-account-key
            name: user-cluster-creds
'
    3. Fügen Sie der Clusterkonfigurationsdatei den Abschnitt stackdriver hinzu, um die Konsistenz zu wahren.
Upgrades 1.29, 1.30, 1.31, 1.32+

Pods können mit Dataplane V2 und restriktiven Netzwerkrichtlinien keine Verbindung zum Kubernetes API-Server herstellen

In Clustern mit der Architektur der Steuerungsebene V2 (CPv2) (Standard in Version 1.29 und höher) und Dataplane V2 können Pods möglicherweise keine Verbindung zum Kubernetes API-Server (kubernetes.default.svc.cluster.local) herstellen. Dieses Problem wird häufig durch das Vorhandensein von Netzwerkrichtlinien ausgelöst, insbesondere durch solche mit Standard-Deny-Regeln für ausgehenden Traffic. Mögliche Symptome:

  • TCP-Verbindungsversuche zur Cluster-IP-Adresse oder zu den Knoten-IP-Adressen des API-Servers führen zu einer Connection reset by peer-Meldung.
  • TLS-Handshake-Fehler beim Herstellen einer Verbindung zum API-Server.
  • Wenn Sie den Befehl cilium monitor -t drop auf dem betroffenen Knoten ausführen, sehen Sie möglicherweise, dass Pakete, die für die IP-Adressen des Steuerungsebenenknotens und den API-Server-Port (in der Regel 6443) bestimmt sind, verworfen werden.

Ursache

Dieses Problem entsteht durch eine Interaktion zwischen Dataplane V2 (basierend auf Cilium) und Kubernetes-Netzwerkrichtlinien in der CPv2-Architektur, in der Steuerungsebenenkomponenten auf Knoten im Nutzercluster ausgeführt werden. Die standardmäßige Cilium-Konfiguration interpretiert ipBlock-Regeln in Netzwerkrichtlinien, die Traffic zu den Knoten-IPs der Steuerungsebenenmitglieder zulassen sollen, nicht korrekt. Dieses Problem hängt mit einem Upstream-Problem in Cilium zusammen (cilium#20550).

Workaround:

Vermeiden Sie für die Versionen 1.29, 1.30 und 1.31 die Verwendung restriktiver Netzwerkrichtlinien für ausgehenden Traffic, die den Traffic zu den Steuerungsebenenknoten blockieren könnten. Wenn Sie eine Standardrichtlinie zum Ablehnen benötigen, müssen Sie möglicherweise eine allgemeine Regel zum Zulassen für den gesamten ausgehenden Traffic hinzufügen, indem Sie beispielsweise im Abschnitt „egress“ keine „to“-Regeln angeben. Dadurch wird der gesamte ausgehende Traffic zugelassen. Diese Lösung ist weniger sicher und möglicherweise nicht für alle Umgebungen geeignet.

Aktivieren Sie für alle anderen Versionen eine Cilium-Konfiguration, damit Knoten-IP-Adressen in den ipBlock-Feldern der Netzwerkrichtlinie korrekt abgeglichen werden. So gleichen Sie Knoten-IPs in ipBlock-Feldern der Netzwerkrichtlinie ab:

  1. Bearbeiten Sie die ConfigMap cilium-config: 
    kubectl edit configmap -n kube-system cilium-config
  2. Fügen Sie den Datenabschnitt hinzu oder ändern Sie ihn, sodass er policy-cidr-match-mode: nodes enthält: 
    data:
      policy-cidr-match-mode: nodes
  3. Starten Sie das anetd-DaemonSet neu, um die Konfigurationsänderung anzuwenden: 
    kubectl rollout restart ds anetd -n kube-system
  4. Achten Sie darauf, dass Sie eine Netzwerkrichtlinie haben, die ausgehenden Traffic von Ihren Pods zu den IP-Adressen der Steuerungsebene auf dem API-Serverport explizit zulässt. Ermitteln Sie die IP-Adressen der Knoten der Steuerungsebene Ihres Nutzerclusters, indem Sie kubectl get svc kubernetes ausführen. Die Ausgabe sieht in etwa so aus: 
        apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-egress-to-kube-apiserver
      namespace: NAMESPACE_NAME
    spec:
      podSelector: {} 
      policyTypes:
      - Egress
      egress:
      - to:
        - ipBlock:
            cidr: CP_NODE_IP_1/32
        - ipBlock:
            cidr: CP_NODE_IP_2/32
        ports:
        - protocol: TCP
          port: 6443 # Kubernetes API Server port on the node
Installation 1.30.200-gke.101

Der gke-connect-Agent-Pod bleibt während der Erstellung des Nutzerclusters im Status Pending hängen

Während der Erstellung des Nutzerclusters kann es vorkommen, dass der gke-connect-Agent-Pod im Status Pending hängen bleibt, sodass der Cluster nicht vollständig erstellt werden kann. Dieses Problem tritt auf, weil der gke-connect-Agent-Pod versucht, einen Zeitplan zu erstellen, bevor Worker-Knoten verfügbar sind, was zu einem Deadlock führt.

Dieses Problem tritt auf, wenn die erste Erstellung des Nutzerclusters aufgrund von Preflight-Validierungsfehlern fehlschlägt und ein nachfolgender Versuch, den Cluster zu erstellen, erfolgt, ohne die teilweise erstellten Ressourcen zuerst zu löschen. Beim nachfolgenden Versuch, den Cluster zu erstellen, bleibt der gke-connect-Agent-Pod aufgrund von nicht tolerierten Taints auf den Knoten der Steuerungsebene hängen. Dies wird durch einen Fehler wie den folgenden angezeigt:

    0/3 nodes are available: 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }`.

Workaround:

Wenn die Erstellung des Nutzerclusters aufgrund von Preflight-Validierungsfehlern fehlschlägt, löschen Sie die teilweise erstellten Clusterressourcen, bevor Sie versuchen, den Cluster mit korrigierten Konfigurationen noch einmal zu erstellen. So wird sichergestellt, dass der Erstellungsprozess korrekt abläuft, einschließlich der Erstellung von Knotenpools, bevor der gke-connect-Agent-Pod bereitgestellt wird.
Aktualisieren 1.16 und frühere Versionen, 1.28.0–1.28.1100, 1.29.0–1.29.700, 1.30.0–1.30.200

Nachdem Sie die Always-On-Secrets-Verschlüsselung mit gkectl update cluster deaktiviert haben, werden die Secrets weiterhin verschlüsselt in etcd gespeichert. Dieses Problem betrifft nur Kubeception-Nutzercluster. Wenn Ihr Cluster die Steuerungsebene V2 verwendet, sind Sie von diesem Problem nicht betroffen.

Führen Sie den folgenden Befehl aus, um zu prüfen, ob die Secrets weiterhin verschlüsselt sind. Damit wird das in etcd gespeicherte Secret default/private-registry-creds abgerufen:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    exec -it -n USER_CLUSTER_NAME kube-etcd-0 -c kube-etcd -- \
    /bin/sh -ec "export ETCDCTL_API=3; etcdctl \
    --endpoints=https://127.0.0.1:2379 \
    --cacert=/etcd.local.config/certificates/etcdCA.crt \
    --cert=/etcd.local.config/certificates/etcd.crt \
    --key=/etcd.local.config/certificates/etcd.key \
    get /registry/secrets/default/private-registry-creds" | hexdump -C

Wenn das Secret verschlüsselt gespeichert ist, sieht die Ausgabe so aus:

00000000  2f 72 65 67 69 73 74 72  79 2f 73 65 63 72 65 74  |/registry/secret|
00000010  73 2f 64 65 66 61 75 6c  74 2f 70 72 69 76 61 74  |s/default/privat|
00000020  65 2d 72 65 67 69 73 74  72 79 2d 63 72 65 64 73  |e-registry-creds|
00000030  0d 0a 6b 38 73 3a 65 6e  63 3a 6b 6d 73 3a 76 31  |..k8s:enc:kms:v1|
00000040  3a 67 65 6e 65 72 61 74  65 64 2d 6b 65 79 2d 6b  |:generated-key-k|
00000050  6d 73 2d 70 6c 75 67 69  6e 2d 31 3a 00 89 65 79  |ms-plugin-1:..ey|
00000060  4a 68 62 47 63 69 4f 69  4a 6b 61 58 49 69 4c 43  |JhbGciOiJkaXIiLC|
...

Wenn das Secret nicht verschlüsselt gespeichert ist, sieht die Ausgabe so aus:

00000000  2f 72 65 67 69 73 74 72  79 2f 73 65 63 72 65 74  |/registry/secret|
00000010  73 2f 64 65 66 61 75 6c  74 2f 70 72 69 76 61 74  |s/default/privat|
00000020  65 2d 72 65 67 69 73 74  72 79 2d 63 72 65 64 73  |e-registry-creds|
00000030  0d 0a 6b 38 73 00 0d 0a  0c 0d 0a 02 76 31 12 06  |..k8s.......v1..|
00000040  53 65 63 72 65 74 12 83  47 0d 0a b0 2d 0d 0a 16  |Secret..G...-...|
00000050  70 72 69 76 61 74 65 2d  72 65 67 69 73 74 72 79  |private-registry|
00000060  2d 63 72 65 64 73 12 00  1a 07 64 65 66 61 75 6c  |-creds....defaul|
...

Workaround:

  1. Führen Sie ein Rolling Update für ein bestimmtes DaemonSet aus: 
        kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      rollout restart statefulsets kube-apiserver \
      -n USER_CLUSTER_NAME
  2. Manifeste aller Secrets im Nutzercluster im YAML-Format abrufen: 
        kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
      get secrets -A -o yaml > SECRETS_MANIFEST.yaml
  3. Wenden Sie alle Secrets im Nutzercluster noch einmal an, damit alle Secrets als Nur-Text in etcd gespeichert werden: 
        kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
      apply -f SECRETS_MANIFEST.yaml

Konfiguration 1.29, 1.30, 1.31

In der Nutzercluster-Konfigurationsdatei user-cluster.yaml, die mit dem Befehl gkectl get-config generiert wurde, fehlt das Feld hostgroups im Abschnitt nodePools. Mit dem Befehl gkectl get-config wird die Datei user-cluster.yaml basierend auf dem Inhalt der benutzerdefinierten Ressource OnPremUserCluster generiert. Das Feld nodePools[i].vsphere.hostgroups ist jedoch in der benutzerdefinierten Ressource OnPremNodePool vorhanden und wird nicht in die Datei user-cluster.yaml kopiert, wenn Sie gkectl get-config ausführen.

Problemumgehung

Fügen Sie das Feld nodePools[i].vsphere.hostgroups manuell zur Datei user-cluster.yaml hinzu, um dieses Problem zu beheben. Die bearbeitete Datei sollte in etwa so aussehen:

apiVersion: v1
kind: UserCluster
...
nodePools:
- name: "worker-pool-1"
  enableLoadBalancer: true
  replicas: 3
  vsphere:
    hostgroups:
    - "hostgroup-1"
...

Sie können die bearbeitete Konfigurationsdatei des Nutzerclusters verwenden, um den Nutzercluster zu aktualisieren, ohne Fehler auszulösen. Das Feld hostgroups wird beibehalten.
Netzwerk 1.29.0-1.29.1000 1.30.0-1.30.500, 1.31.0-1.31.100

Istiod-Pods des gebündelten Ingress können nicht bereit sein, wenn gateway.networking.k8s.io-Ressourcen im Nutzercluster installiert sind. Die folgende Beispiel-Fehlermeldung kann in Pod-Logs gefunden werden:

    failed to list *v1beta1.Gateway: gateways.gateway.networking.k8s.io is forbidden: User \"system:serviceaccount:gke-system:istiod-service-account\" cannot list resource \"gateways\" in API group \"gateway.networking.k8s.io\" at the cluster scope"

Workaround:

Wenden Sie die folgende ClusterRole und ClusterRoleBinding auf Ihren Nutzercluster an: 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: istiod-gateway
rules:
- apiGroups:
  - 'gateway.networking.k8s.io'
  resources:
  - '*'
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: istiod-gateway-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: istiod-gateway
subjects:
- kind: ServiceAccount
  name: istiod-service-account
  namespace: gke-system
Installation 1.29.0-1.29.1000 1.30.0-1.30.500, 1.31.0-1.31.100

Wenn Hostnamen im Feld ipblocks Großbuchstaben enthalten, werden die Knoten der Steuerungsebene des Administratorclusters möglicherweise immer wieder neu gestartet.

Workaround:

Verwenden Sie nur Hostnamen in Kleinbuchstaben.
Installation, Upgrades 1.30.0-1.30.500, 1.31.0-1.31.100

Runtime: out of memory „error“ nach Ausführung von gkeadm create oder upgrade

Beim Erstellen oder Aktualisieren von Administrator-Workstations mit gkeadm-Befehlen kann beim Überprüfen des heruntergeladenen Betriebssystem-Images ein OOM-Fehler auftreten.

Beispiel: 

Downloading OS image
"gs://gke-on-prem-release/admin-appliance/1.30.400-gke.133/gke-on-prem-admin-appliance-vsphere-1.30.400-gke.133.ova"...

[==================================================>] 10.7GB/10.7GB

Image saved to
/anthos/gke-on-prem-admin-appliance-vsphere-1.30.400-gke.133.ova

Verifying image gke-on-prem-admin-appliance-vsphere-1.30.400-gke.133.ova...
|

runtime: out of memory

Workaround:

  • Erhöhen Sie die Größe des Betriebssystemspeichers, in dem Sie den Befehl gkeadm ausführen.
    		•
    Upgrades 1.30.0-1.30.400

    Upgrade eines Nicht-HA-Administratorclusters bleibt bei Creating or updating cluster control plane workloads hängen

    Beim Upgrade eines Nicht-HA-Administratorclusters kann das Upgrade bei Creating or updating cluster control plane workloads hängen bleiben.

    Dieses Problem tritt auf, wenn ip a | grep cali in der Administrator-Master-VM ein nicht leeres Ergebnis zurückgibt.

    Beispiel: 

    ubuntu@abf8a975479b-qual-342-0afd1d9c ~ $ ip a | grep cali
4: cali2251589245f@if3:  mtu 1500 qdisc noqueue state UP group default

    Workaround:

    1. Administrator-Master reparieren: 
      gkectl repair admin-master --kubeconfig=ADMIN_KUBECONFIG \
    --config=ADMIN_CONFIG_FILE \
    --skip-validation
    2. Wählen Sie die VM-Vorlage 1.30 aus, wenn Sie einen Prompt wie im folgenden Beispiel sehen: 
      Please select the control plane VM template to be used for re-creating the
admin cluster's control plane VM.
    3. Upgrade fortsetzen: 
      gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG \
    --config ADMIN_CONFIG_FILE
    Konfiguration 1.31.0

    Redundantes Feld isControlPlane in der Clusterkonfigurationsdatei unter network.controlPlaneIPBlock

    Clusterkonfigurationsdateien, die von gkectl create-config in Version 1.31.0 generiert werden, enthalten ein redundantes isControlPlane-Feld unter network.controlPlaneIPBlock:

        controlPlaneIPBlock:
    netmask: ""
    gateway: ""
    ips:
    - ip: ""
      hostname: ""
      isControlPlane: false
    - ip: ""
      hostname: ""
      isControlPlane: false
    - ip: ""
      hostname: ""
      isControlPlane: false

    Dieses Feld wird nicht benötigt und kann sicher aus der Konfigurationsdatei entfernt werden.

    Migration 1.29.0-1.29.800, 1.30.0-1.30.400, 1.31.0

    Wenn Sie einen Nicht-HA-Administratorcluster, der MetalLB verwendet, zu HA migrieren, bleiben Administrator-Add-on-Knoten möglicherweise im Status NotReady hängen, wodurch die Migration nicht abgeschlossen werden kann.

    Dieses Problem betrifft nur Administratorcluster, die mit MetalLB konfiguriert sind und in denen die automatische Reparatur nicht aktiviert ist.

    Dieses Problem wird durch eine Race Condition während der Migration verursacht, bei der MetalLB-Lautsprecher weiterhin das alte metallb-memberlist-Secret verwenden. Aufgrund der Race-Bedingung ist die alte VIP der Steuerungsebene nicht mehr zugänglich, was dazu führt, dass die Migration ins Stocken gerät.

    Workaround:

    1. Löschen Sie das vorhandene metallb-memberlist-Secret: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    delete secret metallb-memberlist
    2. Starten Sie das metallb-controller-Deployment neu, damit der neue metallb-memberlist generiert werden kann: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    rollout restart deployment metallb-controller
    3. Prüfen Sie, ob das neue metallb-memberlist generiert wurde: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    get secret metallb-memberlist
    4. Aktualisieren Sie updateStrategy.rollingUpdate.maxUnavailable im metallb-speaker-DaemonSet von 1 auf 100%.

      Dieser Schritt ist erforderlich, da bestimmte DaemonSet-Pods auf den NotReady-Knoten ausgeführt werden.

      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    edit daemonset metallb-speaker
    5. Starten Sie das DaemonSet metallb-speaker neu, damit die neue Mitgliederliste übernommen wird: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    rollout restart daemonset metallb-speaker

      Nach einigen Minuten werden die Knoten des Administrator-Add-ons wieder Ready und die Migration kann fortgesetzt werden.

    6. Wenn für den ursprünglichen gkectl-Befehl nach mehr als drei Stunden eine Zeitüberschreitung aufgetreten ist, führen Sie gkectl update noch einmal aus, um die fehlgeschlagene Migration fortzusetzen.
    Konfiguration, Betrieb 1.12+, 1.13+, 1.14+, 1.15+, 1.16+, 1.28+, 1.29+, 1.30+

    Die Clustersicherung für einen Administratorcluster ohne Hochverfügbarkeit schlägt aufgrund langer Datenspeicher- und Datenträger-Namen fehl.

    Wenn Sie versuchen, einen nicht hochverfügbaren Administratorcluster zu sichern, schlägt die Sicherung fehl, da die kombinierte Länge der Namen von Datenspeicher und Datendisk die maximale Zeichenlänge überschreitet.

    Ein Datenspeichername darf maximal 80 Zeichen lang sein.
     Der Sicherungspfad für einen Administratorcluster ohne Hochverfügbarkeit hat die Benennungssyntax „__“. Wenn der zusammengefügte Name die maximale Länge überschreitet, schlägt die Erstellung des Sicherungsordners fehl.

    Workaround:

    Benennen Sie den Datastore oder die Datendisk in einen kürzeren Namen um.
     Achten Sie darauf, dass die kombinierte Länge der Namen von Datenspeicher und Datenträger die maximale Zeichenlänge nicht überschreitet.
    Upgrades 1.28, 1.29, 1.30

    Nachdem Sie den gkectl repair admin-master-Befehl ausgeführt haben, wird für einen Knoten der Administratorsteuerungsebene möglicherweise eine ältere Version als die erwartete Version angezeigt.

    Dieses Problem tritt auf, weil die gesicherte VM-Vorlage, die für die Reparatur des HA-Administratorsteuerungsebenenknotens verwendet wird, nach einem Upgrade nicht in vCenter aktualisiert wird. Das liegt daran, dass die Sicherungs-VM-Vorlage bei der Erstellung der Maschine nicht geklont wurde, wenn der Maschinenname unverändert bleibt.

    Workaround:

    1. Ermitteln Sie den Namen des Computers, auf dem die ältere Kubernetes-Version verwendet wird: 
          kubectl get machine -o wide --kubeconfig=ADMIN_KUBECONFIG
    2. Entfernen Sie die Anmerkung onprem.cluster.gke.io/prevented-deletion: 
          kubectl edit machine MACHINE_NAME --kubeconfig=ADMIN_KUBECONFIG

      Speichern Sie die Änderung.

    3. Führen Sie den folgenden Befehl aus, um den Computer zu löschen: 
          kubectl delete machine MACHINE_NAME --kubeconfig=ADMIN_KUBECONFIG

      Eine neue Maschine mit der richtigen Version wird erstellt.
    Konfiguration 1.30.0

    Wenn Sie einen Nutzercluster oder Nodepool mit Terraform aktualisieren, versucht Terraform möglicherweise, vCenter-Felder auf leere Werte zu setzen.

    Dieses Problem kann auftreten, wenn der Cluster nicht ursprünglich mit Terraform erstellt wurde.

    Workaround:

    Um ein unerwartetes Update zu verhindern, müssen Sie vor dem Ausführen von terraform apply prüfen, ob das Update sicher ist. Gehen Sie dazu so vor:

    1. Führen Sie terraform plan aus
    2. Prüfen Sie in der Ausgabe, ob die Felder vCenter auf nil gesetzt sind.
    3. Wenn ein vCenter-Feld in der Terraform-Konfiguration auf einen leeren Wert gesetzt ist, fügen Sie der Liste ignore_changes vcenter hinzu. Folgen Sie dabei der Terraform-Dokumentation. Dadurch werden Aktualisierungen dieser Felder verhindert.
    4. Führen Sie terraform plan noch einmal aus und prüfen Sie die Ausgabe, um zu bestätigen, dass die Aktualisierung wie erwartet erfolgt ist.
    Updates 1.13, 1.14, 1.15, 1.16

    Nachdem die Steuerungsebenenknoten der Kubeception-Nutzercluster erstellt, aktualisiert oder aktualisiert wurden, werden sie einzeln neu gestartet. Dies geschieht beim ersten Administratorcluster-Vorgang, wenn der Administratorcluster in einer der betroffenen Versionen erstellt oder auf eine der betroffenen Versionen aktualisiert wird. Bei Kubeception-Clustern mit 3 Knoten der Steuerungsebene sollte dies nicht zu Ausfallzeiten der Steuerungsebene führen. Die einzige Auswirkung ist, dass der Administratorcluster-Vorgang länger dauert.

    Installation, Upgrades und Updates 1,31

    In Version 1.31 von Google Distributed Cloud können Fehler auftreten, wenn Sie versuchen, benutzerdefinierte Ressourcen wie Cluster (alle Typen) und Arbeitslasten zu erstellen. Das Problem wird durch eine wichtige Änderung in Kubernetes 1.31 verursacht, die verhindert, dass das Feld caBundle in einer benutzerdefinierten Ressourcendefinition von einem gültigen in einen ungültigen Zustand übergeht. Weitere Informationen zu dieser Änderung finden Sie im Kubernetes 1.31-Changelog.

    Vor Kubernetes 1.31 wurde das Feld caBundle oft auf den provisorischen Wert \n gesetzt, da der API-Server in früheren Kubernetes-Versionen keine leeren CA-Bundle-Inhalte zuließ. Die Verwendung von \n war eine angemessene Problemumgehung, um Verwirrung zu vermeiden, da cert-manager die caBundle normalerweise später aktualisiert.

    Wenn die caBundle einmal von einem ungültigen in einen gültigen Status geändert wurde, sollten keine Probleme auftreten. Wenn die benutzerdefinierte Ressourcendefinition jedoch auf \n (oder einen anderen ungültigen Wert) abgestimmt wird, kann der folgende Fehler auftreten:

    ...Invalid value: []byte{0x5c, 0x6e}: unable to load root certificates: unable to parse bytes as PEM block]

    Problemumgehung

    Wenn Sie eine benutzerdefinierte Ressourcendefinition haben, in der caBundle auf einen ungültigen Wert festgelegt ist, können Sie das Feld caBundle vollständig entfernen. Dadurch sollte das Problem behoben werden.
    Betriebssystem 1,31

    Beim Aktualisieren eines Clusters, der das Betriebssystem-Image Container-Optimized OS (COS) verwendet, auf Version 1.31 schlägt der Befehl cloud-init status fehl, obwohl cloud-init ohne Fehler abgeschlossen wurde.

    Workaround:

    Führen Sie den folgenden Befehl aus, um den Status von cloud-init zu prüfen:

        systemctl show -p Result cloud-final.service

    Wenn die Ausgabe in etwa so aussieht, wurde cloud-init erfolgreich abgeschlossen:

        Result=success
    Upgrades 1,28

    Beim Upgrade eines Clusters auf Version 1.28 schlägt der Befehl gkectl prepare während der Preflight-Prüfungen der Administratorworkstation fehl, wenn die Festplattengröße der Administratorworkstation weniger als 100 GB beträgt. In diesem Fall wird eine Fehlermeldung wie die folgende angezeigt:

        Workstation Hardware: Workstation hardware requirements are not satisfied

    In Version 1.28 wurde die Voraussetzung für die Festplattengröße der Administrator-Workstation von 50 GB auf 100 GB erhöht.

    Workaround:

    1. Führen Sie ein Rollback der Administrator-Workstation durch.
    2. Aktualisieren Sie die Konfigurationsdatei der Administrator-Workstation, um die Festplattengröße auf mindestens 100 GB zu erhöhen.
    3. Führen Sie ein Upgrade der Administratorworkstation durch.
    Upgrades 1,30

    Der gkectl upgrade-Befehl gibt einen falschen Fehler zur NetApp-StorageClass zurück. Die Fehlermeldung sieht etwa so aus: 

        detected unsupported drivers:
      csi.trident.netapp.io

    Workaround:

    Führen Sie gkectl upgrade mit dem Flag `--skip-pre-upgrade-checks` aus.
    Identität Alle Versionen

    Nachdem Sie die CA-Zertifikate (Certificate Authority) in einem Nutzercluster rotiert haben, enthält das Feld spec.certificateAuthorityData in der ClientConfig ein ungültiges CA-Zertifikat, das die Authentifizierung für den Cluster verhindert.

    Workaround:

    Aktualisieren Sie das Feld spec.certificateAuthorityData in ClientConfig manuell mit dem richtigen CA-Zertifikat, bevor Sie sich das nächste Mal über die gcloud CLI authentifizieren.

    1. Kopieren Sie das Cluster-CA-Zertifikat aus dem Feld certificate-authority-data in der kubeconfig des Administratorclusters.
    2. Bearbeiten Sie die ClientConfig und fügen Sie das CA-Zertifikat in das Feld spec.certificateAuthorityData ein. 
          kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
    Updates 1.28+

    Wenn Sie den gebündelten eingehenden Traffic deaktivieren, indem Sie das Feld loadBalancer.vips.ingressVIP in der Clusterkonfigurationsdatei entfernen, führt ein Fehler in der MetalLB-Preflight-Prüfung dazu, dass die Clusteraktualisierung mit der Fehlermeldung „invalid user ingress vip: invalid IP“ fehlschlägt.

    Workaround:

    Ignorieren Sie die Fehlermeldung.
    Sie haben folgende Möglichkeiten, das Preflight zu überspringen:

    • Fügen Sie dem Befehl gkectl update cluster das Flag --skip-validation-load-balancer hinzu.
    • Annotieren Sie das onpremusercluster-Objekt mit onprem.cluster.gke.io/server-side-preflight-skip: skip-validation-load-balancer.
      • .
    VMware, Upgrades 1.16

    Während eines Cluster-Upgrades bleiben die Maschinenobjekte möglicherweise in der Phase „Erstellen“ hängen und können aufgrund einer fehlenden Anti-Affinitätsgruppenregel (AAG) in vCenter nicht mit den Knotenobjekten verknüpft werden.

    Wenn Sie die problematischen Maschinenobjekte beschreiben, werden wiederholt Meldungen wie „Reconfigure DRS rule task "task-xxxx" complete“ (Neukonfiguration der DRS-Regelnaufgabe „task-xxxx“ abgeschlossen) angezeigt.

        kubectl --kubeconfig KUBECONFIG describe machine MACHINE_OBJECT_NAME

    Workaround:

    Deaktivieren Sie die Einstellung für die Anti-Affinitätsgruppe sowohl in der Konfiguration des Administratorclusters als auch in der Konfiguration des Nutzerclusters und lösen Sie den Befehl zum Erzwingen der Aktualisierung aus, um das Cluster-Upgrade zu entblocken:

        gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --force
    
        gkectl update cluster --config USER_CLUSTER_CONFIG_FILE --kubeconfig USER_CLUSTER_KUBECONFIG --force
    Migration 1.29, 1.30

    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

    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

    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 Schlüssel privateRegistry 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+

    Beim Upgrade eines Nutzerclusters kann der Abgleichvorgang vor dem Upgrade länger als das definierte Zeitlimit dauern, was zu einem Upgradefehler führt. Die Fehlermeldung sieht 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.

    Das Zeitlimit für den Abgleichvorgang 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

    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

    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 wird erfolgreich abgeschlossen 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 das Erstellen eines etcd-Snapshots und das Schreiben der Metadatendatei für den Administratorcluster. Die etcd-Sicherung ist weiterhin erfolgreich, da etcdctl nach dem Ausführen von „exec“ in den 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

    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 Installationsreihenfolge des Binärautorisierung-Webhooks und des gke-connect-Pods dazu führen, dass die Erstellung des Nutzerclusters ins Stocken gerät, da ein Knoten keinen Bereitschaftsstatus erreicht. In den betroffenen Szenarien kann die Erstellung von Nutzerclustern ins Stocken geraten, weil ein Knoten den Status „Bereit“ nicht 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 Binärautorisierung-Konfiguration aus Ihrer Konfigurationsdatei. Eine Anleitung zur Einrichtung finden Sie im Installationsleitfaden für die Binärautorisierung für GKE on VMware (Tag 2).
    2. Wenn Sie einen fehlerhaften Knoten während der aktuellen Clustererstellung entsperren möchten, entfernen Sie die Webhook-Konfiguration für die Binärautorisierung im Nutzercluster vorübergehend 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. Die folgende Fehlermeldung wird angezeigt, wenn das Upgrade nicht abgeschlossen werden kann:

        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 von der gespiegelten Maschine zu löschen, und warten Sie, bis er aus dem Nutzercluster gelöscht wurde. 
          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. Führen Sie gkectl upgrade cluster noch einmal aus, 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:

    Achten Sie vor dem Erstellen des Clusters darauf, dass die VIP der Steuerungsebene im selben Subnetz wie die anderen Clusterknoten konfiguriert ist.
    Installation, Upgrades, Updates 1.29.0 – 1.29.100

    Die Clustererstellung oder das Cluster-Upgrade schlägt mit einem Fehler in den vSphere-CSI-Pods fehl, der angibt, dass der vCenter-Nutzername ungültig ist. Das liegt daran, dass der verwendete Nutzername kein vollständig 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 von vollständig qualifizierten Domainnutzernamen zu erzwingen.

    Workaround:

    Verwenden Sie einen vollständig qualifizierten Domainnamen für den vCenter-Nutzernamen in der Konfigurationsdatei für Anmeldedaten. Verwenden Sie beispielsweise „nutzername1@beispiel.de“ anstelle von „nutzername1“.
    Upgrades, Updates 1.28.0 - 1.28.500

    Beim Upgrade eines Administratorclusters von 1.16 auf 1.28 kann es vorkommen, dass beim Bootstrapping des neuen Admin-Master-Computers das Steuerungsebenenzertifikat nicht generiert wird. Das Problem wird durch Änderungen bei der Generierung von Zertifikaten für den Kubernetes API-Server in Version 1.28 und höher verursacht. Das Problem tritt bei Clustern auf, die in Version 1.10 oder früher erstellt und auf Version 1.16 aktualisiert wurden und bei denen das Leaf-Zertifikat vor dem Upgrade nicht rotiert wurde.

    Um festzustellen, ob der Administratorcluster-Upgrade-Fehler auf dieses Problem zurückzuführen ist, führen Sie die folgenden Schritte durch:

    1. Stellen Sie eine SSH-Verbindung zur fehlerhaften Admin-Master-Maschine her.
    2. Öffnen Sie /var/log/startup.log und suchen Sie nach einem Fehler wie:
    Error adding extensions from section apiserver_ext
801B3213B57F0000:error:1100007B:X509 V3 routines:v2i_AUTHORITY_KEYID:unable to get issuer keyid:../crypto/x509/v3_akid.c:177:
801B3213B57F0000:error:11000080:X509 V3 routines:X509V3_EXT_nconf_int:error in extension:../crypto/x509/v3_conf.c:48:section=apiserver_ext, name=authorityKeyIdentifier, value=keyid>

    Workaround:

    1. Stellen Sie eine SSH-Verbindung zum Administrator-Master her. Weitere Informationen finden Sie unter SSH verwenden, um eine Verbindung zu einem Administratorclusterknoten herzustellen.
    2. Erstellen Sie eine Kopie von /etc/startup/pki-yaml.sh und geben Sie ihr den Namen /etc/startup/pki-yaml-copy.sh.
    3. /etc/startup/pki-yaml-copy.sh bearbeiten Suchen Sie authorityKeyIdentifier=keyidset und ändern Sie es zu authorityKeyIdentifier=keyid,issuer in den Abschnitten für folgende Erweiterungen: apiserver_ext, client_ext etcd_server_ext und kubelet_server_ext. Beispiel: 
            [ apiserver_ext ]
      keyUsage = critical, digitalSignature, keyEncipherment
      extendedKeyUsage=serverAuth
      basicConstraints = critical,CA:false
      authorityKeyIdentifier = keyid,issuer
      subjectAltName = @apiserver_alt_names
    4. Speichern Sie die Änderungen in /etc/startup/pki-yaml-copy.sh.
    5. Öffnen Sie /opt/bin/master.sh mit einem Texteditor, suchen Sie nach allen Vorkommen von /etc/startup/pki-yaml.sh und ersetzen Sie sie durch /etc/startup/pki-yaml-copy.sh. Speichern Sie dann die Änderungen.
    6. Führen Sie /opt/bin/master.sh aus, um das Zertifikat zu generieren und den Maschinenstart abzuschließen.
    7. Führen Sie die gkectl upgrade admin noch einmal aus, um das Upgrade für den Administrator-Cluster durchzuführen.
    8. Rotieren Sie nach Abschluss des Upgrades das untergeordnete Zertifikat für beide Administratoren und Nutzercluster, wie unter Rotation starten beschrieben.
    9. Nehmen Sie nach Abschluss der Zertifikatsrotation die gleichen Änderungen an /etc/startup/pki-yaml-copy.sh vor wie zuvor und führen Sie /opt/bin/master.sh aus.
    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 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:

    Wenn Sie die inkorrekte Preflight-Prüfung in einem Release, in dem der Fehler nicht behoben wurde, überspringen möchten, fügen Sie dem gkectl-Befehl --skip-validation-net-config hinzu.
    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 Cloudzu verbinden und eine erneute Registrierung auszulösen:

    Rufen Sie zuerst den Namen der Bereitstellung 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 prüfen, ob der 400-Fehler „Fehler bei der Prüfung der JWT-Signatur“ 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:

    Zur Umgehung dieses Problems müssen Sie den Docker-Dienst neu starten:

    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 funktionieren mit diesen CNI-Plug-ins nicht.

    Workaround:

    Wenn Sie diese Funktion nutzen, sollten Sie ein Upgrade auf die Version mit dem Fix durchführen.
    update 1.15, 1.16, 1.28

    Die Installation von multipathd auf Clusternknoten beeinträchtigt den vSphere-CSI-Treiber, sodass 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
    Gelegentlich kann es zu Problemen bei der Kommunikation zwischen dem Kubernetes API-Server und dem Webhook kommen. In diesem Fall wird möglicherweise die folgende Fehlermeldung angezeigt: 
    failed to apply OnPremAdminCluster 'kube-system/gke-admin-btncc': Internal error occurred: failed calling webhook "monpremadmincluster.onprem.cluster.gke.io": failed to call webhook: Post "https://onprem-admin-cluster-controller.kube-system.svc:443/mutate-onprem-cluster-gke-io-v1alpha1-onpremadmincluster?timeout=10s": dial tcp 10.96.55.208:443: connect: connection refused

    Workaround:

    Wenn einer dieser Fehler auftritt, verwenden Sie je nach Version eine der folgenden Problemumgehungen:
    • 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
  ...
    Speicher 1.28.0-1.28.100

    nfs-common fehlt im Ubuntu-Betriebssystem-Image, was zu Problemen für Kunden führen kann, die NFS-abhängige Treiber wie NetApp verwenden.

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

    Workaround:

    Achten Sie darauf, dass Ihre Knoten Pakete von Canonical herunterladen können.

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

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

    SPBM in Administratorclustern wird in Version 1.28.0 und höher unterstützt. Aber das Feld vCenter.storagePolicyName fehlt in der Konfigurationsdateivorlage.

    Workaround:

    Fügen Sie das Feld `vCenter.storagePolicyName` in die Konfigurationsdatei für den Administratorcluster ein, wenn Sie die Speicherrichtlinie für den Administratorcluster konfigurieren möchten. Hier finden Sie eine Anleitung.
    Logging und Monitoring 1.28.0-1.28.100

    Die kürzlich hinzugefügte API „kubernetesmetadata.googleapis.com“ unterstützt VPC-SC nicht. Daher kann der Agent zum Erfassen von Metadaten unter VPC-SC nicht auf diese API zugreifen. In der Folge fehlen die Metadatenlabels für Messwerte.

    Workaround:

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

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

    Führen Sie dann diesen Befehl aus:

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

    Upgrades, 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 dem folgenden Beispiel 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 diese falsch positiven Benachrichtigungen ignoriert werden, sehen Sie sich die folgenden Optionen an:

    1. Warnung stummschalten über die Benutzeroberfläche des Alert Manager.
    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 Replicas herunter, damit die Änderungen beibehalten werden können.
      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 Upstream-Korrektur wurde vor Kurzem 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 Ingress für einen vorhandenen Cluster zu deaktivieren, schlägt der Befehl gkectl update cluster mit einem Fehler ähnlich dem folgenden Beispiel 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ündeltes Ingress 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 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, wird die Prüfpunktdatei während der Clusteraktualisierung nicht als Hauptdatenquelle verwendet. Die Prüfpunktdatei wird weiterhin für die zukünftige Verwendung aktualisiert.
    Speicher 1.15.0-1.15.6, 1.16.0-1.16.2

    Bei Preflight-Prüfungen wird durch die CSI-Arbeitslast-Validierungsprüfung ein Pod im Namespace default installiert. 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 startet, wird bei den Preflight-Prüfungen 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-Arbeitslast-Pod nicht richtig festgelegt sind, enthält der Jobstatus eine Fehlermeldung wie die folgende:

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

    Wenn der CSI-Arbeitslast-Pod aufgrund einer Istio-Sidecar-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 StorageClass standard-rwo verwendet.
    2. Erstellen Sie einen Pod, der den PVC verwendet.
    3. Prüfen Sie, ob der Pod Daten auf das Volume lesen und schreiben kann.
    4. Entfernen Sie den Pod und den PVC, nachdem Sie die ordnungsgemäße Funktion bestätigt 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, erhalten Sie den folgenden Fehler, 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 den validation-controller noch einmal 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, erhalten Sie den folgenden Fehler, wenn Sie versuchen, den Cluster zu erstellen: 

          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 der validation-controller in Version 1.16 hinzugefügt wurde, fehlt bei Verwendung eines Administratorclusters mit Version 1.15 der validation-controller, der 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. Möglicherweise wird eine der folgenden Fehlermeldungen 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 onprem.cluster.gke.io/skip-project-location-sameness-validation: true-Annotation 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 sind nur für das nächste Mal erforderlich, wenn Sie den Befehl update oder upgrade ausführen: 
        • 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

    Beim Löschen eines Clusters werden zuerst alle zugehörigen Objekte gelöscht. Das Löschen der Validierungsobjekte, die während des Erstellens, Aktualisierens oder Upgradens erstellt wurden, bleibt 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 Validation-Objekte 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 Validation-Objekt zu entfernen: 
            kubectl --kubeconfig ADMIN_KUBECONFIG patch validation/VALIDATION_OBJECT_NAME \
        -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge

      Nachdem Sie den Finalizer aus allen Validation-Objekten entfernt haben, 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. Wenn sich die Pods auf demselben Host befinden, wird die Verbindung zum externen Dienst oder zur externen Anwendung hergestellt.

    Dieses Problem wird dadurch verursacht, dass vSphere VXLAN-Pakete verwirft, 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. ConfigMap cilium-config bearbeiten: 
      kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
    2. Fügen Sie der ConfigMap cilium-config Folgendes hinzu: 
      tunnel-port: 4789
    3. Starten Sie das anetd-DaemonSet neu: 
      kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

    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.
    Upgrades 1.15.0-1.15.4

    Das Upgrade des Administratorclusters von 1.14.x auf 1.15.x mit aktivierter Always-on Secrets-Verschlüsselung schlägt fehl, da der vom Controller generierte Verschlüsselungsschlüssel nicht mit dem Schlüssel übereinstimmt, der auf dem Laufwerk für die Admin-Stammdaten gespeichert ist. Die Ausgabe von gkectl upgrade admin enthält die folgende Fehlermeldung: 

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

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

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

    Problemumgehung

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

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

    Upgradefehler vermeiden

    Wenn Sie noch kein Upgrade ausgeführt haben, empfehlen wir, kein Upgrade auf 1.15.0 bis 1.15.4 auszuführen. Wenn Sie ein Upgrade auf eine betroffene Version durchführen müssen, führen Sie die folgenden Schritte vor dem Upgrade des Administratorclusters aus:

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

    Google Distributed Cloud unterstützt kein Changed Block Tracking (CBT) auf Laufwerken. Einige Sicherungssoftware verwendet die CBT-Funktion, um den Laufwerksstatus zu verfolgen und Sicherungen durchzuführen. Dadurch kann das Laufwerk keine Verbindung zu einer VM herstellen, auf der Google Distributed Cloud ausgeführt wird. Weitere Informationen finden Sie im VMware-KB-Artikel.


    Workaround:

    Sichern Sie die Google Distributed Cloud-VMs nicht, da Sicherungssoftware von Drittanbietern möglicherweise CBT auf ihren Festplatten aktiviert. Es ist nicht notwendig, diese VMs zu sichern.

    Aktivieren Sie CBT nicht auf dem Knoten, da diese Änderung bei Updates oder Upgrades nicht 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-Wissensdatenbankartikel ist veraltet, da dort angegeben wird, dass es derzeit keine 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 ermittelten Versionsabweichungen 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.

    Upgrades, Updates 1.15.0-1.15.4

    Wenn ein Administratorcluster eine CA-Version größer als 1 hat, schlägt ein Update oder Upgrade aufgrund der CA-Versionsvalidierung im Webhook fehl. Die Ausgabe von gkectl upgrade/update enthält die folgende Fehlermeldung: 

        CAVersion must start from 1

    Workaround:

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

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

    Workaround:

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

    Gehen Sie andernfalls so vor:

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

    Speicher 1.15.0+, 1.16.0+

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


    Workaround:

    Bearbeiten Sie die vSphere CSI-Feature-ConfigMap und legen Sie „list-volumes“ auf „false“ fest:

         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 oben genannten 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 des Dienstkontoschlüssels 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.

    Es gibt einen Fehler im 1.16-Nutzercluster-Controller, der die Neuerstellung des 1.15-Master-Computers des Nutzers auslösen kann.

    Welche Lösung Sie wählen, hängt davon ab, wie das Problem auftritt.

    Problemumgehung beim Aktualisieren 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 Administrator-Workstation:

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

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

    Option 3: Für jede IP-Adresse in der IP-Blockdatei einen eindeutigen Hostnamen angeben.
    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 Steuerungsebene des Nutzerclusters nicht mit der Steuerungsebene des Administratorclusters kommunizieren, was zu Problemen beim Anhängen von Volumes für kube-etcd und kube-apiserver auf der Steuerungsebene des Nutzerclusters führt.

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

    Workaround:

    1. Stellen Sie eine SSH-Verbindung zu einem Knoten der Nutzersteuerungsebene her. Da es sich um einen 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 ermitteln und das Log 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 Manager 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 Upgraden 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 zum Knotenobjekt hinzufügen kann. Dies führt zu einer Zeitüberschreitung beim Upgrade oder Erstellen des Clusters.

    Rufen Sie zum Identifizieren des Problems die Pod-Logs des vSphere Cloud Controller Manager 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 mit enableControlplaneV2 false: 
            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 mit enableControlplaneV2 true: 
            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.

    Workaround für Upgrades:

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

    • Nutzercluster:
      1. Aktualisieren Sie den Hostnamen der betroffenen Maschine in „user-ip-block.yaml“ zu einem 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. Aktualisieren Sie den Hostnamen der betroffenen Maschine in „admin-ip-block.yaml“ zu einem 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 Passwort $ oder ` enthält:

    • Nutzercluster der Version 1.15 mit aktivierter Steuerungsebene V2 auf Version 1.16 aktualisieren
    • Hochverfügbarkeits-Administratorcluster (HA) von Version 1.15 auf Version 1.16 aktualisieren
    • Nutzercluster der Version 1.16 mit aktivierter Steuerungsebene V2 erstellen
    • 1.16-Hochverfügbarkeits-Administratorcluster erstellen

    Verwenden Sie eine Version von Google Distributed Cloud ab 1.16.4 mit der Fehlerbehebung oder führen Sie die folgende Problemumgehung durch. Welche Lösung Sie wählen, hängt vom fehlgeschlagenen Vorgang ab.

    Workaround 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 eine geringe Wahrscheinlichkeit, dass die Erstellung eines nachfolgenden 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, bei der der vSphere CSI-Controller eine entfernte Maschine nicht aus seinem 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 den Namen der VM-Vorlage, die dem Namen des Computers entspricht, den Sie reparieren, und verwenden Sie den Vorlagennamen im Reparatur-Befehl.
      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.

    Um zu verhindern, dass das Problem noch einmal auftritt, stellen Sie eine Verbindung zur VM her und ändern Sie die Datei /etc/systemd/system/docker.fluent-bit.service. Fügen Sie --log-opt max-size=10m --log-opt max-file=5 in den Docker-Befehl ein 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 eine Aktualisierung (gkectl update admin) eines nicht hochverfügbaren Administratorclusters mit aktiviertem Prüfpunkt durchzuführen, kann das Upgrade oder die Aktualisierung 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 nicht auf eine Patchversion von Google Distributed Cloud mit dem Fix aktualisieren 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:

    Registrierung des Administratorclusters aufheben: 
        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 „Fehler bei der Registrierung des Clusters“. 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:

    Registrierung des Administratorclusters aufheben: 
        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.
    Netzwerk 1.15.0-1.15.2

    OrderPolicy wird nicht als Parameter erkannt und nicht verwendet. Stattdessen verwendet Google Distributed Cloud immer Random.

    Dieses Problem tritt auf, weil die CoreDNS-Vorlage nicht aktualisiert wurde, was dazu führt, dass orderPolicy ignoriert wird.


    Workaround:

    Aktualisieren Sie die CoreDNS-Vorlage und wenden Sie den Fix an. Diese Korrektur bleibt bis zu einem Upgrade erhalten.

    1. Bearbeiten Sie die vorhandene Vorlage: 
      kubectl edit cm -n kube-system coredns-template
       Ersetzen Sie den Inhalt der Vorlage durch Folgendes: 
      coredns-template: |-
  .:53 {
    errors
    health {
      lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
{{- if .PrivateGoogleAccess }}
    import zones/private.Corefile
{{- end }}
{{- if .RestrictedGoogleAccess }}
    import zones/restricted.Corefile
{{- end }}
    prometheus :9153
    forward . {{ .UpstreamNameservers }} {
      max_concurrent 1000
      {{- if ne .OrderPolicy "" }}
      policy {{ .OrderPolicy }}
      {{- end }}
    }
    cache 30
{{- if .DefaultDomainQueryLogging }}
    log
{{- end }}
    loop
    reload
    loadbalance
}{{ range $i, $stubdomain := .StubDomains }}
{{ $stubdomain.Domain }}:53 {
  errors
{{- if $stubdomain.QueryLogging }}
  log
{{- end }}
  cache 30
  forward . {{ $stubdomain.Nameservers }} {
    max_concurrent 1000
    {{- if ne $.OrderPolicy "" }}
    policy {{ $.OrderPolicy }}
    {{- end }}
  }
}
{{- end }}
    Upgrades, 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 die Wahrscheinlichkeit, dass Sie ungültige Zertifikate für Ihren Administratorcluster erhalten, insbesondere für Cluster der Version 1.15.

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

    • Ungültige Zertifikate können 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, Betrieb 1.10, 1.11, 1.12, 1.13, 1.14

    Netzwerk-Gateway-Pods in kube-system haben möglicherweise den Status Pending oder Evicted, wie in der folgenden gekürzten Beispielausgabe zu sehen ist:

    $ 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 Räumungsereignisse oder darauf hin, dass Pods aufgrund von Knotenressourcen nicht geplant werden können. Da Anthos Network Gateway-Pods keine PriorityClass haben, haben sie dieselbe Standardpriorität wie andere Arbeitslasten. Wenn Knoten ressourcenbeschränkt sind, werden die Netzwerk-Gateway-Pods möglicherweise entfernt. Dieses Verhalten ist besonders schlecht für das 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 durch.

    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 Abgleichsprozesses, z. B. bei einem Cluster-Upgrade.

    • 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 Abschnitt gkeConnect 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 Nebenversion von Google Distributed Cloud 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. (Diesen Schritt vor dem Upgrade auf 1.13 ausführen) Achten Sie darauf, dass enableWindowsDataplaneV2: true in der OnPremUserCluster-CR konfiguriert ist. Andernfalls verwendet der Cluster weiterhin Docker für Windows-Knotenpools, 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 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 Ihres KSA-Signaturschlüssels 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. Sie können den Status prüfen: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
    8. Stellen Sie den Validierungs-Webhook für den Nutzercluster wieder her: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremuserclusters
'
    9. Vermeiden Sie eine weitere Rotation des KSA-Signaturschlüssels, bis 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 sein vCenter-Secret nach der vCenter-Zertifikatsrotation aktualisieren. Das aktuelle System startet die Pods von vsphere-csi-controller jedoch nicht richtig neu, sodass vsphere-csi-controller nach der Rotation abstürzt.

    Workaround:

    Für Cluster, die in Version 1.13 und höher erstellt wurden, folgen Sie 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:

    Für Cluster, die in Version 1.12 und höher erstellt wurden, folgen Sie nach der Clustererstellung der Anleitung zum erneuten Registrieren des Administratorclusters. Bei Clustern, die in 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 das Upgrade der Knoten der Nutzersteuerungsebene ein Zeitlimit überschreitet, wird der Administratorcluster nicht mit der aktualisierten Connect-Agent-Version neu registriert.


    Workaround:

    Prüfen Sie, ob der Cluster unter Registrierte Cluster aufgeführt ist. Optional: Melden Sie sich nach der Einrichtung der Authentifizierung beim Cluster an. Wenn der Cluster noch registriert ist, können Sie die folgende Anleitung zum erneuten Registrierungsversuch überspringen. Für Cluster, die auf Version 1.12 und höher aktualisiert wurden, folgen Sie nach der Clustererstellung der Anleitung zum erneuten Registrieren des Administratorclusters. 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.

    Konfiguration 1.15.0

    Für einen Hochverfügbarkeits-Administratorcluster zeigt gkectl prepare diese falsche Fehlermeldung:

    vCenter.dataDisk must be present in the AdminCluster spec

    Workaround:

    Sie können dieses Fehlermeldung einfach ignorieren.
    VMware 1.15.0

    Bei der Erstellung eines Knotenpools, der VM-Host-Affinität verwendet, kann eine Race-Bedingung dazu führen, dass mehrere VM-Host-Affinitätsregeln mit demselben Namen erstellt werden. Dies kann dazu führen, dass die Erstellung des Knotenpools fehlschlägt.


    Workaround:

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

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

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


    Workaround:

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

    Nachdem Sie einen Knoten auf der Steuerungsebene neu erstellt oder aktualisiert haben, können bestimmte Pods aufgrund eines NodeAffinity-Prädikatsfehlers im Failed-Zustand verbleiben. Diese fehlgeschlagenen Pods haben keine Auswirkungen auf den normalen Clusterbetrieb oder den Clusterzustand.


    Workaround:

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

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

    failed to check secret reference for private registry …


    Workaround:

    Bereiten Sie die Anmeldedaten der privaten Registry für den Nutzercluster entsprechend der Anweisungen in Vorbereitete Anmeldedaten konfigurieren vor.

    Upgrades, Updates 1.15.0

    Während gkectl upgrade admin prüft der Preflight-Check des Speichers für die CSI-Migration, ob die StorageClasses keine Parameter haben, die nach der CSI-Migration ignoriert werden. Wenn es beispielsweise eine StorageClass mit dem Parameter diskformat gibt, kennzeichnet gkectl upgrade admin die StorageClass und meldet einen Fehler bei der Preflight-Validierung. Administratorcluster, die in Google Distributed Cloud 1.10 und davor erstellt wurden, haben eine Speicherklasse mit diskformat: thin, bei der diese Validierung fehlschlägt, aber diese Speicherklasse funktioniert nach der CSI-Migration ordnungsgemäß. Diese Fehler sollten stattdessen als Warnungen interpretiert werden.

    Weitere Informationen finden Sie im Abschnitt zu StorageClass-Parametern unter In-Tree-vSphere-Volumes zum vSphere Container Storage Plug-in migrieren.


    Workaround:

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

    Unter bestimmten Bedingungen können Laufwerke als schreibgeschützt an Windows-Knoten angehängt werden. Das entsprechende Volume ist dann in einem Pod schreibgeschützt. Dieses Problem tritt eher auf, wenn eine neue Gruppe von Knoten eine alte Gruppe von Knoten ersetzt, z. B. bei einem Cluster-Upgrade oder einem Knotenpool-Update. 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. Rufen Sie den PowerShell-Zugriff auf den Knoten entweder über SSH oder über die vSphere-Weboberfläche ab.
    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 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 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. Sie können den Roll-out-Status mit dem folgenden Befehl 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

    Unmittelbar nach gkectl upgrade cluster werden die Steuerungsebenen-Pods möglicherweise noch einmal neu bereitgestellt. Der Clusterstatus von gkectl list clusters ändert sich von RUNNING in RECONCILING. Anfragen an den Nutzercluster können Zeitüberschreitungen verursachen.

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

    Dieses Problem tritt nur bei Nutzerclustern auf, die NICHT Controlplane V2 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 fehlerhafte Version und sollte nicht verwendet werden. Die Artefakte wurden aus dem Cloud Storage-Bucket entfernt.

    Workaround:

    Verwenden Sie stattdessen die Version 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 Registrierungsanmeldedaten mit einer der folgenden Methoden aktualisieren:

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

    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 vor dem Erstellen eines Clusters mit einem manuellen Load-Balancer mit dem Befehl gkectl check-config validieren, 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 Load-Balancer-Validierung ü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 sich nicht registrieren
    • 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. In diesen neueren Releases wird die etcd-Version 3.4.21 verwendet. 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 die Option Kubernetes-Container aus.
      2. Wählen Sie im Menü Aktive Messwertkategorien die Option Anthos aus.
      3. Wählen Sie im Menü Aktive Messwerte die Option etcd_network_client_grpc_sent_bytes_total aus.
      4. Klicken Sie auf Anwenden.
    Upgrades, 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 stellen Sie fest, 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. Fahre 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 kube-apiserver-Pods im angegebenen Cluster.

        Administratorcluster:

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

        Nutzercluster:

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

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

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

    Problemumgehung

    Wenn Sie Ihre Cluster nicht sofort aktualisieren können, um das Problem zu beheben, können Sie die betroffenen Pods 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. Prüfen Sie das GKE Identity Service-Log auf den ungültigen Tokenkontext: 
      kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG
    3. Um die mit jedem ungültigen Token-Kontext 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 an den Debugger unter jwt.io.
    5. Starten Sie die anhand der Tokens ermittelten Pods neu.
    Vorgang 1.8, 1.9, 1.10

    Die etcd-Wartungs-Pods, die das etcddefrag:gke_master_etcddefrag_20210211.00_p0-Image verwenden, sind betroffen. Der Container „etcddefrag“ öffnet bei jedem Defragmentierungszyklus eine neue Verbindung zum etcd-Server und die alten Verbindungen werden nicht bereinigt.


    Workaround:

    Option 1: Führen Sie ein Upgrade auf die neuesten Patchversionen von 1.8 bis 1.11 durch, die die Fehlerbehebung enthalten.

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

    kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n kube-system --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    Vorgang 1.9, 1.10, 1.11, 1.12, 1.13

    Sowohl der Cluster-Health-Controller als auch der Befehl gkectl diagnose cluster führen eine Reihe von Systemdiagnosen durch, einschließlich der Systemdiagnosen für Pods in allen Namespaces. Sie beginnen jedoch, die Pods der Steuerungsebene des Nutzers versehentlich zu überspringen. Wenn Sie den Modus „Steuerungsebene V2“ verwenden, hat dies keine Auswirkungen auf Ihren Cluster.


    Workaround:

    Dies hat keine Auswirkungen auf die Verwaltung von Arbeitslasten oder Clustern. Wenn Sie den Status der Steuerungsebenen-Pods prüfen möchten, können Sie die folgenden Befehle ausführen:

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

    1.6- und 1.7-Administratorclusterupgrades können von der k8s.gcr.io -> registry.k8s.io-Weiterleitung betroffen sein

    Kubernetes hat den Traffic von k8s.gcr.io am 20.03.2023 umgeleitet.registry.k8s.io In Google Distributed Cloud 1.6.x und 1.7.x wird für Administratorcluster-Upgrades das Container-Image k8s.gcr.io/pause:3.2 verwendet. Wenn Sie einen Proxy für Ihre Administrator-Workstation verwenden und der Proxy registry.k8s.io nicht zulässt und das Container-Image k8s.gcr.io/pause:3.2 nicht lokal im Cache gespeichert ist, schlagen die Upgrades des Administratorclusters beim Abrufen des Container-Images fehl.


    Workaround:

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

    gkectl create loadbalancer schlägt mit der folgenden 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. Bei der Preflight-Prüfung wird 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

    Die kurzfristige Lösung besteht darin, die Größe der Netfilter-Hashtabelle (nf_conntrack_buckets) und der Netfilter-Verbindungs-Tracking-Tabelle (nf_conntrack_max) zu 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. Wenn Ihr Knoten beispielsweise acht Kerne hat, legen Sie die Tabellengröße auf 524288 fest.
    Netzwerk 1.13.0-1.13.2

    Wenn Controlplane V2 aktiviert ist, werden calico-typha oder anetd-operator möglicherweise für Windows-Knoten geplant und sie geraten in eine Absturzschleife.

    Der Grund dafür ist, dass die beiden Deployments alle Taints tolerieren, einschließlich des Windows-Knoten-Taints.


    Workaround:

    Führen Sie entweder ein Upgrade auf Version 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 die folgende Toleranz hinzu:

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

    Sie können möglicherweise keinen Nutzercluster erstellen, wenn Sie den Abschnitt privateRegistry mit dem Anmeldedatenfeld 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
       (NOTE 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.)

    Vorgänge 1.10+

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

    Im kube-proxy-freien Modus führt dies zu einem Verlust der Verbindung oder zu einem falschen Traffic-Routing für Dienste mit Cloud Service Mesh, da der Sidecar keine Paketprüfung durchführen kann.

    Dieses Problem tritt in allen Versionen von Google Distributed Cloud 1.10 auf. In einigen neueren Versionen von 1.10 (1.10.2+) gibt es jedoch eine Problemumgehung.


    Workaround:

    Führen Sie entweder ein Upgrade auf Version 1.11 durch, um vollständige Kompatibilität zu erhalten, oder führen Sie bei Version 1.10.2 oder höher Folgendes aus:

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

    Fügen Sie bpf-lb-sock-hostns-only: true der ConfigMap hinzu und starten Sie das anetd-DaemonSet neu:

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

    Speicher 1.12+, 1.13.3

    kube-controller-manager 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 auf dem Knoten an und führen Sie die folgenden Befehle aus, um das Problem zu überprü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 ihn 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+

    Für den über gkectl repair admin-master erstellten Admin-Masterknoten wird möglicherweise eine niedrigere VM-Hardwareversion als erwartet verwendet. 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+, , 1.28+, 1.29+, 1.30+, 1.31+, 1.32+

    In systemd v244 wurde das Standardverhalten von systemd-networkd in der KeepConfiguration-Konfiguration geändert. 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.

    Beispiele:

    • 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 von calico-node-Fehler 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 oder Neustart nicht an den DHCP-Server zurück. Die IPs werden automatisch vom DHCP-Server freigegeben, wenn die Leases ablaufen. 

          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 admin-cluster-creds-Secret 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:

    • Fehler bei der Preflight-Prüfung der langsamen Validierung mit der Fehlermeldung: "Failed to create the test VMs: failed to get service account key: service account is not configured."
    • Die Vorbereitung durch gkectl prepare ist mit der folgenden Fehlermeldung fehlgeschlagen: "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).


    Behelfslösung:

    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 aktivierter Controlplane V2 erstellt wurden, verwenden Knotenpools mit aktiviertem Autoscaling immer ihre autoscaling.minReplicas in der user-cluster.yaml. Das Log des Cluster-Autoscaling-Pods enthält einen Fehler wie den folgenden: 

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

    Autoscaling in allen Knotenpools mit „gkectl update cluster“ deaktivieren, bis ein Upgrade auf eine Version mit dem Fix erfolgt ist
    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


    Behelfslösung:

    Nehmen Sie einzelne IPs in die IP-Blockdatei auf, bis Sie ein Upgrade auf eine Version mit dem Fix durchführen: 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 mit enableControlplaneV2 auf true festgelegt wurde, wird die Neuerstellung der Maschinen der Nutzersteuerungsebene möglicherweise nicht abgeschlossen, wenn der Befehl gkectl abgeschlossen ist.


    Behelfslösung:

    Warten Sie nach Abschluss des Updates, bis die Neuerstellung der Maschinen der Nutzersteuerungsebene abgeschlossen ist. Überwachen Sie dazu die Betriebssystem-Image-Typen der Knoten mit kubectl --kubeconfig USER_KUBECONFIG get nodes -owide. Wenn Sie beispielsweise von Ubuntu auf COS aktualisieren, sollten Sie warten, bis alle Maschinen der Steuerungsebene vollständig von Ubuntu auf COS umgestellt wurden, auch nachdem der Aktualisierungsbefehl abgeschlossen ist.

    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

    Die Clustererstellung schlägt fehl, obwohl der Nutzer die richtige Konfiguration hat. Der Nutzer sieht, dass die Erstellung fehlschlägt, weil der Cluster nicht genügend IP-Adressen hat.


    Workaround:

    Teilen Sie CIDR-Blöcke in mehrere kleinere CIDR-Blöcke auf, z. B. 10.0.0.0/30 wird 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.

    Vorgang, Upgrades, Aktualisierungen 1.11.0 - 1.11.1, 1.10.0 - 1.10.4, 1.9.0 - 1.9.6

    Wenn die Always-On-Secrets-Verschlüsselung zusammen mit der Clustersicherung aktiviert ist, enthält die Sicherung des Administratorclusters nicht die Verschlüsselungsschlüssel und die Konfiguration, die für die Always-On-Secrets-Verschlüsselung erforderlich sind. Wenn Sie den Admin-Master mit dieser Sicherung mithilfe von gkectl repair admin-master --restore-from-backup reparieren, tritt der folgende Fehler auf: 

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

    Vorgang, Upgrades, Aktualisierungen 1.10+

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

    Upgrades, Updates 1.10

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

    Das disk_label wurde aus MachineTemplate.spec.template.spec.providerSpec.machineVariables entfernt, was unerwartet ein Update auf allen MachineDeployments ausgelöst hat.


    Workaround:
    Upgrades, Updates 1.10.0

    Das Aktualisieren des Nutzerclusters auf Version 1.10.0 kann dazu führen, dass Docker häufig neu gestartet wird.

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

    Anhand des Knotenzustands lässt sich erkennen, ob Docker häufig neu gestartet wird. Hier ein Beispiel für eine Ausgabe:

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

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


    Workaround:
    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 GMP-Komponenten vor dem Upgrade auf Version 1.12 manuell im Namespace bereitstellen, werden die Ressourcen von stackdriver gelöscht.


    Workaround:
    Vorgang 1.11, 1.12, 1.13.0 - 1.13.1

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

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


    Workaround:

    Sie können die folgenden Befehle manuell ausführen, um die Debugging-Informationen 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 das Leeren von Knoten in den folgenden Szenarien hängen bleiben:

    • Der Administratorcluster verwendet seit Version 1.12.x den vSphere-CSI-Treiber auf vSAN.
    • Es werden keine PVC-/PV-Objekte von In-Tree-vSphere-Plug-ins im Administrator- und Nutzercluster erstellt.

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

    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 vSphere-In-Tree-Treiber. Wenn keine PVC-/PV-Objekte erstellt werden, kann es zu einem Fehler kommen, bei dem das Node-Drain-Verfahren beim Suchen nach kubevols hängen bleibt, da in der aktuellen Implementierung davon ausgegangen wird, dass kubevols immer vorhanden ist.


    Workaround:

    Erstellen Sie das Verzeichnis kubevols im Datenspeicher, in dem der Knoten erstellt wird. Dies ist in den Dateien user-cluster.yaml oder admin-cluster.yaml im Feld vCenter.datastore definiert.
    Konfiguration 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14

    Wenn ein Nutzercluster gelöscht wird, werden auch die entsprechenden clusterrole- und clusterrolebinding-Objekte für Cluster Autoscaler gelöscht. Dies betrifft alle anderen Nutzercluster im selben Administratorcluster, für die die automatische Clusterskalierung aktiviert ist. Das liegt daran, dass für alle Cluster-Autoscaler-Pods im selben Administratorcluster dieselbe ClusterRole und dasselbe ClusterRoleBinding 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:

    Konfiguration 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

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

    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:

    Konfiguration 1.12.1-1.12.3, 1.13.0-1.13.2

    Ein bekanntes Problem, das dazu führen kann, dass gkectl check-config fehlschlägt, ohne dass gkectl prepare ausgeführt wird. Das ist verwirrend, da wir empfehlen, den Befehl vor 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 Betriebssystemimages zu überspringen.
    Upgrades, Updates 1.11, 1.12, 1.13

    Ein bekanntes Problem, das dazu führen kann, dass gkectl update admin/cluster beim Aktualisieren von anti affinity groups fehlschlägt.

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

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

    Workaround:
    Installation, Upgrades, 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 ausstehende CSRs für einen Knoten aufzurufen:

    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 für den Nutzercluster 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. Manifestdatei kube-controller-manager im Adminbereich der Cluster-Steuerungsebene bearbeiten:
      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 auf false: 
      --node-id-verification-enabled=false
--node-id-verification-csr-signing-enabled=false
    Installation, Upgrades, Updates 1.11.0-1.11.4

    Das Erstellen/Upgrade des Administratorclusters bleibt dauerhaft im folgenden Log hängen und schließlich tritt eine Zeitüberschreitung auf:

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

    In der Version 1.11 der Dokumentation enthält das Log des Cluster-API-Controllers im externen Cluster-Snapshot das folgende Log:

    Invalid value 'XXXX' specified for property startup-data

    Hier ist ein Beispiel für einen Dateipfad für das Log des Cluster-API-Controllers:

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

    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 weitere Floating-IP-Adressen zuweist. Dies kann zu einer höheren Belastung anderer Knoten oder zu einem Mangel an Redundanz für hohe Verfügbarkeit führen.

    Die Datenebene ist davon 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 Verarbeitung von Wiederholungsversuchen wurde in späteren Versionen behoben.


    Workaround:

    Führen Sie ein Upgrade auf eine korrigierte Version durch, wenn diese verfügbar ist.
    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 betrifft alle Rolling Update-Vorgänge für Knotenpools.

    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 den clusterapi-controller-Pod-Logs sehen die Fehler so aus:

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

    Der Fehler 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 beim Entfernen des Finalizers hängen, da andere Controller sehr häufig aktualisiert werden. 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 mehrere verschiedene Optionen zur Behebung dieses Problems vorbereitet, die von Ihrer Umgebung und Ihren Anforderungen abhängen.

    • Option 1: Warten Sie, 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 länger, bis die Umstellung abgeschlossen ist.
    • Option 2: Annotation zur automatischen Reparatur 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 werden, anstatt sie zu entfernen. 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

    Der Befehl gkectl prepare ist fehlgeschlagen:

    - 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 geheimen 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.
    Upgrades, Updates 1.10, 1.11

    Wenn die Maschine der Administratorsteuerungsebene nach einem fortgesetzten Upgradeversuch des Administratorclusters nicht neu erstellt wird, wird die VM-Vorlage der Administratorsteuerungsebene gelöscht. Die VM-Vorlage der Administratorsteuerungsebene ist die Vorlage des Admin-Masters, die zur Wiederherstellung der Steuerungsebene mit gkectl repair admin-master genutzt wird.


    Workaround:

    Die VM-Vorlage der Administratorsteuerungsebene wird beim nächsten Upgrade des Administratorclusters neu generiert.
    Betriebssystem 1.12, 1.13

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


    Workaround:

    In Version 1.12.1 haben wir wieder auf cgroup v1 (Hybrid) umgestellt. 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:
    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-Versionen 7.0U2 und höher behoben.
    2. Klicken Sie bei älteren Versionen mit der rechten Maustaste auf den Host und wählen Sie Verbindung > Trennen aus. 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 einer 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

    Stellen Sie sicher, dass Sie Ihre SSH-Sitzung neu 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-Bereitstellungen 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 Ausstellerressourcen metrics-pki.cluster.local 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-Bereitstellungen 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 Ausstellerressourcen metrics-pki.cluster.local 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.
    Betriebssystem 1.7, 1.8, 1.9, 1.10, 1.11

    Ab Google Distributed Cloud Version 1.7.2 werden die Ubuntu-Betriebssystem-Images mit CIS L1 Server Benchmark gehärtet.

    Daher wurde das Cron-Skript /etc/cron.daily/aide installiert, damit eine aide-Prüfung geplant wird. Auf diese Weise wird die Einhaltung der CIS-L1-Serverregel „1.4.2 Dateisystemintegrität muss regelmäßig geprüft werden” sichergestellt.

    Der Cronjob wird täglich um 6:25 Uhr UTC ausgeführt. Abhängig von der Anzahl der Dateien im Dateisystem kann es zu dieser Zeit zu CPU- und Speicherauslastungsspitzen kommen, die durch den aide-Prozess verursacht werden.


    Workaround:

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

    sudo chmod -x /etc/cron.daily/aide
    Netzwerk 1.10, 1.11, 1.12, 1.13

    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 in der Dokumentation zur Version 1.13 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 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. Diese Annotation kann auch durch die Installation von Cloud Service Mesh hinzugefügt werden.

    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 steuern, indem Sie das Flag enableCloudLoggingForApplications bzw. enableGMPForApplications verwenden.

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

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

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

    Wenn Sie nicht von der anmerkungsbasierten Messwertsammlung wegwechseln können, führen Sie die folgenden Schritte aus:

    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.9.0-1.9.4, 1.10.0-1.10.1

    Selbst in einem neuen Cluster ohne Nutzer-Arbeitslasten kann es zu hohem Netzwerk-Traffic für monitoring.googleapis.com kommen.

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


    Workaround:
    Logging und Monitoring 1.10, 1.11

    Bei Google Distributed Cloud Version 1.10 und höher hat das DaemonSet `gke-metrics-agent` häufige CrashLoopBackOff-Fehler, wenn `enableStackdriverForApplications` im Objekt `stackdriver` auf „true“ gesetzt ist.


    Workaround:

    Deaktivieren Sie zur Behebung dieses Problems die Erfassung von Anwendungsmesswerten mit den folgenden Befehlen. Durch diese Befehle wird die Erfassung von Anwendungslogs nicht deaktiviert.

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

    Wenn in Ihren Standard-Dashboards eingestellte Messwerte verwendet werden, sind einige Diagramme leer. 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 durch die Schritte 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 wurden: 
      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 wurden.
    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+, v1.12.1+ oder v1.13+ 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 dem Fix.
    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:
    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 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. Diese Fehlermeldung wird beispielsweise angezeigt, wenn Sie den folgenden Test-Pod bereitstellen:

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

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

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

    Workaround:
    Upgrades, Updates 1.10, 1.11, 1.12, 1.13

    Knotenpool-Replikate werden nicht aktualisiert, nachdem die automatische Skalierung 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 Messwerte für Windows-Knoten und ‑Pods 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 beschädigte Chunks 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 Cleanup-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. stackdriver-log-forwarder fortsetzen:
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    Logging und Monitoring 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

    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-Agent 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 wurden: 
      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 wurden.
    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 während dieser Zeit nicht verfügbar. Das liegt daran, dass es einige Zeit dauert, bis die aktualisierten gültigen IPs des Knotens für den neuen Serverzertifikatsgenehmiger sichtbar sind.

    Dieses Problem betrifft nur das kubelet-Serverzertifikat und hat keine Auswirkungen auf die Pod-Planung.
    Upgrades, Updates 1.12

    Das Upgrade des Nutzerclusters ist fehlgeschlagen. Fehler:

    .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 weiterhin 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 Löschvorgang für den Nutzercluster kann aus irgendeinem Grund hängen bleiben, was zu einer Ungültigkeit der MetalLB-ConfigMap führt. Es ist nicht möglich, einen neuen Nutzercluster mit diesem Status hinzuzufügen.


    Workaround:

    Sie können das Löschen Ihres 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 bei:

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

    Die für den Nutzercluster check-config erstellte Test-VM verwendet standardmäßig den gleichen osImageType wie der Administratorcluster, und 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:
    Sonstiges 1.11.3

    Der Befehl gkectl repair admin-master ist fehlgeschlagen: 

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

    gkectl repair admin-master kann die VM-Vorlage nicht abrufen, die für die Reparatur der VM der Administratorsteuerungsebene verwendet werden soll, wenn der Name der VM der Administratorsteuerungsebene mit den Zeichen t, m, p oder l endet.


    Workaround:

    Führen Sie den Befehl noch einmal mit --skip-validation aus.
    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. So hat der Administratorcluster die erforderlichen Berechtigungen.

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

    Workaround:
    Betrieb, Sicherheit 1.11

    Wenn Ihre Workstation keinen Zugriff auf Worker-Knoten des Nutzerclusters hat, kommt es bei der Ausführung zu folgenden Fehlern: gkectl diagnose:

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

    Wenn Ihre Workstation keinen Zugriff auf Administratorcluster-Worker-Knoten hat, kommt es bei der Ausführung von gkectl diagnose zu folgenden Fehlern:

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

    Workaround:

    Sie können diese Meldungen bedenkenlos ignorieren.
    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 Dadurch bleiben alle Audit-Regeln auf der Festplatte erhalten.


    Workaround:
    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. Webhook-Konfiguration bearbeiten: 
      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 Ihr NetworkGatewayGroup-Objekt.
    5. Wenden Sie wieder die ursprüngliche Webhook-Konfiguration an: 
      kubectl -n kube-system apply -f webhook-config.yaml
    Installation, Upgrades, Updates 1.10.0-1.10.2

    Während eines Upgrade-Versuchs des Administratorclusters kann die VM der Administrator-Steuerungsebene bei der Erstellung hängen bleiben. Die VM der Administrator-Steuerungsebene gerät während des Bootvorgangs in eine unendliche Warteschleife, und in der /var/log/cloud-init-output.log-Datei wird der folgende Endlosschleifenfehler angezeigt:

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

    Das liegt daran, dass Google Distributed Cloud bei dem Versuch, die IP-Adresse des Knotens im Startscript abzurufen, grep -v ADMIN_CONTROL_PLANE_VIP verwendet, um die VIP der Administratorcluster-Steuerungsebene zu überspringen, die auch der NIC zugewiesen werden kann. Der Befehl überspringt jedoch auch jede IP-Adresse, die ein Präfix der VIP der Steuerungsebene hat, was dazu führt, dass das Startscript hängen bleibt.

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


    Workaround:

    • Wenn der Grund für die Zeitüberschreitung bei der Erstellung des Administratorclusters auf die Broadcast-IP-Adresse zurückzuführen ist, führen Sie den folgenden Befehl auf der VM der Steuerungsebene des Administratorclusters aus: 
      ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
       Dadurch wird eine Zeile ohne Sendeadresse erstellt und die Blockierung des Startvorgangs aufgehoben. Entfernen Sie diese hinzugefügte Zeile, nachdem das Startscript entsperrt wurde, indem Sie den folgenden Befehl ausführen: 
      ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
    • Wenn der Grund für die Zeitüberschreitung bei der Erstellung des Administratorclusters jedoch auf die IP-Adresse der VM der Steuerungsebene zurückzuführen ist, können Sie die Blockierung des Startscripts nicht aufheben. Wechseln Sie zu einer anderen IP-Adresse und erstellen Sie die Version 1.10.3 neu oder aktualisieren Sie auf diese.
    Betriebssystem, Upgrades, Updates 1.10.0-1.10.2

    DataDisk kann bei Verwendung des COS-Images nicht korrekt im Master-Knoten des Administratorclusters bereitgestellt werden und der Zustand des Administratorclusters, der das COS-Image verwendet, geht bei einem Upgrade des Administratorclusters oder einer Reparatur des Administratormasters verloren. (Administratorcluster mit COS-Image ist eine Funktion in der Vorabversion)


    Workaround:

    Administratorcluster mit osImageType auf ubuntu_containerd neu erstellen

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

    In Google Distributed Cloud 1.10.0 werden Namensauflösungen unter Ubuntu standardmäßig an das lokale systemd-resolved weitergeleitet, das 127.0.0.53 überwacht. Der Grund dafür ist, dass /etc/resolv.conf im Ubuntu 20.04-Image, das in Version 1.10.0 verwendet wird, symmetrisch mit /run/systemd/resolve/stub-resolv.conf verknüpft ist, was auf den 127.0.0.53-localhost-DNS-Stub verweist.

    Daher lehnt die localhost-DNS-Namensauflösung die Überprüfung der vorgelagerten DNS-Server (in /run/systemd/resolve/resolv.conf) nach Namen mit dem Suffix .local ab, es sei denn, die Namen werden als Suchdomains angegeben.

    Dies führt dazu, dass alle Lookups nach .local-Namen fehlschlagen. Beispiel: Beim Knotenstart schlägt kubelet beim Abrufen von Images aus einer privaten Registry mit dem Suffix .local fehl. Die Angabe einer vCenter-Adresse mit dem Suffix .local funktioniert auf einer Administratorworkstation nicht.


    Workaround:

    Sie können dieses Problem für Clusterknoten vermeiden. Dazu geben Sie das Feld searchDomainsForDNS in der Konfigurationsdatei des Administratorclusters und der Konfigurationsdatei des Nutzerclusters an, um die Domains einzubeziehen.

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

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

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

    Wie auch für die Administrator-Workstation unterstützt gkeadm die Angabe von Suchdomains nicht; daher muss dieses Problem mit diesem manuellen Schritt umgangen werden.

    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.
    Installation, Betriebssystem 1.10

    Google Distributed Cloud gibt ein dediziertes Subnetz für die Brücken-IP-Adresse von Docker an, die --bip=169.254.123.1/24 verwendet. Das Standard-Subnetz 172.17.0.1/16 wird somit nicht reserviert. In der Version 1.10.0 liegt jedoch ein Fehler im Ubuntu-Betriebssystem-Image vor, der dazu führte, dass die benutzerdefinierte Docker-Konfiguration ignoriert wurde.

    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:

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

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

sudo systemctl daemon-reload

sudo systemctl restart docker

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

    ip a | grep docker0

    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.
    Upgrades, Updates 1.11

    In Google Distributed Cloud 1.11.0 gibt es Änderungen bei der Definition benutzerdefinierter Ressourcen in Bezug auf Logging und Monitoring:

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

    Die Änderungen am Gruppennamen erfolgen, um die CustomResourceDefinition-Updates in Kubernetes 1.22 zu berücksichtigen.

    Wenn Sie keine zusätzliche Logik haben, die die betroffenen benutzerdefinierten Ressourcen anwendet oder bearbeitet, sind keine Maßnahmen erforderlich. Beim Google Distributed Cloud-Upgrade werden die betroffenen Ressourcen migriert und ihre vorhandenen Spezifikationen bleiben nach der Änderung des Gruppennamens erhalten.

    Wenn Sie jedoch Logik ausführen, die die betroffenen Ressourcen anwendet oder bearbeitet, ist besondere Vorsicht geboten. Zuerst müssen sie in Ihrer Manifestdatei mit dem neuen Gruppennamen referenziert werden. Beispiel:

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

    Zweitens müssen die Spezifikationswerte für resourceAttrOverride und storageSizeOverride vom Typ „String“ sein. Beispiel:

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

    Andernfalls werden die Änderungen nicht übernommen und es kann zu einem unerwarteten Status in den Logging- und Monitoring-Komponenten kommen. Mögliche Symptome:

    • Logs zu Abgleichsfehlern in onprem-user-cluster-controller, z. B.: 
      potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1}
    • Fehler in kubectl edit stackdriver stackdriver, z. B.: 
      Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found

    Wenn die oben genannten Fehler auftreten, bedeutet das, dass vor dem Upgrade bereits ein nicht unterstützter Typ in der Stackdriver-CR-Spezifikation vorhanden war. Als Workaround können Sie die Stackdriver-CR unter dem alten Gruppennamen kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver manuell bearbeiten und Folgendes tun:

    1. Ändern Sie die Ressourcenanforderungen und -limits in den Stringtyp.
    2. Entfernen Sie alle addons.gke.io/migrated-and-deprecated: true-Anmerkungen, sofern vorhanden.
    Setzen Sie dann das Upgrade fort oder starten Sie es neu.

    Betriebssystem 1.7 and later

    Wenn ein Fehler auf einem ESXi-Server auftritt und die vCenter HA-Funktion für den Server aktiviert wurde, wird für alle VMs auf dem fehlerhaften ESXi-Server der vMotion-Mechanismus ausgelöst und sie werden auf einen anderen normalen ESXi-Server verschoben. Migrierte COS-VMs verlieren ihre IP-Adressen.

    Workaround:

    VM neu starten
    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 nach der Wiederherstellung eines Split-Brain-Szenarios (aufgrund von VRRP-Paketverlusten) zu längeren Dienstausfallzeiten führen.

    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

    Nächste Schritte

    Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.

    Weitere Informationen zu Supportressourcen finden Sie unter Support. Dazu gehören: