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

Auf dieser Seite werden alle bekannten Probleme für Google Distributed Cloud on VMware aufgeführt. Wenn Sie die bekannten Probleme nach einer Produktkategorie oder -kategorie filtern möchten, wählen Sie die gewünschten Filter aus den folgenden Drop-down-Menüs aus.

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

Wählen Sie die Problemkategorie aus:

Sie können auch nach Ihrem Problem suchen:

Kategorie Erkannte Version(en) Problem und Behelfslösung
Upgrades 1,16, 1,28, 1,29

Upgrade des CPV2-Nutzerclusters hängt aufgrund der gespiegelten Maschine mit deletionTimestamp fest

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

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

Dieses Problem kann auftreten, wenn Sie zuvor versucht haben, den Knoten der Nutzersteuerungsebene zu reparieren, indem Sie gkectl delete machine auf dem gespiegelten Computer im Nutzercluster ausgeführt haben.

Workaround:

  1. Rufen Sie das gespiegelte Maschinenobjekt ab und speichern Sie es zu Sicherungszwecken in einer lokalen Datei.
  2. Führen Sie den folgenden Befehl aus, um den Finalizer vom gespiegelten Computer zu löschen, und warten Sie, bis er aus dem Nutzercluster gelöscht wird. 
        kubectl --kubeconfig ADMIN_KUBECONFIG patch machine/MACHINE_OBJECT_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge
  3. Führen Sie die Schritte unter Knoten der Steuerungsebene des Nutzerclusters von Steuerungsebene V2 aus, um die Knotenreparatur auf den Knoten der Steuerungsebene auszulösen. Dadurch wird die richtige Spezifikation der Quellmaschine wieder mit dem Nutzercluster synchronisiert.
  4. Führen Sie gkectl upgrade cluster noch einmal aus, um das Upgrade fortzusetzen
Konfiguration, Installation 1,15, 1,16, 1,28, 1,29

Fehler bei der Clustererstellung aufgrund von virtueller IP-Adresse der Steuerungsebene in einem anderen Subnetz

Für den Hochverfügbarkeits-Administratorcluster oder den Nutzercluster der ControlPlane V2 muss sich die virtuelle IP-Adresse der Steuerungsebene im selben Subnetz wie andere Clusterknoten befinden. Andernfalls schlägt die Clustererstellung fehl, da kubelet nicht über die virtuelle IP-Adresse der Steuerungsebene mit dem API-Server kommunizieren kann.

Workaround:

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

Fehler bei der Clustererstellung/-upgrades aufgrund eines vCenter-Nutzernamens ohne FQDN

Die Clustererstellung bzw. das Clusterupgrade schlägt mit einem Fehler in vsphere-CSI-Pods fehl, der darauf hinweist, dass der vCenter-Nutzername ungültig ist. Der Grund dafür ist, 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 erst ab Version 1.29 auf, da dem vSphere-CSI-Treiber eine Validierung hinzugefügt wurde, um die Verwendung voll qualifizierter Domain-Nutzernamen zu erzwingen.

Workaround:

Verwenden Sie in der Konfigurationsdatei für Anmeldedaten einen voll qualifizierten Domainnamen für den vCenter-Nutzernamen. Verwenden Sie beispielsweise „nutzername1@beispiel.de“ statt „nutzername1“.
Upgrades, Updates 1.28.0–1.28.500

Das Administratorclusterupgrade für Cluster, die mit Version 1.10 oder niedriger erstellt wurden, schlägt fehl

Wenn Sie einen Administratorcluster von 1.16 auf 1.28 aktualisieren, kann das Bootstrap der neuen Administrator-Master-Maschine möglicherweise das Zertifikat der Steuerungsebene nicht generieren. Das Problem wird durch Änderungen an der Generierung von Zertifikaten für den Kubernetes API-Server ab Version 1.28 verursacht. Das Problem wird bei Clustern reproduziert, die unter Version 1.10 und niedriger erstellt wurden und bis auf Version 1.16 aktualisiert wurden und das untergeordnete Zertifikat vor dem Upgrade nicht rotiert wurde.

Führen Sie die folgenden Schritte aus, um festzustellen, ob der Fehler beim Upgrade des Administratorclusters durch dieses Problem verursacht wird:

  1. Stellen Sie über SSH eine Verbindung zur ausgefallenen Administrator-Master-Maschine her.
  2. Öffnen Sie /var/log/startup.log und suchen Sie nach einem Fehler wie dem folgenden:
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 über SSH eine Verbindung zur Administrator-Master-Maschine her. Weitere Informationen finden Sie unter SSH-Verbindung zu einem Administratorclusterknoten herstellen.
  2. /etc/startup/pki-yaml.sh bearbeiten Suchen Sie nach authorityKeyIdentifier=keyidset und ändern Sie es in den Abschnitten für die folgenden Erweiterungen zu authorityKeyIdentifier=keyid,issuer: 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
  3. Speichern Sie die Änderungen in /etc/startup/pki-yaml.sh.
  4. Führen Sie /opt/bin/master.sh aus, um das Zertifikat zu generieren und den Computerstart abzuschließen.
  5. Führen Sie gkectl upgrade admin noch einmal aus, um den Administratorcluster zu aktualisieren.
  6. Nach Abschluss des Upgrades rotieren Sie das untergeordnete Zertifikat sowohl für Administrator- als auch für Nutzercluster, wie unter Rotation starten beschrieben.
  7. Nehmen Sie nach Abschluss der Zertifikatsrotation die gleichen Änderungen an /etc/startup/pki-yaml.sh wie zuvor vor und führen Sie /opt/bin/master.sh aus.
Konfiguration 1.29.0

Falsche Warnmeldung für Cluster mit aktiviertem Dataplane V2

Die folgende falsche Warnmeldung wird ausgegeben, wenn Sie gkectl ausführen, um einen Cluster zu erstellen, zu aktualisieren oder zu aktualisieren, für den Dataplane V2 bereits aktiviert ist:

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.

gkectl enthält einen Programmfehler, der dazu führt, dass diese Warnung immer angezeigt wird, solange dataplaneV2.forwardMode nicht verwendet wird, auch wenn Sie bereits enableDataplaneV2: true in der Clusterkonfigurationsdatei festgelegt haben.

Workaround:

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

Die Preflight-Prüfung für die HA-Administrator-Clusterinstallation meldet eine falsche Anzahl von erforderlichen statischen IP-Adressen

Wenn Sie einen Administratorcluster für hohe Verfügbarkeit erstellen, zeigt die Preflight-Prüfung die folgende falsche Fehlermeldung an:

- 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 Administratorcluster mit hoher Verfügbarkeit ab 1.28 nicht korrekt, da diese keine Add-on-Knoten mehr haben. Da die 3 IP-Adressen der Knoten-IP-Adressen des Administratorclusters in der Konfigurationsdatei des Administratorclusters im Abschnitt network.controlPlaneIPBlock angegeben sind, werden die IP-Adressen in der IP-Blockdatei nur für Knoten der kubeception-Nutzercluster-Steuerungsebene benötigt.

Workaround:

Wenn Sie die falsche Preflight-Prüfung in einem nicht festen Release überspringen möchten, fügen Sie --skip-validation-net-config in den Befehl gkectl ein.
Vorgang 1.29.0-1.29.100

Connect Agent verliert die Verbindung zu Google Cloud nach der Migration von Administratorclustern ohne Hochverfügbarkeit von Hochverfügbarkeit

Wenn Sie von einem Administratorcluster ohne Hochverfügbarkeit zu einem Administratorcluster mit Hochverfügbarkeit migriert haben, verliert der Connect-Agent im Administratorcluster die Verbindung zu gkeconnect.googleapis.com mit dem Fehler „JWT-Signatur konnte nicht verifiziert werden“. Das liegt daran, dass der KSA-Signaturschlüssel während der Migration geändert wird. Daher ist eine erneute Registrierung erforderlich, um die OIDC-JWKs zu aktualisieren.

Workaround:

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

Rufen Sie zuerst den Bereitstellungsnamen gke-connect ab:

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

Löschen Sie das Deployment gke-connect:

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

Lösen Sie einen erzwungenen Abgleich für den onprem-admin-cluster-controller aus, indem Sie der Antwortvorlage onpremadmincluster eine Anmerkung „erzwungener Abgleich“ 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"
'

Die Idee dahinter ist, dass onprem-admin-cluster-controller die gke-connect-Bereitstellung immer noch einmal bereitstellt und den Cluster noch einmal registriert, wenn keine vorhandene gke-connect-Bereitstellung verfügbar ist.

Nach der Problemumgehung (es kann einige Minuten dauern, bis der Abgleich durch den Controller abgeschlossen ist) können Sie prüfen, ob der 400-Fehler „JWT konnte nicht verifiziert werden“ aus den gke-connect-agent-Logs entfernt wurde:

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

Die IP-Adresse der Docker-Bridge verwendet 172.17.0.1/16 für Knoten der COS-Cluster-Steuerungsebene

Google Distributed Cloud gibt in der Docker-Konfiguration das dedizierte Subnetz --bip=169.254.123.1/24 für die Docker-Bridge-IP-Adresse an, um zu verhindern, dass das standardmäßige Subnetz 172.17.0.1/16 reserviert wird. In den Versionen 1.28.0 bis 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. Daher wählt Docker die Standard-172.17.0.1/16 als Subnetz der Bridge-IP-Adresse aus. Dies kann zu einem IP-Adresskonflikt führen, wenn in diesem IP-Adressbereich bereits eine Arbeitslast ausgeführt wird.

Workaround:

Starten Sie den Docker-Dienst neu, um dieses Problem zu umgehen:

sudo systemctl restart docker

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

ip a | grep docker0

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

Die Verwendung mehrerer Netzwerkschnittstellen mit Standard-CNI funktioniert nicht

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

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

Workaround:

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

NetApp-Trident-Abhängigkeiten beeinträchtigen den vSphere-CSI-Treiber

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

Workaround:

  • multipathd deaktivieren
Updates 1,15; 1,16

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

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

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

Workaround:

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

Das Feld controlPlaneNodePort wird standardmäßig auf 30.968 gesetzt, wenn die Spezifikation manualLB leer ist.

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

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

Workaround:

Geben Sie 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

nfs-common fehlt im Ubuntu-Betriebssystem-Image, was bei Kunden, die NFS-abhängige Treiber wie NetApp verwenden, Probleme verursachen kann.

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

Workaround:

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

Das Feld für die Speicherrichtlinie fehlt in der Konfigurationsvorlage des Administratorclusters

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

Workaround:

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

Die Kubernetes Metadata API unterstützt VPC-SC nicht

Die kürzlich hinzugefügte API „kubernetesmetadata.googleapis.com“ unterstützt VPC-SC nicht. Dies führt dazu, dass der Agent zum Erfassen von Metadaten diese API unter VPC-SC nicht erreicht. In der Folge fehlen Labels für Messwertmetadaten.

Workaround:

Im Namespace „kube-system“ wurde das Feld „featureGates.disableExperimentalMetadataAgent“ durch Ausführung des folgenden Befehls auf „true“ gesetzt.

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

dann ausführen

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

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

Der Clusterapi-Controller kann abstürzen, wenn der Administratorcluster und jeder Nutzercluster mit aktivierter ControlPlane V2 unterschiedliche vSphere-Anmeldedaten verwenden

Wenn ein Administratorcluster und ein Nutzercluster mit aktivierter ControlPlane V2 unterschiedliche vSphere-Anmeldedaten verwenden, z.B. nach dem Aktualisieren von vSphere-Anmeldedaten für den Administratorcluster, kann der Clusterapi-Controller nach dem Neustart möglicherweise keine Verbindung zu 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 die vSphere-Anmeldedaten, damit der Administratorcluster und alle Nutzercluster mit aktivierter Steuerungsebene V2 dieselben vSphere-Anmeldedaten verwenden.

Logging und Monitoring 1,14

etcd: hohe Anzahl fehlgeschlagener GRPC-Anfragen im Prometheus-Benachrichtigungsmanager

Prometheus könnte in etwa folgende Benachrichtigungen melden:

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

Mit den folgenden Schritten können Sie prüfen, ob diese Benachrichtigung falsch positiv ist und ignoriert werden kann:

  1. Vergleichen Sie den Rohmesswert grpc_server_handled_total mit dem in der Benachrichtigung angegebenen grpc_method. Prüfen Sie in diesem Beispiel das Label grpc_code für Watch.

    Sie können diesen Messwert in Cloud Monitoring mit der folgenden MQL-Abfrage prüfen:
    fetch
    k8s_container | metric 'kubernetes.io/anthos/grpc_server_handled_total' | align rate(1m) | every 1m
  2. Eine Benachrichtigung zu allen Codes außer OK kann ignoriert werden, wenn der Code nicht einer der folgenden ist:
    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. Über die Benutzeroberfläche des Benachrichtigungsmanagers können Sie die Benachrichtigung stummschalten.
  2. Wenn Sie die Benachrichtigung nicht stummschalten können, führen Sie die folgenden Schritte aus, um falsch positive Ergebnisse zu unterdrücken:
    1. Skalieren Sie den Monitoring-Operator auf 0 Replikate herunter, damit die Änderungen bestehen bleiben.
    2. Ändern Sie die ConfigMap prometheus-config und fügen Sie grpc_method!="Watch" zur etcdHighNumberOfFailedGRPCRequests-Benachrichtigungskonfiguration hinzu, wie im folgenden Beispiel gezeigt:
      • Original: 
        rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code!="OK",job=~".*etcd.*"}[5m])
      • Geändert: 
        rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code=~"Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded",grpc_method!="Watch",job=~".*etcd.*"}[5m])
        Ersetzen Sie die folgende CLUSTER_NAME durch den Namen Ihres Clusters.
    3. Starten Sie Prometheus und Alertmanager Statefulset neu, um die neue Konfiguration zu übernehmen.
  3. Wenn der Code in einen der problematischen Fälle fällt, prüfen Sie das etcd-Log und das kube-apiserver-Log, um weitere Fehler zu beheben.
Netzwerk 1.16.0–1.16.2, 1.28.0

Langlebige ausgehende NAT-Verbindungen werden getrennt

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

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

Dieses Problem tritt auf, weil die automatische automatische Speicherbereinigung unbeabsichtigt Conntrack-Einträge entfernt, die der Daemon als nicht verwendet einstuft. Vor Kurzem wurde eine Upstream-Korrektur in anetd integriert, um das Verhalten zu korrigieren.


Workaround:

Es gibt keine einfache Problemumgehung und in Version 1.16 gab es keine Probleme mit diesem Verhalten. Wenn Sie feststellen, dass langlebige Verbindungen aufgrund dieses Problems unterbrochen werden, können Sie das Problem umgehen, indem Sie eine Arbeitslast auf demselben Knoten wie die ausgehende IP-Adresse verwenden oder Nachrichten konsistent über die TCP-Verbindung senden.
Vorgang 1,14, 1,15, 1,16

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

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

Workaround:

Wenn Sie von diesem Problem betroffen sind, können Sie Ihren Nutzercluster aktualisieren, indem Sie der Konfigurationsdatei des Nutzerclusters disableNodeIDVerificationCSRSigning: true 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

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

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

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

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


Workaround:

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

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

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

Administratorcluster-Updates schlagen nach CA-Rotation fehl

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

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

Workaround:

Wenn Sie von diesem Problem betroffen sind, können Sie Ihren Administratorcluster aktualisieren, indem Sie das Flag --disable-update-from-checkpoint mit dem Befehl gkectl update admin verwenden:

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

Wenn Sie das Flag --disable-update-from-checkpoint verwenden, verwendet der Aktualisierungsbefehl die Prüfpunktdatei während der Clusteraktualisierung nicht als zentrale Datenquelle. 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

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

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

Es gibt einige bekannte Probleme, die den Start dieses Pods verhindern können:

  • 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 mit aktivierter automatischer Istio-Sidecar-Einfügung im Namespace default installiert ist, wird der CSI-Arbeitslast-Pod nicht gestartet.

Wenn der CSI-Arbeitslast-Pod nicht gestartet wird, wird während der Preflight-Validierung ein Zeitüberschreitungsfehler wie der folgende angezeigt:

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

Wenn Sie herausfinden möchten, ob der Fehler durch fehlende Pod-Ressourcen verursacht wird, führen Sie den folgenden Befehl aus, um den anthos-csi-workload-writer-<run-id>-Jobstatus zu prüfen:

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

Wenn die Ressourcenlimits für den CSI-Arbeitslast-Pod nicht korrekt 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 der Istio-Sidecar-Einfügung nicht gestartet wird, können Sie die automatische Istio-Sidecar-Einfügung im Namespace default vorübergehend deaktivieren. Prüfen Sie die Labels des Namespace und löschen Sie mit dem folgenden Befehl das Label, das mit istio.io/rev beginnt:

kubectl label namespace default istio.io/rev-

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

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

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

Vorgang 1.16.0-1.16.2

Zeitlimits für Nutzerclusterupdates bei Version 1.15 des Administratorclusters

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

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

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 die Preflight-Prüfung hängen, bis das Zeitlimit erreicht ist.

Workaround:

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

Zeitlimits beim Erstellen von Nutzerclustern, wenn Version des Administratorclusters 1.15 ist

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

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

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

Workaround:

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

Die Aktualisierung oder das Upgrade des Administratorclusters schlägt fehl, wenn die Projekte oder Standorte von Add-on-Diensten nicht einander entsprechen

Wenn Sie einen Administratorcluster von Version 1.15.x auf 1.16.x upgraden oder beim Aktualisieren eines Administratorclusters eine connect-, stackdriver-, cloudAuditLogging- oder gkeOnPremAPI-Konfiguration hinzufügen, wird der Vorgang möglicherweise vom Administratorcluster-Webhook abgelehnt. 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."

Für eine Aktualisierung oder ein Upgrade eines Administratorclusters muss der onprem-admin-cluster-controller den Administratorcluster in einem bestimmten Cluster abgleichen. Wenn der Status des Administratorclusters im Artcluster wiederhergestellt wird, kann der Webhook des Administratorclusters nicht unterscheiden, ob das Objekt OnPremAdminCluster zum Erstellen eines Administratorclusters gedacht ist oder Vorgänge für eine Aktualisierung oder ein Upgrade fortsetzt. Einige Validierungen, die nur beim Erstellen erstellt werden, werden ausgelöst, wenn unerwartete Updates und Upgrades durchgeführt werden.


Workaround:

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

  1. Bearbeiten Sie die Clusterressource onpremadminclusters: 
    kubectl edit onpremadminclusters ADMIN_CLUSTER_NAME -n kube-system –kubeconfig ADMIN_CLUSTER_KUBECONFIG
    Ersetzen Sie Folgendes:
    • ADMIN_CLUSTER_NAME: der Name des Administratorclusters.
    • ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters.
  2. Fügen Sie die Annotation onprem.cluster.gke.io/skip-project-location-sameness-validation: true hinzu und speichern Sie die benutzerdefinierte Ressource.
  3. Führen Sie je nach Typ des Administratorclusters einen der folgenden Schritte aus:
    • Bei Administratorclustern ohne Hochverfügbarkeit mit einer Prüfpunktdatei:Fügen Sie den Parameter disable-update-from-checkpoint im Aktualisierungsbefehl oder den Parameter „disable-upgrade-from-checkpoint“ im Upgradebefehl hinzu. Diese Parameter werden nur benötigt, wenn Sie den Befehl update oder upgrade das nächste Mal 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
    • Für Hochverfügbarkeits-Administratorcluster oder Prüfpunktdatei ist deaktiviert: Aktualisieren Sie den Administratorcluster wie gewohnt. Für die Aktualisierungs- oder Upgradebefehle sind keine zusätzlichen Parameter erforderlich.
Vorgang 1.16.0-1.16.2

Das Löschen des Nutzerclusters schlägt fehl, wenn eine vom Nutzer verwaltete Administratorworkstation verwendet wird

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

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

Beim Löschen löscht ein Cluster zuerst alle zugehörigen Objekte. Das Löschen der Validierungsobjekte, die beim Erstellen, Aktualisieren oder Upgraden erstellt wurden, bleibt in der Löschphase hängen. Dies liegt daran, dass ein Finalizer das Löschen des Objekts blockiert, wodurch das Löschen des Clusters fehlschlägt.

Workaround:

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

    Nachdem Sie den Finalizer aus allen Validierungsobjekten entfernt haben, werden die Objekte entfernt und der Vorgang zum Löschen des Nutzerclusters wird automatisch abgeschlossen. Sie müssen nichts weiter tun.

Netzwerk 1,15; 1,16

Ausgehender NAT-Gateway-Traffic zum externen Server schlägt fehl

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

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


Workaround:

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

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

Diese Problemumgehung wird bei jedem Upgrade des Clusters rückgängig gemacht. Sie müssen nach jedem Upgrade neu konfigurieren. VMware muss das Problem in vSphere beheben, um eine dauerhafte Lösung zu erhalten.
Upgrades 1.15.0-1.15.4

Ein Upgrade eines Administratorclusters mit aktivierter Verschlüsselung von immer aktiven Secrets schlägt fehl

Das Upgrade des Administratorclusters von 1.14.x auf 1.15.x mit aktivierter Always-On-Secrets-Verschlüsselung schlägt aufgrund einer Abweichung zwischen dem vom Controller generierten Verschlüsselungsschlüssel und dem Schlüssel fehl, der auf dem Administrator-Master-Datenlaufwerk vorhanden 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 folgendem Fehler fehl: 

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

Problemumgehung

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

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

Fehler beim Upgrade verhindern

Wenn Sie noch kein Upgrade durchgeführt haben, empfehlen wir, kein Upgrade auf 1.15.0 bis 1.15.4 durchzuführen. Wenn Sie ein Upgrade auf eine betroffene Version ausfü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 dem folgenden Befehl: 
    gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
  3. Führen Sie ein Upgrade des Administratorclusters durch.
  4. Always-on-Secret-Verschlüsselung wieder aktivieren
Speicher 1,11–1,16

Laufwerkfehler und Fehler beim Anhängen bei Verwendung von Changed Block Tracking (CBT)

Google Distributed Cloud unterstützt kein Changed Block Tracking (CBT) auf Laufwerken. Einige Sicherungssoftware verwendet die CBT-Funktion, um den Laufwerkstatus 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 dazu führen kann, dass CBT auf ihren Laufwerken aktiviert wird. Es ist nicht erforderlich, 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 aktivierter CBT haben, führen Sie die Lösungsschritte im VMware-KB-Artikel aus, um CBT auf dem First Class-Laufwerk zu deaktivieren.
Speicher 1,14, 1,15, 1,16

Datenbeschädigung auf NFSv3, wenn paralleles Anfügen an eine freigegebene Datei von mehreren Hosts aus erfolgt

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


Workaround:

Der VMware-KB-Artikel ist veraltet, da es keine aktuelle Lösung gibt. Aktualisieren Sie auf Ihren Hosts auf die neueste Version von ESXi und in Ihren Speicherarrays auf die neueste Version von Nutanix, um dieses Problem zu beheben.
Betriebssystem 1.13.10, 1.14.6, 1.15.3

Versionsabweichung zwischen kubelet und der Kubernetes-Steuerungsebene

Bei bestimmten Google Distributed Cloud-Releases verwendet das auf den Knoten ausgeführte Kubelet eine andere Version als die Kubernetes-Steuerungsebene. Es liegt eine Diskrepanz vor, da die auf dem Betriebssystem-Image vorinstallierte Kubelet-Binärdatei eine andere Version verwendet.

In der folgenden Tabelle sind die erkannten Versionsabweichungen aufgeführt:

Google Distributed Cloud-Version Kubelet-Version Kubernetes-Version
1.13.10 Version 1.24.11-gke.1200 Version 1.24.14-gke.2100
1.14.6 Version 1.25.8-gke.1500 Version 1.25.10-gke.1200
1.15.3 Version 1.26.2-gke.1001 Version 1.26.5-gke.2100

Workaround:

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

Upgrades, Updates 1.15.0-1.15.4

Das Upgrade oder Aktualisieren eines Administratorclusters mit einer Zertifizierungsstellenversion größer als 1 schlägt fehl

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

    CAVersion must start from 1

Workaround:

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

Löschen von Clustern ohne Hochverfügbarkeit – Steuerungsebene V2 hängt bis zum Zeitlimit fest

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

Workaround:

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

Gehen Sie andernfalls so vor:

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

Speicher 1.15.0+, 1.16.0+

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

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


Workaround:

Bearbeiten Sie die „configMap“ der vSphere-CSI-Funktion 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

Falsche Warnungen zu PVCs

Wenn ein Cluster integrierte nichtflüchtige Volumes von vSphere enthält, können die Befehle gkectl diagnose und gkectl upgrade bei der Validierung der Clusterspeichereinstellungen falsche Warnungen zu ihren Anforderungen für nichtflüchtige Volumes (Persistent Volume Claims, PVCs) auslösen. Die Warnmeldung sieht so aus: 

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

Workaround:

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

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

Wenn das Feld annotations in der Ausgabe Folgendes enthält, können Sie die Warnung 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+

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

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

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

Workaround:

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

Wenn die Aktualisierung immer noch nicht erfolgreich war, wenden Sie sich an Cloud Customer Care, um das Problem zu beheben.
Upgrades 1.16.0-1.16.5

1.15 Auf der Nutzermastermaschine tritt eine unerwartete Wiederherstellung auf, wenn der Nutzercluster-Controller auf 1.16 aktualisiert wird.

Wenn Sie während eines Nutzercluster-Upgrades nach dem Upgrade des Nutzercluster-Controllers auf 1.16 weitere 1, 15 Nutzercluster haben, die vom selben Administratorcluster verwaltet werden, kann deren Nutzer-Master-Maschine unerwartet neu erstellt werden.

Der 1.16-Nutzercluster-Controller enthält einen Fehler, der die Wiederherstellung des 1.15-Nutzer-Mastercomputers auslösen kann.

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

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

Option 1: Version 1.16.6 oder höher von GKE on VMware mit der Korrektur verwenden

Option 2: Führen Sie die folgenden Schritte aus:

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

    Die nochmalige Annotation lautet:

    onprem.cluster.gke.io/server-side-preflight-rerun: true
  2. Überwachen Sie den Fortschritt des Upgrades. Klicken Sie dazu auf das Feld status des OnPremUserClusters.

Problemumgehung beim Upgrade des Nutzerclusters mit Ihrer eigenen Administratorworkstation:

Option 1: Version 1.16.6 oder höher von GKE on VMware mit der Korrektur verwenden

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 Upgrade-Befehl noch einmal aus.
  3. Löschen Sie nach Abschluss des Upgrades die Datei build.info.
Erstellen 1.16.0–1.16.5, 1.28.0–1.28.100

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

Wenn Sie bei der Clustererstellung in der IP-Blockdatei nicht für jede IP-Adresse einen Hostnamen angeben, schlägt die Preflight-Prüfung mit der folgenden 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.`

Die Preflight-Prüfung enthält einen Programmfehler, bei dem ein leerer Hostname als Duplikat angenommen wird.

Workaround:

Option 1: Verwenden Sie eine Version mit der Fehlerkorrektur.

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

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

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

Bei einem Administratorcluster ohne Hochverfügbarkeit und einem Nutzercluster der Steuerungsebene v1 kann die Wiederherstellung des Administratorclusters oder der Mastermaschine möglicherweise gleichzeitig mit dem Neustart der Mastermaschine des Nutzerclusters erfolgen, wenn Sie den Administratorcluster upgraden oder aktualisieren. Dadurch kann eine Race-Bedingung angezeigt werden. 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 prüfen:

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

Workaround:

  1. Stellen Sie eine SSH-Verbindung zum Knoten der Nutzersteuerungsebene her: Da es sich um den 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 des Anzeigebereichs korrekt rekonstruieren.
Upgrades, Updates 1.16.0

Knoten der Steuerungsebene kann nicht erstellt werden

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

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

Führen Sie zum Identifizieren des Symptoms den folgenden Befehl aus, um ein 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 den ausgefallenen Computer neu, um das gelöschte Knotenobjekt neu zu erstellen.
  2. Stellen Sie eine SSH-Verbindung zu allen Knoten der Steuerungsebene her und starten Sie den statischen Pod des vSphere Cloud Controller Managers neu: 
          sudo crictl ps | grep vsphere-cloud-controller-manager | awk '{print $1}'
      sudo crictl stop PREVIOUS_COMMAND_OUTPUT
  3. Führen Sie den Befehl zum Aktualisieren/Aktualisieren noch einmal aus.
Vorgang 1.16

Doppelter Hostname im selben Rechenzentrum führt zu Fehlern bei Clusterupgrades oder -erstellungen

Das Upgrade eines 1.15-Clusters oder das Erstellen eines 1.16-Clusters mit statischen IP-Adressen schlägt fehl, wenn sich im selben Rechenzentrum doppelte Hostnamen befinden. Dieser Fehler tritt auf, weil der vSphere-Cloud-Controller-Manager keine externe IP-Adresse und Anbieter-ID im Knotenobjekt hinzufügen kann. Dadurch kommt es beim Upgrade/Erstellen des Clusters zu einer Zeitüberschreitung.

Rufen Sie zur Identifizierung des Problems die Pod-Logs des vSphere Cloud Controller Managers für den Cluster ab. Der verwendete Befehl hängt so vom Clustertyp ab:

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

Hier ist ein Beispiel für eine Fehlermeldung:

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

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

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

Die Problemumgehung hängt davon ab, bei welchem Vorgang der Fehler aufgetreten ist.

Problemumgehung für Upgrades:

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

  • Nutzercluster:
    1. Ändern Sie den Hostnamen des betroffenen Computers in „user-ip-block.yaml“ in einen eindeutigen Namen und lösen Sie eine erzwungene Aktualisierung aus:
                gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config NEW_USER_CLUSTER_CONFIG --force
    2. gkectl upgrade cluster noch einmal ausführen
  • Administratorcluster:
    1. Ändern Sie den Hostnamen des betroffenen Computers in „admin-ip-block.yaml“ in einen eindeutigen Namen und lösen Sie eine erzwungene Aktualisierung 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 sollte mit dem übereinstimmen, den Sie in Schritt 1 in „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. Upgrade des Administratorclusters mit deaktiviertem Prüfpunkt noch einmal ausführen:
                gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --disable-upgrade-from-checkpoint

Problemumgehung für Installationen:

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

$ und ` werden für den vSphere-Nutzernamen oder das Passwort nicht unterstützt

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

  • Upgrade eines 1.15-Nutzerclusters mit aktivierter Steuerungsebene V2 auf 1.16 durchführen
  • Upgrade eines Administratorclusters mit Hochverfügbarkeit von 1.15 auf 1.16 durchführen
  • 1.16-Nutzercluster mit aktivierter Steuerungsebene V2 erstellen
  • Administratorcluster mit Hochverfügbarkeit (1.16) erstellen

Verwenden Sie eine Version von Google Distributed Cloud 1.16.4 oder höher mit der Fehlerkorrektur oder führen Sie die folgende Problemumgehung aus. Die Problemumgehung hängt davon ab, bei welchem Vorgang der Fehler aufgetreten ist.

Problemumgehung für Upgrades:

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

Problemumgehung für Installationen:

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

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

Nachdem ein Knoten gelöscht und dann mit demselben Knotennamen neu erstellt wurde, besteht eine geringe Wahrscheinlichkeit, dass eine nachfolgende Erstellung eines 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 dem Cache löscht.


Workaround:

Starten Sie die vSphere-CSI-Controller-Pods neu:

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

Die gkectl-Reparatur „admin-master“ gibt einen Unmarshall-Fehler in der kubeconfig-Datei zurück.

Wenn Sie den Befehl gkectl repair admin-master in einem 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 mit dem Namen der Maschine übereinstimmt, die Sie reparieren, und verwenden Sie den Vorlagennamen im Reparaturbefehl.
  gkectl repair admin-master \
      --config=/home/ubuntu/admin-cluster.yaml \
      --kubeconfig=/home/ubuntu/kubeconfig \
      --admin-master-vm-template=/atl-qual-vc07/vm/gke-admin-98g94-zx...7vx-0-tmpl
Netzwerk 1.10.0+, 1.11.0+, 1.12.0+, 1.13.0+, 1.14.0–1.14.7, 1.15.0–1.15.3, 1.16.0

Seesaw-VM aufgrund wenig Speicherplatzes unterbrochen

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

    GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd

Dieser Fehler weist darauf hin, dass auf der VM nur wenig Speicherplatz verfügbar ist, da das auf der Seesaw-VM ausgeführte fluent-Bit nicht mit der richtigen Logrotation 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 Sie nicht auf die VM zugreifen können, hängen Sie das Laufwerk an eine funktionierende VM (z.B. eine Administrator-Workstation) an, entfernen Sie die Datei vom angehängten Laufwerk und hängen Sie das Laufwerk dann wieder an die ursprüngliche Seesaw-VM an.

Damit das Problem nicht 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

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

Wenn Sie versuchen, ein Upgrade (gkectl upgrade admin) oder Update (gkectl update admin) eines Administratorclusters mit nicht hoher Verfügbarkeit und aktiviertem Prüfpunkt durchzuführen (gkectl update admin), schlägt das Upgrade oder Update möglicherweise mit folgenden Fehlern fehl: 

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

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

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


Workaround:

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

Das Upgrade eines in der GKE On-Prem API registrierten Administratorclusters kann fehlschlagen

Wenn ein Administratorcluster bei der GKE On-Prem API registriert ist, kann das Upgrade des Administratorclusters auf die betroffenen Versionen fehlschlagen, da die Flottenmitgliedschaft nicht aktualisiert werden konnte. Wenn dieser Fehler auftritt, wird beim Versuch, den Cluster zu aktualisieren, der folgende Fehler angezeigt:

    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:

Registrieren Sie den Administratorcluster von 
    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 wird vorübergehend der veraltete Fehler „Cluster konnte nicht registriert werden“ angezeigt. Nach einiger Zeit sollte sie 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 registriert ist, wird seine Annotation zu Ressourcenverknüpfungen auf die benutzerdefinierte Ressource OnPremAdminCluster angewendet. Diese wird bei späteren Updates des Administratorclusters aufgrund des falschen Annotationsschlüssels nicht beibehalten. Dies kann dazu führen, dass der Administratorcluster versehentlich wieder bei der GKE On-Prem API registriert wird.

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


Workaround:

Heben Sie die Registrierung des Administratorclusters auf: 
    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
und registrieren Sie den Administratorcluster noch einmal.
Netzwerk 1.15.0-1.15.2

CoreDNS orderPolicy nicht erkannt

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. Dadurch wird orderPolicy ignoriert.


Workaround:

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

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

OnPremAdminCluster-Status stimmt nicht zwischen Prüfpunkt und tatsächlicher Antwortvorlage überein

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

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

Änderungen der Administratorzertifikate in Administratorclustern beim Abgleichsprozess

Google Distributed Cloud ändert die Administratorzertifikate auf den Steuerungsebenen des Administratorclusters bei jedem Abgleich, z. B. während eines Clusterupgrades. Dadurch erhöht sich die Wahrscheinlichkeit, dass Sie ungültige Zertifikate für Ihren Administratorcluster erhalten, insbesondere bei Clustern der Version 1.15.

Wenn dieses Problem bei Ihnen auftritt, treten möglicherweise folgende Probleme auf:

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

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

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

Workaround:

Führen Sie ein Upgrade auf eine Version von Google Distributed Cloud mit der folgenden Fehlerkorrektur durch: 1.13.10+, 1.14.6+, 1.15.2+. Wenn ein Upgrade für Sie nicht möglich ist, wenden Sie sich an Cloud Customer Care, um das Problem zu beheben.
Netzwerk, Betrieb 1,10, 1,11, 1,12, 1,13, 1,14

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

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

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

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


Workaround:

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

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

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

Das Upgrade des Administratorclusters schlägt nach der Registrierung des Clusters mit gcloud fehl

Nachdem Sie gcloud verwendet haben, um einen Administratorcluster mit einem nicht leeren gkeConnect-Abschnitt zu registrieren, wird beim Versuch, den Cluster zu aktualisieren, 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 Clusterknoten ausgeführt werden, nicht begrenzen

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

gkectl prepare windows fehlgeschlagen

gkectl prepare windows kann Docker in Google Distributed Cloud-Versionen vor 1.13 nicht installieren, da MicrosoftDockerProvider verworfen wurde.


Workaround:

Die allgemeine Idee zur Umgehung dieses Problems besteht darin, ein Upgrade auf Google Distributed Cloud 1.13 durchzuführen und den gkectl von 1.13 zu verwenden, um eine Windows-VM-Vorlage und dann Windows-Knotenpools zu erstellen. Es gibt zwei Möglichkeiten, von Ihrer aktuellen Version zu Google Distributed Cloud 1.13 zu gelangen (siehe unten).

Hinweis: Wir haben Möglichkeiten, dieses Problem in Ihrer aktuellen Version zu umgehen, ohne ein Upgrade auf Version 1.13 durchführen zu müssen. Es 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 der Version Google Distributed Cloud 1.13+ mit Windows-Knotenpools erstellen, Ihre Arbeitslasten zum neuen Cluster migrieren und dann den aktuellen Cluster löschen. Es wird empfohlen, die neueste Google Distributed Cloud-Nebenversion zu verwenden.

Hinweis: Dafür werden zusätzliche Ressourcen für die Bereitstellung des neuen Clusters benötigt, aber weniger Ausfallzeiten und Unterbrechungen bei vorhandenen Arbeitslasten.


Option 2: Windows-Knotenpools löschen und beim Upgrade auf Google Distributed Cloud 1.13 wieder hinzufügen

Hinweis: Bei dieser Option können die Windows-Arbeitslasten erst ausgeführt werden, wenn ein Upgrade auf 1.13 des Clusters durchgeführt wurde und Windows-Knotenpools wieder hinzugefügt wurden.

  1. Löschen Sie vorhandene Windows-Knotenpools. Entfernen Sie dazu die Konfiguration der Windows-Knotenpools aus der Datei „user-cluster.yaml“ und führen Sie dann den folgenden Befehl aus: 
    gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  2. Führen Sie ein Upgrade der reinen Linux-Administrator- und Nutzercluster auf 1.12 durch. Folgen Sie dazu dem Upgrade-Nutzerhandbuch für die entsprechende Ziel-Nebenversion.
  3. (Führen Sie diesen Schritt vor dem Upgrade auf 1.13 aus) Achten Sie darauf, dass enableWindowsDataplaneV2: true in der Antwortvorlage OnPremUserCluster konfiguriert ist. Andernfalls verwendet der Cluster weiterhin Docker für Windows-Knotenpools, die nicht mit der neu erstellten Windows-VM-Vorlage 1.13 kompatibel sind, auf der Docker nicht installiert ist. Wenn der Cluster nicht konfiguriert oder auf „false“ gesetzt ist, setzen Sie ihn in der Datei „user-cluster.yaml“ auf „true“. Führen Sie dann folgenden Befehl aus: 
    gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  4. Führen Sie gemäß dem Upgrade-Nutzerhandbuch ein Upgrade der reinen Linux-Administrator- und Nutzercluster auf 1.13 durch.
  5. Windows-VM-Vorlage mit 1.13 gkectl vorbereiten: 
    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 Konfiguration des Windows-Knotenpools wieder in „user-cluster.yaml“ hinzu und setzen Sie das Feld OSImage auf die neu erstellte Windows-VM-Vorlage.
  7. Aktualisieren Sie den Cluster, 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

RootDistanceMaxSec-Konfiguration wird für ubuntu Knoten nicht wirksam

Auf den Knoten wird anstelle der erwarteten Konfiguration 20 Sekunden der Standardwert von 5 Sekunden für RootDistanceMaxSec verwendet. Wenn Sie das Startlog des Knotens prüfen, indem Sie eine SSH-Verbindung zur VM herstellen, die sich unter `/var/log/startup.log` befindet, erhalten Sie den folgenden Fehler:

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

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


Workaround:

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

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

Fehler bei gkectl update admin aufgrund eines leeren Feldes osImageType

Wenn Sie 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 Cluster der Version 1.13 oder 1.14 verwenden, wird in der Antwort möglicherweise die folgende Nachricht angezeigt:

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

Wenn Sie sich das Log gkectl ansehen, stellen Sie möglicherweise fest, dass mehrere Änderungen die Einstellung osImageType von einem leeren String in ubuntu_containerd beinhalten.

Diese Aktualisierungsfehler sind auf ein fehlerhaftes Backfill des Felds osImageType in der Konfiguration des Administratorclusters seit der Einführung in Version 1.9 zurückzuführen.


Workaround:

Führen Sie mit der Fehlerbehebung ein Upgrade auf eine Version von Google Distributed Cloud durch. Wenn ein Upgrade in Ihrem Fall nicht möglich ist, wenden Sie sich an Cloud Customer Care, um das Problem zu beheben.
Installation, Sicherheit 1,13, 1,14, 1,15, 1,16

SNI funktioniert nicht auf Nutzerclustern mit Steuerungsebene V2

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


Workaround:

Wenn Sie SNI verwenden müssen, bis ein Google Distributed Cloud-Patch mit der Korrektur verfügbar ist, deaktivieren Sie Steuerungsebene V2 (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

$ im Nutzernamen der privaten Registry führt zu einem Fehler beim Starten der Maschine für die Administrator-Steuerungsebene

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

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

Workaround:

Verwenden Sie einen privaten Registry-Nutzernamen ohne $ oder eine Version von Google Distributed Cloud mit der Lösung.
Upgrades, Updates 1.12.0-1.12.4

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

Wenn Sie Administratorcluster aktualisieren, werden die folgenden falsch-positiven Warnungen im Log angezeigt, die Sie ignorieren können. 

    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

Nutzercluster konnte nach Rotation des KSA-Signaturschlüssels nicht aktualisiert werden

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

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


Workaround:

Ändern Sie die Version Ihres KSA-Signaturschlüssels wieder auf 1, behalten Sie aber die neuesten Schlüsseldaten bei:
  1. Prüfen Sie das Secret im Administratorcluster unter dem Namespace USER_CLUSTER_NAME und rufen Sie den Namen des Secrets „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. Aktualisieren 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. Aktualisieren Sie das Feld spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation in Ihrer benutzerdefinierten OnPremUserCluster-Ressource auf 1: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
edit onpremusercluster USER_CLUSTER_NAME
  7. Warten Sie, bis der Zielnutzercluster bereit ist. Sie können den Status so prüfen: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
  8. Stellen Sie den Validierungs-Webhook für den Nutzercluster wieder her: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremuserclusters
'
  9. Vermeiden Sie eine weitere Rotation des KSA-Signaturschlüssels, bis der Cluster auf die Version mit der Fehlerkorrektur aktualisiert wurde.
Vorgang 1.13.1+, 1.14, 1., 1.16

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

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


Workaround:

Führen Sie die Schritte zum Bereinigen der F5-Partition eines Nutzerclusters aus, um die F5-Ressourcen zu entfernen.
Installation, Upgrades, Updates 1.13.8, 1.14.4

Art Cluster ruft Container-Images aus docker.io ab

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

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

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

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

    Die Antwort enthält Einträge wie den 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 im Container-Image des Clusters vorab geladen werden. Art v0.18.0 hat jedoch ein Problem mit den vorab geladenen Container-Images, die dazu führen, dass sie versehentlich aus dem Internet abgerufen werden.


    Workaround:

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

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

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

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

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

    Wenn Ihre Cluster-VMs mit einem Switch verbunden sind, der doppelte GARP-Anfragen (Gratuitous ARP) herausfiltert, kann es bei der Wahl des Keepa Lively-Leaders zu einer Race-Bedingung kommen, die dazu führt, dass einige Knoten falsche ARP-Tabelleneinträge enthalten.

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


    Workaround:

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

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

    vsphere-csi-controller sollte sein vCenter-Secret nach der vCenter-Zertifikatsrotation aktualisieren. Das aktuelle System startet die Pods von vsphere-csi-controller jedoch nicht ordnungsgemäß neu, was dazu führt, dass vsphere-csi-controller nach der Rotation abstürzt.

    Workaround:

    Folgen Sie bei Clustern, die mit Version 1.13 und höher erstellt wurden, der Anleitung unten, um vsphere-csi-controller neu zu starten 

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

    Das Erstellen des Administratorclusters schlägt bei Clusterregistrierung-Fehlern nicht fehl

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

    Suchen Sie im Log von „gkectl create admin“ nach den folgenden Fehlermeldungen, um das Symptom zu identifizieren: 
    Failed to register admin cluster

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

    Workaround:

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

    1. Hängen Sie ein gefälschtes 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

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

    Wenn beim Upgrade des Administratorclusters eine Zeitüberschreitung auftritt, wird der Administratorcluster nicht noch einmal mit der aktualisierten Connect-Agent-Version registriert, wenn beim Upgrade der Knoten der Nutzersteuerungsebene eine Zeitüberschreitung auftritt.


    Workaround:

    Prüfen Sie, ob der Cluster unter den registrierten Clustern angezeigt wird. Optional: Nach dem Einrichten der Authentifizierung beim Cluster anmelden Wenn der Cluster noch registriert ist, können Sie die folgenden Anweisungen für einen erneuten Registrierungsversuch überspringen. Folgen Sie bei Clustern, die auf Version 1.12 und höher aktualisiert wurden, der Anleitung zum erneuten Versuch der Administratorclusterregistrierung nach der Clustererstellung. Bei Clustern, die auf frühere Versionen aktualisiert wurden, gilt Folgendes:
    1. Hängen Sie ein gefälschtes Schlüssel/Wert-Paar wie "foo: bar" an Ihre Connect-Register-SA-Schlüsseldatei an.
    2. Führen Sie gkectl update admin aus, um den Administratorcluster noch einmal zu registrieren.

    Konfiguration 1.15.0

    Falsche Fehlermeldung zu vCenter.dataDisk

    Bei einem Administratorcluster mit hoher Verfügbarkeit zeigt gkectl prepare diese falsche Fehlermeldung an:

    vCenter.dataDisk must be present in the AdminCluster spec

    Workaround:

    Sie können diese Fehlermeldung ignorieren.
    VMware 1.15.0

    Knotenpoolerstellung schlägt aufgrund redundanter VM-Host-Affinitätsregeln fehl

    Beim Erstellen 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 der Knotenpool nicht erstellt werden kann.


    Workaround:

    Entfernen Sie die alten redundanten Regeln, damit die Knotenpoolerstellung fortgesetzt werden kann. Diese Regeln heißen [USER_CLUSTER_NAME]-[HASH].
    Vorgang 1.15.0

    gkectl repair admin-master schlägt möglicherweise aus folgendem Grund fehl: failed to delete the admin master node object and reboot the admin master VM

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

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


    Workaround:

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

    Pods verbleiben im Status „Fehlgeschlagen“, damit ein Knoten der Steuerungsebene neu erstellt oder aktualisiert werden kann

    Nachdem Sie einen Knoten der Steuerungsebene neu erstellt oder aktualisiert haben, verbleiben bestimmte Pods aufgrund eines Fehlers des NodeAffinity-Prädikats im Status Failed. Diese fehlgeschlagenen Pods wirken sich nicht auf den normalen Clusterbetrieb oder die Integrität aus.


    Workaround:

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

    OnPremUserCluster ist aufgrund von Anmeldedaten der privaten Registry nicht bereit

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

    failed to check secret reference for private registry …


    Workaround:

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

    Upgrades, Updates 1.15.0

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

    Während des gkectl upgrade admin wird durch die Storage-Preflight-Prüfung für CSI-Migration sichergestellt, dass die Speicherklassen keine Parameter haben, die nach der CSI-Migration ignoriert werden. Wenn beispielsweise eine Speicherklasse mit dem Parameter diskformat vorliegt, wird sie von gkectl upgrade admin gekennzeichnet und bei der Preflight-Validierung wird ein Fehler gemeldet. Administratorcluster, die in Google Distributed Cloud 1.10 und davor erstellt wurden, haben eine Speicherklasse mit diskformat: thin, die diese Validierung nicht besteht. Diese Speicherklasse funktioniert jedoch auch nach der CSI-Migration problemlos. Diese Fehler sollten stattdessen als Warnungen interpretiert werden.

    Weitere Informationen finden Sie im Abschnitt zum Parameter „StorageClass“ des Artikels In-Tree vSphere-Volumes zum vSphere Container Storage-Plug-in migrieren.


    Workaround:

    Nachdem Sie sich vergewissert haben, dass 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

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

    Unter bestimmten Umständen können Laufwerke schreibgeschützt an Windows-Knoten angehängt werden. Dies führt dazu, dass das entsprechende Volume in einem Pod schreibgeschützt ist. Dieses Problem tritt eher auf, wenn ein neuer Satz von Knoten einen alten Satz von Knoten ersetzt (z. B. Clusterupgrade oder Knotenpoolaktualisierung). Zustandsorientierte Arbeitslasten, die zuvor einwandfrei 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 sein Volume schreiben kann: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
    POD_NAME --namespace POD_NAMESPACE \
    -o=jsonpath='{.metadata.uid}{"\n"}'
    2. Verwenden Sie den PersistentVolumeClaim, um den Namen des nichtflüchtiges Volumes abzurufen: 
      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. Erlangen Sie PowerShell-Zugriff auf den Knoten, entweder über SSH oder die vSphere-Weboberfläche.
    5. Umgebungsvariablen festlegen: 
      PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID
    6. Ermitteln Sie die Laufwerksnummer für das Laufwerk, das mit dem nichtflüchtigem Volume verknüpft ist: 
      PS C:\Users\administrator> disknum=(Get-Partition -Volume (Get-Volume -UniqueId ("\\?\"+(Get-Item (Get-Item
"C:\var\lib\kubelet\pods\$podid\volumes\kubernetes.io~csi\$pvname\mount").Target).Target))).DiskNumber
    7. Prüfen Sie, ob das Laufwerk readonly ist: 
      PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
      Das Ergebnis sollte True lauten.
    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 für einen neuen Knoten geplant wird, müssen Sie möglicherweise die vorherigen Schritte auf dem neuen Knoten wiederholen.

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

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

    Wenn Sie die vSphere-Anmeldedaten für einen Administratorcluster nach dem Aktualisieren der Clusteranmeldedaten aktualisieren, wird im Administratorcluster möglicherweise unter dem Namespace kube-system vsphere-csi-secret angezeigt, dass noch die alten Anmeldedaten verwendet werden.


    Workaround:

    1. Rufen Sie den Namen des vsphere-csi-secret-Secrets ab: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
    2. Aktualisieren Sie die Daten des vsphere-csi-secret-Secrets, das Sie im obigen Schritt erhalten haben: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system patch secret CSI_SECRET_NAME -p \
  "{\"data\":{\"config\":\"$( \
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets CSI_SECRET_NAME -ojsonpath='{.data.config}' \
      | base64 -d \
      | sed -e '/user/c user = \"VSPHERE_USERNAME_TO_BE_UPDATED\"' \
      | sed -e '/password/c password = \"VSPHERE_PASSWORD_TO_BE_UPDATED\"' \
      | base64 -w 0 \
    )\"}}"
    3. 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 so verfolgen: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
      Nach dem erfolgreichen Roll-out der Bereitstellung sollte die aktualisierte vsphere-csi-secret vom Controller verwendet werden.
    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-Absturzschleife beim Aktivieren von Cloud-Audit-Logs mit gkectl update cluster

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


    Workaround:

    Stellen Sie für einen v2-Nutzercluster der Steuerungsebene mit enableControlplaneV2: true über SSH eine Verbindung zur Maschine der Steuerungsebene des Nutzers her und aktualisieren Sie /etc/kubernetes/manifests/audit-proxy.yaml mit --cluster_name=USER_CLUSTER_NAME.

    Bearbeiten Sie für einen v1-Nutzercluster der Steuerungsebene den audit-proxy-Container im 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

    Eine zusätzliche erneute Bereitstellung der Steuerungsebene direkt nach gkectl upgrade cluster

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

    Dies liegt daran, dass die Zertifikatsrotation der Steuerungsebene nach gkectl upgrade cluster automatisch erfolgt.

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


    Workaround:

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

    Ungültige Version 1.12.7-gke.19 wurde entfernt

    Google Distributed Cloud 1.12.7-gke.19 ist ein schlechter Release und sollten 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

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

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

    • gkectl update credentials componentaccess, wenn keine private Registry verwendet wird
    • gkectl update credentials privateregistry bei Verwendung einer privaten Registry

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

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


    Workaround:

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

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

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

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

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

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

    1. Kopieren Sie das Standard-Secret in den Namespace gke-connect: 
      kubectl --kubeconfig=KUBECONFIG -n=kube-system get secret private-registry-creds -oyaml | sed 's/ namespace: .*/ namespace: gke-connect/' | kubectl --kubeconfig=KUBECONFIG -n=gke-connect apply -f -
    2. Rufen Sie den Bereitstellungsnamen für gke-connect-agent ab: 
      kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
    3. Fügen Sie dem gke-connect-agent-Deployment 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

    Manuelle Prüfung der Konfiguration des Load-Balancers fehlgeschlagen

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

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

    Workaround:

    Option 1: Sie können die Patchversionen 1.13.7 und 1.14.4 verwenden, die die Korrektur enthalten.

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

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

    etcd-Uhrenhunger

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

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

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

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

    Problemumgehung

    Wenn Sie nicht sofort ein Upgrade durchführen können, verringern Sie die Anzahl der Knoten in Ihrem Cluster, um das Risiko eines Clusterfehlers zu verringern. Entfernen Sie Knoten, bis der Messwert etcd_network_client_grpc_sent_bytes_total weniger als 300 Mbit/s beträgt.

    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 das Feld Messwert auswählen, geben Sie Kubernetes Container in die Filterleiste ein und wählen Sie dann den Messwert über die Untermenüs 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 „Übernehmen“.
    Upgrades, Updates 1.10, 1.11, 1.12, 1.13 und 1.14

    GKE Identity Service kann Latenzen der Steuerungsebene verursachen

    Bei Clusterneustarts oder -upgrades kann der GKE Identity Service mit Traffic aus abgelaufenen JWT-Tokens überlastet werden, der über den Authentifizierungs-Webhook vom kube-apiserver an den GKE Identity Service weitergeleitet wird. Der GKE Identity Service führt zwar keine Absturzschleife aus, reagiert aber nicht mehr und verarbeitet keine weiteren Anfragen. 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 können Sie feststellen, ob Sie von diesem Problem betroffen sind:

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

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

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

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

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

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

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

        Administratorcluster:

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

        Nutzercluster:

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

        Wenn die kube-apiserver-Logs Einträge wie 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 fehlerhaften Pods als Behelfslösung identifizieren und neu starten:

    1. Erhöhen Sie die Ausführlichkeitsstufe des GKE Identity Service auf 9: 
      kubectl patch deployment ais -n anthos-identity-service --type=json \
    -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", \
    "value":"--vmodule=cloud/identity/hybrid/charon/*=9"}]' \
    --kubeconfig KUBECONFIG
    2. Prüfen Sie das Log des GKE-Identitätsdienstes auf den ungültigen Tokenkontext: 
      kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG
    3. Zum Abrufen der Tokennutzlast, die mit jedem ungültigen Tokenkontext verknüpft ist, 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 Namespace des Quellpods zu sehen, kopieren Sie das Token in den Debugger unter jwt.io.
    5. Starten Sie die mit den Tokens identifizierten Pods neu.
    Vorgang 1,8, 1,9, 1,10

    Das Problem mit dem Anstieg der Arbeitsspeichernutzung von etcd-Maintenance-Pods

    Die etcd-Wartungs-Pods, die das etcddefrag:gke_master_etcddefrag_20210211.00_p0-Image verwenden, sind betroffen. Der Container „etcddefrag“ öffnet während jedes Defrag-Zyklus eine neue Verbindung zum etcd-Server und die alten Verbindungen werden nicht bereinigt.


    Workaround:

    Option 1: Führen Sie ein Upgrade auf die neueste Patch-Version von 1.8 auf 1.11 durch, die den Fehler behebt.

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

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

    Systemdiagnosen von Pods der Steuerungsebene von Nutzerclustern verpassen

    Sowohl der Clusterintegritäts-Controller als auch der Befehl gkectl diagnose cluster führen eine Reihe von Systemdiagnosen durch, einschließlich der Systemdiagnosen der Pods über alle Namespaces hinweg. Sie beginnen jedoch versehentlich, die Pods der Nutzersteuerungsebene zu überspringen. Wenn Sie den V2-Modus der Steuerungsebene verwenden, hat dies keine Auswirkungen auf Ihren Cluster.


    Workaround:

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

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

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

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


    Workaround:

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

    Seesaw-Validierung beim Erstellen des Load-Balancers fehlgeschlagen

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

    Workaround:

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

    Zeitüberschreitungen der Anwendung aufgrund von Fehlern beim Einfügen von Conntrack-Tabellen

    Version 1.14 von Google Distributed Cloud ist anfällig für Fehler beim Einfügen von Tabellen mit netfilter-Verbindungsverfolgung (conntrack), wenn Ubuntu- oder COS-Betriebssystem-Images verwendet werden. Einfügungsfehler führen zu zufälligen Zeitüberschreitungen in der Anwendung und können selbst dann auftreten, wenn die Conntrack-Tabelle Platz für neue Einträge bietet. Die Fehler werden durch Änderungen in Kernel 5.15 und höher verursacht, durch die das Einfügen von Tabellen anhand der Kettenlänge eingeschränkt wird.

    Um festzustellen, ob Sie von diesem Problem betroffen sind, können Sie mit dem folgenden Befehl die Statistiken des Systems für das Verbindungs-Tracking im Kernel auf jedem Knoten prüfen:

    sudo conntrack -S

    Die Antwort sieht so aus:

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

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

    Problemumgehung

    Zur vorläufigen Abhilfe können Sie sowohl die netfiler-Hash-Tabelle (nf_conntrack_buckets) als auch die netfilter-Verbindungs-Tracking-Tabelle (nf_conntrack_max) erhöhen. Verwenden Sie die folgenden Befehle auf jedem Clusterknoten, um die Tabellengröße zu erhöhen:

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

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

    Absturzschleife "calico-typha" oder "anetd-operator" auf Windows-Knoten mit Steuerungsebene v2

    Bei Steuerungsebene v2 oder einem neuen Installationsmodell kann calico-typha oder anetd-operator für Windows-Knoten geplant werden und in eine Absturzschleife geraten.

    Der Grund ist, dass die beiden Bereitstellungen alle Markierungen tolerieren, einschließlich der Windows-Knotenmarkierung.


    Workaround:

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

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

    Folgendes spec.template.spec.tolerations entfernen:

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

    Und fügen Sie die folgende Toleranz hinzu:

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

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

    Sie können möglicherweise keinen Nutzercluster erstellen, wenn Sie den Abschnitt privateRegistry mit den Anmeldedaten fileRef angeben. Preflight schlägt möglicherweise mit der folgenden Meldung fehl:

    [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 bestimmte private Registry-Anmeldedaten für Ihren Nutzercluster verwenden möchten, können Sie den Abschnitt privateRegistry vorübergehend so angeben: 
      privateRegistry:
  address: PRIVATE_REGISTRY_ADDRESS
  credentials:
    username: PRIVATE_REGISTRY_USERNAME
    password: PRIVATE_REGISTRY_PASSWORD
  caCertPath: PRIVATE_REGISTRY_CACERT_PATH
      (HINWEIS: Dies ist nur eine vorübergehende Lösung, und diese Felder wurden bereits verworfen. Wir empfehlen, beim Upgrade auf Version 1.14.3 oder höher die Anmeldedatendatei zu verwenden.)

    Operations 1.10+

    Cloud Service Mesh und andere Service Meshes nicht mit Dataplane v2 kompatibel

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

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

    Dieses Problem tritt bei allen Versionen von GKE on Bare Metal 1.10 auf. Für einige neuere Versionen von 1.10 (1.10.2 und höher) gibt es jedoch eine Behelfslösung.


    Workaround:

    Führen Sie ein Upgrade auf 1.11 aus, um die vollständige Kompatibilität zu erreichen, oder führen Sie bei Verwendung von 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 zur 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 trennt möglicherweise nichtflüchtige Volumes nach 6 Minuten erzwungen

    kube-controller-manager kann zu einer Zeitüberschreitung führen, wenn die PV/PVCs nach 6 Minuten getrennt werden und die PV/PVCs zwangsweise getrennt werden. Detaillierte Logs aus kube-controller-manager enthalten ähnliche Ereignisse wie die folgenden:

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

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

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

    # See all the mounting points with disks
lsblk -f

# See some ext4 errors
sudo dmesg -T

    Im Kubelet-Log werden Fehler wie die folgenden angezeigt:

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

    Workaround:

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

    Das Clusterupgrade bleibt hängen, wenn der CSI-Treiber eines Drittanbieters verwendet wird

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

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


    Workaround:

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

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

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

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


    Workaround:

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

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

    In systemd v244 wurde für systemd-networkd eine Änderung des Standardverhaltens in der KeepConfiguration-Konfiguration festgelegt. Vor dieser Änderung haben VMs beim Herunterfahren oder Neustarten keine Release-Meldung zur DHCP-Freigabe an den DHCP-Server gesendet. Nach dieser Änderung senden VMs eine solche Nachricht und geben die IP-Adressen an den DHCP-Server zurück. Infolgedessen kann die freigegebene IP-Adresse einer anderen VM neu zugewiesen und/oder der VM eine andere IP-Adresse zugewiesen werden. Dies führt zu IP-Konflikten (auf Kubernetes-Ebene, nicht auf vSphere-Ebene) und/oder zu IP-Änderungen auf den VMs, durch die die Cluster auf verschiedene Weise aufgeteilt werden können.

    Es können beispielsweise die folgenden Symptome auftreten.

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


    Workaround:

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

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

    Vorgang, Upgrades, Updates 1.12.0–1.12.5, 1.13.0–1.13.5, 1.14.0–1.14.1

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

    Dieses Problem betrifft nur Administratorcluster, die von 1.11.x aktualisiert wurden. Administratorcluster, die nach 1.12 neu erstellt wurden, sind nicht betroffen.

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

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

    Nachdem der Dienstkontoschlüssel für den Komponentenzugriff gelöscht wurde, können weder neue Nutzercluster installiert noch vorhandene Nutzercluster aktualisiert werden. Im Folgenden sind einige Fehlermeldungen aufgeführt, die auftreten können:

    • Preflight-Fehler bei langsamer Validierung mit Fehlermeldung: "Failed to create the test VMs: failed to get service account key: service account is not configured."
    • Die Vorbereitung bis zum gkectl prepare ist fehlgeschlagen. Es wurde folgende Fehlermeldung ausgegeben: "Failed to prepare OS images: dialing: unexpected end of JSON input"
    • Wenn Sie einen Nutzercluster der Version 1.13 über die Google Cloud Console oder die gcloud CLI aktualisieren und gkectl update admin --enable-preview-user-cluster-central-upgrade zum Bereitstellen des Upgrade Platform-Controllers ausführen, schlägt der Befehl mit der folgenden Meldung fehl: "failed to download bundle to disk: dialing: unexpected end of JSON input" (Diese Meldung wird im Feld status in der Ausgabe von kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml angezeigt.)


    Problemumgehung:

    Fügen Sie den Dienstkontoschlüssel für den Komponentenzugriff manuell wieder dem Secret hinzu, 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+

    Cluster-Autoscaling funktioniert nicht, wenn Steuerungsebene V2 aktiviert ist

    Bei Nutzerclustern, die mit Controlplane V2 oder einem neuen Installationsmodell erstellt wurden, verwenden Knotenpools mit aktiviertem Autoscaling immer deren autoscaling.minReplicas in user-cluster.yaml. Das Log des Cluster-Autoscaling-Pods zeigt ebenfalls, dass deren Fehler fehlerhaft sind. 

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


    Problemumgehung:

    Autoscaling in allen Knotenpools mit „gkectl update cluster“ deaktivieren, bis ein Upgrade auf eine Version mit der Fehlerkorrektur durchgeführt wird
    Installation 1.12.0–1.12.4, 1.13.0–1.13.3, 1.14.0

    CIDR ist in der IP-Blockdatei nicht zulässig

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

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


    Problemumgehung:

    Beziehen Sie einzelne IP-Adressen in die IP-Blockdatei ein, bis Sie ein Upgrade auf eine Version mit der Fehlerkorrektur durchführen: 1.12.5, 1.13.4, 1.14.1+.
    Upgrades, Updates 1.14.0-1.14.1

    Aktualisierung des Betriebssystem-Image-Typs in „admin-cluster.yaml“ wartet nicht darauf, dass Maschinen der Steuerungsebene des Nutzers neu erstellt werden

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


    Problemumgehung:

    Warten Sie nach Abschluss des Updates, bis die Maschinen der Steuerungsebene des Nutzers ebenfalls die Neuerstellung abgeschlossen haben. Ü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 wir warten, bis alle Maschinen der Steuerungsebene vollständig von Ubuntu zu COS gewechselt sind, auch nachdem der Aktualisierungsbefehl abgeschlossen ist.

    Vorgang 1,10, 1,11, 1,12, 1,13, 1,14,0

    Fehler beim Erstellen oder Löschen von Pods aufgrund eines Problems mit dem Authentifizierungstoken des Calico CNI-Dienstkontos

    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 dem Erstellen oder Upgrade des Clusters mit Calico auf 1.14 auf.

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

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


    Workaround:

    Dieses Problem wurde in Google Distributed Cloud Version 1.14.1 behoben. Führen Sie ein Upgrade auf diese oder eine neuere Version durch.

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

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

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

    IP-Blockvalidierung schlägt bei Verwendung von CIDR fehl

    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.


    Problemumgehung:

    Teilen Sie CIDRs in mehrere kleinere CIDR-Blöcke auf. Beispielsweise wird 10.0.0.0/30 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, Updates 1.11.0–1.11.1, 1.10.0–1.10.4, 1.9.0–1.9.6

    Die Sicherung des Administratorclusters enthält nicht die immer aktiven Secrets-Verschlüsselungsschlüssel und die Konfiguration

    Wenn das Verschlüsselungsfeature für immer aktive Secrets zusammen mit der Clustersicherung aktiviert ist, enthält die Administratorclustersicherung die Verschlüsselungsschlüssel und die Konfiguration, die für das Verschlüsselungsfeature immer aktive Secrets erforderlich sind, nicht. Das Reparieren des Administrator-Masters mit dieser Sicherung mithilfe von gkectl repair admin-master --restore-from-backup führt daher zu folgendem Fehler:

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

    Vorgang, Upgrades, Updates 1.10+

    Administrator-Master-VM mit einem neuen Bootlaufwerk neu erstellen (z.B. gkectl repair admin-master) schlägt fehl, wenn das Verschlüsselungsfeature für immer aktive Secrets mit dem Befehl „gkectl update“ aktiviert wird.

    Wenn die Verschlüsselungsfunktion für immer aktive Secrets bei der Clustererstellung nicht, aber später über den gkectl update-Vorgang aktiviert wird, kann der gkectl repair admin-master den Knoten der Steuerungsebene des Administratorclusters nicht reparieren. Es wird empfohlen, das Verschlüsselungsfeature für immer aktive Secrets bei der Clustererstellung zu aktivieren. Es gibt derzeit keine Abhilfe.

    Upgrades, Updates 1.10

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

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

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


    Workaround:
    Upgrades, Updates 1.10.0

    Docker wird nach Clusterupgrade häufig neu gestartet

    Ein Upgrade des Nutzerclusters auf 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

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

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

    Um die Ursache zu verstehen, müssen Sie eine SSH-Verbindung zu dem Knoten 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

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

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

    Ab Version 1.12 werden GMP-Komponenten im Namespace gmp-system und in CRDs vom Objekt stackdriver verwaltet, wobei das Flag enableGMPForApplications standardmäßig auf false gesetzt ist. Wenn Sie GMP-Komponenten vor dem Upgrade auf 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

    Fehlende ClusterAPI-Objekte im Szenario des Cluster-Snapshots system

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

    Einige Kubernetes-Ressourcen wie Cluster API-Objekte in diesem Namespace enthalten jedoch nützliche Informationen zur Fehlerbehebung. Sie sollten sie im Cluster-Snapshot 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 gilt:

    USER_CLUSTER_KUBECONFIG ist 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

    Das Löschen des Nutzerclusters bleibt beim Knotenausgleich für die vSAN-Einrichtung hängen

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

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

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

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

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

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

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


    Workaround:

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

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

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

    Die Symptome sind folgende:

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

    Workaround:

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

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

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

    Die Symptome sind folgende:

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

    Workaround:

    Konfiguration 1.12.1–1.12.3, 1.13.0–1.13.2

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

    Ein bekanntes Problem, bei dem gkectl check-config fehlschlagen kann, ohne gkectl prepare auszuführen. 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 Betriebssystem-Images zu überspringen.
    Upgrades, Updates 1,11, 1,12, 1,13

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

    Bekanntes Problem, bei dem gkectl update admin/cluster beim Aktualisieren von anti affinity groups fehlschlagen kann.

    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

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

    Die Knotenregistrierung schlägt beim Erstellen, Aktualisieren, Aktualisieren und automatischen Knotenreparaturen fehl, wenn ipMode.type auf static gesetzt ist und der konfigurierte Hostname in der IP-Blockdatei einen oder mehrere Punkte enthält. In diesem Fall werden CSR-Anfragen für die Zertifikatssignierung für einen Knoten nicht automatisch genehmigt.

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

    kubectl get csr -A -o wide

    Prüfen Sie die folgenden Logs auf Fehlermeldungen:

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

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

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


    Workaround:

    Nutzercluster

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

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

    Administratorcluster

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

    Fehler beim Starten der Maschine für die Administrator-Steuerungsebene aufgrund eines Zertifikatspakets der privaten Registry

    Die Erstellung bzw. Aktualisierung des Administratorclusters bleibt dauerhaft beim folgenden Log hängen und es tritt irgendwann eine Zeitüberschreitung auf:

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

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

    Invalid value 'XXXX' specified for property startup-data

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

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

    NetworkGatewayNodes marked unhealthy from concurrent status update conflict

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

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

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

    Der Status NotHealthy hindert den Controller daran, dem Knoten zusätzliche Floating-IP-Adressen zuzuweisen. Dies kann andere Knoten stärker belasten oder zu einem Mangel an Redundanz für Hochverfügbarkeit führen.

    Ansonsten ist die Dataplane-Aktivität nicht betroffen.

    Ein Konflikt im networkgatewaygroup-Objekt führt dazu, dass einige Statusaktualisierungen aufgrund eines Fehlers bei der Wiederholungsverarbeitung fehlschlagen. Wenn zu viele Statusaktualisierungen fehlschlagen, erkennt ang-controller-manager, dass der Knoten sein Heartbeat-Zeitlimit überschritten hat, und markiert den Knoten NotHealthy.

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


    Workaround:

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

    Race-Bedingung verhindert das Löschen von Maschinenobjekten während und beim Aktualisieren oder Upgrade

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

    Das Symptom ist, dass der Befehl gkectl mit der folgenden Fehlermeldung abläuft:

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

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

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

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

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


    Workaround:

    Wir haben verschiedene Lösungsmöglichkeiten für dieses Problem vorbereitet, die von Ihrer Umgebung und Ihren Anforderungen abhängen.

    • Option 1: Warten Sie, bis das Upgrade schließlich von selbst abgeschlossen ist.

      Basierend auf der Analyse und Reproduktion in Ihrer Umgebung kann das Upgrade auch ohne manuelle Eingriffe abgeschlossen werden. Der Nachteil dieser Option ist, dass ungewiss ist, wie lange das Entfernen des Finalisierungs für jedes Maschinenobjekt dauert. Mit gutem Glück kann er sofort verarbeitet werden. Er kann auch mehrere Stunden dauern, wenn der Abgleich des Maschinensatz-Controllers zu schnell erfolgt und der Controller zwischen den Abgleichen keine Möglichkeit hat, den Finaler zu entfernen.

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

      Der Maschinensatz-Controller filtert die Maschinen heraus, bei denen die Annotation für die automatische Reparatur und der Löschzeitstempel ungleich null sind, und sendet keine Löschaufrufe an diese Maschinen. Dies kann dabei helfen, die Race-Bedingung zu vermeiden.

      Der Nachteil besteht darin, dass die Pods auf den Maschinen direkt gelöscht und nicht entfernt werden. Dadurch wird die PDB-Konfiguration nicht berücksichtigt. Dies kann zu Ausfallzeiten Ihrer Arbeitslasten führen.

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

    Wenn dieses Problem auftritt und das Upgrade oder Update nach längerer Zeit immer noch nicht abgeschlossen werden kann, wenden Sie sich an unser Supportteam, um Lösungsvorschläge zu erhalten.
    Installation, Upgrades, Updates 1.10.2, 1.11, 1.12, 1.13

    gkectl-Preflight-Fehler bei der Vorbereitung der Betriebssystem-Image-Validierung

    gkectl prepare-Befehl fehlgeschlagen bei:

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

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


    Workaround:

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

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

    Der Administratorcluster konnte aufgrund eines Fehlers nicht erstellt werden:

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

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


    Workaround:

    Entfernen Sie das Präfix https:// oder http:// aus dem Feld vCenter.Address in der YAML-Datei für die Konfiguration des Administratorclusters oder des Nutzerclusters.
    Installation, Upgrades, Updates 1,10, 1,11, 1,12, 1,13

    gkectl prepare Panik auf util.CheckFileExists

    gkectl prepare kann bei folgendem Stacktrace in Panik geraten:

    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 besteht darin, dass gkectl prepare das Zertifikatsverzeichnis der privaten Registry mit einer falschen Berechtigung erstellt hat.


    Workaround:

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

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

    gkectl repair admin-master und fortsetzbares Administratorupgrade funktionieren nicht zusammen

    Führen Sie nach einem fehlgeschlagenen Upgrade des Administratorclusters nicht gkectl repair admin-master aus. Dies kann dazu führen, dass nachfolgende Versuche eines Administratorupgrades fehlschlagen, z. B. aufgrund eines Fehlers beim Einschalten des Administrator-Masters oder wenn die VM nicht mehr zugänglich ist.


    Workaround:

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

    Ein fortgesetztes Upgrade des Administratorclusters kann zu einer fehlenden VM-Vorlage der Administrator-Steuerungsebene führen

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


    Workaround:

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

    cgroup v2 kann sich auf Arbeitslasten auswirken

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


    Workaround:

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

    Benutzerdefinierte ClientConfig-Ressource

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


    Workaround:

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

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

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

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


    Workaround:

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

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

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

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

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

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

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

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

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

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

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

    Zugehöriger govmomi-Programmfehler.


    Workaround:

    Diese Problemumgehung wird vom VMware-Support bereitgestellt:

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

    SSH-Verbindung durch Remote-Host geschlossen

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

    Zur Einhaltung der CIS-Regel „5.2.16 Achten Sie darauf, dass das SSH-Intervall bei Inaktivität konfiguriert ist“ hat /etc/ssh/sshd_config die folgenden Einstellungen:

    ClientAliveInterval 300
ClientAliveCountMax 0

    Der Zweck dieser Einstellungen besteht darin, eine Clientsitzung nach 5 Minuten Inaktivität zu beenden. Der Wert ClientAliveCountMax 0 verursacht jedoch ein unerwartetes Verhalten. Wenn Sie die SSH-Sitzung auf der Administratorworkstation oder einem Clusterknoten verwenden, wird die SSH-Verbindung möglicherweise getrennt, auch wenn Ihr SSH-Client nicht inaktiv ist, z. B. beim Ausführen eines zeitaufwendigen Befehls, und der Befehl kann mit der folgenden Meldung beendet werden:

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

    Workaround:

    Sie haben folgende Möglichkeiten:

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

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

    In Konflikt stehende cert-manager-Installation

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

    Sie müssen diese Problemumgehung nur einmal für jeden Cluster anwenden. Die Änderungen bleiben beim Clusterupgrade erhalten.

    Hinweis: Ein häufiges Symptom bei der Installation eines eigenen Zertifikatmanagers ist, dass die Version oder das Image von cert-manager (z. B. Version 1.7.2) möglicherweise wieder auf die ältere Version zurückgesetzt wird. Der Grund dafür ist, dass monitoring-operator versucht, cert-manager abzugleichen und dabei die Version zurückzusetzen.

    Workaround:

    <pKonflikte während des Upgrades vermeiden

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

    Eigenen Zertifikatmanager 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
    • Installiere deine Version von cert-manager neu. Stellen Sie Ihre benutzerdefinierten Ressourcen wieder her, falls vorhanden.
    • Sie können diesen Schritt überspringen, wenn Sie die Upstream-Standardinstallation für cert-manager verwenden oder sicher sind, dass Ihr cert-manager im Namespace cert-manager installiert ist. Andernfalls kopieren Sie die Ressourcen des Zertifikats metrics-ca cert-manager.io/v1 und des Ausstellers metrics-pki.cluster.local aus 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 Zertifikatmanager in Administratorclustern wiederherstellen

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

    • Skalieren Sie das monitoring-operator-Deployment auf 0. 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n kube-system scale deployment monitoring-operator --replicas=0
    • Skalieren Sie die von monitoring-operator verwalteten cert-manager-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
    • Installiere deine Version von cert-manager neu. Stellen Sie Ihre benutzerdefinierten Ressourcen wieder her, falls vorhanden.
    • Sie können diesen Schritt überspringen, wenn Sie die Upstream-Standardinstallation für cert-manager verwenden oder sicher sind, dass Ihr cert-manager im Namespace cert-manager installiert ist. Andernfalls kopieren Sie die Ressourcen des Zertifikats metrics-ca cert-manager.io/v1 und des Ausstellers metrics-pki.cluster.local aus 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

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

    Die Docker-, containerd- und Runc-Images in den Ubuntu-Betriebssystem-Images, die mit Google Distributed Cloud geliefert werden, sind mithilfe von Ubuntu PPA an spezielle Versionen angepinnt. Dadurch wird sichergestellt, dass Änderungen der Containerlaufzeit vor jedem Release von Google Distributed Cloud qualifiziert werden.

    Die Sonderversionen sind dem Ubuntu CVE Tracker jedoch unbekannt, der von verschiedenen CVE-Scantools als Feeds für Sicherheitslücken verwendet wird. Daher werden in Docker, containerd und runc das Scannen auf Sicherheitslücken falsch positive Ergebnisse angezeigt.

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

    Informationen zu CVE-Korrekturen finden Sie in den Versionshinweisen.


    Workaround:

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

    Die Netzwerkverbindung zwischen Administrator- und Nutzercluster ist während eines Upgrades des Clusters ohne Hochverfügbarkeit möglicherweise kurzzeitig nicht verfügbar

    Wenn Sie Cluster ohne Hochverfügbarkeit von 1.9 auf 1.10 aktualisieren, stellen Sie möglicherweise fest, dass kubectl exec, kubectl log und Webhook für Nutzercluster für 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 Cluster ohne Hochverfügbarkeit gibt es nur ein Replikat für das Statefulset. Während des Upgrades kann es daher vorkommen, 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 möchten, empfehlen wir, zu Hochverfügbarkeitsclustern zu wechseln.
    Installation, Upgrades, Updates 1,10, 1,11, 1,12, 1,13

    Die Prüfung der Konnektivitätsbereitschaft in der HA-Clusterdiagnose nach dem Erstellen oder Upgrade des Clusters ist fehlgeschlagen

    Wenn Sie einen HA-Cluster erstellen oder aktualisieren und dabei feststellen, dass die Konnektivitätsprüfung in der Clusterdiagnose fehlgeschlagen ist, wirkt sich dies in den meisten Fällen nicht auf die Funktionalität von Google Distributed Cloud (kubectl exec, kubectl-Log und Webhook) aus. Dies liegt daran, dass eines oder zwei der Konnektivitätsreplikate aufgrund von instabilen Netzwerk- oder anderen Problemen für einen bestimmten Zeitraum möglicherweise nicht gelesen werden können.


    Workaround:

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

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

    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, sodass eine aide-Prüfung geplant wird, um sicherzustellen, dass die CIS L1-Server-Regel „1.4.2 Regelmäßige Prüfung der Dateisystemintegrität“ durchgeführt wird.

    Der Cronjob wird täglich um 06:25 Uhr (UTC) ausgeführt. Abhängig von der Anzahl der Dateien im Dateisystem kann es ungefähr zu dieser Zeit zu Spitzen bei der CPU- und Speicherauslastung kommen, die durch diesen aide-Prozess verursacht wird.


    Workaround:

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

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

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

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

    Das zugrunde liegende Problem besteht darin, dass die zustandsorientierten verteilten Firewallregeln von NSX-T die Verbindung von einem Client zum Nutzercluster-API-Server über den Seesaw-Load-Balancer beenden, da Seesaw asymmetrische Verbindungsabläufe verwendet. Integrationsprobleme bei verteilten NSX-T-Firewallregeln wirken sich auf alle Google Distributed Cloud-Releases aus, die Seesaw verwenden. Möglicherweise treten ähnliche Verbindungsprobleme bei Ihren eigenen Anwendungen auf, wenn diese große Kubernetes-Objekte erstellen, deren Größe 32.000 KB übersteigt.


    Workaround:

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

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

    Unerwartete Monitoringabrechnung

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

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

    Wenn Sie prüfen möchten, ob Sie von diesem Problem betroffen sind, listen Sie Ihre benutzerdefinierten Messwerte auf. Wenn Ihnen die Abrechnung unerwünschter Messwerte mit dem Namenspräfix external.googleapis.com/prometheus angezeigt wird und enableStackdriverForApplications als 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, dass Sie Ihre Cluster auf Version 1.12 oder höher aktualisieren, das Flag enableStackdriverForApplications nicht mehr verwenden und zur neuen Lösung managed-service-for-prometheus für das Anwendungsmonitoring wechseln, die nicht mehr auf die Annotation prometheus.io/scrap=true angewiesen ist. Mit der neuen Lösung können Sie außerdem die Log- und Messwerterfassung für Ihre Anwendungen separat mit den Flags enableCloudLoggingForApplications und enableGMPForApplications steuern.

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

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

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

    Wenn Sie nicht von der annotierungsbasierten Messwerterfassung wegwechseln können, gehen Sie so vor:

    1. Suchen Sie die Quell-Pods und -dienste, die die unerwünschten berechneten Messwerte enthalten. 
      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, sollten Sie Cloud Service Mesh ohne die Prometheus-Option konfigurieren oder das Feature „Istio Metrics Merging“ deaktivieren.
    Installation 1,11, 1,12, 1,13

    Installationsprogramm schlägt beim Erstellen von vSphere-Datenlaufwerk fehl

    Das Google Distributed Cloud-Installationsprogramm kann fehlschlagen, wenn benutzerdefinierte Rollen mit 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. Zum Beheben des Problems sollten Sie die benutzerdefinierte Rolle auf der vSphere-vCenter-Ebene (Root) binden.


    Workaround:

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

    Weitere Informationen zum Erstellen von Rollen finden Sie unter Berechtigungen für vCenter-Nutzerkonten.
    Logging und Monitoring 1.9.0–1.9.4, 1.10.0–1.10.1

    Hoher Netzwerkverkehr zu Monitoring.googleapis.com

    Möglicherweise kommt es zu einem hohen Netzwerktraffic zu monitoring.googleapis.com, selbst in einem neuen Cluster ohne Nutzerarbeitslasten.

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


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

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

    Ab Google Distributed Cloud Version 1.10 hat das DaemonSet „gke-metrics-agent“ häufige CrashLoopBackOff-Fehler, wenn „enableStackdriverForApplications“ im Objekt „Stackdriver“ auf „true“ gesetzt ist.


    Workaround:

    Deaktivieren Sie die Erfassung von Anwendungsmesswerten durch Ausführen der folgenden Befehle, um dieses Problem zu beheben. Diese Befehle deaktivieren die Erfassung von Anwendungslogs nicht.

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

    Verworfene Messwerte im Dashboard ersetzen

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

    gcloud monitoring dashboards list > all-dashboard.json

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

    Die folgenden eingestellten Messwerte sollten zu den ersetzten Messwerten migriert werden.

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

    Workaround:

    So ersetzen Sie die eingestellten Messwerte:

    1. Löschen Sie den „GKE On-Prem-Knotenstatus“ im Google Cloud Monitoring-Dashboard. Installieren Sie „GKE On-Prem-Knotenstatus“ gemäß dieser Anleitung neu.
    2. Löschen Sie im Google Cloud Monitoring-Dashboard „GKE On-Prem-Knotenauslastung“. Installieren Sie „GKE On-Prem-Knotenauslastung“ gemäß dieser Anleitung neu.
    3. Löschen Sie „GKE On-Prem vSphere-VM-Status“ im Google Cloud Monitoring-Dashboard. Installieren Sie „GKE On-Prem vSphere-VM-Status“ gemäß dieser Anleitung neu.

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

    Unbekannte Messwertdaten in Cloud Monitoring

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

    Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    Andere Messwerttypen, die möglicherweise irrelevante zusammenfassende Messwerte enthalten, 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 Zusammenfassungsmesswerte befinden sich zwar in der Messwertliste, werden aber derzeit nicht von gke-metrics-agent unterstützt.
    Logging und Monitoring 1,10, 1,11, 1,12, 1,13

    Fehlende Messwerte auf einigen Knoten

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

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

    Workaround:

    Gehen Sie wie folgt vor, um das Problem zu beheben: Für [Version 1.9.5+, 1.10.2+, 1.11.0]: Erhöhen Sie die CPU-Kapazität für den gke-metrics-agent. Führen Sie dazu die Schritte 1 bis 4 aus.

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

    Fehlende Planer- und Controller-Manager-Messwerte im Administratorcluster

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

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

    Workaround:

    Führen Sie ein Upgrade auf v1.11.3+, v1.12.1+ oder v1.13+ aus.
    1.11.0–1.11.2, 1.12.0

    Fehlende Planer- und Controller-Manager-Messwerte im Nutzercluster

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

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

    Workaround:

    Dieses Problem wurde in Google Distributed Cloud Version 1.13.0 und höher behoben. Aktualisieren Sie Ihren Cluster auf eine Version mit der Fehlerkorrektur.
    Installation, Upgrades, Updates 1,10, 1,11, 1,12, 1,13

    Fehler beim Registrieren des Administratorclusters während der Erstellung

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

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

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

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

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

    Die Verwendung des GKE Identity Service kann dazu führen, dass der Connect-Agent unvorhersehbar neu startet

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


    Workaround:

    Wenn dieses Problem bei einem vorhandenen Cluster aufgetreten ist, haben Sie folgende Möglichkeiten:

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

    Cisco ACI funktioniert nicht mit Direct Server Return (DSR)

    Seesaw wird im DSR-Modus ausgeführt und funktioniert in Cisco ACI standardmäßig nicht, da IP-Adressen auf Datenebene gelernt werden.


    Workaround:

    Eine mögliche Behelfslösung besteht darin, IP Learning zu deaktivieren. Fügen Sie dazu die Seesaw-IP-Adresse als virtuelle L4-L7-IP-Adresse im Cisco Application Policy Infrastructure Controller (APIC) hinzu.

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

    Probleme mit dem vSphere 7.0 Update 3

    VMware hat kürzlich kritische Probleme mit den folgenden Releases von vSphere 7.0 Update 3 festgestellt:

    • 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

    Fehler beim Bereitstellen des emptyDir-Volumes als exec in einem Pod, der auf COS-Knoten ausgeführt wird

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

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

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

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

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

    Das Update des Replikats des Clusterknotenpools funktioniert nicht, nachdem das Autoscaling für den Knotenpool deaktiviert wurde

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


    Workaround:

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

    Windows-Monitoring-Dashboards zeigen Daten aus Linux-Clustern an

    Ab Version 1.11 werden in den sofort einsatzbereiten Monitoring-Dashboards auf dem Windows-Pod-Status-Dashboard und dem Windows-Knotenstatus-Dashboard auch Daten von Linux-Clustern angezeigt. Das liegt daran, dass die Windows-Knoten- und Pod-Messwerte auch in Linux-Clustern verfügbar gemacht werden.
    Logging und Monitoring 1.10, 1.11, 1.12

    stackdriver-log-forwarder in konstantem CrashLoopBackOff

    Bei Google Distributed Cloud Version 1.10, 1.11 und 1.12 kann das stackdriver-log-forwarder-DaemonSet CrashLoopBackOff-Fehler haben, wenn auf dem Laufwerk fehlerhafte zwischengespeicherte Logs 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 dieses unerwartete Verhalten zu vermeiden: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
      Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.
    2. Stellen Sie das Bereinigungs-DaemonSet bereit, um unterbrochene Blöcke zu bereinigen:
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF
    3. Mit den folgenden Befehlen können Sie prüfen, ob das Bereinigungs-DaemonSet alle Teile bereinigt hat. Die Ausgabe der beiden Befehle sollte der Anzahl der Knoten im Cluster entsprechen:
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

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

    stackdriver-log-forwarder sendet keine Logs an Cloud Logging

    Wenn Sie in Cloud Logging keine Logs von Ihren Clustern sehen und den folgenden Fehler darin 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 Logeingaberate das Limit des Logging-Agents, wodurch stackdriver-log-forwarder keine Logs sendet. Dieses Problem tritt bei 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 stackdriver-Ressource zum Bearbeiten: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Fügen Sie dem stackdriver-Manifest den folgenden Abschnitt resourceAttrOverride hinzu, um die CPU-Anfrage für stackdriver-log-forwarder zu erhöhen: 
      spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
      Die bearbeitete Ressource sollte in etwa so aussehen: 
      spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
    3. Speichern Sie die Änderungen und schließen Sie den Texteditor.
    4. Führen Sie den folgenden Befehl aus, um zu prüfen, ob die Änderungen übernommen wurden: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
    | grep "cpu: 1200m"
      Der Befehl sucht nach cpu: 1200m, wenn Ihre Änderungen übernommen wurden.
    Sicherheit 1.13

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

    Der Knoten ist kurzzeitig bereit, das Kubelet-Serverzertifikat jedoch nicht. kubectl exec und kubectl logs sind in dieser Zeit nicht verfügbar. Das liegt daran, dass es einige Zeit dauert, bis der Genehmiger des neuen Serverzertifikats die aktualisierten gültigen IP-Adressen des Knotens sieht.

    Dieses Problem wirkt sich nur auf das Kubelet-Serverzertifikat aus, nicht auf die Pod-Planung.
    Upgrades, Updates 1.12

    Das teilweise Upgrade des Administratorclusters blockiert ein späteres Upgrade des Nutzerclusters nicht

    Nutzerclusterupgrade fehlgeschlagen mit:

    .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 lautet immer noch 1.10. Das Nutzercluster-Upgrade auf 1.12 wird durch keine Preflight-Prüfung blockiert und schlägt aufgrund eines Problems mit Versionsabweichung fehl.


    Workaround:

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

    Datastore meldet fälschlicherweise nicht ausreichend freien Speicherplatz

    gkectl diagnose cluster-Befehl ist fehlgeschlagen bei: 

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

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


    Workaround:

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

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

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

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


    Workaround:

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

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

    Wenn osImageType cos für den Administratorcluster verwendet und gkectl check-config nach dem Erstellen des Administratorclusters und vor dem Erstellen des Nutzerclusters ausgeführt wird, schlägt der Vorgang in folgenden Fällen fehl:

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

    Die für den Nutzercluster check-config erstellte Test-VM verwendet standardmäßig dieselbe osImageType aus dem Administratorcluster. Die Test-VM ist derzeit noch nicht mit COS kompatibel.


    Workaround:

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

    Grafana im Administratorcluster kann Nutzercluster nicht erreichen

    Dieses Problem betrifft Kunden, die Grafana im Administratorcluster verwenden, um Nutzercluster in den Google Distributed Cloud-Versionen 1.12.0 und 1.12.1 zu überwachen. Dies liegt daran, dass die pushprox-Clientzertifikate in Nutzerclustern nicht mit der Zulassungsliste im pushprox-Server im Administratorcluster übereinstimmen. Das Symptom ist „pushprox-client“ in Nutzerclustern, die Fehlerlogs wie die folgenden ausgeben:

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

    Workaround:
    Sonstiges 1.11.3

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

    gkectl repair admin-master-Befehl ist fehlgeschlagen bei: 

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

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


    Workaround:

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

    Cloud-Audit-Logging ist aufgrund verweigerter Berechtigung fehlgeschlagen

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

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

    Workaround:
    Betrieb, Sicherheit 1.11

    gkectl diagnose – Prüfung der Zertifikate fehlgeschlagen

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

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

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

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

    Workaround:

    Wenn es sicher ist, können Sie diese Meldungen ignorieren.
    Betriebssystem 1,8, 1,9, 1,10, 1,11, 1,12, 1,13

    /var/log/audit/ belegt Speicherplatz auf VMs

    /var/log/audit/ ist mit Audit-Logs gefüllt. Sie können die Laufwerksnutzung mit dem Befehl sudo du -h -d 1 /var/log/audit prüfen.

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

    Seit Google Distributed Cloud Version 1.8 wird das Ubuntu-Image mit CIS Level 2 Benchmark gehärtet. Eine der Complianceregeln, „4.1.2.2 Achten Sie darauf, dass Audit-Logs nicht automatisch gelöscht werden“, stellt die Auditd-Einstellung max_log_file_action = keep_logs sicher. Dadurch bleiben alle Audit-Regeln auf dem Laufwerk erhalten.


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

    NetworkGatewayGroup Floating-IP-Adresse steht in Konflikt mit Knotenadresse

    Nutzer können NetworkGatewayGroup-Objekte aufgrund des folgenden Fehlers beim Validierungs-Webhook nicht erstellen oder aktualisieren:

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

    In betroffenen Versionen kann sich das Kubelet fälschlicherweise an eine dem Knoten zugewiesene Floating-IP-Adresse binden und als Knotenadresse in node.status.addresses melden. Der validierende Webhook prüft die NetworkGatewayGroup-Gleitkommazahl mit allen node.status.addresses im Cluster und betrachtet dies als Konflikt.


    Workaround:

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

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

    Zeitlimit für Administratorcluster wird erstellt oder aktualisiert

    Während eines Upgrades des Administratorclusters kann die VM der Administrator-Steuerungsebene während der Erstellung hängen bleiben. Die VM der Administrator-Steuerungsebene befindet sich beim Start in eine Endlosschleife und Sie sehen den folgenden Endlosschleifenfehler in der Datei /var/log/cloud-init-output.log:

    + 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 versucht, die IP-Adresse des Knotens im Startskript abzurufen, grep -v ADMIN_CONTROL_PLANE_VIP verwendet, um die virtuelle IP-Adresse des Administratorclusters zu überspringen, die auch der NIC zugewiesen werden kann. Der Befehl überspringt jedoch auch alle IP-Adressen, die das Präfix der virtuellen IP-Adresse der Steuerungsebene haben, wodurch das Startskript hängen bleibt.

    Angenommen, die virtuelle IP-Adresse der Steuerungsebene des Administratorclusters lautet 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 Übertragungsadresse dasselbe Präfix wie die virtuelle IP-Adresse der Steuerungsebene hat, z. B. 192.168.1.255.


    Workaround:

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

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

    DataDisk kann bei Verwendung des COS-Images nicht korrekt auf dem Masterknoten des Administratorclusters bereitgestellt werden und der Status des Administratorclusters, der das COS-Image verwendet, geht beim Upgrade des Administratorclusters oder bei der Reparatur des Administratormasters verloren. (Administratorcluster, der das COS-Image verwendet, 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 und SSH in den Administrator-Master-Knoten ab. Das Ergebnis df -h enthält /dev/sdb1 98G 209M 93G 1% /opt/data. Und lsblk Ergebnis enthält -sdb1 8:17 0 100G 0 part /opt/data
    Betriebssystem 1.10

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

    In Google Distributed Cloud Version 1.10.0 werden Namensauflösungen unter Ubuntu standardmäßig zur lokalen Systemd-resolved-Überwachung auf 127.0.0.53 weitergeleitet. Dies liegt daran, dass auf dem Ubuntu 20.04-Image, das in Version 1.10.0 verwendet wird, /etc/resolv.conf per symmetrischer Verknüpfung mit /run/systemd/resolve/stub-resolv.conf verknüpft ist, was auf den DNS-Stub des localhost-Typs 127.0.0.53 verweist.

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

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


    Workaround:

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

    Derzeit unterstützt gkectl update noch nicht die Aktualisierung des Felds searchDomainsForDNS.

    Wenn Sie dieses Feld also nicht vor dem Erstellen des Clusters eingerichtet haben, müssen Sie eine SSH-Verbindung zu den Knoten herstellen und den lokalen systemd-resolved-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 enthält) in /run/systemd/resolve/resolv.conf (der auf das tatsächliche vorgelagerte DNS verweist): 

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

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

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

    Docker-Bridge-IP verwendet 172.17.0.1/16 anstelle von 169.254.123.1/24

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

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


    Workaround:

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

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

sudo systemctl daemon-reload

sudo systemctl restart docker

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

    ip a | grep docker0

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

    Upgrade auf 1.11 wird durch Stackdriver-Bereitschaft blockiert

    In Google Distributed Cloud Version 1.11.0 wurden Änderungen in der Definition von benutzerdefinierten Ressourcen für Logging und Monitoring vorgenommen:

    • Der Gruppenname der benutzerdefinierten Ressource stackdriver wurde von addons.sigs.k8s.io in addons.gke.io geändert.
    • Der Gruppenname der benutzerdefinierten Ressourcen monitoring und metricsserver wurde von addons.k8s.io in addons.gke.io geändert.
    • Die Spezifikationen der oben genannten Ressourcen werden nach und nach mit ihrem Schema verglichen. Insbesondere müssen die Spezifikation „resourceAttrOverride“ und „storageSizeOverride“ in der benutzerdefinierten Ressource stackdriver einen Stringtyp in den Werten der Anfragen und Limits für CPU, Arbeitsspeicher und Speichergröße haben.

    Die Änderungen des Gruppennamens werden vorgenommen, um den CustomResourceDefinition-Updates in Kubernetes 1.22 zu entsprechen.

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

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

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

    Zweitens: Achten Sie darauf, dass die Spezifikationswerte resourceAttrOverride und storageSizeOverride vom Typ „String“ sind. 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 Anfragen und Änderungen nicht wirksam und können zu einem unerwarteten Status in Logging- und Monitoring-Komponenten führen. Mögliche Symptome sind:

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

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

    1. Ändern Sie die Ressourcenanfragen und -limits in den Stringtyp.
    2. Entfernt alle addons.gke.io/migrated-and-deprecated: true-Anmerkungen, falls vorhanden.
    Setzen Sie dann den Upgradeprozess fort oder starten Sie ihn neu.

    Betriebssystem 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16

    COS-VMs zeigen keine IP-Adressen an, wenn VMs durch ein nicht ordnungsgemäßes Herunterfahren des Hosts verschoben werden

    Immer wenn ein Fehler in einem ESXi-Server vorliegt und die vCenter-Hochverfügbarkeitsfunktion für den Server aktiviert wurde, lösen alle VMs auf dem fehlerhaften ESXi-Server den vMotion-Mechanismus aus und werden auf einen anderen normalen ESXi-Server verschoben. Migrierte COS-VMs würden ihre IP-Adressen verlieren.

    Workaround:

    VM neu starten
    Netzwerk alle Versionen vor 1.14.7, 1.15.0-1.15.3, 1.16.0

    Von Seesaw gesendete GARP-Antwort legt keine Ziel-IP fest

    Der regelmäßige GARP (Gratuitous ARP), der alle 20 Sekunden von Seesaw gesendet wird, legt die Ziel-IP-Adresse nicht im ARP-Header fest. Einige Netzwerke (wie Cisco ACI) akzeptieren solche Pakete möglicherweise nicht. Dies kann zu einer längeren Dienstausfallzeit führen, nachdem ein Split Brain (aufgrund von VRRP-Paketabbrüchen) wiederhergestellt wurde.

    Workaround:

    Lösen Sie einen Seeaw-Failover aus, indem Sie sudo seesaw -c failover auf einer der Seesaw-VMs ausführen. Dadurch sollte der Traffic wiederhergestellt werden.
    Betriebssystem 1.16, 1.28.0–1.28.200

    Kubelet wird mit Logs überschwemmt, die besagen, dass „/etc/kubernetes/manifests“ auf den Worker-Knoten nicht vorhanden ist

    "staticPodPath" wurde fälschlicherweise für Worker-Knoten festgelegt

    Workaround:

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