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

Auf dieser Seite werden alle bekannten Probleme von Google Distributed Cloud auf VMware aufgeführt. Zum Filtern der bekannten Probleme nach einer Produktversion oder -kategorie wählen Sie in den folgenden Drop-down-Menüs die gewünschten Filter aus.

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

Wählen Sie die Problemkategorie aus:

Oder suchen Sie nach Ihrem Problem:

Kategorie Erkannte Version(en) Problem und Problemumgehung
Updates 1.29.0

Nach der Migration eines Nutzerclusters zu Controlplane V2 wird das Messwertserver-PDB des Administratorclusters möglicherweise falsch konfiguriert.

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

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes -o wide

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

Symptome:

Die Ausgabe von Administratorclusterdiagnose enthält die folgenden Informationen

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

Workaround:

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

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

Webhook der Binärautorisierung blockiert den Start des CNI Plug-ins, was dazu führt, dass einer der Nodepools nicht gestartet wird.

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

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

Workaround:

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

CPV2 Nutzercluster-Upgrade bleibt aufgrund eines gespiegelten Rechners mit deletionTimestamp hängen

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

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

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

Workaround:

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

Fehler beim Erstellen des Clusters aufgrund von virtueller IP-Adresse der Steuerungsebene in einem anderen Subnetz

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

Workaround:

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

Fehler beim Erstellen/Upgraden des Clusters aufgrund eines Nicht-FQDN-vCenter-Nutzernamens

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

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

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

Workaround:

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

Das Upgrade des Administratorclusters schlägt für Cluster fehl, die in Version 1.10 oder früher erstellt wurden

Beim Upgrade eines Administratorclusters von 1.16 auf 1.28 kann der Bootstrap der neuen Administrator-Mastermaschine möglicherweise das Zertifikat der Steuerungsebene nicht generieren. Das Problem wird durch Änderungen bei der Generierung von Zertifikaten für den Kubernetes API-Server in Version 1.28 und höher verursacht. Das Problem wird für Cluster reproduziert, die unter Version 1.10 und früher erstellt wurden und bis auf Version 1.16 aktualisiert wurden. Das untergeordnete Zertifikat wurde vor dem Upgrade nicht rotiert.

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

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

Workaround:

  1. Stellen Sie eine SSH-Verbindung zum Administrator-Mastercomputer her. Weitere Informationen finden Sie unter SSH zum Herstellen einer Verbindung zu einem Administratorclusterknoten verwenden.
  2. /etc/startup/pki-yaml.sh bearbeiten Suchen Sie authorityKeyIdentifier=keyidset und ändern Sie es zu authorityKeyIdentifier=keyid,issuer in den Abschnitten für folgende Erweiterungen: apiserver_ext, client_ext etcd_server_ext und kubelet_server_ext. Beispiel: 
          [ apiserver_ext ]
      keyUsage = critical, digitalSignature, keyEncipherment
      extendedKeyUsage=serverAuth
      basicConstraints = critical,CA:false
      authorityKeyIdentifier = keyid,issuer
      subjectAltName = @apiserver_alt_names
  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 um den Computerstart abzuschließen.
  5. Führen Sie die gkectl upgrade admin noch einmal aus, um das Upgrade für den Administrator-Cluster durchzuführen.
  6. Rotieren Sie nach Abschluss des Upgrades das untergeordnete Zertifikat für beide Administratoren und Nutzercluster, wie unter Rotation starten beschrieben.
  7. Nehmen Sie nach Abschluss der Zertifikatsrotation die gleichen Änderungen an /etc/startup/pki-yaml.sh vor wie zuvor und führen Sie /opt/bin/master.sh aus.
Konfiguration 1.29.0

Falsche Warnmeldung für Cluster mit aktiviertem Dataplane V2

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

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

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

Workaround:

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

Die Preflight-Prüfung für die Hochverfügbarkeit von Administratorclustern meldet die falsche Anzahl von erforderlichen statischen IP-Adressen

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

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

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

Workaround:

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

Connect Agent verliert die Verbindung zu Google Cloud nach der Migration eines Administratorclusters ohne HA zu einem HA-Administratorcluster

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

Workaround:

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

Rufen Sie zuerst den Bereitstellungsnamen gke-connect ab:

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

Löschen Sie das Deployment gke-connect:

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

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

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

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

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

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

Brücken-IP-Adresse von Docker verwendet 172.17.0.1/16 für Knoten der COS-Cluster-Steuerungsebene

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

Workaround:

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

sudo systemctl restart docker

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

ip a | grep docker0

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

Die Verwendung mehrerer Netzwerkschnittstellen mit Standard-CNI funktioniert nicht

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

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

Workaround:

Führen Sie ein Upgrade auf die Version mit der Fehlerkorrektur durch, wenn Sie diese Funktion verwenden.
update 1.15, 1.16, 1.28

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

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

Workaround:

  • multipathd deaktivieren
Updates 1.15, 1.16

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

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

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

Workaround:

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

Das Feld controlPlaneNodePort ist standardmäßig auf 30968 gesetzt, wenn die Spezifikation für manualLB leer ist

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

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

Workaround:

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

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

nfs-common fehlt im Ubuntu-Betriebssystem-Image

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

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

Workaround:

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

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

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

Das Feld für die Speicherrichtlinie fehlt in der Konfigurationsvorlage für den Administratorcluster

SPBM in Administratorclustern wird in Versionen ab 1.28.0 unterstützt. Aber das Feld vCenter.storagePolicyName fehlt in der Konfigurationsdateivorlage.

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. Hier finden Sie eine Anleitung.
Logging und Monitoring 1.28.0-1.28.100

Kubernetes Metadata API unterstützt VPC-SC nicht

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

Workaround:

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

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

Führen Sie dann diesen Befehl aus:

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

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

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

Wenn ein Administratorcluster und ein Nutzercluster mit aktivierter Steuerungsebene v2 unterschiedliche vSphere-Anmeldedaten verwenden, z.B. nach einer Aktualisierung der vSphere-Anmeldedaten für den Administratorcluster, kann der clusterapi-controller nach einem Neustart möglicherweise keine Verbindung zum vCenter herstellen. Sehen Sie sich das Log des clusterapi-controllers an, der im Namespace `kube-system` des Administratorclusters ausgeführt wird,

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

Workaround:

Aktualisieren Sie vSphere-Anmeldedaten, damit der Administratorcluster und alle Nutzercluster mit aktivierter Steuerungsebene v2 dieselben vSphere-Anmeldedaten verwenden.

Logging und Monitoring 1.14

etcd hohe Anzahl von fehlgeschlagenen GRPC-Anfragen im Prometheus Alert Manager

Prometheus kann Benachrichtigungen ähnlich wie die folgenden melden:

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

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

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

    Sie können diesen Messwert mit 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 über alle anderen Codes als OK kann bedenkenlos ignoriert werden, wenn der Code nicht zu den folgenden gehört: 
    Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded

Workaround:

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

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

Langlebige NAT-Verbindungen für ausgehenden Traffic werden unterbrochen

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

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

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


Workaround:

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

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

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

Workaround:

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

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

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

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

Dieser Fehler tritt auf, weil gkectl während der Preflight-Prüfungen nach einer Load Balancer-Ingress-IP-Adresse sucht. Obwohl diese Prüfung nicht erforderlich ist, wenn gebündelter eingehenden Traffic deaktiviert wird, schlagen die gkectl Preflight-Prüfung fehl, wenn disableBundledIngress auf true festgelegt ist.


Workaround:

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

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

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

Updates von Administratorclustern schlagen nach der CA-Rotation fehl

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

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

Workaround:

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

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

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

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

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

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

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

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

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

Prüfen Sie, ob der Fehler auf zu wenige festgelegte Pod-Ressourcen zurückzuführen ist. Führen Sie dazu den Befehl Befehl „anthos-csi-workload-writer-<run-id>“ aus, um den Jobstatus zu prüfen:

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

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

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

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

kubectl label namespace default istio.io/rev-

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

  1. Erstellen Sie einen PVC, der die Speicherklasse standard-rwo verwendet.
  2. Erstellen Sie einen Pod, der den PVC verwendet.
  3. Stellen Sie sicher, dass der Pod Daten auf das Volume lesen/schreiben kann.
  4. Entfernen Sie den Pod und den PVC, nachdem Sie den ordnungsgemäßen Betrieb geprüft haben.

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

Vorgang 1.16.0-1.16.2

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

Wenn Sie bei einer nutzerverwalteten Administrator-Workstation angemeldet sind, kann es vorkommen, dass der Befehl gkectl update cluster eine Zeitüberschreitung verursacht und der Nutzercluster nicht aktualisiert werden kann. Das passiert, wenn die Version des Administratorclusters 1.15 ist und Sie gkectl update admin ausführen, bevor Sie gkectl update cluster ausführen. Wenn dieser Fehler auftritt, wird der folgende Fehler angezeigt, wenn Sie versuchen, den Cluster zu aktualisieren: 

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

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

Workaround:

  1. Führen Sie den folgenden Befehl aus, um validation-controller 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

Nutzercluster erstellen Zeitüberschreitungen, wenn die Version des Administratorclusters 1.15 ist

Wenn Sie bei einer nutzerverwalteten Administrator-Workstation angemeldet sind, kann es vorkommen, dass der Befehl gkectl create cluster eine Zeitüberschreitung verursacht und der Nutzercluster nicht erstellt werden kann. Das passiert, wenn die Version des Administratorclusters 1.15 ist. Wenn dieser Fehler auftritt, wird beim Erstellen des Clusters der folgende Fehler angezeigt: 

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

Da validation-controller in 1.16 hinzugefügt wurde, fehlt bei Verwendung des 1.15-Administratorclusters die validation-controller, die für das Auslösen der Preflight-Prüfungen verantwortlich ist. Wenn Sie also versuchen, einen Nutzercluster zu erstellen, bleiben die Preflight-Prüfungen hängen, bis eine Zeitüberschreitung erreicht ist.

Workaround:

  1. Führen Sie den folgenden Befehl aus, um 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

Das Update oder das Upgrade des Administratorclusters schlägt fehl, wenn die Projekte oder Standorte der Add-on-Dienste nicht übereinstimmen.

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

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

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


Workaround:

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

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

      • gkectl upgrade admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --disable-upgrade-from-checkpoint
    • Bei Hochverfügbarkeits-Administratorclustern oder falls eine Checkpoint-Datei deaktiviert ist: Administratorcluster wie gewohnt aktualisieren oder upgraden. Keine zusätzlichen Parameter sind für die Aktualisierungs- oder Upgradebefehle erforderlich.
Vorgang 1.16.0-1.16.2

Das Löschen von Nutzerclustern schlägt bei Verwendung einer vom Nutzer verwalteten Administrator-Workstation fehl

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

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

Dabei werden zuerst alle zugehörigen Objekte eines Clusters gelöscht. Das Löschen der Validierungsobjekte, die während der Erstellung, Aktualisierung oder des Upgrades erstellt wurden, bleiben in der Löschphase hängen. Das passiert, weil ein Finalizer das Löschen des Objekts blockiert, was dazu führt, dass das Löschen des Clusters fehlschlägt.

Workaround:

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

    Nach dem Entfernen des Finalizers aus allen Validierungsobjekten werden die Objekte entfernt und der Löschvorgang 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 Egress-NAT-Gateway-Pod auf zwei verschiedenen Worker-Knoten befinden, kann der Traffic vom Quell-Pod keine externen Dienste erreichen. Befinden sich die Pods auf demselben Host, ist die Verbindung zum externen Dienst oder zur externen Anwendung erfolgreich.

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


Workaround:

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

  1. ConfigMap cilium-config bearbeiten: 
    kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
  2. Fügen Sie Folgendes der ConfigMap cilium-config 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 muss nach jedem Upgrade neu konfiguriert werden. VMware muss das Problem in vSphere beheben, um eine dauerhafte Lösung zu finden.
Upgrades 1.15.0-1.15.4

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

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

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

Die Ausführung von kubectl get secrets -A --kubeconfig KUBECONFIG` schlägt mit 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, gehen Sie so vor, um den Upgradefehler zu umgehen:

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

Upgradefehler verhindern

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

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

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

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


Workaround:

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

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

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

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

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


Workaround:

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

Versionsabweichung zwischen Kubelet und der Kubernetes-Steuerungsebene

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

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

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

Workaround:

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

Upgrades, Updates 1.15.0-1.15.4

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

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

    CAVersion must start from 1

Workaround:

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

Löschen von Nicht-HA-Steuerungsebenen-V2-Clustern hängt bis Zeitüberschreitung

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

Workaround:

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

Andernfalls gehen Sie so vor:

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

Speicher 1.15.0+, 1.16.0+

Konstante CNS-attachvolume-Aufgaben werden für integriertes PVC/PV nach dem Upgrade auf Version 1.15 oder höher jede Minute angezeigt.

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


Workaround:

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

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

Starten Sie die vSphere CSI-Controller-Pods neu:

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

Falsche Warnungen vor PVCs

Wenn ein Cluster integrierte nichtflüchtige vSphere-Volumes enthält, lösen die Befehle gkectl diagnose und gkectl upgrade beim Validieren der Cluster-Speichereinstellungen möglicherweise falsche Warnungen vor ihren Anforderungen an nichtflüchtigen Volumes (Persistent Volume Claims, PVCs) aus. Die Warnmeldung sieht so aus: 

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

Workaround:

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

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

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

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

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

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

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

Workaround:

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

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

1.15 Der Master-Computer des Nutzers stößt auf eine unerwartete Neuerstellung, wenn der Nutzercluster-Controller auf 1.16 aktualisiert wird

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

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

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

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

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

Option 2: Gehen Sie so vor:

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

    Die Wiederholungsannotation lautet:

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

Problemumgehung beim Upgrade des Nutzerclusters mit Ihrer eigenen Administratorworkstation:

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

Option 2: Gehen Sie so vor:

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

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

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

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

In der Preflight-Prüfung liegt ein Fehler vor, der davon ausgeht, dass ein leerer Hostname als Duplikat vorliegt.

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

Fehler bei der Volume-Bereitstellung beim Upgrade/Aktualisieren des Administratorclusters, wenn ein Nicht-HA-Administratorcluster und der v1-Nutzercluster der Steuerungsebene verwendet werden

Bei einem Nicht-HA-Administratorcluster und einem Nutzercluster auf Steuerungsebene v1 kann es vorkommen, dass bei einem Upgrade oder einer Aktualisierung des Administratorclusters der Neustart des Administratorcluster-Mastercomputers gleichzeitig mit dem Neustart des Nutzercluster-Mastercomputers erfolgt, was zu einer Race-Bedingung führen kann. Dadurch können die Pods der Nutzercluster-Steuerungsebene nicht mit der Steuerungsebene des Administratorclusters kommunizieren. Dies führt zu Problemen beim Anhängen von Volumes für kube-etcd und kube-apiserver auf der Steuerungsebene des Nutzerclusters.

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

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

Workaround:

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

Knoten der Steuerungsebene kann nicht erstellt werden

Während eines Upgrades oder Updates eines Administratorclusters kann eine Race-Bedingung dazu führen, dass der vSphere Cloud Controller-Manager unerwartet einen neuen Knoten der Steuerungsebene löscht. Dies führt dazu, dass der clusterapi-Controller auf die Erstellung des Knotens warten muss und sogar das Upgrade/Update ausfällt. In diesem Fall sieht die Ausgabe des Befehls gkectl upgrade/update ähnlich aus wie die folgende:

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

Führen Sie den folgenden Befehl aus, um das Symptom zu identifizieren und die Logs im vSphere Cloud Controller-Manager im Administratorcluster abzurufen:

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

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

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

Workaround:

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

Doppelter Hostname im selben Rechenzentrum führt zu Fehlern beim Clusterupgrade oder bei der Erstellung

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

Rufen Sie zum Identifizieren des Problems die Pod-Logs des vSphere Cloud Controller-Managers für den Cluster ab. Welchen Befehl Sie verwenden, hängt vom Clustertyp ab:

  • Administratorcluster: 
          kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
      kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n kube-system
  • Nutzercluster (kubeception): 
          kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME | grep vsphere-cloud-controller-manager
      kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME
    .
  • Nutzercluster: (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 ein Beispiel für eine Fehlermeldung:

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

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

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

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

Problemumgehung für Upgrades:

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

  • Nutzercluster:
    1. Aktualisieren Sie den Hostnamen des betroffenen Computers in user-ip-block.yaml auf einen eindeutigen Namen und lösen Sie eine erzwungene Aktualisierung aus:
                gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config NEW_USER_CLUSTER_CONFIG --force
    2. gkectl upgrade cluster wiederholen
  • Administratorcluster:
    1. Aktualisieren Sie den Hostnamen der betroffenen Maschine in „admin-ip-block.yaml“ zu einem eindeutigen Namen und lösen Sie ein erzwungenes Update aus:
                gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config NEW_ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check
    2. Wenn es sich um einen Administratorcluster ohne Hochverfügbarkeit handelt und Sie feststellen, dass die Administrator-Master-VM einen doppelten Hostnamen verwendet, müssen Sie außerdem Folgendes tun:
      Name der Administrator-Master-Maschine abrufen 
                kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A
      Objekt der Administrator-Master-Maschine aktualisieren
      Hinweis: Der NEW_ADMIN_MASTER_HOSTNAME muss mit dem übereinstimmen, was Sie in Schritt 1 in der Datei „admin-ip-block.yaml“ festgelegt haben.
                kubectl patch machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG --type='json' -p '[{"op": "replace", "path": "/spec/providerSpec/value/networkSpec/address/hostname", "value":"NEW_ADMIN_MASTER_HOSTNAME"}]'
      Prüfen Sie, ob der Hostname im Administrator-Master-Maschinenobjekt aktualisiert wurde:
                kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -oyaml
          kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -o jsonpath='{.spec.providerSpec.value.networkSpec.address.hostname}'
      .
    3. 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 bei Installationen:

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

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

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

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

Verwenden Sie eine Version 1.16.4 oder höher von Google Distributed Cloud mit der Fehlerbehebung oder führen Sie die folgende Problemumgehung durch. Die Problemumgehung hängt davon ab, welcher Vorgang fehlgeschlagen ist.

Problemumgehung für Upgrades:

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

Problemumgehung bei Installationen:

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

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

Nachdem ein Knoten gelöscht und dann mit demselben Knotennamen neu erstellt wurde, besteht die Möglichkeit, dass die nachfolgende Erstellung von PersistentVolumeClaim (PVC) mit einem Fehler wie dem folgenden fehlschlägt:

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

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


Workaround:

Starten Sie die vSphere CSI-Controller-Pods neu:

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

gkectl repair admin-master gibt einen kubeconfig-Unmarshall-Fehler zurück

Wenn Sie den Befehl gkectl repair admin-master für einen Hochverfügbarkeits-Administratorcluster ausführen, gibt gkectl die folgende Fehlermeldung zurück: 

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

Workaround:

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

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

So finden Sie die VM-Vorlage der Maschine:

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

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

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

Seesaw-VM aufgrund von zu wenig Speicherplatz unterbrochen

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

    GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd

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


Workaround:

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

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

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

Fehler beim öffentlichen SSH-Schlüssel nach dem Upgrade oder der Aktualisierung des Administratorclusters

Beim Versuch, ein Upgrade (gkectl upgrade admin) oder eine Aktualisierung (gkectl update admin) eines nicht hochverfügbaren Administratorclusters mit aktiviertem Prüfpunkt durchzuführen, kann das Upgrade oder die Aktualisierung mit Fehlern wie den folgenden fehlschlagen: 

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

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

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


Workaround:

Wenn Sie 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 Administratorclusters, der in der GKE On-Prem API registriert ist, kann fehlschlagen

Wenn ein Administratorcluster in der GKE On-Prem API registriert ist, schlägt ein Upgrade des Administratorcluster auf die betroffenen Versionen möglicherweise fehl, da die Flottenmitgliedschaft nicht aktualisiert werden konnte. Wenn dieser Fehler auftritt, erhalten Sie den folgenden Fehler, wenn Sie versuchen, ein Upgrade für den Cluster auszuführen:

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

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


Workaround:

Melden Sie den Administratorcluster ab: 
    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
und setzen Sie das Upgrade des Administratorclusters fort. Möglicherweise sehen Sie vorübergehend die veraltete Fehlermeldung „Fehler bei der Registrierung des Clusters“. Nach einer Weile sollte er automatisch aktualisiert werden.
Upgrades, Updates 1.13.0-1.13.9, 1.14.0-1.14.4, 1.15.0

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

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


Workaround:

Melden Sie den Administratorcluster ab: 
    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
und melden Sie den Administratorcluster noch einmal an.
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, was dazu führt, dass orderPolicy ignoriert wird.


Workaround:

Aktualisieren Sie die CoreDNS-Vorlage und wenden Sie die Fehlerkorrektur an. Diese Lösung 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 zwischen Prüfpunkt und tatsächlicher Antwortvorlage inkonsistent

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

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

Änderungen an Administratorzertifikaten für Administratorcluster beim Abgleich

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

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

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

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

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

Workaround:

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

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

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

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

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


Workaround:

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

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

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

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

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

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

Löschen Sie den Namespace gke-connect: 

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

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

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

gkectl prepare windows schlägt fehl.

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


Workaround:

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

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


Option 1: Blau/Grün-Upgrade

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

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


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

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

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

RootDistanceMaxSec-Konfiguration wird nicht wirksam für ubuntu Knoten

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

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

Die Verwendung eines 5-Sekunden-RootDistanceMaxSec kann dazu führen, dass die Systemuhr nicht mehr mit dem NTP-Server synchronisiert ist, wenn die Abweichung der Uhr größer als 5 Sekunden ist.


Workaround:

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

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

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

Wenn Sie die Version 1.13 gkectl verwenden, um einen Administratorcluster der Version 1.12 zu aktualisieren, wird möglicherweise der folgende Fehler angezeigt:

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

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

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

Wenn Sie das Log von gkectl prüfen, sehen Sie möglicherweise, dass zu den mehrfachen Änderungen das Setzen von osImageType von einem leeren String auf ubuntu_containerd gehört.

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


Workaround:

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

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:

Bis ein Google Distributed Cloud-Patch mit der Fehlerbehebung verfügbar ist, sollten Sie, wenn Sie SNI verwenden müssen, die Steuerungsebene V2 deaktivieren (enableControlplaneV2: false).
Installation 1.0-1.11, 1.12, 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

$ im Nutzernamen der privaten Registry führt zu einem Startfehler der Maschine für die Administratorsteuerungsebene

Die Maschine der Administrator-Steuerungsebene kann nicht gestartet werden, wenn der Nutzername der privaten Registry $ enthält. Wenn Sie die /var/log/startup.log auf der Maschine der Administrator-Steuerungsebene prüfen, sehen Sie den folgenden Fehler: 

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

.

Workaround:

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

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

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

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

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

Nach der Rotation der KSA-Signaturschlüssel und der anschließenden Aktualisierung der Nutzercluster, schlägt gkectl update möglicherweise mit der folgenden Fehlermeldung fehl: 

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


Workaround:

Ändern Sie die Version Ihres KSA-Signaturschlüssels wieder auf 1, behalten Sie jedoch die neuesten Schlüsseldaten bei:
  1. Prüfen Sie das Secret im Administratorcluster unter dem Namespace USER_CLUSTER_NAME und rufen Sie den Namen des Secrets für den Schlüssel „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 von ksa-signing-key-rotation-stage auf '{"tokenVersion":1,"privateKeyVersion":1,"publicKeyVersions":[1]}': 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME \
edit configmap ksa-signing-key-rotation-stage
    .
  5. Deaktivieren Sie den Validierungs-Webhook, um die Versionsinformationen in der benutzerdefinierten Ressource „OnPremUserCluster“ zu bearbeiten: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    resources:
    - onpremuserclusters
'
  6. Aktualisieren Sie in Ihrer benutzerdefinierten Ressource „OnPremUserCluster“ das Feld spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation auf 1: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
edit onpremusercluster USER_CLUSTER_NAME
    .
  7. Warten Sie, bis der Zielnutzercluster bereit ist. Sie können den Status prüfen: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
  8. Stellen Sie den Validierungs-Webhook für den Nutzercluster wieder her: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremuserclusters
'
  9. Vermeiden Sie eine weitere Rotation des KSA-Signaturschlüssels, bis für den Cluster ein Upgrade auf die Version mit der Korrektur durchgeführt wurde.
Vorgang 1.13.1+, 1.14, 1., 1.16

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

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


Workaround:

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

Kind-Cluster ruft die Container-Images von docker.io ab

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

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

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

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

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

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

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


    Workaround:

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

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

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

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

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

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

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


    Workaround:

    Führen Sie 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 nach der vCenter-Zertifikatrotation sein vCenter-Secret aktualisieren. Das aktuelle System startet jedoch die Pods von vsphere-csi-controller nicht ordnungsgemäß neu, wodurch vsphere-csi-controller nach der Rotation abstürzt.

    Workaround:

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

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

    Das Erstellen des Administratorclusters schlägt bei Clusterregistrierungsfehlern nicht fehl

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

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

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

    Workaround:

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

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

    Upgrades, Updates 1.10, 1.11, 1.12, 1.13.0-1.13.1

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

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


    Workaround:

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

    Konfiguration 1.15.0

    Falsche Fehlermeldung zu vCenter.dataDisk

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

    vCenter.dataDisk must be present in the AdminCluster spec

    Workaround:

    Sie können dieses Fehlermeldung einfach ignorieren.
    VMware 1.15.0

    Knotenpool kann aufgrund redundanter VM-Host-Affinitätsregeln nicht erstellt werden

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


    Workaround:

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

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

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

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


    Workaround:

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

    Pods bleiben nach der Neuerstellung oder Aktualisierung eines Knotens auf der Steuerungsebene im Status „Fehlgeschlagen“.

    Nachdem Sie einen Knoten auf der Steuerungsebene neu erstellt oder aktualisiert haben, können bestimmte Pods aufgrund eines NodeAffinity-Prädikatsfehlers im Failed-Zustand verbleiben. Diese fehlgeschlagenen Pods haben keine Auswirkungen auf normale Clustervorgänge oder -integrität.


    Workaround:

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

    OnPremUserCluster ist aufgrund von Anmeldedaten für die private Registry nicht bereit

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

    failed to check secret reference for private registry …


    Workaround:

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

    Upgrades, Updates 1.15.0

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

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

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


    Workaround:

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

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


    Workaround:

    1. Rufen Sie die UID des Pods ab, der nicht auf sein Volume schreiben kann: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
    POD_NAME --namespace POD_NAMESPACE \
    -o=jsonpath='{.metadata.uid}{"\n"}'
    2. Rufen Sie mit dem PersistentVolumeClaim den Namen des PersistentVolume ab: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
    PVC_NAME --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.volumeName}{"\n"}'
    3. Ermitteln Sie den Namen des Knotens, auf dem der Pod ausgeführt wird: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
    --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.nodeName}{"\n"}'
    4. Erhalten 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 Nummer des Laufwerks, das mit PersistentVolume verknüpft ist: 
      PS C:\Users\administrator> disknum=(Get-Partition -Volume (Get-Volume -UniqueId ("\\?\"+(Get-Item (Get-Item
"C:\var\lib\kubelet\pods\$podid\volumes\kubernetes.io~csi\$pvname\mount").Target).Target))).DiskNumber
    7. Prüfen Sie, ob das Laufwerk readonly ist: 
      PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
      Das Ergebnis sollte True sein.
    8. Setzen Sie readonly auf false. 
      PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
    9. Löschen Sie den Pod, damit er neu gestartet wird: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
    --namespace POD_NAMESPACE
    10. Der Pod sollte für denselben Knoten geplant werden. Für den Fall, dass der Pod auf einem neuen Knoten geplant wird, müssen Sie die vorangegangenen Schritte auf dem neuen Knoten wiederholen.

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

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

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


    Workaround:

    1. Rufen Sie den Namen des vsphere-csi-secret-Secrets ab: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
    2. Aktualisieren Sie die Daten des Secrets vsphere-csi-secret, das Sie im obigen Schritt erhalten haben: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system patch secret CSI_SECRET_NAME -p \
  "{\"data\":{\"config\":\"$( \
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets CSI_SECRET_NAME -ojsonpath='{.data.config}' \
      | base64 -d \
      | sed -e '/user/c user = \"VSPHERE_USERNAME_TO_BE_UPDATED\"' \
      | sed -e '/password/c password = \"VSPHERE_PASSWORD_TO_BE_UPDATED\"' \
      | base64 -w 0 \
    )\"}}"
    3. vsphere-csi-controller neu starten: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller
    4. So können Sie den Roll-out-Status verfolgen: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
      Nachdem die Bereitstellung erfolgreich eingeführt wurde, sollte der 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

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

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


    Workaround:

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

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

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

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

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

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

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


    Workaround:

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

    Der fehlerhafte Release 1.12.7-gke.19 wurde entfernt

    Google Distributed Cloud 1.12.7-gke.19 ist eine schlechte Version, die Sie nicht verwenden sollten. Die Artefakte wurden aus dem Cloud Storage-Bucket entfernt.

    Workaround:

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

    gke-connect-agent verwendet weiterhin das ältere Image, nachdem die Registrierungsanmeldedaten aktualisiert wurden

    Wenn Sie die Registry-Anmeldedaten mit einer der folgenden Methoden aktualisieren:

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

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

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


    Workaround:

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

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

      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: Sie können das Standard-Image-Pull-Secret für Ihren Cluster in der Bereitstellung gke-connect-agent hinzufügen:

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

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

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

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

    Workaround:

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

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

    gkectl check-config --skip-validation-load-balancer
    Vorgang 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, and 1.14

    etcd-Monitoringmangel

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

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

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

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

    Problemumgehung

    Wenn Sie kein sofortiges Upgrade durchführen können, verringern Sie einen Clusterfehler durch Reduzieren der Knotenanzahl im Cluster. Entfernen Sie Knoten bis der etcd_network_client_grpc_sent_bytes_total-Messwert unter 300 Mbit/s liegt.

    So rufen Sie diesen Messwert im Metrics Explorer auf:

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

      Zum Metrics Explorer

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

    GKE Identity Service kann zu Latenzen der Steuerungsebene führen

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

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

    • 1.12.6+
    • 1.13.6+
    • 1.14.2+

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

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

      Ersetzen Sie CLUSTER_ENDPOINT mit der virtuellen IP-Adresse der Steuerungsebene und dem Load-Balancer-Port der Steuerungsebene für Ihren Cluster (z. B. 172.16.20.50:443).

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

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

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

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

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

        Administratorcluster:

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

        Nutzercluster:

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

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

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

    Problemumgehung

    Wenn Sie Ihre Cluster nicht sofort aktualisieren können, um das Problem zu beheben, haben Sie folgende Möglichkeiten: Identifizieren Sie die betroffenen Pods und starten Sie sie neu, um das Problem zu umgehen:

    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 Identity Service auf den ungültigen Tokenkontext: 
      kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG
    3. Um die mit jedem ungültigen Token-Kontext verknüpfte Token-Nutzlast abzurufen, parsen Sie jedes zugehörige Dienstkonto-Secret mit dem folgenden Befehl: 
      kubectl -n kube-system get secret SA_SECRET \
    --kubeconfig KUBECONFIG \
    -o jsonpath='{.data.token}' | base64 --decode
    4. Um das Token zu decodieren und den Namen und den Namespace des Quell-Pods aufzurufen, kopieren Sie das Token an den Debugger unter jwt.io.
    5. Starten Sie die in den Tokens identifizierten Pods neu.
    Vorgang 1.8, 1.9, 1.10

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

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


    Workaround:

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

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

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

    Systemdiagnosen von Pods der Steuerungsebene des Nutzerclusters fehlen

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


    Workaround:

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

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

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

    Kubernetes hat den Traffic am 20.03.2023 von k8s.gcr.io zu registry.k8s.io umgeleitet. 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 zur Zulassungsliste des Proxys für Ihre Administrator-Workstation hinzu.
    Netzwerk 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    Seesaw-Validierungsfehler beim Erstellen des Load-Balancers

    gkectl create loadbalancer schlägt mit folgender Fehlermeldung fehl:

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

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

    Workaround:

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

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

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

    Ob Sie von diesem Problem betroffen sind, können Sie mit folgendem Befehl in den Systemstatistiken des Kernel-Verbindungstrackings auf jedem Knoten überprüfen:

    sudo conntrack -S

    Die Antwort sieht so aus:

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

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

    Problemumgehung

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

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

    Ersetzen Sie TABLE_SIZE durch die neue Größe in Byte. Der Standardwert für die Tabellengröße ist 262144. Wir empfehlen einen Wert, der dem 65.536-fachen der Anzahl der Kerne auf dem Knoten entspricht. Beispiel: Wenn Ihr Knoten acht Kerne hat, legen Sie die Tabellengröße auf 524288 fest.
    Netzwerk 1.13.0-1.13.2

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

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

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


    Workaround:

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

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

    Entfernen Sie folgende spec.template.spec.tolerations:

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

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

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

    Die Datei mit den Anmeldedaten für die private Registry des Nutzerclusters kann nicht geladen werden.

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

    [FAILURE] Docker registry access: Failed to login.


    Workaround:

    • Wenn Sie das Feld nicht angeben wollten oder dieselben Anmeldedaten für die private Registry wie der Administratorcluster verwenden möchten, können Sie den Abschnitt privateRegistry in der Konfigurationsdatei des Nutzerclusters einfach entfernen oder kommentieren.
    • Wenn Sie private Registry-Anmeldedaten für einen bestimmten Nutzercluster verwenden möchten, können Sie den privateRegistry-Abschnitt 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 sind bereits veraltet. Verwenden Sie die Anmeldedaten-Datei, wenn Sie auf 1.14.3+ aktualisieren).

    Vorgänge 1.10+

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

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

    Dies wird im kube-proxy-freien Modus durch Verbindungsverlust oder falsches Trafficrouting für Dienste mit Cloud Service Mesh sichtbar, da die Sidecar-Datei keine Paketprüfung durchführen kann.

    Dieses Problem tritt bei allen Versionen von Google Distributed Cloud 1.10 auf. Einige neuere Versionen von 1.10 (1.10.2 und höher) haben jedoch eine Problemumgehung.


    Workaround:

    Führen Sie entweder ein Upgrade auf 1.11 für die vollständige Kompatibilität durch oder führen Sie Folgendes aus, wenn Sie 1.10.2 oder höher verwenden:

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

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

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

    Speicher 1.12+, 1.13.3

    kube-controller-manager trennt möglicherweise nichtflüchtige Volumes nach 6 Minuten erzwungenermaßen

    kube-controller-manager kann beim Trennen von PV/PVCs nach 6 Minuten eine Zeitüberschreitung verursachen und die PV/PVCs erzwungenermaßen trennen. Detaillierte Logs von kube-controller-manager zeigen ähnliche Ereignisse an wie die folgenden:

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

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

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

    # See all the mounting points with disks
lsblk -f

# See some ext4 errors
sudo dmesg -T

    Im kubelet-Log werden Fehler wie die folgenden angezeigt:

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

    Workaround:

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

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

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

    gkectl repair admin-master erstellt die Administrator-Master-VM, ohne die VM-Hardwareversion zu aktualisieren.

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

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


    Workaround:

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

    Die VM gibt die DHCP-Freigabe beim Herunterfahren/Neustarten unerwartet aus, was zu Änderungen der IP-Adresse führen kann.

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

    Zum Beispiel können die folgenden Symptome auftreten.

    • Die vCenter-Benutzeroberfläche zeigt an, 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 von calico-node-Fehler nicht gestartet werden 
      2023-01-19T22:07:08.817410035Z 2023-01-19 22:07:08.817 [WARNING][9] startup/startup.go 1135: Calico node 'node1' is already using the IPv4 address 10.180.85.130.
2023-01-19T22:07:08.817514332Z 2023-01-19 22:07:08.817 [INFO][9] startup/startup.go 354: Clearing out-of-date IPv4 address from this node IP="10.180.85.130/24"
2023-01-19T22:07:08.825614667Z 2023-01-19 22:07:08.825 [WARNING][9] startup/startup.go 1347: Terminating
2023-01-19T22:07:08.828218856Z Calico node failed to start


    Workaround:

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

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

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

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

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

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

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

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

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


    Behelfslösung:

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

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

    Cluster-Autoscaling funktioniert nicht, wenn Steuerungsebene v2 aktiviert ist

    Bei Nutzerclustern, die mit Steuerungsebene v2 oder einem neuen Installationsmodell erstellt wurden, verwenden Knotenpools mit aktiviertem Autoscaling immer ihre autoscaling.minReplicas in der Datei user-cluster.yaml. Das Log des Cluster-Autoscaling-Pods zeigt auch an, dass dessen Pods fehlerhaft sind. 

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


    Behelfslösung:

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

    CIDR in der IP-Blockdatei nicht zulässig

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

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


    Behelfslösung:

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

    Das Update des Betriebssystem-Image-Typs in der Datei admin-cluster.yaml wartet nicht darauf, dass Maschinen der Nutzersteuerungsebene neu erstellt werden

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


    Behelfslösung:

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

    Vorgang 1.10, 1.11, 1.12, 1.13, 1.14.0

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

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

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


    Workaround:

    Dieses Problem wurde in Google Distributed Cloud Version 1.14.1 behoben. Upgrade auf diese oder eine neuere Version.

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

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

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

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

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


    Behelfslösung:

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

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

    Die Sicherung des Administratorclusters enthält nicht die Verschlüsselungsschlüssel und die Konfiguration für immer aktive Secrets

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

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

    Vorgang, Upgrades, Aktualisierungen 1.10+

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

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

    Upgrades, Updates 1.10

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

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

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


    Workaround:
    Upgrades, Updates 1.10.0

    Docker wird nach dem Clusterupgrade häufig neu gestartet

    Das Upgrade des Nutzerclusters auf 1.10.0 kann zu einem häufigen Neustart von Docker führen.

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

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

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

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


    Workaround:
    Upgrades, Updates 1.11, 1.12

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

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

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


    Workaround:
    Vorgang 1.11, 1.12, 1.13.0 - 1.13.1

    Fehlende ClusterAPI-Objekte im Cluster-Snapshot-Szenario system

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

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


    Workaround:

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

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

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

    Das Löschen von Nutzerclustern bleibt im 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 auf vSAN
    • Es sind keine PVC-/PV-Objekte vorhanden, die von integrierten vSphere-Plug-ins im Administrator- und Nutzercluster erstellt wurden.

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

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

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

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

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


    Workaround:

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

    Cluster Autoscaler „clusterrolebinding“ und „clusterrole“ werden nach dem Löschen eines Nutzerclusters gelöscht.

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

    Die Symptome sind folgende:

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

    .

    Workaround:

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

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

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

    Die Symptome sind folgende:

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

    .

    Workaround:

    Konfiguration 1.12.1-1.12.3, 1.13.0-1.13.2

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

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

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

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

    Workaround:

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

    Option 2: Verwenden Sie gkectl check-config --skip-validation-os-images, um die Validierung der Betriebssystem-Images zu überspringen.
    Upgrades, Updates 1.11, 1.12, 1.13

    gkectl update admin/cluster schlägt beim Aktualisieren von Anti-Affinitätsgruppen fehl

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

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

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

    Workaround:
    Installation, Upgrades, 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 bei der Cluster-Erstellung, dem Upgrade, der Aktualisierung und der automatischen Knotenreparatur fehl, wenn ipMode.type gleich static ist und der konfigurierte Hostname in der IP-Blockdatei einen oder mehrere Punkte enthält. In diesem Fall werden die Certificate Signing Requests (CSR) für einen Knoten nicht automatisch genehmigt.

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

    kubectl get csr -A -o wide

    Prüfen Sie die folgenden Logs auf Fehlermeldungen:

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

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

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


    Workaround:

    Nutzercluster

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

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

    Administratorcluster

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

    Fehler beim Starten der Maschine der Administratorsteuerungsebene aufgrund eines privaten Registry-Zertifikats-Bundles

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

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

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

    Invalid value 'XXXX' specified for property startup-data

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

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

    NetworkGatewayNodes marked unhealthy from concurrent status update conflict

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

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

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

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

    Die Dataplane-Aktivität ist ansonsten nicht betroffen.

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

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


    Workaround:

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

    Die Race-Bedingung blockiert das Löschen von Maschinenobjekten während einer Aktualisierung oder eines Upgrades

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

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

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

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

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

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

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


    Workaround:

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

    • Option 1: Warten, bis das Upgrade abgeschlossen ist

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

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

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

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

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

    Wenn dieses Problem auftritt und das Upgrade oder Update auch nach längerer Zeit nicht abgeschlossen werden kann, wenden Sie sich an unser Supportteam.
    Installation, Upgrades, Updates 1.10.2, 1.11, 1.12, 1.13

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

    Befehl gkectl prepare fehlgeschlagen mit:

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

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


    Workaround:

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

    vCenter-URL mit dem Präfix https:// oder http:// kann dazu führen, dass der Cluster nicht gestartet wird

    Fehler beim Erstellen des Administratorclusters:

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

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


    Workaround:

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

    gkectl prepare-Panic auf util.CheckFileExists

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

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

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

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


    Workaround:

    Führen Sie die folgenden Befehle auf der 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 Administrator-Upgrade 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 Upgrade-Versuche des Administrators fehlschlagen, z. B. weil der Administrator-Master nicht eingeschaltet werden kann oder die VM nicht erreichbar ist.


    Workaround:

    Wenn dieses Fehlerszenario bereits aufgetreten ist, wenden Sie sich an den Support.
    Upgrades, Updates 1.10, 1.11

    Fortgesetztes Upgrade des Administratorclusters kann zu fehlender VM-Vorlage für die Administratorsteuerungsebene führen

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


    Workaround:

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

    cgroup v2 kann sich auf Arbeitslasten auswirken

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


    Workaround:

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

    Benutzerdefinierte ClientConfig-Ressource

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


    Workaround:

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

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

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

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


    Workaround:

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

    Nutzerclusterinstallation wegen Problem bei Leader-Auswahl durch Cert Manager/CA Injektor fehlgeschlagen

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

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

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

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

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

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

    Workaround:
    VMware 1.10, 1.11, 1.12, 1.13

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

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

    Ähnlicher Govmomi-Fehler.


    Workaround:

    Diese Problemumgehung wird vom VMware-Support bereitgestellt:

    1. Das Problem wurde in vCenter-Version 7.0U2 und höher behoben.
    2. Klicken Sie bei niedrigeren Versionen mit der rechten Maustaste auf den Host und wählen Sie Verbindung > Verbindung trennen. Stellen Sie die Verbindung wieder her. Dadurch wird ein Update der Portgruppe der VM erzwungen.
    Betriebssystem 1.10, 1.11, 1.12, 1.13

    SSH-Verbindung durch Remote-Host geschlossen

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

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

    ClientAliveInterval 300
ClientAliveCountMax 0

    Bei diesen Einstellungen wird eine Clientsitzung nach 5 Minuten Inaktivität beendet. Der Wert ClientAliveCountMax 0 führt jedoch zu unerwartetem Verhalten. Wenn Sie die SSH-Sitzung auf der Administrator-Workstation oder einem Clusterknoten verwenden, wird die SSH-Verbindung möglicherweise getrennt, auch wenn Ihr SSH-Client nicht inaktiv ist, z. B. wenn ein zeitaufwendiger Befehl ausgeführt wird. Ihr Befehl wird dann möglicherweise mit der folgenden Nachricht beendet:

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

    Workaround:

    Sie haben folgende Möglichkeiten:

    • Verwenden Sie nohup, um zu verhindern, dass Ihr Befehl beim Trennen einer SSH-Verbindung beendet wird. 
      nohup gkectl upgrade admin --config admin-cluster.yaml \
    --kubeconfig kubeconfig
    • Aktualisieren Sie sshd_config so, dass ein ClientAliveCountMax-Wert ungleich null verwendet wird. Die CIS-Regel empfiehlt die Verwendung eines Werts unter 3: 
      sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' \
    /etc/ssh/sshd_config
sudo systemctl restart sshd

    Stellen Sie sicher, dass Sie Ihre SSH-Sitzung neu verbinden.
    Installation 1.10, 1.11, 1.12, 1.13

    In Konflikt stehende cert-manager-Installation

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

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

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

    Workaround:

    <pKonflikte während des Upgrades vermeiden

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

    Eigenen Cert-Manager in Nutzerclustern wiederherstellen

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

    Eigenen Cert-Manager in Administratorclustern wiederherstellen

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

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

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

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

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

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

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

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

    Informationen zu CVE-Korrekturen finden Sie in den Versionshinweisen.


    Workaround:

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

    Die Netzwerkverbindung zwischen Administrator- und Nutzercluster ist möglicherweise während des Upgrades eines Nicht-HA-Clusters für kurze Zeit nicht verfügbar.

    Wenn Sie ein Upgrade von Clustern ohne Hochverfügbarkeit von Version 1.9 auf 1.10 durchführen, werden Sie möglicherweise feststellen, dass kubectl exec, kubectl log und Webhook für Nutzercluster für eine kurze Zeit nicht verfügbar sind. Diese Ausfallzeit kann bis zu einer Minute betragen. Dies liegt daran, dass die eingehende Anfrage (kubectl exec, kubectl log und webhook) von kube-apiserver für den Nutzercluster verarbeitet wird. Der Nutzer „kube-apiserver” ist ein Statefulset. In einem Nicht-HA-Cluster gibt es nur ein Replikat für das StatefulSet. Während des Upgrades kann es also sein, dass der alte kube-apiserver nicht verfügbar ist, während der neue kube-apiserver noch nicht bereit ist.


    Workaround:

    Diese Ausfallzeit findet nur während des Upgrades statt. Wenn Sie während des Upgrades eine kürzere Ausfallzeit wünschen, empfehlen wir, zu HA-Clustern zu wechseln.
    Installation, Upgrades, Updates 1.10, 1.11, 1.12, 1.13

    Prüfung der Konnektivitätsbereitschaft in HA-Clustern nach Cluster-Erstellung oder Upgrade fehlgeschlagen

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


    Workaround:

    Die Konnektivität wird alleine wiederhergestellt. Warten Sie 30 Minuten bis eine Stunde und führen Sie die Clusterdiagnose noch einmal aus.
    Betriebssystem 1.7, 1.8, 1.9, 1.10, 1.11

    /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, damit eine aide-Prüfung geplant wird. Auf diese Weise wird die Einhaltung der CIS-L1-Serverregel „1.4.2 Dateisystemintegrität muss regelmäßig geprüft werden” sichergestellt.

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


    Workaround:

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

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

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

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

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


    Workaround:

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

    Wenn Ihre Cluster einen manuellen Load-Balancer verwenden, folgen Sie dieser Anleitung, um Ihren Load-Balancer so zu konfigurieren, dass Clientverbindungen zurückgesetzt werden, wenn ein Backend-Knotenfehler auftritt. Ohne diese Konfiguration reagieren Clients des Kubernetes API-Servers möglicherweise mehrere Minuten lang nicht, wenn eine Serverinstanz ausfällt.
    Logging und Monitoring 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

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

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

    Um festzustellen, ob Sie von diesem Problem betroffen sind, listen Sie Ihre benutzerdefinierten Messwerte auf. Wenn Sie die Abrechnung unerwünschter Messwerte mit dem Namenspräfix external.googleapis.com/prometheus sehen und auch enableStackdriverForApplications in der Antwort von kubectl -n kube-system get stackdriver stackdriver -o yaml auf „true“ gesetzt ist, trifft dieses Problem auf Sie zu.


    Problemumgehung

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

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

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

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

    Wenn Sie nicht von der annotierten Messwerterfassung wechseln können, gehen Sie so vor:

    1. Suchen Sie die Quell-Pods und -Dienste mit den unerwünschten Abrechnungs-Messwerten. 
      kubectl --kubeconfig KUBECONFIG \
  get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
  services -A -o yaml | grep 'prometheus.io/scrape: "true"'
    2. Entfernen Sie die Annotation prometheus.io/scrap=true aus dem Pod oder Dienst. Wenn die Annotation von Cloud Service Mesh hinzugefügt wird, prüfen Sie die Optionen, Cloud Service Mesh ohne Prometheus zu konfigurieren oder das Zusammenführen von Messwerten von Istio zu deaktivieren.
    Installation 1.11, 1.12, 1.13

    Das Installationsprogramm schlägt beim Erstellen eines vSphere-Datenlaufwerks fehl

    Das Google Distributed Cloud-Installationsprogramm kann fehlschlagen, wenn benutzerdefinierte Rollen auf der falschen Berechtigungsebene gebunden sind.

    Wenn die Rollenbindung falsch ist, bleibt das Erstellen eines vSphere-Datenlaufwerks mit govc hängen und das Laufwerk wird mit einer Größe von 0 erstellt. Um das Problem zu beheben, sollten Sie die benutzerdefinierte Rolle auf vSphere Vcenter-Ebene (Root) binden.


    Workaround:

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

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

    Hoher Netzwerkverkehr zu monitoring.googleapis.com

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

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


    Workaround:
    Logging und Monitoring 1.10, 1.11

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

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


    Workaround:

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

    1. Skalieren Sie stackdriver-operator herunter, um zu verhindern, dass die folgenden Änderungen rückgängig gemacht werden: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy stackdriver-operator \
    --replicas=0
      Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der Nutzercluster-kubeconfig-Datei.
    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 eingestellte Messwerte verwendet werden, sehen Sie ein paar leere Diagramme. Um die veralteten Messwerte in den Monitoring-Dashboards zu finden, führen Sie die folgenden Befehle aus:

    gcloud monitoring dashboards list > all-dashboard.json

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

    Die folgenden verworfenen Messwerte sollten zu ihren Ersatzwerten migriert werden.

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

    Workaround:

    So ersetzen Sie die verworfenen Messwerte

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

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

    Unbekannte Messwertdaten in Cloud Monitoring

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

    Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    Weitere Messwerttypen mit irrelevanten Zusammenfassungsmesswerten sind:

    :
    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    Diese Messwerte des Zusammenfassungstyps sind zwar in der Messwertliste enthalten, werden jedoch derzeit nicht von gke-metrics-agent unterstützt.
    Logging und Monitoring 1.10, 1.11, 1.12, 1.13

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

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

    Workaround:

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

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

    Fehlende Planer- und Controller-Manager-Messwerte im Administratorcluster

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

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

    Workaround:

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

    Fehlende Planer- und Controller-Manager-Messwerte im Nutzercluster

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

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

    Workaround:

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

    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 der Administratorcluster sich während der Erstellung nicht mit der bereitgestellten gkeConnect-Spezifikation registrieren kann, wird der folgende Fehler angezeigt.

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

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

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

    Workaround:
    Identität 1.10, 1.11, 1.12, 1.13

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

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


    Workaround:

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

    • Deaktivieren Sie den GKE Identity Service. Wenn Sie den GKE Identity Service deaktivieren, wird die bereitgestellte GKE Identity Service-Binärdatei oder die GKE Identity Service ClientConfig nicht entfernt. Zum Deaktivieren von GKE Identity Service führen Sie den folgenden Befehl aus: 
      gcloud container fleet identity-service disable \
    --project PROJECT_ID
      Ersetzen Sie PROJECT_ID durch die ID des Flotten-Hostprojekts des Clusters.
    • Aktualisieren Sie den Cluster auf Version 1.9.3 oder höher oder auf Version 1.10.1 oder höher, um die Connect Agent-Version zu aktualisieren.
    Netzwerk 1.10, 1.11, 1.12, 1.13

    Cisco ACI funktioniert nicht mit Direct Server Return (DSR)

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


    Workaround:

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

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

    Probleme mit dem vSphere 7.0 Update 3

    VMWare hat vor Kurzem kritische Probleme in den folgenden vSphere 7.0 Update 3-Releases identifiziert:

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

    Workaround:

    VMWare hat diese Releases seitdem entfernt. Sie sollten ESXi und vCenter Server auf eine neuere Version aktualisieren.
    Betriebssystem 1.10, 1.11, 1.12, 1.13

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

    Für Pods, die auf Knoten ausgeführt werden, die Container-Optimized OS-Images (COS) verwenden, können Sie das Volume emptyDir nicht als exec bereitstellen. Es wird bereitgestellt als noexec und Sie erhalten die folgende Fehlermeldung: exec user process caused: permission denied. Sie sehen z. B. Folgendes: Fehlermeldung beim Bereitstellen des folgenden Test-Pods:

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

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

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

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

    Das Update des Clusterknotenpool-Replikats funktioniert nicht, nachdem die automatische Skalierung für den Knotenpool deaktiviert wurde

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


    Workaround:

    So entfernen Sie die Annotationen cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size und cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size aus der Maschinenbereitstellung des entsprechenden Knotenpools.
    Logging und Monitoring 1.11, 1.12, 1.13

    Windows-Monitoring-Dashboards zeigen Daten aus Linux-Clustern

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

    stackdriver-log-forwarder in konstantem CrashLoopBackOff

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


    Workaround:

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

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

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
    4. Löschen Sie das Bereinigungs-Daemonset: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system delete ds fluent-bit-cleanup
    5. Setzen Sie stackdriver-log-forwarder fort: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    Logging und Monitoring 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

    stackdriver-log-forwarder sendet keine Logs an Cloud Logging

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

    2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk
    Wahrscheinlich überschreitet die Logeingaberate den Grenzwert 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 Ressource stackdriver zum Bearbeiten: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Um die CPU-Anfrage für stackdriver-log-forwarder zu erhöhen, fügen Sie den folgenden resourceAttrOverride-Abschnitt zum stackdriver-Manifest hinzu: 
      spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
      Ihre bearbeitete Ressource sollte etwa so aussehen: 
      spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
    3. Speichern Sie die Änderungen und schließen Sie den Texteditor.
    4. Prüfen Sie mit dem folgenden Befehl, ob Ihre Änderungen wirksam sind: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
    | grep "cpu: 1200m"
      Der Befehl findet cpu: 1200m, wenn Ihre Änderungen übernommen wurden.
    Sicherheit 1.13

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

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

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

    Das teilweise Upgrade des Administratorclusters blockiert das spätere Upgrade des Nutzerclusters nicht

    Fehler beim Upgrade des Nutzerclusters:

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

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


    Workaround:

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

    Datastore meldet fälschlicherweise, dass nicht genügend freier Speicherplatz verfügbar ist

    Befehl gkectl diagnose cluster fehlgeschlagen mit: 

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

    Die Validierung des freien Datenspeicher-Speicherplatzes sollte nicht für vorhandene Cluster-Knotenpools verwendet werden und wurde versehentlich in gkectl diagnose cluster hinzugefügt.


    Workaround:

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

    Neuer Nutzercluster kann nicht hinzugefügt werden, wenn der Administratorcluster MetalLB Load Balancer verwendet.

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

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


    Workaround:

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

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

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

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

    Die für den Nutzercluster check-config erstellte Test-VM verwendet standardmäßig den gleichen osImageType wie der Administratorcluster, und derzeit ist die Test-VM noch nicht mit COS kompatibel.


    Workaround:

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

    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. Die Ursache ist eine Diskrepanz zwischen den Zertifikaten des Pushprox-Clients in den Nutzerclustern und der Zulassungsliste des Pushprox-Servers im Administratorcluster. Das Symptom ist, dass pushprox-client in Nutzerclustern Fehlerlogs wie die folgenden ausgibt:

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

    Workaround:
    Sonstiges 1.11.3

    gkectl repair admin-master stellt die VM-Vorlage für die Wiederherstellung nicht zur Verfügung

    Befehl gkectl repair admin-master fehlgeschlagen mit: 

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

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


    Workaround:

    Führen Sie den Befehl mit --skip-validation noch einmal aus.
    Logging und Monitoring 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

    Cloud-Audit-Logging-Fehler aufgrund einer abgelehnten Berechtigung

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

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

    Workaround:
    Betrieb, Sicherheit 1.11

    gkectl diagnose – Zertifikate konnten nicht geprüft werden

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

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

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

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

    Workaround:

    Sie können diese Meldungen bedenkenlos ignorieren.
    Betriebssystem 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    /var/log/audit/ füllt den Laufwerksspeicher auf VMs

    /var/log/audit/ wird mit Audit-Logs gefüllt. Sie können die Laufwerksnutzung durch Ausführen von sudo du -h -d 1 /var/log/audit prüfen.

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

    Seit Google Distributed Cloud v1.8 ist das Ubuntu-Image mit der CIS-Level-2-Benchmark gehärtet. Und eine der Complianceregeln, „4.1.2.2 Sicherstellen, dass Audit-Logs nicht automatisch gelöscht werden“, sorgt für die Auditd-Einstellung max_log_file_action = keep_logs Dies führt dazu, dass alle Audit-Regeln auf dem Laufwerk gespeichert werden.


    Workaround:
    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 der Knotenadresse

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

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

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


    Workaround:

    In demselben Cluster, in dem die Erstellung oder Aktualisierung von NetworkGatewayGroup-Objekten fehlschlägt, deaktivieren Sie vorübergehend den ANG-Validierungs-Webhook und senden Ihre Änderung:

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

    Zeitüberschreitung beim Erstellen oder Aktualisieren des Administratorclusters

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

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

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

    Angenommen, die VIP 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 Sendeadresse das gleiche Präfix wie die VIP der Steuerungsebene hat, z. B. 192.168.1.255.


    Workaround:

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

    Der Zustand des Administratorclusters, der das COS-Image verwendet, geht bei einem Upgrade des Administratorclusters oder einer Reparatur des Administratormasters verloren.

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


    Workaround:

    Administratorcluster mit osImageType auf ubuntu_containerd neu erstellen

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

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

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

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

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


    Workaround:

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

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

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

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

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

    Hinweis: Diese Lösung bleibt bei der Neuerstellung von VMs nicht bestehen. Sie müssen diese Problemumgehung jedes Mal neu anwenden, wenn VMs neu erstellt werden.
    Installation, Betriebssystem 1.10

    Brücken-IP-Adresse von Docker nutzt 172.17.0.1/16 anstelle von 169.254.123.1/24

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

    Deshalb nutzt Docker das Standard-Subnetz 172.17.0.1/16 als Brücken-Subnetz für IP-Adressen. Dies kann zu einem Konflikt der IP-Adressen führen, wenn bereits Arbeitslast innerhalb dieses IP-Adressbereichs ausgeführt wird.


    Workaround:

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

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

sudo systemctl daemon-reload

sudo systemctl restart docker

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

    ip a | grep docker0

    Hinweis: Diese Lösung bleibt bei der Neuerstellung von VMs nicht bestehen. Sie müssen diese Problemumgehung jedes Mal neu anwenden, wenn VMs neu erstellt werden.
    Upgrades, Updates 1.11

    Upgrade auf 1.11 wird durch Stackdriver-Bereitschaft blockiert

    In der Google Distributed Cloud-Version 1.11.0 gibt es Änderungen in der Definition benutzerdefinierter Ressourcen im Zusammenhang mit Logging und Monitoring:

    • 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 nun anhand ihres Schemas validiert. Insbesondere für die Spezifikationen „resourceAttrOverride“ und „storageSizeOverride“ in der benutzerdefinierten Ressource stackdriver muss ein Stringtyp in den Werten für CPU-, Arbeitsspeicher- und Speichergrößenanforderungen und ‐limits festgelegt werden.

    Die Änderungen des Gruppennamens werden vorgenommen, um den Aktualisierungen von CustomResourceDefinition 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 in der Manifestdatei mit dem neuen Gruppennamen referenziert werden. Beispiel:

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

    Stellen Sie außerdem sicher, 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 Änderungen nicht übernommen und können zu einem unerwarteten Status in Logging- und Monitoring-Komponenten führen. Mögliche Symptome sind:

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

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

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

    Betriebssystem 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

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

    Immer wenn ein Fehler bei einem ESXi-Server auftritt und die vCenter-HA-Funktion für den Server aktiviert wurde, lösen alle VMs im 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-Adresse fest

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

    Workaround:

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

    Kubelet ist mit Logs überflutet, die darauf hinweisen, 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.