s <0x0 Bekannte Probleme bei Google Distributed Cloud for Bare Metal

Auf dieser Seite werden alle bekannten Probleme mit Google Distributed Cloud (nur Software) für Bare Metal (früher Google Distributed Cloud Virtual, davor Anthos-Cluster auf Bare Metal) aufgeführt.

Diese Seite richtet sich an Administratoren, Architekten und Betreiber, die den Lebenszyklus der zugrunde liegenden technischen Infrastruktur verwalten und auf Benachrichtigungen und Seiten reagieren, wenn Service Level Objectives (SLOs) nicht erfüllt werden oder Anwendungen ausfallen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud-Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

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

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

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

Wählen Sie eine Kategorie für Ihr Problem aus:

Oder suchen Sie nach Ihrem Problem:

Kategorie Identifizierte Version(en) Problem und Problemumgehung
Netzwerk, Upgrades und Updates 1.30 und höher

Die gebündelte Ingress-Funktion in Google Distributed Cloud verwendet istiod. Für diese Funktion werden keine benutzerdefinierten Ressourcendefinitionen verwendet, die von Istio definiert werden. Da der verwendete Code jedoch Open Source ist, reagieren die Pods empfindlich auf Istio-Installationen, die Sie möglicherweise für Ihre eigenen Anwendungsfälle haben.

Wenn in den Clustern keine benutzerdefinierten Ressourcendefinitionen von Istio vorhanden sind, deklariert sich „istiod“ als bereit, ohne auf benutzerdefinierte Ressourcendefinitionen zu warten. Wenn jedoch v1beta benutzerdefinierte Ressourcendefinitionen im Cluster vorhanden sind, wartet Istiod auf v1 benutzerdefinierte Ressourcendefinitionen, bevor es die Bereitschaft erklärt. Dadurch kann es passieren, dass der Istiod-Pod nicht bereit ist und Clusterupgrades fehlschlagen.

Überprüfung:

Prüfen Sie den Status des Istiod-Pods im Namespace gke-system, um festzustellen, ob Ihr Cluster betroffen ist:

kubectl get pods -n gke-system -l app=istiod

Wenn der Pod-Status Running ist, die Bereitschaftsprüfung aber fehlschlägt (z. B. 0/1 bereit), ist Ihr Cluster wahrscheinlich betroffen.


Workaround:

Verwenden Sie eine der folgenden Behelfslösungen, um dieses Problem zu beheben.

  • Stellen Sie die benutzerdefinierten v1-Ressourcendefinitionen von Istio manuell in Ihrem Cluster bereit.

  • Deaktivieren Sie die Funktion „Gebündelter Ingress“, wenn Sie sie nicht verwenden.
Installation, Upgrades und Updates 1.30.400 und früher

Bei Clustern mit Version 1.30.400 oder früher kann es zu lifecycle-controllers-manager-Pod-Abstürzen kommen, wenn PreflightCheck-benutzerdefinierte Ressourcen validiert werden. Diese Abstürze führen dazu, dass die Clusterbereitstellung und ‑upgrades nicht abgeschlossen werden können.

Dieses Problem tritt aufgrund einer Nullzeiger-Dereferenzierung während der PreflightCheck-Ressourcenvalidierung auf.


Workaround:

Um die Clusterbereitstellung oder Upgrades fortzusetzen, umgehen Sie die Preflight-Prüfungen. Legen Sie in der Clusterkonfigurationsdatei das Feld bypassPreflightCheck auf true fest:

spec:
  bypassPreflightCheck: true

Weitere Informationen finden Sie unter Preflight-Prüfungen beim Anwenden von Kubernetes-Ressourcen umgehen.
Vorgang, Zurücksetzen/Löschen 1.33 und früher

Wenn Sie einen Cluster mit bmctl restore cluster wiederherstellen, wird der NPD-Systemd-Dienst (Node Problem Detector) auf Knoten nach Abschluss des Wiederherstellungsvorgangs nicht gestartet.

Führen Sie nach einem Wiederherstellungsvorgang systemctl is-active node-problem-detector auf Clusternknoten aus, um zu prüfen, ob Sie betroffen sind. Wenn der Befehl inactive zurückgibt, sind Sie von diesem Problem betroffen.


Workaround:

So stellen Sie die NPD wieder her:

  1. Deaktivieren Sie NPD gemäß der Anleitung unter Node Problem Detector aktivieren und deaktivieren.
  2. Aktivieren Sie NPD gemäß der Anleitung unter Node Problem Detector aktivieren und deaktivieren.

Durch das explizite Deaktivieren und Aktivieren von NPD werden NPD-Bereitstellungsjobs ausgelöst, die den NPD-Dienst auf allen Knoten installieren.
Netzwerk, Betrieb 1.28 und früher, 1.29.0–1.29.700, 1.30.0–1.30.300

In Clustern, in denen der gebündelte Layer-2-Load-Balancer verwendet wird, können alle 7 Tage „Connection Refused“-Fehler oder eine kurze Nichtverfügbarkeit des API-Servers (ca. 1 Minute) auftreten.

Dieses Verhalten tritt auf, weil die haproxy- und keepalived-Pods auf den Knoten der Steuerungsebene aufgrund einer TTL-Einstellung für Jobs neu gestartet werden. Dieses Problem betrifft Cluster in den Versionen 1.29.0 bis 1.29.700, 1.30.0 bis 1.30.300 sowie 1.28 und früher.


Überprüfung:

So prüfen Sie, ob Ihr Cluster von diesem Problem betroffen ist:

  1. Suchen Sie den Namen des Aktualisierungsjobs:

    kubectl get jobs -n kube-system | grep bm-system-cplb-update

  2. Prüfen Sie die Einstellung für die Gültigkeitsdauer des Jobs:

    kubectl get job JOB_NAME -n kube-system -o jsonpath='{.spec.ttlSecondsAfterFinished}'

    Ersetzen Sie JOB_NAME durch den Namen, der im vorherigen Schritt zurückgegeben wurde.

  3. Wenn die Ausgabe 604800 (entspricht 7 Tagen in Sekunden) lautet, ist Ihr Cluster von diesem Problem betroffen.


Workaround:

Um die wöchentlichen Neustarts zu verhindern, patchen Sie das Feld ttlSecondsAfterFinished in den vorhandenen Load Balancer-Aktualisierungsjobs manuell auf einen größeren Wert. Gehen Sie dazu so vor:

  1. Bearbeiten Sie den Load-Balancer-Aktualisierungsjob:

    kubectl edit job JOB_NAME -n kube-system

  2. Suchen Sie im Editor das Feld ttlSecondsAfterFinished und ändern Sie den Wert in 7776000 (ca. 90 Tage).

  3. Speichern Sie die Änderungen und beenden Sie den Editor, um sie zu übernehmen.
Vorgang 1.32.0-1.32.700, 1.33.0-1.33.300, 1.34.0

Der cluster-operator-Pod stürzt möglicherweise ab oder gerät aufgrund eines Panikfehlers: assignment to entry in nil map in einem Controller in eine Absturzschleife. Dies kann passieren, wenn der Controller versucht, Anmerkungen für eine benutzerdefinierte Ressource wie NodePool zu aktualisieren, die keine Anmerkungen hat (nil-Map).


Workaround:

Damit die Panik vermieden wird, muss die benutzerdefinierte Ressource (z. B. NodePool) mindestens eine Annotation haben. Mit dem folgenden Befehl können Sie eine Dummy-Annotation hinzufügen:

kubectl annotate nodepool NODEPOOL_NAME \
    -n CLUSTER_NAMESPACE dummy-annotation="added-manually" --overwrite \
    --kubeconfig=ADMIN_KUBECONFIG

Ersetzen Sie Folgendes:

  • NODEPOOL_NAME: Der Name der benutzerdefinierten NodePool-Ressource.
  • CLUSTER_NAMESPACE: Der Namespace des Clusters.
  • ADMIN_KUBECONFIG: Der Pfad zur kubeconfig-Datei des Administratorclusters.
Upgrades und Updates 1.34.0

Das Upgrade des Worker-Knotens schlägt aufgrund einer Hostnamenabweichung fehl.

Worker-Knoten-Upgrades schlagen aufgrund einer Regression (kubernetes/kubeadm#3244) in kubeadm fehl. Die Regression tritt auf, wenn der Linux-Hostname nicht mit dem Wert des Labels kubernetes.io/hostname auf den entsprechenden Kubernetes-Knoten übereinstimmt.

Verwenden Sie journalctl, um zu bestätigen, dass der betroffene Knoten fehlschlägt, wie im folgenden Beispiel:

[root@vm-lb-0--40b1a328a3448f5-112eaaafe1beedad ~]# journalctl -t kubeadm

Die Antwort sollte in etwa so aussehen:

Dec 09 20:09:50 vm-lb-0--40b1a328a3448f5-112eaaafe1beedad kubeadm[3684235]: error: error execution phase kubelet-config: could not remove the CRI socket annotation from Node "vm-lb-0--40b1a328a3448f5-112eaaafe1beedad": nodes "vm-lb-0--40b1a328a3448f5-112eaaafe1beedad" not found

In diesem Beispiel stimmt der in der journalctl-Antwort gemeldete Linux-Hostname nicht mit dem kubernetes.io/hostname-Label für den Knoten überein. Das bestätigt, dass das Upgrade von diesem Problem betroffen ist:

kubectl get nodes lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos \
  -ojsonpath='{.metadata.labels.kubernetes\.io\/hostname}'

Die Antwort:

lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos

Workaround:

Damit der betroffene Knoten das Upgrade abschließen kann, versuchen Sie, den Hostnamen vorübergehend so zu ändern, dass er dem Wert des Labels kubernetes.io/hostname auf den entsprechenden Kubernetes-Knoten entspricht, wie im folgenden Beispiel:

[root@vm-lb-0--40b1a328a3448f5-112eaaafe1beedad ~]# hostname lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos
Netzwerk 1.34.0

Wenn Sie das schnelle Failover für ausgehenden NAT-Traffic aktivieren, wird durch das Absperren eines Gateway-Knotens mit kubectl cordon <NODE_NAME> eine reibungslose Migration eingeleitet, bei der bestehende ausgehende Verbindungen beibehalten werden. In der reinen Softwareversion 1.34.0 von Google Distributed Cloud funktioniert die Funktion für die reibungslose Migration jedoch nicht wie vorgesehen.

Wenn ein Administrator einen aktiven Egress-Gateway-Knoten in einem Cluster der Version 1.34.0, der schnelles Failover verwendet, sperrt, verhält sich die Sperrung wie ein ungeplanter Knotenausfall und beendet alle vorhandenen zustandsorientierten Verbindungen auf diesem Knoten sofort.


Workaround:

Für dieses Problem gibt es keine Umgehungslösung.
Netzwerk 1.32.0

Bei ClusterIP-Diensten kann es zu zeitweiligen oder fehlgeschlagenen Verbindungen kommen, wenn der Traffic an Backend-Pods auf verschiedenen Knoten weitergeleitet wird. Dieser Kommunikationsfehler wird durch eine Regression in Cilium v1.15 verursacht, die dazu geführt hat, dass die CILIUM_POST_nat-Regeln aus iptables entfernt wurden. Die CILIUM_POST_nat-Regeln sind für die Quellnetzwerkadressübersetzung (Source Network Address Translation, SNAT) erforderlich. Wenn sie entfernt werden, führt dies zu einer unzuverlässigen Maskierung durch kube-proxy, was zu Kommunikationsfehlern bei ClusterIP-Diensten führt.

Wenn Sie beispielsweise einen Cluster aktualisieren und der Vorgang ins Stocken gerät, sehen Sie möglicherweise Logmeldungen wie die folgenden, die darauf hinweisen, dass das TLS-Handshake-Zeitlimit überschritten wurde, während der ClusterIP-Dienst versucht, eine Verbindung zum API-Server im Knotenpool np1 herzustellen:

      I0527 15:42:39.261368  372146 upgrade.go:994] Error trying to connect to api server: Get "https://10.200.0.108:443/apis/baremetal.cluster.gke.io/v1/namespaces/cluster-baremetal-test/nodepools/np1": net/http: TLS handshake timeout
      E0527 15:42:39.264789  372146 exec.go:207] command "/root/bmctl-upgrade upgrade cluster --kubeconfig /root/bmctl-workspace/baremetal-test/baremetal-test-kubeconfig --quiet --cluster baremetal-test --manifest-profile-env staging" times out

Dieses Problem wurde in Version 1.32.100 und höher behoben.

Workaround:

Wenn Sie kein Upgrade auf eine Version mit dem Fix durchführen können, empfehlen wir, das Cilium-Image manuell auf Version v1.15.6-anthos1.32.50 oder höher zu aktualisieren. Mit diesem Update wird das Problem behoben, indem die erforderlichen CILIUM_POST_nat-Regeln wieder eingeführt werden.

So aktualisieren Sie das Cilium-Image:

  1. Bearbeiten Sie das DaemonSet anetd im Namespace kube-system: 
    kubectl edit ds anetd -n kube-system
  2. Replace all occurrences of the Cilium image tag with version v1.15.6-anthos1.32.50 or a later version.

    Example old image:

    image: gcr.io/anthos-baremetal-staging/anthos-networking/cilium/cilium:v1.15.6-anthos1.32-gke.41@sha256:1940fccc...

    Beispiel für ein neues Bild:

    image: gcr.io/anthos-baremetal-staging/anthos-networking/cilium/cilium:v1.15.6-anthos1.32-gke.50
  3. Speichern Sie die Änderungen und schließen Sie den Editor.
Installation, Upgrades und Updates 1.33

Wenn Sie versuchen, den Befehl bmctl configure projects zu verwenden, um die Workload Identity-Föderation für ein neues Google Cloud Projekt zu konfigurieren, schlägt der Befehl mit der folgenden Fehlermeldung fehl:

Error ((retry 1) error adding iam policy bindings: failed to add project binding: failed to set project "<>" iam policy: googleapi: Error 400: Identity Pool does not exist (projectID.). Please check that you specified a valid resource name as returned in the `name` attribute in the configuration API., badRequest) ensuring iam policy binding: project-Id

Dieser Fehler tritt auf, weil der erforderliche Standard-Workload Identity-Pool mit dem Namen projectID. nicht automatisch im neuen Projekt bereitgestellt wird.

Workaround:

Führen Sie die folgenden Schritte aus, um die Identitätsföderation von Arbeitslasten für Ihr Projekt zu konfigurieren:

  1. Erstellen Sie den fehlenden Standard-Workload Identity-Pool manuell: 
    gcloud iam workload-identity-pools create PROJECT_ID. \
    --location=global \
    --project=PROJECT_ID

    Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

  2. Aktualisieren Sie auf Ihrer Administrator-Workstation die Umgebungsvariable GCP_ACCESS_TOKEN mit einem neu abgerufenen Zugriffstoken: 
    export GCP_ACCESS_TOKEN=$(gcloud auth application-default print-access-token)

    Standardmäßig hat das Zugriffstoken eine Lebensdauer von 3.600 Sekunden (1 Stunde). Wenn Sie die Clusterauthentifizierung mit Workload Identity verwenden, prüft bmctl die Ablaufzeit des Tokens. Wenn das Token innerhalb von 1.800 Sekunden (30 Minuten) abläuft, meldet bmctl einen Fehler und wird beendet.

  3. Führen Sie bmctl configure projects noch einmal aus.
Upgrades und Updates, Logging und Monitoring 1.29, 1.30, 1.31, 1.32

Das Ansible-Playbook cal-update enthält Logikfehler, die dazu führen, dass es fehlschlägt, wenn versucht wird, das Flag disableCloudAuditLogging zu ändern. Dadurch wird verhindert, dass Audit-Logs aktiviert oder richtig deaktiviert werden.

Wenn disableCloudAuditLogging von true in false geändert wird, können keine Audit-Logs aktiviert werden, da das Skript fehlschlägt, bevor die Konfigurationsänderung auf kube-apiserver angewendet wird. Wenn disableCloudAuditLogging von false in true geändert wird, können Audit-Logs deaktiviert werden. Der cal-update-Job schlägt jedoch kontinuierlich fehl, sodass das Playbook die Systemdiagnosen nicht erreicht. Die angezeigte Fehlermeldung lautet: 

The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'stdout_lines'

Workaround:

Für dieses Problem gibt es keine Behelfslösung. Sie müssen Ihren Cluster auf eine Version aktualisieren, die die Korrektur enthält. Gehen Sie beim Upgrade so vor:

  1. Deaktivieren Sie das Audit-Logging, indem Sie disableCloudAuditLogging auf true setzen.
  2. Wenn der Patch verfügbar ist, aktualisieren Sie Ihren Cluster auf eine der folgenden Patchversionen (oder höher), die die Korrektur enthalten:
    • 1.30.1200
    • 1.31.800
    • 1.32.400
  3. Wenn Sie Cloud-Audit-Logs wieder aktivieren möchten, setzen Sie disableCloudAuditLogging wieder auf false.
Upgrades und Updates 1.32+

Upgrades für Administratorcluster mit Hochverfügbarkeit (HA) schlagen nach einem Reparaturvorgang fehl

Bei Hochverfügbarkeits-Administratorclustern schlägt der Befehl gkectl upgrade admin fehl und bleibt hängen, wenn Sie ihn nach dem Ausführen des Befehls gkectl repair admin-master ausführen.

Mit dem Befehl gkectl repair admin-master wird reparierten Maschinen die Anmerkung machine.onprem.gke.io/managed=false hinzugefügt. Diese Anmerkung führt dazu, dass der cluster-api-Controller beim Ausführen des Befehls gkectl upgrade admin in einem Abgleichszustand hängen bleibt. Upgrades für Nicht-HA-Cluster enthalten eine Pivot-Logik, mit der diese Annotation entfernt wird. Diese Pivot-Logik fehlt jedoch bei Upgrades für HA-Cluster.

Workaround:

Entfernen Sie die Annotation machine.onprem.gke.io/managed manuell aus den Computerressourcen im Administratorcluster, bevor Sie das Upgrade starten.
Upgrades, Konfiguration 1.32.0 – 1.32.200

Bei Clustern, die mit einem Registrierungsspiegel konfiguriert sind, schlägt die check_gcr_pass-Preflight-Prüfung bei einem Upgrade auf Version 1.32.0 oder höher fehl. Dieser Fehler ist auf eine Änderung bei der Erstellung der benutzerdefinierten PreflightCheck-Ressource zurückzuführen. Dabei werden Registrierungsspiegelkonfigurationen aus der Clusterspezifikation, die in der Prüfung verwendet wird, ausgelassen.

Dieses Problem wurde bei internen Tests in Clustern mit Proxy- und Registry-Mirror-Konfigurationen festgestellt.

Workaround:

Sie haben zwei Möglichkeiten, dieses Problem zu umgehen:

  • Verwenden Sie das Flag --force, wenn Sie das Upgrade auslösen.
  • Rufen Sie die aktuelle Clusterkonfiguration mit bmctl get config ab und verwenden Sie diese neu generierte Konfigurationsdatei, um das Upgrade auszulösen.
Konfiguration, Updates 1.15 bis 1.30, 1.31.0 bis 1.31.800, 1.32.0 bis 1.32.300

In bestimmten Clusterversionen werden die Spezifikationen der regelmäßigen Systemdiagnose-CronJobs möglicherweise nicht aktualisiert, wenn sich die Konfiguration der Clusterressource ändert. Diese Aktualisierungsfehler führen zu veralteten Systemdiagnosen und potenziellen Jobfehlern.

Dieses Problem wurde in den Google Distributed Cloud-Versionen 1.31.900, 1.32.400 und 1.33.0 und höher behoben.

Workaround:

Bei Versionen 1.30 und früher können Sie das Problem mit den folgenden Schritten umgehen:

  1. Deaktivieren Sie regelmäßige Systemdiagnosen.

    Dadurch wird die aktuelle HealthCheck-Ressource gelöscht.

  2. Regelmäßige Systemdiagnosen wieder aktivieren.

    Dadurch werden neue HealthCheck-Ressourcen erstellt, die die aktuelle Clusterkonfiguration berücksichtigen.
Netzwerk 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30, 1.31

Keepalived wird verwendet, um die VIP der Steuerungsebene von einer Maschine auf eine andere zu verschieben, um Hochverfügbarkeit zu erreichen. Wenn die VIP der Steuerungsebene vom gebündelten Layer 2-Load-Balancer verarbeitet wird, kann es sein, dass Failovers der Keepalived-Instanz zu kurzen Intervallen (unter einer Sekunde) führen, in denen Gratuitous-ARPs mit unterschiedlichen MAC-Adressen verschachtelt werden. Die Switching-Netzwerkinfrastruktur kann dieses Interleaving als abnormal interpretieren und weitere ARP-Nachrichten für bis zu 30 Minuten ablehnen. Blockierte ARP-Nachrichten können wiederum dazu führen, dass die VIP der Steuerungsebene in diesem Zeitraum nicht verfügbar ist.

Die Verschachtelung von überflüssigen ARPs wird durch die Keepalived-Einstellungen verursacht, die in Version 1.31 und früher verwendet werden. Insbesondere wurden alle Knoten so konfiguriert, dass sie dieselbe Priorität verwenden. Keepalived-Konfigurationsänderungen in Version 1.32 beheben dieses Problem, indem sie unterschiedliche Prioritäten für jede Keepalived-Instanz konfigurieren und auch eine Clustereinstellung (controlPlane.loadBalancer.keepalivedVRRPGARPMasterRepeat) bereitstellen, um die Anzahl der unaufgeforderten ARPs zu reduzieren.

Workaround:

In Version 1.31 und früher können Sie die Interleaving-Häufigkeit der kostenlosen ARPs reduzieren, indem Sie die Keepalived-Konfigurationsdatei /usr/local/etc/keepalived/keepalived.conf direkt bearbeiten. Bearbeiten Sie für jeden Knoten, auf dem der Load Balancer der Steuerungsebene ausgeführt wird, die Konfigurationsdatei, um die folgenden Einstellungen zu ändern:

  • priority: Legen Sie für jeden Knoten einen eindeutigen priority-Wert fest. Gültige Werte liegen zwischen 1 und 254.
  • weight: Ändern Sie den weight-Wert von -2 in -253, damit ein Keepalived-Failover ausgelöst wird, wenn eine Systemdiagnose fehlschlägt.
Logging und Monitoring 1.30, 1.31, 1.32, 1.33

Aufgrund eines internen Definitionsfehlers werden für den Messwert kubernetes.io/anthos/custom_resurce_watchers möglicherweise ungenaue Daten angezeigt. Wenn Sie von diesem Problem betroffen sind, sehen Sie möglicherweise Fehler in den Logs, die den folgenden ähneln:

One or more TimeSeries could not be written: timeSeries[42]: Value type for metric kubernetes.io/anthos/custom_resurce_watchers must be INT64, but is DOUBLE.

Sie können diese Fehler ignorieren. Dieser Messwert wird nicht für kritische Systemwarnungen verwendet und die Fehler haben keine Auswirkungen auf die Funktion Ihres Projekts oder Ihrer Cluster.
Vorgang 1.30, 1.31, 1.32, 1.33

Wenn das Verzeichnis .manifests auf der Administrator-Workstation fehlt, wenn Sie bmctl check cluster --snapshot ausführen, schlägt der Befehl mit einem Fehler wie dem folgenden fehl:

Error message: failing while capturing snapshot failed to parse cluster config
file
failed to get CRD file

Dieser Fehler tritt auf, weil für den Befehl bmctl check cluster --snapshot die Dateien mit benutzerdefinierten Ressourcendefinitionen im Verzeichnis .manifests erforderlich sind, um die Clusterkonfiguration zu validieren. Dieses Verzeichnis wird normalerweise bei der Clusterkonfiguration erstellt. Wenn Sie das Verzeichnis versehentlich löschen oder bmctl von einem anderen Speicherort aus ausführen, kann der Befehl den Snapshot-Vorgang nicht fortsetzen.

Problemumgehungen:

Sie können dieses Problem beheben, indem Sie das Verzeichnis .manifests manuell neu generieren. Verwenden Sie dazu eine der folgenden Methoden:

  • Führen Sie den Befehl bmctl check cluster aus: 
    bmctl check cluster --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG

    Im Rahmen der ersten Prüfungen wird mit diesem Befehl automatisch das Verzeichnis .manifests in Ihrem aktuellen Arbeitsverzeichnis erstellt, unabhängig davon, ob der Befehl erfolgreich abgeschlossen wird oder nicht.

  • Führen Sie im Verzeichnis mit der aktuellen Clusterkonfigurationsdatei den Befehl bmctl create cluster aus: 
    bmctl create cluster --cluster TEST_CLUSTER

    Dieser Befehl führt wahrscheinlich zu einem Fehler, z. B. Unable to Parse Cluster Configuration File (Clusterkonfigurationsdatei kann nicht geparst werden). Das Verzeichnis .manifests wird jedoch weiterhin in Ihrem aktuellen Arbeitsverzeichnis erstellt.

    Das temporäre Verzeichnis bmctl-workspace/TEST_CLUSTER, das generiert wird, kann danach sicher gelöscht werden.

Nachdem Sie eine der beiden oben genannten Problemumgehungen ausgeführt haben, versuchen Sie es noch einmal mit dem Befehl bmctl check cluster --snapshot.
Installation, Upgrades und Updates 1.32.0, 1.32.100

Wenn die HAProxy-Instanz auf einem Knoten, auf dem die VIP der Steuerungsebene gehostet wird, nicht verfügbar ist, verhindert die Einstellung nopreempt in der Keepalived-Instanz, dass die VIP der Steuerungsebene auf einen Knoten mit einem fehlerfreien HAProxy verschoben wird. Dieses Problem hängt mit einer Funktion zusammen, die die Prioritäten des Keepalived-VRRP-Protokolls (Virtual Router Redundancy Protocol) automatisch konfiguriert und nicht mit der Einstellung nopreempt kompatibel ist.


Workaround:

Um das Problem zu umgehen, führen Sie die folgenden Schritte aus, um das Keepalived-Feature zu deaktivieren:

  1. Fügen Sie dem Cluster die Annotation preview.baremetal.cluster.gke.io/keepalived-different-priorities: "disable" hinzu: 
    kubectl annotate --kubeconfig ADMIN_KUBECONFIG \
    -n CLUSTER_NAMESPACE \
    clusters.baremetal.cluster.gke.io/CLUSTER_NAME \
    preview.baremetal.cluster.gke.io/keepalived-different-priorities="disable"
  2. Entfernen Sie nopreempt aus /usr/local/etc/keepalived/keepalived.conf auf den Knoten, auf denen der Load-Balancer der Steuerungsebene ausgeführt wird.

    Abhängig von der Load-Balancer-Konfiguration sind dies entweder die Knoten der Steuerungsebene oder die Knoten in einem Load-Balancer-Knotenpool.

  3. Nachdem nopreempt entfernt wurde, müssen die statischen keepalived-Pods neu gestartet werden, damit die Änderungen aus den Konfigurationsdateien übernommen werden. Verwenden Sie dazu auf jedem Knoten den folgenden Befehl, um die keepalived-Pods neu zu starten: 
    crictl rmp -f \
    $(crictl pods --namespace=kube-system --name='keepalived-*' -q)
Installation, Upgrades und Updates 1.30, 1.31, 1.32.0

Bei fehlgeschlagenen Preflight- und Systemdiagnosejobs können Artefakte in zeitgestempelten abm-tools-*-Ordnern unter /usr/local/bin zurückbleiben. Wenn Sie davon betroffen sind, sehen Sie möglicherweise zahlreiche Ordner wie den folgenden: /usr/local/bin/abm-tools-preflight-20250410T114317. Wiederholte Fehler können zu einer erhöhten Festplattennutzung führen.

Problemumgehung

Entfernen Sie diese Ordner manuell, wenn dieses Problem auftritt: 

rm -rf  /usr/local/bin/abm-tools-*
Netzwerk 1.28.0-1.28.200

In Clustern, in denen NAT-Gateway für ausgehenden Traffic aktiviert ist, wird der Load-Balancer-Traffic verworfen, wenn ein Load-Balancer Back-Ends auswählt, die den Trafficauswahlregeln entsprechen, die von einer veralteten benutzerdefinierten Ressource EgressNATPolicy angegeben werden.

Dieses Problem tritt beim Erstellen und Löschen von Pods auf, die einer Richtlinie für ausgehenden Traffic entsprechen. Die Richtlinien für ausgehenden Traffic werden nicht wie vorgesehen bereinigt, wenn die Pods gelöscht werden. Die veralteten Richtlinien für ausgehenden Traffic führen dazu, dass LoadBalancer-Pods versuchen, Traffic an eine Verbindung zu senden, die nicht mehr vorhanden ist.

Dieses Problem wurde in Google Distributed Cloud-Versionen ab 1.28.300 behoben.

Problemumgehung

Um NAT-Richtlinienressourcen für ausgehenden Traffic zu bereinigen, starten Sie jeden Knoten neu, auf dem ein Backend gehostet wird, das Fehler verursacht.
Upgrades und Updates, Zurücksetzen/Löschen 1,28

Wenn Sie einen Knoten der Steuerungsebene in Google Distributed Cloud 1.28 ersetzen (entfernen und hinzufügen), kann es sein, dass der neue Knoten dem Cluster nicht beitreten kann. Das liegt daran, dass beim Prozess, der für die Einrichtung des neuen Knotens (bm-system-machine-init) verantwortlich ist, der folgende Fehler auftritt:

Failed to add etcd member: etcdserver: unhealthy cluster

Dieser Fehler tritt auf, wenn ein alter Knoten der Steuerungsebene entfernt wird und seine Mitgliedschaft in der etcd-events nicht ordnungsgemäß bereinigt wird. Dadurch bleibt ein veraltetes Mitglied zurück. Das veraltete Mitglied verhindert, dass neue Knoten dem etcd-events-Cluster beitreten. Dadurch schlägt der machine-init-Prozess fehl und der neue Knoten wird immer wieder neu erstellt.

Die Folgen dieses Problems sind unter anderem:

  • Der neue Knoten der Steuerungsebene kann nicht richtig gestartet werden.
  • Der Cluster kann im Status RECONCILING hängen bleiben.
  • Der Knoten der Steuerungsebene wird aufgrund des machine-init-Fehlers kontinuierlich gelöscht und neu erstellt.

Dieses Problem wurde in Version 1.29 und höher behoben.

Workaround:

Wenn Sie kein Upgrade auf Version 1.29 ausführen können, können Sie das fehlerhafte etcd-events-Mitglied manuell aus dem Cluster entfernen. Folgen Sie dazu dieser Anleitung:

  1. Verwenden Sie SSH, um auf einen funktionierenden Knoten der Steuerungsebene zuzugreifen.
  2. Führen Sie den folgenden Befehl aus: 
    ETCDCTL_API=3 etcdctl \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --cert=/etc/kubernetes/pki/etcd/server.crt \
    --key=/etc/kubernetes/pki/etcd/server.key \
    --endpoints=localhost:2382 \
    member list
  3. Wenn die Antwort den entfernten Knoten in der Mitgliederliste enthält, suchen Sie in der ersten Spalte nach der Mitglieds-ID für den Knoten und führen Sie den folgenden Befehl aus: 
    ETCDCTL_API=3 etcdctl \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --cert=/etc/kubernetes/pki/etcd/server.crt \
    --key=/etc/kubernetes/pki/etcd/server.key \
    --endpoints=localhost:2382 \
    member remove MEMBER_ID
     Ersetzen Sie MEMBER_ID durch die Mitglieds-ID des entfernten Knotens.

Der neue Steuerungsebenenknoten sollte nach einigen Minuten automatisch dem Cluster beitreten.
Upgrades und Updates 1.30.500-gke.126, 1.30.600-gke.68, 1.31.100-gke.136, 1.31.200-gke.58

Während eines Clusterupgrades kann der Upgradevorgang auf dem ersten Knoten der Steuerungsebene mit einer Fehlermeldung im Ansible-Job fehlschlagen, die darauf hinweist, dass die Datei super-admin.conf fehlt.

Dieses Problem tritt auf, weil der erste Knoten der Steuerungsebene, der aktualisiert wird, möglicherweise nicht der erste Knoten ist, der bei der Clustererstellung bereitgestellt wurde. Beim Upgrade wird davon ausgegangen, dass der erste Knoten, der aktualisiert wird, derjenige ist, der die Datei super-admin.conf enthält.

Dieses Problem wurde in den folgenden Patch-Updates behoben: 1.30.500-gke.127, 1.30.600-gke.69 und 1.31.200-gke.59.

Workaround:

Führen Sie auf dem fehlgeschlagenen Knoten den folgenden Schritt aus, um das Problem zu beheben:

  • Kopieren Sie die Datei /etc/kubernetes/admin.conf nach /etc/kubernetes/super-admin.conf: 
    cp /etc/kubernetes/admin.conf /etc/kubernetes/super-admin.conf

    Der Upgradeprozess wird automatisch wiederholt und sollte erfolgreich verlaufen.
Upgrades und Updates 1.29.0 – 1.29.1100, 1.30.0 – 1.30.400

Pods mit einer NoSchedule-Toleranz werden bei Upgrades für den Ausschluss in Betracht gezogen. Aufgrund der NoSchedule-Toleranz kann der Deployment- oder DaemonSet-Controller den Pod jedoch noch einmal auf dem Knoten planen, der gerade gewartet wird, was das Upgrade möglicherweise verzögert.

So können Sie feststellen, ob Sie von diesem Problem betroffen sind:

  1. Prüfen Sie die anthos-cluster-operator-Pod-Logs, um die Pods zu identifizieren, die das Leeren des Knotens blockieren.

    Im folgenden Beispiel-Log-Snippet ist der node-problem-detector-mgmt-ydhc2-Pod noch nicht geleert:

    nodepool_controller.go:720] controllers/NodePool "msg"="Pods yet to drain for 10.0.0.3 machine are 1 : [node-problem-detector-mgmt-ydhc2]" "nodepool"={"Namespace":"test-cluster","Name":"test-cluster"}
  2. Führen Sie für jeden Pod, der das Leeren des Knotens verhindert, den folgenden Befehl aus, um die Toleranzen zu prüfen: 
    kubectl get po POD_NAME -n kube-system \
    -o json | jq '.spec.tolerations'

    Ersetzen Sie POD_NAME durch den Namen des Pods, der das Leeren des Knotens blockiert.

    Sie sollten eine der folgenden Kombinationen sehen:

    • Toleranz mit NoSchedule-Effekt und Exists-Operator
    • Toleranz mit NoSchedule-Effekt und "baremetal.cluster.gke.io/maintenance"-Schlüssel
    • Toleranz mit leerem Effekt und "baremetal.cluster.gke.io/maintenance"-Schlüssel

    Die Antwort könnte so aussehen:

    {
  "effect": "NoSchedule",
  "operator": "Exists"
},

Workaround:

Sie haben folgende Möglichkeiten, das Entleeren des Knotens zu entblocken:

  • Fügen Sie die baremetal.cluster.gke.io/maintenance:NoExecute-Toleranz zu Pods hinzu, die eine baremetal.cluster.gke.io/maintenance:Schedule-Toleranz haben und kein ordnungsgemäßes Beenden erfordern.
  • Entfernen Sie die ermittelten Toleranzkombinationen aus Pods, die während des Node-Draining entfernt werden sollen.
Netzwerk 1.28, 1.29 und 1.30

Netzwerkaufrufe an Pods, für die hostPort aktiviert ist, schlagen fehl und Pakete werden verworfen, wenn die Anfrage vom selben Knoten stammt, auf dem der Pod ausgeführt wird. Dies gilt für alle Cluster- und Knotentypen. Cluster, die ohne kube-proxy erstellt wurden, sind jedoch nicht betroffen.

So prüfen Sie, ob Sie von diesem Problem betroffen sind:

  1. Rufen Sie die Namen der anetd-Pods ab:

    Die anetd-Pods sind für die Steuerung des Netzwerkverkehrs verantwortlich.

    kubectl get pods -l k8s-app=cilium -n kube-system
  2. Prüfen Sie den Status der anetd-Pods: 
    kubectl -n kube-system exec -it ANETD_POD_NAME -- cilium status --all-clusters

    Ersetzen Sie ANETD_POD_NAME durch den Namen eines der anetd-Pods in Ihrem Cluster.

    Wenn die Antwort KubeProxyReplacement: Partial ... enthält, sind Sie von diesem Problem betroffen.

Problemumgehung

Wenn Sie Anfragen an Pods senden müssen, die hostPort verwenden, und die Pods auf demselben Knoten ausgeführt werden, können Sie einen Cluster ohne kube-proxy erstellen. Alternativ können Sie Pods so konfigurieren, dass sie ein portmap-CNI-Plug-in (Container Network Interface) verwenden.
Logging und Monitoring In Version 1.29.100 erkannt, kann auch in anderen Versionen auftreten

Hohe Festplatten-I/O aufgrund von Verlust der Netzwerkverbindung oder ungültigem Dienstkonto

Bei stackdriver-log-forwarder-Pods kann es zu Verbindungsverlusten kommen oder das Dienstkonto ist abgelaufen. In beiden Fällen können die Logs nicht an logging.googleapis.com gesendet werden. Dies führt zu einer Ansammlung von Logs im Puffer und zu einer hohen Datenträger-E/A. Der Cloud Logging-Agent (Fluent Bit), ein DaemonSet mit dem Namen stackdriver-log-forwarder, verwendet einen dateisystembasierten Puffer mit einem Limit von 4 GB. Wenn der Puffer voll ist, versucht der Agent, ihn zu rotieren oder zu leeren, was zu hohen E/A-Vorgängen führen kann.


Das sollten Sie prüfen:

Prüfen Sie, ob die Schlüssel für das Dienstkonto abgelaufen sind. Falls ja, drehen Sie sie, um das Problem zu beheben.

Mit dem folgenden Befehl können Sie das aktuell verwendete Dienstkonto bestätigen und es in IAM validieren:

kubectl get secret google-cloud-credentials -n CLUSTER_NAMESPACE -o jsonpath='{.data.credentials\.json}' | base64 --decode

Workaround:

Warnung:Wenn Sie den Puffer entfernen, gehen alle derzeit im Puffer gespeicherten Logs (einschließlich Kubernetes-Knoten-, Pod- und Containerlogs) dauerhaft verloren.
 Wenn die Pufferung durch einen Verlust der Netzwerkverbindung zum Logging-Dienst von Google Cloud verursacht wird, gehen diese Logs dauerhaft verloren, wenn der Puffer gelöscht wird oder wenn der Puffer voll ist und der Agent die Logs nicht senden kann.

  1. Entfernen Sie den stackdriver-log-forwarder-DaemonSet-Pod aus dem Cluster, indem Sie einen Knotenselektor hinzufügen. Dadurch wird das stackdriver-log-forwarder-DaemonSet beibehalten, aber von den Knoten entfernt:

    kubectl --kubeconfig KUBECONFIG -n kube-system \
    patch daemonset stackdriver-log-forwarder \
    -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'

    Ersetzen Sie KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.

    Prüfen Sie, ob die stackdriver-log-forwarder-Pods gelöscht wurden, bevor Sie mit dem nächsten Schritt fortfahren.

  2. Wenn dies nur bei einem oder wenigen Knoten der Fall ist:

    • Stellen Sie über SSH eine Verbindung zum Knoten her, auf dem stackdriver-log-forwarder ausgeführt wurde. Prüfen Sie, ob „stackdriver-log-forwarder“ nicht mehr auf diesen Knoten ausgeführt wird.
    • Löschen Sie auf dem Knoten alle Pufferdateien mit rm -rf /var/log/fluent-bit-buffers/ und fahren Sie dann mit Schritt 6 fort.

  3. Wenn es zu viele Knoten mit diesen Dateien gibt und Sie ein Skript verwenden möchten, um alle Knoten mit diesen Backlog-Chunks zu bereinigen, verwenden Sie die folgenden Skripts:

    Stellen Sie ein DaemonSet bereit, um alle Daten in Puffern in fluent-bit zu bereinigen:

    kubectl --kubeconfig KUBECONFIG -n kube-system apply -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

  4. Prüfen Sie, ob das DaemonSet alle Knoten bereinigt hat. Die Ausgabe der folgenden beiden Befehle sollte der Anzahl der Knoten im Cluster entsprechen:

    kubectl --kubeconfig KUBECONFIG logs \
    -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l
kubectl --kubeconfig KUBECONFIG \
    -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l

  5. Löschen Sie das Bereinigungs-Daemonset:

    kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \
    fluent-bit-cleanup

  6. Starten Sie die stackdriver-log-forwarder-Pods neu:

    kubectl --kubeconfig KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder --type json \
    -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
Upgrades und Updates, Betrieb 1.28, 1.29, 1.30.0 und 1.30.100

Pods können beim Beenden hängen bleiben, wenn Knoten geleert werden. Pods, die nicht mehr reagieren, können Vorgänge wie Upgrades blockieren, bei denen Knoten geleert werden. Pods können hängen bleiben, wenn der Container als „wird ausgeführt“ angezeigt wird, obwohl der zugrunde liegende Hauptprozess des Containers bereits erfolgreich beendet wurde. In diesem Fall wird der Container auch nicht durch den Befehl crictl stop beendet.

So können Sie feststellen, ob Sie von dem Problem betroffen sind:

  1. Prüfen Sie, ob in Ihrem Cluster Pods mit dem Status Terminating vorhanden sind: 
    kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \
    -o wide | grep Terminating
  2. Wenn Pods beim Beenden hängen bleiben, prüfen Sie mit kubectl describe, ob Ereignisse vorhanden sind: 
    kubectl describe pod POD_NAME \
    --kubeconfig CLUSTER_KUBECONFIG \
    -n NAMESPACE

    Wenn Sie Warnungen wie die folgenden mit Unhealthy und FailedKillPod als Gründen sehen, sind Sie von diesem Problem betroffen:

    Events:
  Type     Reason         Age                      From     Message
  ----     ------         ----                     ----     -------
  Warning  FailedKillPod  19m (x592 over 46h)      kubelet  error killing pod: [failed to "KillContainer" for "dnsmasq" with KillContainerError: "rpc error: code = DeadlineExceeded desc = context deadline exceeded", failed to "KillPodSandbox" for "0843f660-461e-458e-8f07-efe052deae23" with KillPodSandboxError: "rpc error: code = DeadlineExceeded desc = context deadline exceeded"]
  Warning  Unhealthy      4m37s (x16870 over 46h)  kubelet  (combined from similar events): Readiness probe errored: rpc error: code = Unknown desc = failed to exec in container: failed to start exec "c1ea4ffe7e4f1bacaab4f312bcc45c879785f6e22e7dc2d94abc3a019e20e1a9": OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown

Dieses Problem wird durch ein Upstream-Problem mit containerd verursacht, das in Google Distributed Cloud-Versionen 1.28.1000, 1.29.600, 1.30.200, 1.31 und höher behoben wurde.

Problemumgehung

So heben Sie die Blockierung des Clustervorgangs auf:

  1. Erzwingen Sie das Löschen aller Pods, die nicht reagieren: 
    kubectl delete pod POD_NAME -n POD_NAMESPACE --force
  2. Wenn die Pods erfolgreich neu gestartet wurden, versuchen Sie es noch einmal mit dem Clustervorgang.
Upgrades und Updates, Betrieb 1.28, 1.29 und 1.30.0-1.30.100

Pods können beim Beenden hängen bleiben, wenn Knoten geleert werden. Festsitzende Pods können Clusteroperationen wie Upgrades blockieren, bei denen Knoten per Drain beendet werden. Pods können hängen bleiben, wenn der runc init-Prozess eingefroren wird. Dadurch kann containerd den cgroups-Prozess, der mit diesem Pod verknüpft ist, nicht löschen.

So können Sie feststellen, ob Sie von dem Problem betroffen sind:

  1. Prüfen Sie, ob in Ihrem Cluster Pods mit dem Status Terminating vorhanden sind: 
    kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \
    -o wide | grep Terminating
  2. Prüfen Sie die kubelet-Logs auf den Knoten, auf denen Pods beim Beenden hängen bleiben:

    Der folgende Befehl gibt Logeinträge zurück, die den Text Failed to remove cgroup enthalten.

    journalctl -u kubelet --no-pager -f | grep "Failed to remove cgroup"

    Wenn die Antwort Warnungen wie die folgenden enthält, sind Sie von diesem Problem betroffen:

    May 22 23:08:00 control-1--f1c6edcdeaa9e08-e387c07294a9d3ab.lab.anthos kubelet[3751]: time="2024-05-22T23:08:00Z" level=warning msg="Failed to remove cgroup (will retry)" error="rmdir /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy"
...
May 22 23:09:04 control-1 kubelet[3751]: time="2024-05-22T23:09:04Z" level=warning msg="Failed to remove cgroup (will retry)" error="rmdir /sys/fs/cgroup/net_cls,net_prio/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy"
...

Problemumgehung

So heben Sie den eingefrorenen Status des runc init-Prozesses auf und entsperren Clustervorgänge:

  1. Prüfen Sie anhand des cgroup-Pfads aus den Kubelet-Logs, ob cgroup eingefroren ist. Sehen Sie sich dazu den Inhalt der Datei freezer.state an: 
    cat CGROUP_PATH_FROM_KUBELET_LOGS/freezer.state

    Der Inhalt von freezer.state gibt den Status von cgroup an.

    Mit einem Pfad aus den vorherigen Beispiel-Logeinträgen würde der Befehl so aussehen:

    cat /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope/freezer.state
  2. Fixierung von cgroups mit dem Status FREEZING oder FROZEN aufheben: 
    echo "THAWED" > CGROUP_PATH_FROM_KUBELET_LOGS/freezer.state

    Wenn die cgroups THAWED wurden, werden die entsprechenden runc init-Prozesse automatisch beendet und die cgroups automatisch entfernt. So wird verhindert, dass weitere Failed to remove cgroup-Warnungen in den kubelet-Logs angezeigt werden. Die Pods, die sich im Status Terminating befinden, werden kurz nach dem Bereinigen automatisch entfernt.

  3. Nachdem die eingefrorenen cgroups bereinigt und die hängengebliebenen Pods entfernt wurden, versuchen Sie es noch einmal.
Konfiguration, Netzwerk 1.28.0 bis 1.28.1000, 1.29.0 bis 1.29.500 und 1.30.0 bis 1.30.200

In den identifizierten Versionen von Google Distributed Cloud kann es vorkommen, dass kubelet Knotenleases über 40 Sekunden lang nicht aktualisiert. Dies führt zu NodeNotReady-Ereignissen.

Das Problem tritt unregelmäßig auf, etwa alle sieben Tage. Das Failover der virtuellen IP-Adresse der Steuerungsebene kann etwa zur selben Zeit wie die NodeNotReady-Ereignisse auftreten.

Dieses Problem wurde in den Versionen 1.28.1100, 1.29.600, 1.30.300 und höher behoben.

Workaround:

So beheben Sie das Problem:

  1. Erstellen Sie /etc/default/kubelet und fügen Sie die folgenden Umgebungsvariablen hinzu:
    2. HTTP2_READ_IDLE_TIMEOUT_SECONDS=10
HTTP2_PING_TIMEOUT_SECONDS=5
  2. Starten Sie das Kubelet neu: 
    systemctl restart kubelet
  3. Rufen Sie die neue Prozess-ID (PID) für kubelet ab: 
    pgrep kubelet
  4. Prüfen Sie, ob die Umgebungsvariablen nach dem Neustart von kubelet auf dem Knoten wirksam werden: 
    cat /proc/KUBELET_PID/environ | tr '\0' '\n' | grep -e HTTP2_READ_IDLE_TIMEOUT_SECONDS -e HTTP2_PING_TIMEOUT_SECONDS

    Ersetzen Sie KUBELET_PID durch die Ausgabe des Befehls aus dem vorherigen Schritt.

    In der Ausgabe des Befehls cat sollten die beiden hinzugefügten Umgebungsvariablen in den letzten Zeilen aufgeführt sein.
Updates 1,30

Wenn Sie einen Nutzercluster mit dem Befehl bmctl create cluster erstellen und das Feld cloudOperationsServiceAccountKeyPath im Header übergeben, wird das Feld spec.clusterOperations.serviceAccountSecret der erstellten Clusterressource hinzugefügt. Dieses Feld ist nicht in der Clusterkonfigurationsdatei enthalten und ist unveränderlich. Mit dem Befehl bmctl update cluster wird dieses Feld nicht aus dem Header ausgefüllt. Versuche, den Cluster mit dem Befehl bmctl update cluster und der ursprünglichen Clusterkonfigurationsdatei zu aktualisieren, schlagen mit dem folgenden Fehler fehl: 

[2025-01-15 16:38:46+0000] Failed to calculate diff:
---
E000090: Unable to calculate diff

An error occurred while calculating diff between live configuration and cluster.yaml file



Wrapped error: error in dryRunClient.Update for {map[apiVersion:baremetal.cluster.gke.io/v1 kind:Cluster metadata:map[annotations:map[baremetal.cluster.gke.io/enable-kubelet-read-only-port:false baremetal.cluster.gke.io/maintenance-mode-deadline-seconds:180 preview.baremetal.cluster.gke.io/add-on-configuration:enable] creationTimestamp: name:user-test namespace:cluster-user-test resourceVersion:1171702] spec:map[anthosBareMetalVersion:0.0.0-gke.0 bypassPreflightCheck:false clusterNetwork:map[multipleNetworkInterfaces:false pods:map[cidrBlocks:[10.240.0.0/13]] services:map[cidrBlocks:[172.26.0.0/16]]] clusterOperations:map[location:us-west1 projectID:baremetal-test] controlPlane:map[nodePoolSpec:map[nodes:[map[address:10.200.0.15]]]] gkeConnect:map[projectID:baremetal-test] loadBalancer:map[addressPools:[map[addresses:[10.200.0.20/32 10.200.0.21/32 10.200.0.22/32 10.200.0.23/32 10.200.0.24/32 fd00:1::15/128 fd00:1::16/128 fd00:1::17/128 fd00:1::18/128] name:pool1]] mode:bundled ports:map[controlPlaneLBPort:443] vips:map[controlPlaneVIP:10.200.0.19 ingressVIP:10.200.0.20]] nodeAccess:map[loginUser:root] nodeConfig:map[podDensity:map[maxPodsPerNode:250]] profile:default storage:map[lvpNodeMounts:map[path:/mnt/localpv-disk storageClassName:local-disks] lvpShare:map[numPVUnderSharedPath:5 path:/mnt/localpv-share storageClassName:local-shared]] type:user] status:map[]]}: admission webhook "vcluster.kb.io" denied the request: Cluster.baremetal.cluster.gke.io "user-test" is invalid: spec: Forbidden: Fields should be immutable.
(A in old)
(B in new)

{"clusterNetwork":{"multipleNetworkInterfaces":false,"services":{"cidrBlocks":["172.26.0.0/16"]},"pods":{"cidrBlocks":["10.240.0.0/13"]},"bundledIngress":true},"controlPlane":{"nodePoolSpec":{"nodes":[{"address":"10.200.0.15"}],"operatingSystem":"linux"}},"credentials":{"sshKeySecret":{"name":"ssh-key","namespace":"cluster-user-test"},"imagePullSecret":{"name":"private-registry-creds","namespace":"cluster-user-test"}},"loadBalancer":{"mode":"bundled","ports":{"controlPlaneLBPort":443},"vips":{"controlPlaneVIP":"10.200.0.19","ingressVIP":"10.200.0.20"},"addressPools":[{"name":"pool1","addresses":["10.200.0.20/32","10.200.0.21/32","10.200.0.22/32","10.200.0.23/32","10.200.0.24/32","fd00:1::15/128","fd00:1::16/128","fd00:1::17/128","fd00:1::18/128"]}]},"gkeConnect":{"projectID":"baremetal-test","location":"global","connectServiceAccountSecret":{"name":"gke-connect","namespace":"cluster-user-test"},"registerServiceAccountSecret":{"name":"gke-register","namespace":"cluster-user-test"}},"storage":{"lvpShare":{"path":"/mnt/localpv-share","storageClassName":"local-shared","numPVUnderSharedPath":5},"lvpNodeMounts":{"path":"/mnt/localpv-disk","storageClassName":"local-disks"}},"clusterOperations":{"projectID":"baremetal-test","location":"us-west1"

A: ,"serviceAccountSecret":{"name":"google-cloud-credentials","namespace":"cluster-user-test"}},"type":"user","nodeAccess":{"loginUser":"root"},"anthosBareMetalVersion":"0.0.0-gke.0","bypassPreflightCheck":false,"nodeConfig":{"podDensity":{"maxPodsPerNode":250},"containerRuntime":"containerd"},"profile":"default"}

B: },"type":"user","nodeAccess":{"loginUser":"root"},"anthosBareMetalVersion":"0.0.0-gke.0","bypassPreflightCheck":false,"nodeConfig":{"podDensity":{"maxPodsPerNode":250},"containerRuntime":"containerd"},"profile":"default"}



For more information, see https://cloud.google.com/distributed-cloud/docs/reference/gke-error-ref#E000090

Dieses Problem tritt nur auf, wenn Sie eine Version 1.30.x von bmctl für Updates verwenden.

Workaround:

Als Workaround können Sie die Clusterkonfiguration der tatsächlichen Clusterressource abrufen, bevor Sie die Änderungen vornehmen:

  1. Rufen Sie die Konfigurationsdatei des Nutzerclusters basierend auf der bereitgestellten Clusterressource ab: 
    bmctl get config --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG_PATH

    Die abgerufene benutzerdefinierte Ressource wird in eine YAML-Datei mit dem Namen bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP.yaml geschrieben. Diese neue Konfigurationsdatei enthält spec.clusterOperations.serviceAccountSecret, was für die Ausführung des Aktualisierungsbefehls erforderlich ist. Der TIMESTAMP im Dateinamen gibt das Datum und die Uhrzeit der Dateierstellung an.

  2. Ersetzen Sie die vorhandene Clusterkonfigurationsdatei durch die abgerufene Datei. Speichern Sie die Sicherung der vorhandenen Datei.
  3. Bearbeiten Sie die neue Clusterkonfigurationsdatei und verwenden Sie bmctl update, um den Nutzercluster zu aktualisieren: 
    bmctl update cluster --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG_PATH
Upgrades und Updates, Sicherheit 1.29, 1.30 und 1.31

Die Kubelet-Zertifikatsrotation schlägt fehl, wenn kubelet-client-current.pem und kubelet-server-current.pem tatsächliche Dateien und keine symbolischen Links sind.

Dieses Problem kann auftreten, nachdem Sie bmctl restore verwendet haben, um einen Cluster aus einer Sicherung wiederherzustellen.

Workaround:

Wenn Sie von diesem Problem betroffen sind, können Sie die folgenden Schritte als Problemumgehung verwenden:
  1. Sichern Sie die aktuellen Zertifikatsdateien: 
    mkdir -p ~/kubelet-backup/
cp -r /var/lib/kubelet/pki/ ~/kubelet-backup/
  2. Optional: Löschen Sie die angesammelten Zertifikatsdateien: 
    ls | grep -E "^kubelet-server-20*" | xargs rm -rf
ls | grep -E "^kubelet-client-20*" | xargs rm -rf
  3. Benennen Sie die Dateien kubelet-client-current.pem und kubelet-server-current.pem um:

    Die Verwendung eines Zeitstempels ist ein gängiges Umbenennungsschema.

    datetime=$(date +%Y-%m-%d-%H-%M-%S)
mv kubelet-server-current.pem kubelet-server-${datetime}.pem
mv kubelet-client-current.pem kubelet-client-${datetime}.pem
  4. Erstellen Sie in derselben Sitzung wie beim vorherigen Befehl symbolische Links, die auf die gültigen neuesten (umbenannten) Zertifikate verweisen: 
    ln -s kubelet-server-${datetime}.pem kubelet-server-current.pem
ln -s kubelet-client-${datetime}.pem kubelet-client-current.pem
  5. Legen Sie die Berechtigungen für die symbolischen Links auf 777 fest: 
    chmod 777 kubelet-server-current.pem
chmod 777 kubelet-client-current.pem
  6. Wenn die Zertifikate erfolgreich rotiert wurden, löschen Sie das Sicherungsverzeichnis: 
    rm -rf ~/kubelet-backup/
Installation, Upgrades und Updates 1,31

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

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

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

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

Problemumgehung

Wenn Sie eine benutzerdefinierte Ressourcendefinition haben, in der caBundle auf einen ungültigen Wert festgelegt ist, können Sie das Feld caBundle vollständig entfernen. Dadurch sollte das Problem behoben werden.
Installation, Upgrades und Updates 1.28, 1.29 und 1.30

Bei einem Clusterupgrade wird jeder Clusterknoten geleert und aktualisiert. In Version 1.28 und höher wurde in Google Distributed Cloud von markierungsbasiertem Beenden von Knoten zu auf Räumung basierendem Beenden gewechselt. Um Pod-Abhängigkeiten zu berücksichtigen, folgt das auf dem Entfernen basierende Leeren außerdem einer mehrstufigen Reihenfolge. In jeder Phase des Drain-Vorgangs haben Pods eine Kulanzzeit von 20 Minuten, um beendet zu werden. Beim vorherigen taintbasierten Drain-Vorgang gab es nur ein einziges Zeitlimit von 20 Minuten. Wenn für jede Phase die vollen 20 Minuten erforderlich sind, um alle Pods zu entfernen, kann das Leeren eines Knotens deutlich länger dauern als das vorherige Taint-basierte Leeren. Eine längere Zeit für das Leeren von Knoten kann wiederum die Zeit, die für ein Clusterupgrade oder das Versetzen eines Clusters in den Wartungsmodus benötigt wird, erheblich verlängern.

Es gibt auch ein Upstream-Kubernetes-Problem, das sich auf die Timeout-Logik für das auf Räumung basierende Leeren auswirkt. Dieses Problem kann auch die Zeit für das Leeren von Knoten verlängern.

Workaround:

Als Behelfslösung können Sie das bereinigungsbasierte Beenden von Knoten per Drain deaktivieren. Dadurch wird wieder auf das taintbasierte Draining zurückgegriffen. Wir empfehlen jedoch nicht, Knoten auf Grundlage von Taints zu leeren, da dabei keine PodDisruptionBudgets (PDBs) berücksichtigt werden, was zu Dienstunterbrechungen führen kann.
Installation, Upgrades und Updates 1.16, 1.28 und 1.29

Die Clusterabstimmung ist eine Standardphase für die meisten Clusteroperationen, einschließlich der Clustererstellung und Clusterupgrades. Während des Clusterabgleichs löst der Google Distributed Cloud-Clustercontroller eine Preflight-Prüfung aus. Wenn diese Preflight-Prüfung fehlschlägt, wird die weitere Clusterabstimmung blockiert. Daher werden auch Clusteroperationen blockiert, die die Clusterabstimmung umfassen.

Diese Preflight-Prüfung wird nicht regelmäßig, sondern nur im Rahmen der Clusterabstimmung ausgeführt. Selbst wenn Sie das Problem beheben, das den ursprünglichen Preflight-Fehler verursacht hat, und On-Demand-Preflight-Prüfungen erfolgreich ausgeführt werden, wird die Clusterabstimmung aufgrund dieser alten fehlgeschlagenen Preflight-Prüfung weiterhin blockiert.

Wenn die Installation oder das Upgrade eines Clusters hängen bleibt, können Sie mit den folgenden Schritten prüfen, ob Sie von diesem Problem betroffen sind:

  1. Prüfen Sie die anthos-cluster-operator-Pod-Logs auf Einträge wie die folgenden: 
    "msg"="Preflight check not ready. Won't reconcile"
  2. Prüfen Sie, ob die vom Clustercontroller ausgelöste Preflight-Prüfung fehlgeschlagen ist: 
    kubectl describe preflightcheck PREFLIGHT_CHECK_NAME \
    -n CLUSTER_NAMESPACE \
    --kubeconfig=ADMIN_KUBECONFIG

    Ersetzen Sie Folgendes:

    • PREFLIGHT_CHECK_NAME: Der Name der zu löschenden Preflight-Prüfung. In diesem Fall entspricht der Name dem Clusternamen.
    • CLUSTER_NAMESPACE: der Namespace des Clusters, für den die Vorabprüfung fehlschlägt.
    • ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters.

    Wenn die Preflight-Prüfung fehlgeschlagen ist (Status.Pass ist false), sind Sie wahrscheinlich von diesem Problem betroffen.

Dieses Problem wurde in Version 1.30 und allen späteren Versionen behoben.

Problemumgehung

Um Clusteroperationen zu entblockieren, löschen Sie die fehlgeschlagene Preflight-Prüfung manuell aus dem Administratorcluster:

kubectl delete preflightcheck PREFLIGHT_CHECK_NAME \
    -n CLUSTER_NAMESPACE \
    --kubeconfig=ADMIN_KUBECONFIG

Sobald die alte fehlgeschlagene Preflight-Prüfung gelöscht wurde, kann der Clustercontroller eine neue Preflight-Prüfung erstellen.
Installation, Upgrades und Updates 1.30.100, 1.30.200 und 1.30.300

Das Erstellen von Nutzerclustern in den Versionen 1.30.100, 1.30.200 oder 1.30.300 oder das Aktualisieren vorhandener Nutzercluster auf diese Versionen schlägt möglicherweise fehl. Dieses Problem tritt nur auf, wenn kubectl oder ein GKE On-Prem API-Client (die Google Cloud -Konsole, die gcloud CLI oder Terraform) für Erstellungs- und Upgradevorgänge des Nutzerclusters verwendet wird.

In diesem Fall bleibt die Erstellung des Nutzerclusters im Status Provisioning hängen und ein Upgrade des Nutzerclusters bleibt im Status Reconciling hängen.

So prüfen Sie, ob ein Cluster betroffen ist:

  1. Rufen Sie die Clusterressource ab: 
    kubectl get cluster CLUSTER_NAME -n USER_CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name des Nutzerclusters, der nicht reagiert.
    • USER_CLUSTER_NAMESPACE: der Namespace-Name des Nutzerclusters.
    • ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des verwaltenden Clusters.

    Wenn der CLUSTER STATE-Wert Provisioning oder Reconciling ist, sind Sie möglicherweise von diesem Problem betroffen. Die folgende Beispielantwort ist ein Hinweis darauf, dass ein Upgrade nicht abgeschlossen werden kann:

    NAME            ABM VERSION      DESIRED ABM VERSION  CLUSTER STATE
some-cluster    1.30.0-gke.1930  1.30.100-gke.96      Reconciling

    Die nicht übereinstimmenden Versionen sind auch ein Hinweis darauf, dass das Clusterupgrade noch nicht abgeschlossen ist.

  2. Suchen Sie den vollständigen Namen des anthos-cluster-operator-Pods: 
    kubectl get pods -n kube-system -o=name \
    -l baremetal.cluster.gke.io/lifecycle-controller-component=true \
    --kubeconfig ADMIN_KUBECONFIG

    Wie im folgenden Beispiel zu sehen ist, ist die Ausgabe eine Liste von Pods, die den anthos-cluster-operator-Pod enthält:

    pod/anthos-cluster-operator-1.30.100-gke.96-d96cf6765-lqbsg
pod/cap-controller-manager-1.30.100-gke.96-fcb5b5797-xzmb7
  3. Streamen Sie die Logs des anthos-cluster-operator-Pods nach einer sich wiederholenden Meldung, die darauf hinweist, dass der Cluster bei der Bereitstellung oder beim Abgleich hängen geblieben ist: 
    kubectl logs POD_NAME -n kube-system -f --since=15s \
    --kubeconfig ADMIN_KUBECONFIG | \
    grep "Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing"

    Ersetzen Sie POD_NAME durch den vollständigen Namen des anthos-cluster-operator-Pods aus dem vorherigen Schritt.

    Achten Sie während der Ausführung des Befehls auf einen kontinuierlichen Stream übereinstimmender Logzeilen. Dies ist ein Hinweis darauf, dass der Clustervorgang nicht mehr reagiert. Die folgende Beispielausgabe ähnelt der Ausgabe, die angezeigt wird, wenn ein Cluster nicht abgeglichen werden kann:

    ...
I1107 17:06:32.528471       1 reconciler.go:1475]  "msg"="Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" "Cluster"={"name":"user-t05db3f0761d4061-cluster","namespace":"cluster-user-t05db3f0761d4061-cluster"} "controller"="cluster" "controllerGroup"="baremetal.cluster.gke.io" "controllerKind"="Cluster" "name"="user-t05db3f0761d4061-cluster" "namespace"="cluster-user-t05db3f0761d4061-cluster" "reconcileID"="a09c70a6-059f-4e81-b6b2-aaf19fd5f926"
I1107 17:06:37.575174       1 reconciler.go:1475]  "msg"="Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" "Cluster"={"name":"user-t05db3f0761d4061-cluster","namespace":"cluster-user-t05db3f0761d4061-cluster"} "controller"="cluster" "controllerGroup"="baremetal.cluster.gke.io" "controllerKind"="Cluster" "name"="user-t05db3f0761d4061-cluster" "namespace"="cluster-user-t05db3f0761d4061-cluster" "reconcileID"="e1906c8a-cee0-43fd-ad78-88d106d4d30a""Name":"user-test-v2"} "err"="1 error occurred:\n\t* failed to construct the job: ConfigMap \"metadata-image-digests\" not found\n\n"
...

    Drücken Sie Strg+C, um das Streamen der Logs zu beenden.

  4. Prüfen Sie, ob die ConfigMapForwarder nicht mehr reagiert: 
    kubectl get configmapforwarder metadata-image-digests-in-cluster \
    -n USER_CLUSTER_NAMESPACE \
    -o jsonpath='{range .status.conditions[?(@.type=="Ready")]}Reason: {.reason}{"\n"}Message: {.message}{"\n"}{end}' \
    --kubeconfig ADMIN_KUBECONFIG

    Die Antwort enthält Gründe und Nachrichten aus der ConfigMapForwarder-Ressource. Wenn ConfigMapForwarder nicht mehr reagiert, sollten Sie eine Ausgabe wie die folgende sehen:

    Reason: Stalled
Message: cannot forward configmap kube-system/metadata-image-digests without "baremetal.cluster.gke.io/mark-source" annotation
  5. Prüfen Sie, ob die metadata-image-digests-ConfigMap nicht im Namespace des Nutzerclusters vorhanden ist: 
    kubectl get configmaps metadata-image-digests \
    -n USER_CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

    Die Antwort sollte in etwa so aussehen:

    Error from server (NotFound): configmaps "metadata-image-digests" not found

Problemumgehung

Als Workaround können Sie die ConfigMap manuell aktualisieren, um die fehlende Annotation hinzuzufügen:

  1. Fügen Sie der ConfigMap die fehlende Annotation hinzu: 
    kubectl annotate configmap metadata-image-digests \
    -n kube-system "baremetal.cluster.gke.io/mark-source"="true" \
    --kubeconfig ADMIN_KUBECONFIG

    Wenn sie richtig annotiert ist, sollte die metadata-image-digests-ConfigMap automatisch im Namespace des Nutzerclusters erstellt werden.

  2. Prüfen Sie, ob die ConfigMap automatisch im Namespace des Nutzerclusters erstellt wird: 
    kubectl get configmaps metadata-image-digests \
    -n USER_CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

    Wenn die ConfigMap erfolgreich erstellt wurde, sieht die Antwort des Befehls in etwa so aus:

    NAME                     DATA   AGE
metadata-image-digests   0      7s

Nachdem Sie die oben genannten Korrekturen und Überprüfungen vorgenommen haben, sollte der Clusteroperator nicht mehr blockiert sein und der Cluster sollte wie gewohnt funktionieren.
Vorgang, Zurücksetzen/Löschen 1.30.0 – 1.30.300, 1.29.0 – 1.29.700, 1.28.0 – 1.28.1100

Wenn bmctl restore --control-plane-node als Nutzer ohne Root-Berechtigung ausgeführt wird, tritt beim Kopieren von Dateien vom Steuerungsebenenknoten auf den Arbeitsstationscomputer ein chown-Problem auf.

Workaround:

Führen Sie den Befehl bmctl restore --control-plane-node mit sudo für Nutzer ohne Root-Berechtigung aus.
Upgrades 1.30.0-gke.1930

Während eines Upgrades kann der Job „upgrade-health-check“ aufgrund des fehlenden Pause-Images in Version 3.9 im aktiven Status bleiben.

Dieses Problem hat keine Auswirkungen auf den Erfolg des Upgrades.

Workaround:

Löschen Sie den Job „upgrade-health-check“ manuell mit dem folgenden Befehl:

    kubectl delete job upgrade-health-check-JOB_ID --cascade=true
Betriebssystem 1.28, 1.29, 1.30

Langsame Downloads in Containern unter RHEL 9.2

Das Herunterladen von Artefakten, deren Größe das memory.max-Limit der Cgroup überschreitet, kann sehr lange dauern. Dieses Problem wird durch einen Fehler im Linux-Kernel für Red Hat Enterprise Linux (RHEL) 9.2 verursacht. Kernel mit aktiviertem cgroup v2 sind betroffen. Das Problem wurde in den Kernelversionen 5.14.0-284.40.1.el_9.2 und höher behoben.

Workaround:

Erhöhen Sie für betroffene Pods die Einstellungen für das Arbeitsspeicherlimit für die zugehörigen Container (spec.containers[].resources.limits.memory), damit die Limits größer als die Größe der heruntergeladenen Artefakte sind.
Upgrades 1.28 bis 1.29.200

Während eines Bare-Metal-Clusterupgrades kann das Upgrade mit einer Fehlermeldung fehlschlagen, die darauf hinweist, dass ein Konflikt in der benutzerdefinierten Ressourcendefinition networks.networking.gke.io vorliegt. Der Fehler weist darauf hin, dass v1alpha1 nicht in spec.versions vorhanden ist.

Dieses Problem tritt auf, weil die v1alpha1-Version der benutzerdefinierten Ressourcendefinition während des Upgrades nicht zu v1 migriert wurde.

Workaround:

Patchen Sie die betroffenen Cluster mit den folgenden Befehlen:

kubectl patch customresourcedefinitions/networkinterfaces.networking.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
kubectl patch customresourcedefinitions/networks.networking.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
Installation, Upgrades und Updates 1.28.0 bis 1.28.600 und 1.29.0 bis 1.29.200

Während der Clusterinstallation oder des Clusterupgrades schlagen die Preflight-Prüfungen für Maschinen im Zusammenhang mit den fs.inotify-Kerneleinstellungen möglicherweise fehl. Wenn Sie von diesem Problem betroffen sind, enthält das Log der Preflight-Prüfung des Geräts einen Fehler wie den folgenden: 

Minimum kernel setting required for fs.inotify.max_user_instances is 8192. Current fs.inotify.max_user_instances value is 128. Please run "echo "fs.inotify.max_user_instances=8192" | sudo tee --append /etc/sysctl.conf" to set the correct value.

Dieses Problem tritt auf, weil die Werte fs.inotify max_user_instances und max_user_watches fälschlicherweise von der Steuerungsebene und den Bootstrap-Hosts anstelle der vorgesehenen Knotencomputer gelesen werden.

Behelfslösung :
Um dieses Problem zu umgehen, passen Sie die Werte für fs.inotify.max_user_instances und fs.inotify.max_user_watches auf allen Steuerungsebenen und Bootstrap-Maschinen an die empfohlenen Werte an: 

echo fs.inotify.max_user_watches=524288 | sudo tee --append /etc/sysctl.conf
echo fs.inotify.max_user_instances=8192 | sudo tee --append /etc/sysctl.conf
sudo sysctl -p

Nach Abschluss der Installation oder des Upgrades können diese Werte bei Bedarf wiederhergestellt werden.

Upgrades 1.28.0 - 1.28.500

Wenn Sie bmctl verwenden, um ein Upgrade für einen Cluster durchzuführen, schlägt das Upgrade möglicherweise mit einem GCP reachability check failed-Fehler fehl, obwohl die Ziel-URL von der Administratorworkstation aus erreichbar ist. Dieses Problem wird durch einen Fehler in bmctl-Versionen 1.28.0 bis 1.28.500 verursacht.

Workaround:

Bevor Sie den Befehl bmctl upgrade ausführen, legen Sie die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS so fest, dass sie auf eine gültige Dienstkontoschlüsseldatei verweist:

export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH
bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

Wenn Sie die Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) auf diese Weise festlegen, hat bmctl die erforderlichen Anmeldedaten für den Zugriff auf den Google API-Endpunkt.
Konfiguration, Installation, Upgrades und Updates, Netzwerk, Sicherheit 1.15, 1.16, 1.28, 1.29

Die Clusterinstallation und das Clusterupgrade schlagen fehl, wenn ipam-controller-manager erforderlich ist und Ihr Cluster unter Red Hat Enterprise Linux (RHEL) 8.9 oder höher (abhängig von Upstream-RHEL-Änderungen) mit SELinux im Enforcing-Modus ausgeführt wird. Das gilt insbesondere, wenn die container-selinux-Version höher als 2.225.0 ist.

Ihr Cluster erfordert die ipam-controller-manager in den folgenden Situationen:

  • Ihr Cluster ist für IPv4/IPv6-Dual-Stack-Netzwerk konfiguriert.
  • Ihr Cluster ist mit clusterNetwork.flatIPv4 konfiguriert, das auf true festgelegt ist.
  • Ihr Cluster ist mit der Annotation preview.baremetal.cluster.gke.io/multi-networking: enable konfiguriert.

Die Clusterinstallation und das Clusterupgrade schlagen fehl, wenn ipam-controller-manager installiert ist.

Problemumgehung

Legen Sie den Standardkontext für das Verzeichnis /etc/kubernetes auf jedem Knoten der Steuerungsebene auf den Typ etc_t fest: 

semanage fcontext /etc/kubernetes --add -t etc_t
semanage fcontext /etc/kubernetes/controller-manager.conf --add -t etc_t
restorecon -R /etc/kubernetes

Mit diesen Befehlen wird die Änderung von container-selinux im Verzeichnis /etc/kubernetes rückgängig gemacht.

Nachdem der Cluster auf eine Version mit dem Fix aktualisiert wurde, machen Sie die vorherige Änderung des Dateikontexts auf jedem Knoten der Steuerungsebene rückgängig: 

semanage fcontext /etc/kubernetes --delete -t etc_t
semanage fcontext /etc/kubernetes/controller-manager.conf --delete -t etc_t
restorecon -R /etc/kubernetes
Upgrades 1.28.0 - 1.28.500

Wenn Sie bmctl verwenden, um ein Upgrade für einen Cluster durchzuführen, schlägt das Upgrade möglicherweise mit einem GCP reachability check failed-Fehler fehl, obwohl die Ziel-URL von der Administratorworkstation aus erreichbar ist. Dieses Problem wird durch einen Fehler in bmctl-Versionen 1.28.0 bis 1.28.500 verursacht.

Workaround:

Bevor Sie den Befehl bmctl upgrade ausführen, legen Sie die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS so fest, dass sie auf eine gültige Dienstkontoschlüsseldatei verweist:

export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH
bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

Wenn Sie die Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) auf diese Weise festlegen, hat bmctl die erforderlichen Anmeldedaten für den Zugriff auf den Google API-Endpunkt.
Installation 1,29

Die Installation eines Clusters mit einem separaten Load-Balancer-Knotenpool kann fehlschlagen, wenn Sie die Binärautorisierungsrichtlinie während der Clustererstellung aktivieren.

Dieses Problem tritt auf, weil die Erstellung des GKE Identity Service-Pods und anderer wichtiger Pods durch den Binärautorisierung-Webhook blockiert wird.

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

  1. Ermitteln Sie, welche Pods fehlschlagen: 
    kubectl get pods \
    -n anthos-identity-service \
    --kubeconfig CLUSTER_KUBECONFIG
  2. Beschreiben Sie den fehlerhaften Pod.
  3. Suchen Sie in der Ausgabe nach der folgenden Meldung:
    4. admission webhook "binaryauthorization.googleapis.com" denied the
        request: failed to post request to endpoint: Post
"https://binaryauthorization.googleapis.com/internal/projects/PROJECT_NUMBER/policy/locations/LOCATION/clusters/CLUSTER_NAME:admissionReview":
        oauth2/google: status code 400:
{"error":"invalid_target","error_description":"The
        target service indicated by the \"audience\" parameters is invalid.
This might either be because the pool or provider is disabled or deleted
or because it doesn't exist."}

    Wenn Sie die oben genannte Meldung sehen, ist Ihr Cluster von diesem Problem betroffen.

Workaround:

So umgehen Sie das Problem:

  1. Vorgang zum Erstellen des Clusters abbrechen.
  2. Entfernen Sie den Block spec.binaryAuthorization aus der Clusterkonfigurationsdatei.
  3. Erstellen Sie den Cluster mit deaktivierter Binärautorisierung.
  4. Nach Abschluss der Installation aktivieren Sie die Binärautorisierungsrichtlinie für einen vorhandenen Cluster.
Konfiguration, Installation 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30

Wenn Sie SELinux aktiviert haben und Dateisysteme in Kubernetes-bezogene Verzeichnisse einhängen, können Probleme wie ein fehlgeschlagener Cluster, nicht lesbare Dateien oder Berechtigungsprobleme auftreten.

Führen Sie den folgenden Befehl aus, um festzustellen, ob Sie von diesem Problem betroffen sind: 

ls -Z /var/lib/containerd
. Wenn Sie system_u:object_r:unlabeled_t:s0 sehen, wo Sie ein anderes Label wie system_u:object_r:container_var_lib_t:s0 erwarten, sind Sie betroffen.

Workaround:

Wenn Sie vor Kurzem Dateisysteme in Verzeichnisse eingebunden haben, müssen Sie dafür sorgen, dass diese Verzeichnisse mit Ihrer SELinux-Konfiguration übereinstimmen.

Außerdem sollten Sie die folgenden Befehle auf jeder Maschine ausführen, bevor Sie bmctl create cluster ausführen:

restorecon -R -v /var
 
restorecon -R -v /etc

Diese einmalige Korrektur bleibt nach dem Neustart bestehen, ist jedoch jedes Mal erforderlich, wenn ein neuer Knoten mit denselben Mount-Punkten hinzugefügt wird. Weitere Informationen finden Sie in der Red Hat-Dokumentation unter Dateisysteme bereitstellen.
Zurücksetzen/Löschen 1.29.0

Wenn Sie bmctl reset cluster -c ${USER_CLUSTER} ausführen, nachdem alle zugehörigen Jobs abgeschlossen sind, kann der Befehl den Namespace des Nutzerclusters nicht löschen. Der Namespace des Nutzerclusters befindet sich im Status Terminating. Irgendwann läuft das Zurücksetzen des Clusters ab und es wird ein Fehler zurückgegeben.

Workaround:

So entfernen Sie den Namespace und schließen das Zurücksetzen des Nutzerclusters ab:

  1. Löschen Sie den Pod metrics-server aus dem Administratorcluster: 
    kubectl delete pods -l k8s-app=metrics-server \
    -n gke-managed-metrics-server --kubeconfig ADMIN_KUBECONFIG_PATH
     In dieser Situation verhindert der metrics-server-Pod das Entfernen des Clusternamespace.
  2. Erzwingen Sie im Administratorcluster das Entfernen des Finalizers im Namespace des Nutzerclusters: 
    kubectl get ns ${USER_CLUSTER_NAMESPACE} -ojson | \
    jq '.spec.finalizers = []' | \
    kubectl replace --raw "/api/v1/namespaces/${USER_CLUSTER_NAMESPACE}/finalize" -f -
     Sobald der Finalizer entfernt wurde, wird der Clusternamespace entfernt und das Zurücksetzen des Clusters ist abgeschlossen.
Konfiguration, Installation, Sicherheit 1.16.0 bis 1.16.7 und 1.28.0 bis 1.28.400

Wenn Sie Binärautorisierung für Google Distributed Cloud aktiviert haben und eine Version von 1.16.0 bis 1.16.7 oder 1.28.0 bis 1.28.400 verwenden, kann es zu Problemen bei der Planung der Pods für die Funktion kommen. In diesen Versionen fehlt im Binary Authorization-Deployment ein nodeSelector. Daher können die Pods für die Funktion auf Worker-Knoten anstelle von Knoten der Steuerungsebene geplant werden. Dieses Verhalten führt nicht zu Fehlern, ist aber nicht beabsichtigt.

Workaround:

Führen Sie für alle betroffenen Cluster die folgenden Schritte aus:

  1. Öffnen Sie die Bereitstellungsdatei für die Binärautorisierung: 
    kubectl edit -n binauthz-system deployment binauthz-module-deployment
  2. Fügen Sie im Block spec.template.spec Folgendes nodeSelector hinzu:
    3.       nodeSelector:
        node-role.kubernetes.io/control-plane: ""
  3. Speichern Sie die Änderungen.

Nachdem die Änderung gespeichert wurde, werden die Pods nur auf den Knoten der Steuerungsebene neu bereitgestellt. Diese Korrektur muss nach jedem Upgrade angewendet werden.
Upgrades und Updates 1.28.0, 1.28.100, 1.28.200, 1.28.300

Beim Aktualisieren von Clustern, die vor Version 1.11.0 erstellt wurden, auf die Versionen 1.28.0 bis 1.28.300 kann es passieren, dass der Pod des Lifecycle-Controller-Deployers während des Upgrades in einen Fehlerstatus wechselt. In diesem Fall enthalten die Logs des Lifecycle Controller-Deployer-Pods eine Fehlermeldung ähnlich der folgenden: 

"inventorymachines.baremetal.cluster.gke.io\" is invalid: status.storedVersions[0]: Invalid value: \"v1alpha1\": must appear in spec.versions

Workaround:

Dieses Problem wurde in Version 1.28.400 behoben. Führen Sie ein Upgrade auf Version 1.28.400 oder höher durch, um das Problem zu beheben.

Wenn Sie kein Upgrade durchführen können, führen Sie die folgenden Befehle aus, um das Problem zu beheben: 

kubectl patch customresourcedefinitions/nodepoolclaims.baremetal.cluster.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'

kubectl patch customresourcedefinitions/machineclasses.baremetal.cluster.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'

kubectl patch customresourcedefinitions/inventorymachines.baremetal.cluster.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
Logging und Monitoring 1.13.7, 1.14, 1.15, 1.16, 1.28

Manchmal werden Cluster- oder Containerlogs im Log-Explorer in resource.labels.project_id mit einer anderen Projekt-ID getaggt.

Dies kann passieren, wenn der Cluster für die Verwendung von Observability PROJECT_ONE konfiguriert ist. Diese wird im Feld clusterOperations.projectID in der Clusterkonfiguration festgelegt. Die cloudOperationsServiceAccountKeyPath in der Konfiguration hat jedoch einen Dienstkontoschlüssel aus dem Projekt PROJECT_TWO.

In solchen Fällen werden alle Logs an PROJECT_ONE weitergeleitet, resource.labels.project_id wird jedoch als PROJECT_TWO gekennzeichnet.

Workaround:

Verwenden Sie eine der folgenden Optionen, um das Problem zu beheben:

  • Verwenden Sie ein Dienstkonto aus demselben Zielprojekt.
  • Ändern Sie project_id in der JSON-Datei des Dienstkontoschlüssels in das aktuelle Projekt.
  • Ändern Sie project_id direkt im Logfilter im Log-Explorer.
Netzwerk 1.29, 1.30

Bei Clustern der Version 1.29.0, die gebündeltes Load-Balancing mit BGP verwenden, kann die Load-Balancing-Leistung abnehmen, wenn sich die Gesamtzahl der Dienste vom Typ LoadBalancer der Zahl 2.000 nähert. Wenn die Leistung nachlässt, dauert es entweder lange, bis neu erstellte Dienste eine Verbindung herstellen, oder ein Client kann keine Verbindung zu ihnen herstellen. Vorhandene Dienste funktionieren weiterhin, aber Fehlerzustände wie der Verlust eines Load-Balancer-Knotens werden nicht effektiv behandelt. Diese Dienstprobleme treten auf, wenn die ang-controller-manager-Bereitstellung aufgrund von Arbeitsspeichermangel beendet wird.

Wenn Ihr Cluster von diesem Problem betroffen ist, sind die Dienste im Cluster nicht erreichbar und nicht fehlerfrei. Die ang-controller-manager-Bereitstellung befindet sich in einem CrashLoopBackOff. Die Antwort beim Auflisten der ang-controller-manager-Bereitstellungen ähnelt der folgenden: 

ang-controller-manager-79cdd97b88-9b2rd   0/1    CrashLoopBackOff   639 (59s ago)   2d10h   10.250.210.152   vm-bgplb-centos4-n1-02   <none>   <none>

ang-controller-manager-79cdd97b88-r6tcl   0/1   CrashLoopBackOff   620 (4m6s ago)   2d10h   10.250.202.2     vm-bgplb-centos4-n1-11   <none>   <none>

Problemumgehung

Als Workaround können Sie das Speicherressourcenlimit der ang-controller-manager-Bereitstellung um 100 MiB erhöhen und das CPU-Limit entfernen:

kubectl edit deployment ang-controller-manager -n kube-system --kubeconfig ADMIN_KUBECONFIG

Nachdem Sie die Änderungen erfolgreich vorgenommen und den Editor geschlossen haben, sollten Sie die folgende Ausgabe sehen: 

deployment.apps/ang-controller-manager edited

Prüfen Sie das Manifest von ang-controller-manager im Cluster, um zu sehen, ob die Änderungen angewendet wurden: 

kubectl get deployment ang-controller-manager \
   -n kube-system \
   -o custom-columns=NAME:.metadata.name,CPU_LIMITS:.spec.template.spec.containers[*].resources.limits.cpu,MEMORY_LIMITS:.spec.template.spec.containers[*].resources.limits.memory \
   --kubeconfig ADMIN_KUBECONFIG

Die Antwort sollte in etwa so aussehen: 

NAME                     CPU_LIMITS   MEMORY_LIMITS
ang-controller-manager   <none>       400Mi
Installation, Upgrades, Sicherung und Wiederherstellung 1.28.0, 1.28.100

Bei mehreren Clustervorgängen für Administratorcluster wird ein Bootstrap-Cluster erstellt. Bevor ein Bootstrap-Cluster erstellt wird, führt bmctl einen Google Cloud Erreichbarkeitstest von der Administratorworkstation aus durch. Diese Prüfung kann aufgrund von Verbindungsproblemen mit dem Artifact Registry-Endpunkt gcr.io fehlschlagen. Möglicherweise wird eine Fehlermeldung wie die folgende angezeigt:

        system checks failed for bootstrap machine: GCP reachability check failed: failed to reach url https://gcr.io: Get "https://cloud.google.com/artifact-registry/": net/http: request canceled (Client.Timeout exceeded while awaiting headers)

Problemumgehung

Um dieses Problem zu umgehen, wiederholen Sie den Vorgang mit dem Flag --ignore-validation-errors.
Netzwerk 1.15, 1.16

Bare-Metal-Cluster verwenden GKE Dataplane V2, das mit einigen Speicheranbietern nicht kompatibel ist. Möglicherweise treten Probleme mit hängenden NFS-Volumes oder Pods auf. Das ist besonders wahrscheinlich, wenn Sie Arbeitslasten mit ReadWriteMany-Volumes haben, die von Speichertreibern unterstützt werden, die für dieses Problem anfällig sind:

  • Robin.io
  • Portworx (sharedv4-Dienstvolumes)
  • csi-nfs

Diese Liste ist nicht vollständig.

Problemumgehung

Eine Lösung für dieses Problem ist für die folgenden Ubuntu-Versionen verfügbar:

  • 20.04 LTS: Verwenden Sie ein 5.4.0-Kernel-Image, das neuer als linux-image-5.4.0-166-generic ist.
  • 22.04 LTS: Verwenden Sie entweder ein 5.15.0-Kernel-Image, das neuer als linux-image-5.15.0-88-generic ist, oder den 6.5-HWE-Kernel.

Wenn Sie keine dieser Versionen verwenden, wenden Sie sich an den Google-Support.
Logging und Monitoring 1.15, 1.16, 1.28

Möglicherweise stellen Sie fest, dass kube-state-metrics oder der gke-metrics-agent-Pod, der sich auf demselben Knoten wie kube-state-metrics befindet, nicht genügend Arbeitsspeicher (OOM) hat.

Dies kann in Clustern mit mehr als 50 Knoten oder mit vielen Kubernetes-Objekten passieren.

Problemumgehung

Um dieses Problem zu beheben, aktualisieren Sie die benutzerdefinierte Ressourcendefinition stackdriver, damit das Feature-Gate ksmNodePodMetricsOnly verwendet wird. Durch dieses Feature-Gate wird dafür gesorgt, dass nur eine kleine Anzahl wichtiger Messwerte verfügbar ist.

So verwenden Sie diesen Workaround:

  1. Prüfen Sie die benutzerdefinierte Ressourcendefinition stackdriver auf verfügbare Feature-Gates: 
    kubectl -n kube-system get crd stackdrivers.addons.gke.io -o yaml | grep ksmNodePodMetricsOnly
  2. Aktualisieren Sie die benutzerdefinierte Ressourcendefinition stackdriver, um ksmNodePodMetricsOnly zu aktivieren: 
    kind:stackdriver
spec:
  featureGates:
     ksmNodePodMetricsOnly: true
Installation 1.28.0-1.28.200

Bei der Installation eines Clusters auf dem Betriebssystem Red Hat Enterprise Linux (RHEL) 9.2 kann ein Fehler aufgrund des fehlenden iptables-Pakets auftreten. Der Fehler tritt während der Preflight-Prüfung auf und löst eine Fehlermeldung ähnlich der folgenden aus:

'check_package_availability_pass': "The following packages are not available: ['iptables']"

RHEL 9.2 ist in der Vorabversion für Google Distributed Cloud-Version 1.28 verfügbar.

Problemumgehung

Umgehen Sie den Preflight-Prüfungsfehler, indem Sie spec.bypassPreflightCheck in der Clusterressource auf true setzen.
Vorgang 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

Wenn MetalLB eine große Anzahl von Diensten (über 10.000) verarbeitet, kann das Failover über eine Stunde dauern. Das liegt daran, dass MetalLB eine ratenbeschränkte Warteschlange verwendet, die bei hoher Skalierung eine Weile braucht, bis sie den Dienst erreicht, der ein Failover benötigt.

Problemumgehung

Aktualisieren Sie Ihren Cluster auf Version 1.28 oder höher. Wenn Sie kein Upgrade durchführen können, führt eine manuelle Bearbeitung des Dienstes (z. B. durch Hinzufügen einer Anmerkung) dazu, dass der Dienst schneller auf den Failover-Modus umschaltet.
Vorgang 1.16.0-1.16.6, 1.28.0-1.28.200

bmctl check cluster kann aufgrund von Proxyfehlern fehlschlagen, wenn die Umgebungsvariablen HTTPS_PROXY und NO_PROXY auf der Administratorworkstation nicht definiert sind. Der bmctl-Befehl gibt eine Fehlermeldung aus, dass einige Google-Dienste nicht aufgerufen werden konnten, wie im folgenden Beispiel:

[2024-01-29 23:49:03+0000] error validating cluster config: 2 errors occurred:
        * GKERegister check failed: 2 errors occurred:
        * Get "https://gkehub.googleapis.com/v1beta1/projects/baremetal-runqi/locations/global/memberships/ci-ec1a14a903eb1fc": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 108.177.98.95:443: i/o timeout
        * Post "https://cloudresourcemanager.googleapis.com/v1/projects/baremetal-runqi:testIamPermissions?alt=json&prettyPrint=false": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 74.125.199.95:443: i/o timeout

Problemumgehung

Stellen Sie HTTPS_PROXY und NO_PROXY auf der Administrator-Workstation manuell ein.
Upgrades und Updates 1.28.0-gke.435

In einigen Fällen ist in der Datei /var/log/apiserver/audit.log auf den Knoten der Steuerungsebene sowohl die Gruppen- als auch die Nutzerinhaberschaft auf root festgelegt. Diese Einstellung für den Dateibesitz führt zu Upgradefehlern für die Steuerungsebenenknoten, wenn ein Cluster von Version 1.16.x auf Version 1.28.0-gke.435 aktualisiert wird. Dieses Problem betrifft nur Cluster, die vor Version 1.11 erstellt wurden und für die Cloud-Audit-Logs deaktiviert waren. Cloud-Audit-Logs sind standardmäßig für Cluster ab Version 1.9 aktiviert.

Problemumgehung

Wenn Sie Ihren Cluster nicht auf Version 1.28.100-gke.146 aktualisieren können, führen Sie die folgenden Schritte als Problemumgehung aus, um das Clusterupgrade auf Version 1.28.0-gke.435 abzuschließen:

  • Wenn Cloud-Audit-Logs aktiviert sind, entfernen Sie die Datei /var/log/apiserver/audit.log.
  • Wenn Cloud-Audit-Logs deaktiviert sind, ändern Sie den /var/log/apiserver/audit.log-Inhaber in den des übergeordneten Verzeichnisses /var/log/apiserver.
Netzwerk, Upgrades und Updates 1.28.0-gke.435

Google Distributed Cloud verwendet MetalLB für das gebündelte Load-Balancing. In Google Distributed Cloud-Version 1.28.0-gke.435 wird das gebündelte MetalLB auf Version 0.13 aktualisiert, wodurch CRD-Unterstützung für IPAddressPools eingeführt wird. Da ConfigMaps jedoch einen beliebigen Namen für ein IPAddressPool zulassen, mussten die Poolnamen in einen Kubernetes-kompatiblen Namen konvertiert werden, indem dem Namen des IPAddressPool ein Hash angehängt wurde. Ein IPAddressPool mit dem Namen default wird beispielsweise in einen Namen wie default-qpvpd konvertiert, wenn Sie Ihren Cluster auf Version 1.28.0-gke.435 aktualisieren.

Da für MetalLB ein bestimmter Name eines IPPool für die Auswahl erforderlich ist, wird durch die Namenskonvertierung verhindert, dass MetalLB einen Pool auswählt und IP-Adressen zuweist. Daher erhalten Dienste, die metallb.universe.tf/address-pool als Annotation zum Auswählen des Adresspools für eine IP-Adresse verwenden, keine IP-Adresse mehr vom MetalLB-Controller.

Dieses Problem wurde in Google Distributed Cloud-Version 1.28.100-gke.146 behoben.

Problemumgehung

Wenn Sie Ihren Cluster nicht auf Version 1.28.100-gke.146 aktualisieren können, führen Sie die folgenden Schritte als Workaround aus:

  1. Rufen Sie den konvertierten Namen von IPAddressPool ab: 
    kubectl get IPAddressPools -n kube-system
  2. Aktualisieren Sie den betroffenen Dienst, um die Annotation metallb.universe.tf/address-pool auf den konvertierten Namen mit dem Hash festzulegen.

    Wenn der Name IPAddressPool beispielsweise von default in einen Namen wie default-qpvpd geändert wurde, ändern Sie die Annotation metallb.universe.tf/address-pool: default im Dienst in metallb.universe.tf/address-pool: default-qpvpd.

Der Hash, der bei der Namenskonvertierung verwendet wird, ist deterministisch. Der Workaround ist also dauerhaft.
Upgrades und Updates 1.14, 1.15, 1.16, 1.28, 1.29

Wenn Sie ein Upgrade von Clustern auf Version 1.14.x durchführen, werden einige Ressourcen aus der vorherigen Version nicht gelöscht. Möglicherweise sehen Sie eine Reihe von verwaisten Pods wie die folgenden:

capi-webhook-system/capi-controller-manager-xxx
capi-webhook-system/capi-kubeadm-bootstrap-controller-manager-xxx

Diese verwaisten Objekte haben keine direkten Auswirkungen auf den Clusterbetrieb. Wir empfehlen jedoch, sie zu entfernen.

  • Führen Sie die folgenden Befehle aus, um die verwaisten Objekte zu entfernen: 
    kubectl delete ns capi-webhook-system
kubectl delete validatingwebhookconfigurations capi-validating-webhook-configuration
kubectl delete mutatingwebhookconfigurations capi-mutating-webhook-configuration

Dieses Problem wurde in Google Distributed Cloud-Version 1.15.0 und höher behoben.
Installation 1,14

Wenn Sie versuchen, Google Distributed Cloud Version 1.14.x zu installieren, kann ein Fehler aufgrund der machine-init-Jobs auftreten, ähnlich wie in der folgenden Beispielausgabe:

"kubeadm join" task failed due to:
error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members

"kubeadm reset" task failed due to:
panic: runtime error: invalid memory address or nil pointer dereference

Workaround:

Entfernen Sie das veraltete etcd-Mitglied, das dazu führt, dass der machine-init-Job fehlschlägt. Führen Sie die folgenden Schritte auf einem funktionierenden Steuerungsebenenknoten aus:

  1. Listen Sie die vorhandenen etcd-Mitglieder auf: 
    etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/peer.crt \
  member list
     Suchen Sie nach Mitgliedern mit dem Status unstarted, wie in der folgenden Beispielausgabe gezeigt: 
    5feb7ac839625038, started, vm-72fed95a, https://203.0.113.11:2380, https://203.0.113.11:2379, false
99f09f145a74cb15, started, vm-8a5bc966, https://203.0.113.12:2380, https://203.0.113.12:2379, false
bd1949bcb70e2cb5, unstarted, , https://203.0.113.10:2380, , false
  2. Entfernen Sie das fehlerhafte etcd-Mitglied: 
    etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/peer.crt \
  member remove MEMBER_ID
     Ersetzen Sie MEMBER_ID durch die ID des fehlgeschlagenen etcd-Mitglieds. In der vorherigen Beispielausgabe lautet diese ID bd1949bcb70e2cb5.

    Die folgende Beispielausgabe zeigt, dass das Mitglied entfernt wurde: 
    Member bd1949bcb70e2cb5 removed from cluster  9d70e2a69debf2f
Netzwerk 1.28.0

In Cilium 1.13 sind die Berechtigungen für die cilium-operator-ClusterRole falsch. Die Berechtigungen für die Knoten list und watch fehlen. Der cilium-operator kann keine Garbage Collectors starten, was zu den folgenden Problemen führt:

  • Verlust von Cilium-Ressourcen.
  • Veraltete Identitäten werden nicht aus BFP-Richtlinienzuordnungen entfernt.
  • Richtlinienkarten können das Limit von 16.000 Pixeln erreichen.
    • Es können keine neuen Einträge hinzugefügt werden.
    • Falsche Durchsetzung von NetworkPolicy.
  • Identitäten erreichen möglicherweise das Limit von 64.000.
    • Es können keine neuen Pods erstellt werden.

Ein Operator, dem die Knotenberechtigungen fehlen, meldet die folgende Beispiel-Logmeldung:

2024-01-02T20:41:37.742276761Z level=error msg=k8sError error="github.com/cilium/cilium/operator/watchers/node.go:83: Failed to watch *v1.Node: failed to list *v1.Node: nodes is forbidden: User \"system:serviceaccount:kube-system:cilium-operator\" cannot list resource \"nodes\" in API group \"\" at the cluster scope" subsys=k8s

Der Cilium-Agent meldet eine Fehlermeldung, wenn er keinen Eintrag in eine Richtlinienzuordnung einfügen kann, wie im folgenden Beispiel:

level=error msg="Failed to add PolicyMap key" bpfMapKey="{6572100 0 0 0}" containerID= datapathPolicyRevision=0 desiredPolicyRevision=7 endpointID=1313 error="Unable to update element for Cilium_policy_01313 map with file descriptor 190: the map is full, please consider resizing it. argument list too long" identity=128 ipv4= ipv6= k8sPodName=/ port=0 subsys=endpoint

Workaround:

Entfernen Sie die Cilium-Identitäten und fügen Sie dem Operator dann die fehlenden ClusterRole-Berechtigungen hinzu:

  1. Entfernen Sie die vorhandenen CiliumIdentity-Objekte: 
    kubectl delete ciliumid –-all
  2. Bearbeiten Sie das ClusterRole-Objekt cilium-operator: 
    kubectl edit clusterrole cilium-operator
  3. Fügen Sie einen Abschnitt für nodes mit den fehlenden Berechtigungen hinzu, wie im folgenden Beispiel gezeigt: 
    - apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - get
  - list
  - watch
  4. Speichern Sie die Datei und schließen Sie den Editor. Der Operator erkennt die Berechtigungsänderung dynamisch. Sie müssen den Operator nicht manuell neu starten.
Upgrades und Updates 1.15.0-1.15.7, 1.16.0-1.16.3

Eine der kubeadm-Systemdiagnoseaufgaben, die während der Preflight-Prüfung für das Upgrade ausgeführt werden, schlägt möglicherweise mit der folgenden Fehlermeldung fehl:

[ERROR CreateJob]: could not delete Job \"upgrade-health-check\" in the namespace \"kube-system\": jobs.batch \"upgrade-health-check\" not found

Dieser Fehler kann ignoriert werden. Wenn dieser Fehler auftritt und das Upgrade blockiert, führen Sie den Upgrade-Befehl noch einmal aus.

Wenn dieser Fehler auftritt, wenn Sie den Preflight-Check mit dem Befehl bmctl preflightcheck ausführen, wird dadurch nichts blockiert. Sie können die Preflight-Prüfung noch einmal ausführen, um die korrekten Preflight-Informationen zu erhalten.


Workaround:

Führen Sie den Upgradebefehl noch einmal aus. Wenn der Fehler während bmctl preflightcheck auftritt, führen Sie den Befehl preflightcheck noch einmal aus.
Vorgang 1.14, 1.15.0-1.15.7, 1.16.0-1.16.3, 1.28.0

Dieses Problem betrifft Cluster, in denen nach dem Ersetzen oder Entfernen eines Knotens regelmäßige Netzwerk-Systemdiagnosen durchgeführt werden. Wenn Ihr Cluster regelmäßig Systemdiagnosen durchläuft, führt die regelmäßige Netzwerkdiagnose nach dem Ersetzen oder Entfernen eines Knotens zu einem Fehler, da die ConfigMap für das Netzwerkinventar nach der Erstellung nicht aktualisiert wird.


Workaround:

Die empfohlene Problemumgehung besteht darin, die Inventory-ConfigMap und die regelmäßige Netzwerkdiagnose zu löschen. Der Clusteroperator erstellt sie automatisch mit den neuesten Informationen neu.

Führen Sie für Cluster der Version 1.14.x die folgenden Befehle aus:

kubectl delete configmap \
    $(kubectl get cronjob CLUSTER_NAME-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@name=="inventory-config-volume")].configMap.name}' \
    -n CLUSTER_NAMESPACE) \
    -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
kubectl delete healthchecks.baremetal.cluster.gke.io \
    CLUSTER_NAME-network -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Führen Sie für Cluster ab Version 1.15.0 die folgenden Befehle aus:

kubectl delete configmap \
    $(kubectl get cronjob bm-system-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@.name=="inventory-config-volume")]configMap.name}' \
    -n CLUSTER_NAMESPACE) \
    -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
kubectl delete healthchecks.baremetal.cluster.gke.io \
    bm-system-network -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
Netzwerk 1.14, 1.15, 1.16.0-1.16.2

Wenn Sie ein Netzwerkgerät haben, dessen Name einen Punkt (.) enthält, z. B. bond0.2, behandelt Network Gateway for GDC den Punkt als Pfad im Verzeichnis, wenn es sysctl ausführt, um Änderungen vorzunehmen. Wenn das Network Gateway for GDC prüft, ob die Erkennung doppelter Adressen (Duplicate Address Detection, DAD) aktiviert ist, kann die Prüfung fehlschlagen und es erfolgt kein Abgleich.

Das Verhalten unterscheidet sich je nach Clusterversion:

  • 1.14 und 1.15: Dieser Fehler tritt nur auf, wenn Sie dynamische IPv6-Adressen verwenden. Wenn Sie keine IPv6-Floating-IP-Adressen verwenden, tritt dieses Problem nicht auf, wenn Ihre Gerätenamen einen Punkt enthalten.
  • 1.16.0 – 1.16.2: Dieser Fehler tritt immer auf, wenn die Namen Ihrer Geräte einen Punkt enthalten.

Workaround:

Aktualisieren Sie Ihren Cluster auf Version 1.16.3 oder höher.

Als vorübergehende Lösung, bis Sie Ihre Cluster aktualisieren können, entfernen Sie den Punkt (.) aus dem Namen des Geräts.
Upgrades und Updates, Netzwerk, Sicherheit 1.16.0

Wenn seccomp für Ihren Cluster deaktiviert ist (spec.clusterSecurity.enableSeccomp auf false festgelegt), schlagen Upgrades auf Version 1.16.0 fehl.

In Google Distributed Cloud-Version 1.16 wird Kubernetes-Version 1.27 verwendet. In Kubernetes-Version 1.27.0 und höher ist das Feature zum Festlegen von seccomp-Profilen allgemein verfügbar und verwendet kein Feature-Gate mehr. Diese Kubernetes-Änderung führt dazu, dass Upgrades auf Version 1.16.0 fehlschlagen, wenn seccomp in der Clusterkonfiguration deaktiviert ist. Dieses Problem wurde in Clustern mit Version 1.16.1 und höher behoben. Wenn das Feld cluster.spec.clusterSecurity.enableSeccomp auf false festgelegt ist, können Sie ein Upgrade auf Version 1.16.1 oder höher durchführen.

Cluster, bei denen spec.clusterSecurity.enableSeccomp nicht festgelegt oder auf true gesetzt ist, sind nicht betroffen.
Installation, Betrieb 1.11, 1.12, 1.13, 1.14, 1.15.0-1.15.5, 1.16.0-1.16.1

Wenn Sie /var/lib/containerd optional eingebunden haben, können die containerd-Metadaten nach einem Neustart beschädigt werden. Beschädigte Metadaten können dazu führen, dass Pods fehlschlagen, einschließlich systemkritischer Pods.

Prüfen Sie, ob dieses Problem Sie betrifft. Suchen Sie dazu in /etc/fstab nach einer optionalen Bereitstellung für /var/lib/containerd/ und prüfen Sie, ob nofail in den Bereitstellungsoptionen enthalten ist.


Workaround:

Entfernen Sie die Mount-Option nofail in /etc/fstab oder führen Sie ein Upgrade Ihres Clusters auf Version 1.15.6 oder höher durch.
Vorgang 1.13, 1.14, 1.15, 1.16, 1.28

Es kann vorkommen, dass von einem Deployment (ReplicaSet) verwaltete Pods den Status Failed und den Status TaintToleration haben. Diese Pods verwenden keine Clusterressourcen, sollten aber gelöscht werden.

Mit dem folgenden kubectl-Befehl können Sie die Pods auflisten, die Sie bereinigen können:

kubectl get pods –A | grep TaintToleration

Die folgende Beispielausgabe zeigt einen Pod mit dem Status TaintToleration:

kube-system    stackdriver-metadata-agent-[...]    0/1    TaintToleration    0

Workaround:

Prüfen Sie für jeden Pod mit den beschriebenen Symptomen das ReplicaSet, zu dem der Pod gehört. Wenn das ReplicaSet erfüllt ist, können Sie die Pods löschen:

  1. Rufen Sie das ReplicaSet ab, das den Pod verwaltet, und suchen Sie den Wert ownerRef.Kind: 
    kubectl get pod POD_NAME -n NAMESPACE -o yaml
  2. Rufen Sie das ReplicaSet ab und prüfen Sie, ob status.replicas mit spec.replicas übereinstimmt: 
    kubectl get replicaset REPLICA_NAME -n NAMESPACE -o yaml
  3. Wenn die Namen übereinstimmen, löschen Sie den Pod: 
    kubectl delete pod POD_NAME -n NAMESPACE.
Upgrades 1.16.0

Wenn Sie ein Upgrade eines vorhandenen Clusters auf Version 1.16.0 durchführen, können Pod-Fehler im Zusammenhang mit etcd-Ereignissen den Vorgang zum Stillstand bringen. Genauer gesagt schlägt der Job „upgrade-node“ für den Schritt TASK [etcd_events_install : Run etcdevents] fehl.

Wenn Sie von diesem Problem betroffen sind, sehen Sie Pod-Fehler wie die folgenden:

  • Der kube-apiserver-Pod kann nicht gestartet werden und es wird der folgende Fehler ausgegeben: 
    connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:2382: connect: connection refused"
  • Der etcd-events-Pod kann nicht gestartet werden und es wird der folgende Fehler ausgegeben: 
    Error: error syncing endpoints with etcd: context deadline exceeded

Workaround:

Wenn Sie Ihren Cluster nicht auf eine Version mit der Fehlerkorrektur aktualisieren können, verwenden Sie die folgende temporäre Problemumgehung, um die Fehler zu beheben:

  1. Verwenden Sie SSH, um auf den Knoten der Steuerungsebene mit den gemeldeten Fehlern zuzugreifen.
  2. Bearbeiten Sie die Manifestdatei „etcd-events“, /etc/kubernetes/manifests/etcd-events.yaml, und entfernen Sie das Flag initial-cluster-state=existing.
  3. Wenden Sie das Manifest an.
  4. Das Upgrade sollte fortgesetzt werden.
Netzwerk 1.15.0-1.15.2

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

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 Korrektur an. Diese Korrektur bleibt bis zu einem Upgrade erhalten.

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

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

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

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


Workaround:

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

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

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

Das Erstellen von Clustern mit Version 1.15.0, 1.15.1 oder 1.15.2 oder das Aktualisieren von Clustern auf Version 1.15.0, 1.15.1 oder 1.15.2 schlägt fehl, wenn der Clustername länger als 48 Zeichen (Version 1.15.0) oder 45 Zeichen (Version 1.15.1 oder 1.15.2) ist. Während der Clustererstellung und Upgradevorgänge erstellt Google Distributed Cloud eine Health Check-Ressource mit einem Namen, der den Clusternamen und die Version enthält:

  • Bei Clustern der Version 1.15.0 lautet der Name der Systemdiagnoseressource CLUSTER_NAME-add-ons-CLUSTER_VER.
  • Bei Clustern der Version 1.15.1 oder 1.15.2 lautet der Name der Systemdiagnoseressource CLUSTER_NAME-kubernetes-CLUSTER_VER.

Bei langen Clusternamen überschreitet der Ressourcenname der Systemdiagnose die Kubernetes-Längenbeschränkung von 63 Zeichen für Labelnamen, wodurch die Erstellung der Systemdiagnoseressource verhindert wird. Ohne eine erfolgreiche Systemdiagnose schlägt der Clusterbetrieb fehl.

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

kubectl describe healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Wenn Sie von diesem Problem betroffen sind, enthält die Antwort eine Warnung für ein ReconcileError wie das folgende: 

...
Events:
  Type     Reason          Age                   From                    Message
  ----     ------          ----                  ----                    -------
  Warning  ReconcileError  77s (x15 over 2m39s)  healthcheck-controller  Reconcile error, retrying: 1 error occurred:
           * failed to create job for health check
db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1: Job.batch
"bm-system-db-uat-mfd7-fic-hybrid-cloud-u24d5f180362cffa4a743" is invalid: [metadata.labels: Invalid
value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63
characters, spec.template.labels: Invalid value:
"db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters]

Problemumgehung

Um das Cluster-Upgrade oder die Clustererstellung zu entblocken, können Sie den Healthcheck umgehen. Verwenden Sie den folgenden Befehl, um die benutzerdefinierte Ressource für die Systemdiagnose mit dem Status „Bestanden“ zu patchen: (status: {pass: true})

kubectl patch healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG --type=merge \
    --subresource status --patch 'status: {pass: true}'
Upgrades und Updates 1.14, 1.15

Wenn in Clustern der Versionen 1.14.0 und 1.14.1 eine Vorschaufunktion aktiviert ist, kann kein Upgrade auf Version 1.15.x durchgeführt werden. Dies gilt für Vorabfunktionen wie die Möglichkeit, einen Cluster ohne kube-proxy zu erstellen. Diese Funktion wird mit der folgenden Annotation in der Clusterkonfigurationsdatei aktiviert:

preview.baremetal.cluster.gke.io/kube-proxy-free: "enable"

Wenn Sie von diesem Problem betroffen sind, wird beim Cluster-Upgrade ein Fehler wie der folgende angezeigt:

[2023-06-20 23:37:47+0000] error judging if the cluster is managing itself:
error to parse the target cluster: error parsing cluster config: 1 error
occurred:

Cluster.baremetal.cluster.gke.io "$cluster-name" is invalid:
Annotations[preview.baremetal.cluster.gke.io/$preview-feature-name]:
Forbidden: preview.baremetal.cluster.gke.io/$preview-feature-name feature
isn't supported in 1.15.1 Anthos Bare Metal version

Dieses Problem wurde in Clustern ab Version 1.14.2 behoben.


Workaround:

Wenn Sie Ihre Cluster nicht auf Version 1.14.2 oder höher aktualisieren können, bevor Sie ein Upgrade auf Version 1.15.x durchführen, können Sie direkt auf Version 1.15.x aktualisieren, indem Sie einen Bootstrap-Cluster verwenden:

bmctl upgrade cluster --use-bootstrap=true
Vorgang 1,15

Mit Network Gateway für GDC können Sie keine neuen NetworkGatewayGroup-benutzerdefinierten Ressourcen erstellen, die IP-Adressen in spec.floatingIPs enthalten, die bereits in vorhandenen NetworkGatewayGroup-benutzerdefinierten Ressourcen verwendet werden. Diese Regel wird durch einen Webhook in Bare-Metal-Clustern der Version 1.15.0 und höher erzwungen. Bereits vorhandene doppelte Floating-IP-Adressen führen nicht zu Fehlern. Der Webhook verhindert nur die Erstellung neuer benutzerdefinierter NetworkGatewayGroups-Ressourcen, die doppelte IP-Adressen enthalten.

Die Webhook-Fehlermeldung gibt die in Konflikt stehende IP-Adresse und die vorhandene benutzerdefinierte Ressource an, die sie bereits verwendet: 

IP address exists in other gateway with name default

In der ursprünglichen Dokumentation für erweiterte Netzwerkfunktionen wie das NAT-Gateway für ausgehenden Traffic wird nicht vor doppelten IP-Adressen gewarnt. Anfangs wurde nur die NetworkGatewayGroup-Ressource mit dem Namen default vom Abgleich erkannt. Das Network Gateway für GDC erkennt jetzt alle benutzerdefinierten NetworkGatewayGroup-Ressourcen im System-Namespace. Vorhandene benutzerdefinierte NetworkGatewayGroup-Ressourcen werden unverändert berücksichtigt.


Workaround:

Fehler treten nur beim Erstellen einer neuen benutzerdefinierten NetworkGatewayGroup-Ressource auf.

So beheben Sie den Fehler:

  1. Verwenden Sie den folgenden Befehl, um benutzerdefinierte NetworkGatewayGroups-Ressourcen aufzulisten: 
    kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
    -n kube-system -o yaml
  2. Öffnen Sie vorhandene benutzerdefinierte NetworkGatewayGroup-Ressourcen und entfernen Sie alle in Konflikt stehenden Floating-IP-Adressen (spec.floatingIPs): 
    kubectl edit NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
    -n kube-system RESOURCE_NAME
  3. Um die Änderungen zu übernehmen, schließen Sie die bearbeiteten benutzerdefinierten Ressourcen und speichern Sie sie.
VM Runtime on GDC 1.13.7

Wenn Sie VM Runtime on GDC in einem neuen oder aktualisierten Cluster der Version 1.13.7 aktivieren, der eine private Registrierung verwendet, werden VMs, die eine Verbindung zum Knotennetzwerk herstellen oder eine GPU verwenden, möglicherweise nicht richtig gestartet. Dieses Problem wird durch einige System-Pods im vm-system-Namespace verursacht, bei denen Fehler beim Abrufen von Images auftreten. Wenn Ihre VM beispielsweise das Knotennetzwerk verwendet, melden einige Pods möglicherweise Fehler beim Abrufen von Images wie die folgenden:

macvtap-4x9zp              0/1   Init:ImagePullBackOff  0     70m

Dieses Problem wurde in Clustern ab Version 1.14.0 behoben.

Problemumgehung

Wenn Sie Ihre Cluster nicht sofort aktualisieren können, können Sie Images manuell abrufen. Mit den folgenden Befehlen wird das macvtap-CNI-Plugin-Image für Ihre VM abgerufen und per Push in Ihre private Registry übertragen: 

docker pull \
    gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker tag \
    gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 \
    REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker push \
    REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21

Ersetzen Sie REG_HOST durch den Domainnamen eines Hosts, den Sie lokal spiegeln.

Installation 1.11, 1.12

Während der Clustererstellung im Kind-Cluster kann der gke-metrics-agent-Pod aufgrund eines Fehlers beim Abrufen des Images nicht gestartet werden:

error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"

Außerdem wird im containerd-Log des Bootstrap-Clusters der folgende Eintrag angezeigt:

Sep 13 23:54:20 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:20.378172743Z" level=info msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" " Sep 13 23:54:21 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:21.057247258Z" level=error msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" failed" error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"

Im Pod wird der folgende Fehler „failing to pull“ angezeigt:

gcr.io/gke-on-prem-staging/gke-metrics-agent

Problemumgehung

Trotz der Fehler wird die Clustererstellung nicht blockiert, da der gke-metrics-agent-Pod im Kind-Cluster dazu dient, die Erfolgsrate der Clustererstellung zu erhöhen und interne Tracking- und Monitoring-Vorgänge zu ermöglichen. Sie können diesen Fehler also ignorieren.

Problemumgehung

Trotz der Fehler wird die Clustererstellung nicht blockiert, da der gke-metrics-agent-Pod im Kind-Cluster dazu dient, die Erfolgsrate der Clustererstellung zu erhöhen und interne Tracking- und Monitoring-Vorgänge zu ermöglichen. Sie können diesen Fehler also ignorieren.
Vorgang, Netzwerk 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

Wenn Sie auf einen Dual-Stack-Dienst (einen Dienst mit IPv4- und IPv6-Endpunkten) zugreifen und den IPv6-Endpunkt verwenden, kann der LoadBalancer-Knoten, der den Dienst bereitstellt, abstürzen. Dieses Problem betrifft Kunden, die Dual-Stack-Dienste mit CentOS oder RHEL und einer Kernelversion vor kernel-4.18.0-372.46.1.el8_6 verwenden.

Wenn Sie der Meinung sind, dass dieses Problem Sie betrifft, prüfen Sie die Kernelversion auf dem LoadBalancer-Knoten mit dem Befehl uname -a.


Workaround:

Aktualisieren Sie den LoadBalancer-Knoten auf die Kernelversion kernel-4.18.0-372.46.1.el8_6 oder höher. Diese Kernelversion ist in CentOS und RHEL ab Version 8.6 standardmäßig verfügbar.
Netzwerk 1.11, 1.12, 1.13, 1.14.0

Nach dem Neustart eines Knotens können zeitweise Verbindungsprobleme für einen NodePort- oder LoadBalancer-Dienst auftreten. Beispielsweise können zeitweilige TLS-Handshake- oder Verbindungsreset-Fehler auftreten. Dieses Problem wurde für Clusterversionen 1.14.1 und höher behoben.

Prüfen Sie die iptables-Weiterleitungsregeln auf Knoten, auf denen der Backend-Pod für den betroffenen Dienst ausgeführt wird, um festzustellen, ob dieses Problem Sie betrifft:

sudo iptables -L FORWARD

Wenn Sie die Regel KUBE-FORWARD vor der Regel CILIUM_FORWARD in iptables sehen, sind Sie möglicherweise von diesem Problem betroffen. Die folgende Beispielausgabe zeigt einen Knoten, in dem das Problem auftritt:

Chain FORWARD (policy ACCEPT)
target                  prot opt source   destination
KUBE-FORWARD            all  --  anywhere anywhere                /* kubernetes forwarding rules */
KUBE-SERVICES           all  --  anywhere anywhere    ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere anywhere    ctstate NEW /* kubernetes externally-visible service portals */
CILIUM_FORWARD          all  --  anywhere anywhere                /* cilium-feeder: CILIUM_FORWARD */

Workaround:

Starten Sie den anetd-Pod auf dem falsch konfigurierten Knoten neu. Nachdem Sie den anetd-Pod neu gestartet haben, sollte die Weiterleitungsregel in iptables richtig konfiguriert sein.

Die folgende Beispielausgabe zeigt, dass die Regel CILIUM_FORWARD jetzt korrekt vor der Regel KUBE-FORWARD konfiguriert ist:

Chain FORWARD (policy ACCEPT)
target                  prot opt source   destination
CILIUM_FORWARD          all  --  anywhere anywhere                /* cilium-feeder: CILIUM_FORWARD */
KUBE-FORWARD            all  --  anywhere anywhere                /* kubernetes forwarding rules */
KUBE-SERVICES           all  --  anywhere anywhere    ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere anywhere    ctstate NEW /* kubernetes externally-visible service portals */
Upgrades und Updates 1.9, 1.10

Bei der Vorschaufunktion von Clustern der Version 1.9.x mit bmctl 1.9.x bleiben die ursprünglichen Berechtigungs- und Inhaberinformationen nicht erhalten. Wenn Sie prüfen möchten, ob Sie von dieser Funktion betroffen sind, extrahieren Sie die gesicherte Datei mit dem folgenden Befehl:

tar -xzvf BACKUP_FILE

Problemumgehung

Prüfen Sie, ob metadata.json vorhanden ist und ob bmctlVersion 1.9.x ist. Wenn metadata.json nicht vorhanden ist, führen Sie ein Upgrade auf einen 1.10.x-Cluster durch und verwenden Sie bmctl 1.10.x für die Sicherung/Wiederherstellung.
Upgrades und Erstellungen 1.14.2

Wenn Sie ein Upgrade auf einen Cluster der Version 1.14.2 mit einer OIDC-/LDAP-Konfiguration durchgeführt oder einen solchen Cluster erstellt haben, kann es sein, dass der clientconfig-operator-Pod im Status „Ausstehend“ hängen bleibt. Bei diesem Problem gibt es zwei clientconfig-operator-Pods, von denen sich einer im Status „Wird ausgeführt“ und der andere im Status „Ausstehend“ befindet.

Dieses Problem betrifft nur Cluster der Version 1.14.2. Ältere Clusterversionen wie 1.14.0 und 1.14.1 sind nicht betroffen. Dieses Problem wurde in Version 1.14.3 und allen nachfolgenden Releases behoben, einschließlich Version 1.15.0 und höher.


Workaround:

Als Workaround können Sie die clientconfig-operator-Bereitstellung patchen, um zusätzlichen Sicherheitskontext hinzuzufügen und sicherzustellen, dass die Bereitstellung bereit ist.

Verwenden Sie den folgenden Befehl, um clientconfig-operator im Zielcluster zu patchen: 

kubectl patch deployment clientconfig-operator -n kube-system \
    -p '{"spec":{"template":{"spec":{"containers": [{"name":"oidcproxy","securityContext":{"runAsGroup":2038,"runAsUser":2038}}]}}}}' \
    --kubeconfig CLUSTER_KUBECONFIG

Ersetzen Sie Folgendes:

  • CLUSTER_KUBECONFIG: Der Pfad der kubeconfig-Datei für den Zielcluster.
Vorgang 1.11, 1.12, 1.13, 1.14, 1.15

Bei Clustern ohne gebündeltes Load Balancing (spec.loadBalancer.mode auf manual gesetzt) kann der Befehl bmctl update credentials certificate-authorities rotate nicht mehr reagieren und mit dem folgenden Fehler fehlschlagen: x509: certificate signed by unknown authority.

Wenn Sie von diesem Problem betroffen sind, gibt der Befehl bmctl möglicherweise die folgende Meldung aus, bevor er nicht mehr reagiert:

Signing CA completed in 3/0 control-plane nodes

In diesem Fall schlägt der Befehl schließlich fehl. Das Log für das Rotieren der Zertifizierungsstelle für einen Cluster mit drei Steuerungsebenen kann Einträge wie die folgenden enthalten: 

[2023-06-14 22:33:17+0000] waiting for all nodes to trust CA bundle OK
[2023-06-14 22:41:27+0000] waiting for first round of pod restart to complete OK
Signing CA completed in 0/0 control-plane nodes
Signing CA completed in 1/0 control-plane nodes
Signing CA completed in 2/0 control-plane nodes
Signing CA completed in 3/0 control-plane nodes
...
Unable to connect to the server: x509: certificate signed by unknown
authority (possibly because of "crypto/rsa: verification error" while
trying to verify candidate authority certificate "kubernetes")

Problemumgehung

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Google-Support.
Installation, Netzwerk 1.11, 1.12, 1.13, 1.14.0-1.14.1

Wenn Sie einen Dual-Stack-Cluster (einen Cluster mit sowohl IPv4- als auch IPv6-Adressen) bereitstellen, kann es sein, dass die ipam-controller-manager-Pods in einer Crashloop enden. Dieses Verhalten führt dazu, dass die Knoten zwischen den Status Ready und NotReady wechseln, und kann dazu führen, dass die Clusterinstallation fehlschlägt. Dieses Problem kann auftreten, wenn der API-Server stark ausgelastet ist.

Um festzustellen, ob dieses Problem bei Ihnen auftritt, prüfen Sie, ob die ipam-controller-manager-Pods mit CrashLoopBackOff-Fehlern fehlschlagen:

kubectl -n kube-system get pods | grep  ipam-controller-manager

Die folgende Beispielausgabe zeigt Pods im Status CrashLoopBackOff:

ipam-controller-manager-h7xb8   0/1  CrashLoopBackOff   3 (19s ago)   2m ipam-controller-manager-vzrrf   0/1  CrashLoopBackOff   3 (19s ago)   2m1s
ipam-controller-manager-z8bdw   0/1  CrashLoopBackOff   3 (31s ago)   2m2s

Rufen Sie Details für den Knoten ab, der sich im Status NotReady befindet:

kubectl describe node <node-name> | grep PodCIDRs

In einem Cluster mit diesem Problem sind einem Knoten keine PodCIDRs zugewiesen, wie in der folgenden Beispielausgabe zu sehen:

PodCIDRs:

In einem fehlerfreien Cluster sollten allen Knoten Dual-Stack-PodCIDRs zugewiesen sein, wie in der folgenden Beispielausgabe zu sehen:

PodCIDRs:    192.168.6.0/24,222:333:444:555:5:4:7:0/120

Workaround:

Starten Sie den/die ipam-controller-manager-Pod(s) neu:

kubectl -n kube-system rollout restart ds ipam-controller-manager
Vorgang 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 und 1.14

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

  • Pod-Planung wird unterbrochen
  • Knoten können sich nicht registrieren
  • kubelet beobachtet keine Pod-Änderungen

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

Dieses Problem wurde in den Google Distributed Cloud-Versionen 1.12.9, 1.13.6, 1.14.3 und nachfolgenden Releases behoben. In diesen neueren Releases wird die etcd-Version 3.4.21 verwendet. Alle früheren Versionen von Google Distributed Cloud sind von diesem Problem betroffen.

Problemumgehung

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

So rufen Sie diesen Messwert im Metrics Explorer auf:

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

    Zum Metrics Explorer

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

Das SriovNetworkNodeState-Objekt syncStatus kann den Wert „Failed“ (Fehler) für einen konfigurierten Knoten melden. Führen Sie den folgenden Befehl aus, um den Status eines Knotens aufzurufen und festzustellen, ob das Problem Sie betrifft:

kubectl -n gke-operators get \
    sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io NODE_NAME \
    -o jsonpath='{.status.syncStatus}'

Ersetzen Sie NODE_NAME durch den Namen des Knotens, den Sie prüfen möchten.


Workaround:

Wenn der Status des SriovNetworkNodeState-Objekts „Fehler“ lautet, führen Sie ein Upgrade Ihres Clusters auf Version 1.11.7 oder höher oder Version 1.12.4 oder höher durch.
Upgrades und Updates 1.10, 1.11, 1.12, 1.13, 1.14.0, 1.14.1

Nach Abschluss des Upgrades kann es vorkommen, dass für einige Worker-Knoten die Bedingung „Bereit“ auf false gesetzt ist. In der Knotenressource wird neben der Bedingung „Bereit“ ein Fehler angezeigt, der dem folgenden Beispiel ähnelt:

container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized

Wenn Sie sich auf der Maschine anmelden, auf der der Vorgang angehalten wurde, ist die CNI-Konfiguration auf der Maschine leer:

sudo ls /etc/cni/net.d/

Problemumgehung

Starten Sie den anetd-Pod des Knotens neu, indem Sie ihn löschen.
Upgrades und Updates, Sicherheit 1.10

Nach mehreren manuellen oder automatischen Zertifikatsrotationen wird der Webhook-Pod, z. B. anthos-cluster-operator, nicht mit den neuen Zertifikaten aktualisiert, die von cert-manager ausgestellt wurden. Jede Aktualisierung der benutzerdefinierten Clusterressource schlägt fehl und führt zu einem Fehler wie dem folgenden: 

Internal error occurred: failed calling
webhook "vcluster.kb.io": failed to call webhook: Post "https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=10s": x509: certificate signed by unknown authority (possibly because of "x509:
invalid signature: parent certificate cannot sign this kind of certificate"
while trying to verify candidate authority certificate
"webhook-service.kube-system.svc")

Dieses Problem kann in den folgenden Fällen auftreten:

  • Wenn Sie zwei manuelle Zertifikatsrotationen, die von cert-manager ausgestellt wurden, auf einem Cluster durchgeführt haben, der älter als 180 Tage ist, und den anthos-cluster-operator noch nie neu gestartet haben,
  • Wenn Sie auf einem Cluster, der älter als 90 Tage ist, manuelle cert-manager-Zertifikatsrotationen durchgeführt und die anthos-cluster-operator nie neu gestartet haben.

Problemumgehung

Starten Sie den Pod neu, indem Sie anthos-cluster-operator beenden.
Upgrades und Updates 1.14.0

In Administratorclustern der Version 1.14.0 werden bei Upgrades von Nutzerclustern möglicherweise ein oder mehrere veraltete Lifecycle Controller Deployer-Pods erstellt. Dieses Problem betrifft Nutzercluster, die ursprünglich mit Versionen vor 1.12 erstellt wurden. Die unbeabsichtigt erstellten Pods beeinträchtigen keine Upgradevorgänge, befinden sich aber möglicherweise in einem unerwarteten Status. Wir empfehlen, die veralteten Pods zu entfernen.

Dieses Problem wurde in Version 1.14.1 behoben.

Workaround:

So entfernen Sie die veralteten Lifecycle Controller-Bereitstellungs-Pods:

  1. Preflight-Prüfungsressourcen auflisten: 
    kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A

    Sie erhalten folgende Ausgabe:

    NAMESPACE                    NAME                      PASS   AGE
cluster-ci-87a021b9dcbb31c   ci-87a021b9dcbb31c        true   20d
cluster-ci-87a021b9dcbb31c   ci-87a021b9dcbb31cd6jv6   false  20d

    Dabei ist „ci-87a021b9dcbb31c“ der Clustername.

  2. Löschen Sie Ressourcen, deren Wert in der Spalte „PASS“ entweder true oder false ist.

    Wenn Sie beispielsweise die Ressourcen in der vorherigen Beispielausgabe löschen möchten, verwenden Sie die folgenden Befehle:

    kubectl delete preflightchecks ci-87a021b9dcbb31c \
    -n cluster-ci-87a021b9dcbb31c \
    --kubeconfig ADMIN_KUBECONFIG 
kubectl delete preflightchecks ci-87a021b9dcbb31cd6jv6 \
    -n cluster-ci-87a021b9dcbb31c \
    --kubeconfig ADMIN_KUBECONFIG
Netzwerk 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

Google Distributed Cloud Advanced Networking kann BGP-Sitzungen nicht richtig verwalten, wenn externe Peers eine große Anzahl von Routen (etwa 100 oder mehr) bewerben. Bei einer großen Anzahl eingehender Routen benötigt der knotenlokale BGP-Controller zu lange, um BGP-Sitzungen abzugleichen, und kann den Status nicht aktualisieren. Da keine Statusaktualisierungen oder Systemdiagnosen erfolgen, wird die Sitzung als veraltet gelöscht.

Unerwünschtes Verhalten bei BGP-Sitzungen, das auf ein Problem hinweisen kann, umfasst Folgendes:

  • Kontinuierliches Löschen und Neuerstellen von bgpsession.
  • bgpsession.status.state wird nie zu Established
  • Routen, die nicht beworben werden oder wiederholt beworben und zurückgezogen werden.

Probleme mit dem BGP-Load-Balancing können sich durch Verbindungsprobleme mit LoadBalancer-Diensten bemerkbar machen.

Das BGP-Problem FlatIP kann sich durch Verbindungsprobleme mit Pods bemerkbar machen.

Wenn Sie feststellen möchten, ob Ihre BGP-Probleme dadurch verursacht werden, dass die Remote-Peers zu viele Routen ankündigen, verwenden Sie die folgenden Befehle, um die zugehörigen Status und Ausgaben zu prüfen:

  • Verwenden Sie kubectl get bgpsessions für den betroffenen Cluster. In der Ausgabe wird bgpsessions mit dem Status „Not Established“ (Nicht eingerichtet) angezeigt und die Zeit des letzten Berichts zählt kontinuierlich bis etwa 10–12 Sekunden hoch, bevor sie anscheinend auf null zurückgesetzt wird.
  • Die Ausgabe von kubectl get bgpsessions zeigt, dass die betroffenen Sitzungen wiederholt neu erstellt werden: 
    kubectl get bgpsessions \
    -o jsonpath="{.items[*]['metadata.name', 'metadata.creationTimestamp']}"
  • Logmeldungen weisen darauf hin, dass veraltete BGP-Sitzungen gelöscht werden: 
    kubectl logs ang-controller-manager-POD_NUMBER

    Ersetzen Sie POD_NUMBER durch den Leader-Pod in Ihrem Cluster.


Workaround:

Reduzieren oder eliminieren Sie die Anzahl der Routen, die vom Remote-Peer mit einer Exportrichtlinie für den Cluster beworben werden.

In Clusterversionen 1.14.2 und höher können Sie auch das Feature deaktivieren, mit dem empfangene Routen verarbeitet werden, indem Sie ein AddOnConfiguration verwenden. Fügen Sie das Argument --disable-received-routes dem Container bgpd des Daemonsets ang-daemon hinzu.
Netzwerk 1.14, 1.15, 1.16, 1.28

Bei Clustern, die auf einem Ubuntu-Betriebssystem mit Kernel 5.15 oder höher ausgeführt werden, kann es zu Fehlern beim Einfügen der Tabelle für das Verbindungs-Tracking (conntrack) von Netfilter kommen. Einfügungsfehler 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 ü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

Als kurzfristige Maßnahme können Sie die Größe der Netfilter-Hashtabelle (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. Wenn Ihr Knoten beispielsweise acht Kerne hat, legen Sie die Tabellengröße auf 524288 fest.
Upgrades und Updates 1.11.3, 1.11.4, 1.11.5, 1.11.6, 1.11.7, 1.11.8, 1.12.4, 1.12.5, 1.12.6, 1.12.7, 1.12.8, 1.13.4, 1.13.5

Wir empfehlen, Ihre Cluster vor dem Upgrade zu sichern, damit Sie die vorherige Version wiederherstellen können, falls das Upgrade fehlschlägt. Ein Problem mit dem Befehl bmctl restore cluster führt dazu, dass Sicherungen von Clustern mit den angegebenen Versionen nicht wiederhergestellt werden können. Dieses Problem tritt nur bei Upgrades auf, bei denen Sie ein Backup einer früheren Version wiederherstellen.

Wenn Ihr Cluster betroffen ist, enthält das bmctl restore cluster-Log den folgenden Fehler:

Error: failed to extract image paths from profile: anthos version VERSION not supported

Workaround:

Bis dieses Problem behoben ist, empfehlen wir, die Anleitung unter Cluster sichern und wiederherstellen zu verwenden, um Ihre Cluster manuell zu sichern und bei Bedarf manuell wiederherzustellen.
Netzwerk 1.10, 1.11, 1.12, 1.13, 1.14.0-1.14.2

Mit NetworkGatewayGroup können keine Daemons für Knoten erstellt werden, die nicht sowohl IPv4- als auch IPv6-Schnittstellen haben. Dadurch schlagen Funktionen wie BGP LB und EgressNAT fehl. Wenn Sie die Logs des fehlerhaften ang-node-Pods im Namespace kube-system prüfen, werden Fehler angezeigt, die dem folgenden Beispiel ähneln, wenn eine IPv6-Adresse fehlt:

ANGd.Setup    Failed to create ANG daemon    {"nodeName": "bm-node-1", "error":
"creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""}

Im vorherigen Beispiel gibt es keine IPv6-Adresse auf der ens192-Schnittstelle. Ähnliche ARP-Fehler werden angezeigt, wenn dem Knoten eine IPv4-Adresse fehlt.

NetworkGatewayGroup versucht, eine ARP- und eine NDP-Verbindung zur Link-Local-IP-Adresse herzustellen. Wenn die IP-Adresse nicht vorhanden ist (IPv4 für ARP, IPv6 für NDP), schlägt die Verbindung fehl und der Daemon wird nicht fortgesetzt.

Dieses Problem wurde in Version 1.14.3 behoben.


Workaround:

Stellen Sie über SSH eine Verbindung zum Knoten her und fügen Sie dem Link, der die Knoten-IP enthält, eine IPv4- oder IPv6-Adresse hinzu. Im vorherigen Beispiel-Logeintrag war diese Schnittstelle ens192:

ip address add dev INTERFACE scope link ADDRESS

Ersetzen Sie Folgendes:

  • INTERFACE: Die Schnittstelle für Ihren Knoten, z. B. ens192.
  • ADDRESS: Die IP-Adresse und Subnetzmaske, die auf die Schnittstelle angewendet werden sollen.
Zurücksetzen/Löschen 1.10, 1.11, 1.12, 1.13.0-1.13.2

Wenn Sie versuchen, einen Knoten der Steuerungsebene zu entfernen, indem Sie die IP-Adresse aus Cluster.Spec entfernen, gerät anthos-cluster-operator in eine Absturzschleife, die alle anderen Vorgänge blockiert.


Workaround:

Das Problem wurde in den Versionen 1.13.3 und 1.14.0 und höher behoben. Alle anderen Versionen sind betroffen. Upgrade auf eine der korrigierten Versionen durchführen

Führen Sie als Workaround den folgenden Befehl aus:

kubectl label baremetalmachine IP_ADDRESS \
    -n CLUSTER_NAMESPACE baremetal.cluster.gke.io/upgrade-apply-

Ersetzen Sie Folgendes:

  • IP_ADDRESS: Die IP-Adresse des Knotens, der sich in einer Absturzschleife befindet.
  • CLUSTER_NAMESPACE: Der Cluster-Namespace.
Installation 1.13.1, 1.13.2 und 1.13.3

Wenn Sie Cluster mit einer großen Anzahl von Knoten installieren, wird möglicherweise eine kubeadmin join-Fehlermeldung wie im folgenden Beispiel angezeigt:

TASK [kubeadm : kubeadm join --config /dev/stdin --ignore-preflight-errors=all] ***
fatal: [10.200.0.138]: FAILED! => {"changed": true, "cmd": "kubeadm join
--config /dev/stdin --ignore-preflight-errors=all", "delta": "0:05:00.140669", "end": "2022-11-01 21:53:15.195648", "msg": "non-zero return code", "rc": 1,
"start": "2022-11-01 21:48:15.054979", "stderr": "W1101 21:48:15.082440   99570 initconfiguration.go:119]
Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!\nerror
execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"\n
To see the stack trace of this error execute with --v=5 or higher", "stderr_lines":
["W1101 21:48:15.082440   99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\".
Please update your configuration!", "error execution phase preflight: couldn't validate the identity of the API Server:
could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"",
"To see the stack trace of this error execute with --v=5 or higher"], "stdout": "[preflight]
Running pre-flight checks", "stdout_lines": ["[preflight] Running pre-flight checks"]}

Workaround:

Dieses Problem wurde in Google Distributed Cloud-Version 1.13.4 und höher behoben.

Wenn Sie eine betroffene Version verwenden müssen, erstellen Sie zuerst einen Cluster mit weniger als 20 Knoten und passen Sie dann die Größe des Clusters an, um nach Abschluss der Installation zusätzliche Knoten hinzuzufügen.
Logging und Monitoring 1.10, 1.11, 1.12, 1.13.0

In Google Distributed Cloud Edge-Clustern können niedrige CPU-Limits für metrics-server zu häufigen Neustarts von metrics-server führen. Das horizontale Pod-Autoscaling (HPA) funktioniert nicht, da metrics-server fehlerhaft ist.

Wenn das metrics-server-CPU-Limit kleiner als 40m ist, kann dies Auswirkungen auf Ihre Cluster haben. Die metrics-server-CPU-Grenzwerte finden Sie in einer der folgenden Dateien:

  • Clusterversionen 1.x–1.12: 
    kubectl get deployment metrics-server -n kube-system \
    -o yaml > metrics-server.yaml
  • Clusterversionen 1.13 oder höher: 
    kubectl get deployment metrics-server -n gke-managed-metrics-server \
    -o yaml > metrics-server.yaml

Workaround:

Dieses Problem wurde in Clusterversion 1.13.1 oder höher behoben. Aktualisieren Sie Ihre Cluster, um dieses Problem zu beheben.

Eine kurzfristige Problemumgehung, bis Sie Cluster aktualisieren können, besteht darin, die CPU-Limits für metrics-server manuell zu erhöhen:

  1. Skalieren Sie metrics-server-operator herunter: 
    kubectl scale deploy metrics-server-operator --replicas=0
  2. Aktualisieren Sie die Konfiguration und erhöhen Sie die CPU-Limits:
    • Clusterversionen 1.x–1.12: 
      kubectl -n kube-system edit deployment metrics-server
    • Clusterversionen 1.13: 
      kubectl -n gke-managed-metrics-server edit deployment metrics-server

    Entfernen Sie die Zeile --config-dir=/etc/config und erhöhen Sie die CPU-Limits, wie im folgenden Beispiel gezeigt:

    [...]
- command:
- /pod_nanny
# - --config-dir=/etc/config # <--- Remove this line
- --container=metrics-server
- --cpu=50m # <--- Increase CPU, such as to 50m
- --extra-cpu=0.5m
- --memory=35Mi
- --extra-memory=4Mi
- --threshold=5
- --deployment=metrics-server
- --poll-period=30000
- --estimator=exponential
- --scale-down-delay=24h
- --minClusterSize=5
- --use-metrics=true
[...]
  3. Speichern Sie die metrics-server-Datei und schließen Sie sie, um die Änderungen zu übernehmen.
Netzwerk 1.14, 1.15, 1.16

Die Verbindung zu einem Pod, der mit hostNetwork über einen NodePort-Dienst aktiviert ist, schlägt fehl, wenn sich der Backend-Pod auf demselben Knoten wie der Ziel-NodePort befindet. Dieses Problem betrifft LoadBalancer-Dienste, wenn sie mit Pods mit hostNetwork verwendet werden. Bei mehreren Back-Ends kann es zu sporadischen Verbindungsfehlern kommen.

Dieses Problem wird durch einen Fehler im eBPF-Programm verursacht.


Workaround:

Wenn Sie einen NodePort-Dienst verwenden, richten Sie ihn nicht auf den Knoten aus, auf dem einer der Backend-Pods ausgeführt wird. Wenn Sie den LoadBalancer-Dienst verwenden, achten Sie darauf, dass die Pods mit hostNetwork nicht auf LoadBalancer-Knoten ausgeführt werden.
Upgrades und Updates 1.12.3, 1.13.0

Administratorcluster, auf denen Version 1.13.0 ausgeführt wird, können keine Nutzercluster verwalten, auf denen Version 1.12.3 ausgeführt wird. Vorgänge für einen Nutzercluster der Version 1.12.3 schlagen fehl.


Workaround:

Führen Sie ein Upgrade Ihres Administratorclusters auf Version 1.13.1 oder ein Upgrade des Nutzerclusters auf dieselbe Version wie den Administratorcluster durch.
Upgrades und Updates 1.12

Administratorcluster ab Version 1.13.0 dürfen keine Worker-Knotenpools enthalten. Upgrades auf Version 1.13.0 oder höher für Administratorcluster mit Worker-Knotenpools sind blockiert. Wenn das Upgrade des Administratorclusters nicht fortgesetzt wird, können Sie prüfen, ob Worker-Knotenpools die Ursache sind. Suchen Sie dazu in der Datei upgrade-cluster.log im Ordner bmctl-workspace nach dem folgenden Fehler:

Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed.

Workaround:

Verschieben Sie vor dem Upgrade alle Worker-Knotenpools in Nutzercluster. Eine Anleitung zum Hinzufügen und Entfernen von Knotenpools finden Sie unter Knotenpools in einem Cluster verwalten.

Upgrades und Updates 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

Wenn Sie vorhandene Ressourcen wie die benutzerdefinierten Ressourcen ClientConfig oder Stackdriver mit kubectl apply aktualisieren, gibt der Controller möglicherweise einen Fehler zurück oder macht Ihre Eingaben und geplanten Änderungen rückgängig.

Sie können beispielsweise versuchen, die benutzerdefinierte Stackdriver-Ressource so zu bearbeiten, dass Sie zuerst die Ressource abrufen und dann eine aktualisierte Version anwenden:

  1. Rufen Sie die vorhandene YAML-Definition ab: 
    kubectl get stackdriver -n kube-system stackdriver \
    -o yaml > stackdriver.yaml
  2. Aktivieren Sie Funktionen oder aktualisieren Sie die Konfiguration in der YAML-Datei.
  3. Wenden Sie die aktualisierte YAML-Datei wieder an: 
    kubectl apply -f stackdriver.yaml

Der letzte Schritt für kubectl apply ist der, bei dem möglicherweise Probleme auftreten.


Workaround:

Verwenden Sie kubectl apply nicht, um Änderungen an vorhandenen Ressourcen vorzunehmen. Verwenden Sie stattdessen kubectl edit oder kubectl patch, wie in den folgenden Beispielen gezeigt:

  1. Bearbeiten Sie die benutzerdefinierte Stackdriver-Ressource: 
    kubectl edit stackdriver -n kube-system stackdriver
  2. Aktivieren Sie Funktionen oder aktualisieren Sie die Konfiguration in der YAML-Datei.
  3. Speichern und Editor schließen

Alternative Vorgehensweise mit kubectl patch:

  1. Rufen Sie die vorhandene YAML-Definition ab: 
    kubectl get stackdriver -n kube-system stackdriver \
    -o yaml > stackdriver.yaml
  2. Aktivieren Sie Funktionen oder aktualisieren Sie die Konfiguration in der YAML-Datei.
  3. Wenden Sie die aktualisierte YAML-Datei wieder an: 
    kubectl patch stackdriver stackdriver --type merge \
    -n kube-system --patch-file stackdriver.yaml
Logging und Monitoring 1.12, 1.13, 1.14, 1.15, 1.16

Der stackdriver-log-forwarder stürzt ab, wenn er versucht, einen beschädigten Backlog-Abschnitt zu verarbeiten. Die folgenden Beispielfehler werden in den Containerlogs angezeigt:

[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks

Wenn dieser Crashloop auftritt, können Sie keine Logs in Cloud Logging sehen.


Workaround:

Führen Sie folgende Schritte aus, um diese Fehler zu beheben:

  1. Identifizieren Sie die beschädigten Backlog-Chunks. Hier sind einige Beispiele für Fehlermeldungen: 
    [2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks
    In diesem Beispiel ist die Datei tail.1/1-1659339894.252926599.flb, die in var/log/fluent-bit-buffers/tail.1/ gespeichert ist, die Ursache des Problems. Alle *.flb-Dateien, bei denen die Formatprüfung fehlgeschlagen ist, müssen entfernt werden.
  2. Beenden Sie die aktiven Pods für stackdriver-log-forwarder: 
    kubectl --kubeconfig KUBECONFIG -n kube-system \
    patch daemonset stackdriver-log-forwarder \
    -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
     Ersetzen Sie KUBECONFIG durch den Pfad zur kubeconfig-Datei des Nutzerclusters.

    Prüfen Sie, ob die stackdriver-log-forwarder-Pods gelöscht wurden, bevor Sie mit dem nächsten Schritt fortfahren.
  3. Stellen Sie über SSH eine Verbindung zum Knoten her, auf dem stackdriver-log-forwarder ausgeführt wird.
  4. Löschen Sie auf dem Knoten alle beschädigten *.flb-Dateien in var/log/fluent-bit-buffers/tail.1/.

    Wenn es zu viele beschädigte Dateien gibt und Sie ein Skript verwenden möchten, um alle Backlog-Chunks zu bereinigen, verwenden Sie die folgenden Skripts:
    1. Stellen Sie ein DaemonSet bereit, um alle fehlerhaften Daten in Puffern in fluent-bit zu bereinigen: 
      kubectl --kubeconfig KUBECONFIG -n kube-system apply -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
    2. Prüfen Sie, ob das DaemonSet alle Knoten bereinigt hat. Die Ausgabe der folgenden beiden Befehle sollte der Anzahl der Knoten im Cluster entsprechen: 
      kubectl --kubeconfig KUBECONFIG logs \
    -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l
kubectl --kubeconfig KUBECONFIG \
    -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
    3. Löschen Sie das Bereinigungs-Daemonset: 
      kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \
    fluent-bit-cleanup
    4. Starten Sie die stackdriver-log-forwarder-Pods neu: 
      kubectl --kubeconfig KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder --type json \
    -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
Netzwerk, VM Runtime on GDC 1.14.0

In Clustern mit mehreren NICs kann das Neustarten von Dataplane V2 (anetd) dazu führen, dass virtuelle Maschinen keine Verbindung zu Netzwerken herstellen können. In den anetd-Pod-Logs wird möglicherweise ein Fehler wie der folgende angezeigt:

could not find an allocator to allocate the IP of the multi-nic endpoint

Workaround:

Als schnelle Lösung können Sie die VM neu starten. Um ein erneutes Auftreten des Problems zu vermeiden, aktualisieren Sie Ihren Cluster auf Version 1.14.1 oder höher.
Vorgang 1.13, 1.14.0, 1.14.1

Je nach Arbeitslast des Clusters kann die gke-metrics-agent mehr als 4.608 MiB Arbeitsspeicher verwenden. Dieses Problem betrifft nur Google Distributed Cloud for Bare Metal-Cluster mit Edge-Profil. Standardprofilcluster sind davon nicht betroffen.


Workaround:

Aktualisieren Sie Ihren Cluster auf Version 1.14.2 oder höher.
Installation 1.12, 1.13

Wenn Sie Cluster mit kubectl erstellen, kann es aufgrund von Race-Bedingungen vorkommen, dass die Preflight-Prüfung nie abgeschlossen wird. Daher kann die Clustererstellung in bestimmten Fällen fehlschlagen.

Der Preflight-Check-Abgleicher erstellt ein SecretForwarder, um das Standard-Secret ssh-key in den Ziel-Namespace zu kopieren. In der Regel werden bei der Preflight-Prüfung die Inhaberreferenzen verwendet und nach Abschluss von SecretForwarder abgeglichen. In seltenen Fällen kann es jedoch vorkommen, dass die Inhaberreferenzen von SecretForwarder die Referenz zur Preflight-Prüfung verlieren, wodurch die Preflight-Prüfung hängen bleibt. Daher schlägt die Clustererstellung fehl. Wenn Sie die Abstimmung für die controllergesteuerte Preflight-Prüfung fortsetzen möchten, löschen Sie den Clusteroperator-Pod oder die Preflight-Prüfungsressource. Wenn Sie die Preflight-Prüfungsressource löschen, wird eine weitere erstellt und die Abstimmung wird fortgesetzt. Alternativ können Sie Ihre vorhandenen Cluster (die mit einer früheren Version erstellt wurden) auf eine Version mit Fehlerkorrektur aktualisieren.

Netzwerk 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

Wenn Sie in der Funktion mit mehreren NICs das CNI-Whereabouts-Plug-in verwenden und mit dem CNI-DEL-Vorgang eine Netzwerkschnittstelle für einen Pod löschen, werden einige reservierte IP-Adressen möglicherweise nicht richtig freigegeben. Das passiert, wenn der CNI-Vorgang DEL unterbrochen wird.

Mit dem folgenden Befehl können Sie die nicht verwendeten IP-Adressreservierungen der Pods prüfen:

kubectl get ippools -A --kubeconfig KUBECONFIG_PATH

Behelfslösung:

Löschen Sie die IP-Adressen (ippools), die nicht verwendet werden, manuell.
Installation 1.10, 1.11.0, 1.11.1, 1.11.2

Der Node Problem Detector kann in Nutzerclustern der Version 1.10.x fehlschlagen, wenn Administratorcluster der Version 1.11.0, 1.11.1 oder 1.11.2 Nutzercluster der Version 1.10.x verwalten. Wenn der Node Problem Detector fehlschlägt, wird das Log mit der folgenden Fehlermeldung aktualisiert:

Error - NPD not supported for anthos baremetal version 1.10.4:
anthos version 1.10.4 not supported.

Problemumgehung

Aktualisieren Sie den Administratorcluster auf Version 1.11.3, um das Problem zu beheben.
Vorgang 1,14

In Version 1.14 wird die Einstellung maxPodsPerNode für Cluster im Inselmodus nicht berücksichtigt. Den Knoten wird daher eine Pod-CIDR-Maskengröße von 24 (256 IP-Adressen) zugewiesen. Dies kann dazu führen, dass dem Cluster früher als erwartet die Pod-IP-Adressen ausgehen. Wenn Ihr Cluster beispielsweise eine Pod-CIDR-Maskengröße von 22 hat, wird jedem Knoten eine Pod-CIDR-Maske von 24 zugewiesen und der Cluster kann nur bis zu 4 Knoten unterstützen. In Ihrem Cluster kann es auch zu Netzwerkinstabilität kommen, wenn in einem Zeitraum mit hoher Pod-Churn maxPodsPerNode auf 129 oder höher festgelegt ist und nicht genügend Overhead im Pod-CIDR für jeden Knoten vorhanden ist.

Wenn Ihr Cluster betroffen ist, meldet der anetd-Pod den folgenden Fehler, wenn Sie dem Cluster einen neuen Knoten hinzufügen und keine podCIDR verfügbar ist:

error="required IPv4 PodCIDR not available"

Problemumgehung

So beheben Sie das Problem:

  1. Führen Sie ein Upgrade auf Version 1.14.1 oder höher durch.
  2. Entfernen Sie die Worker-Knoten und fügen Sie sie wieder hinzu.
  3. Entfernen Sie die Knoten der Steuerungsebene und fügen Sie sie wieder hinzu. Am besten einzeln, um Ausfallzeiten des Clusters zu vermeiden.
Upgrades und Updates 1.14.0, 1.14.1

Ein Upgrade-Rollback kann für Cluster mit Version 1.14.0 oder 1.14.1 fehlschlagen. Wenn Sie ein Upgrade eines Clusters von 1.14.0 auf 1.14.1 durchführen und dann versuchen, mit dem Befehl bmctl restore cluster ein Rollback auf 1.14.0 durchzuführen, wird möglicherweise ein Fehler wie im folgenden Beispiel zurückgegeben:

I0119 22:11:49.705596  107905 client.go:48] Operation failed, retrying with backoff.
Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck" cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io"
denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid:
Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690),
Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil),
CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable

Workaround:

Löschen Sie alle healthchecks.baremetal.cluster.gke.io-Ressourcen im Cluster-Namespace und führen Sie den Befehl bmctl restore cluster noch einmal aus:

  1. Alle healthchecks.baremetal.cluster.gke.io-Ressourcen auflisten: 
    kubectl get healthchecks.baremetal.cluster.gke.io \
    --namespace=CLUSTER_NAMESPACE \
    --kubeconfig=ADMIN_KUBECONFIG

    Ersetzen Sie Folgendes:

    • CLUSTER_NAMESPACE: der Namespace für den Cluster.
    • ADMIN_KUBECONFIG: Der Pfad zur kubeconfig-Datei des Administratorclusters.
  2. Löschen Sie alle healthchecks.baremetal.cluster.gke.io-Ressourcen, die im vorherigen Schritt aufgeführt sind: 
    kubectl delete healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_RESOURCE_NAME \
    --namespace=CLUSTER_NAMESPACE \
    --kubeconfig=ADMIN_KUBECONFIG
     Ersetzen Sie HEALTHCHECK_RESOURCE_NAME durch den Namen der Healthcheck-Ressourcen.
  3. Führen Sie den Befehl bmctl restore cluster noch einmal aus.
Netzwerk 1.12.0

In einem Cluster, in dem flatIPv4 auf true festgelegt ist, sind Dienste vom Typ LoadBalancer nicht über ihre externen IP-Adressen zugänglich.

Dieses Problem wurde in Version 1.12.1 behoben.


Workaround:

Legen Sie in der ConfigMap cilium-config für enable-415 den Wert "true" fest und starten Sie dann die anetd-Pods neu.
Upgrades und Updates 1.13.0, 1.14

Wenn Sie versuchen, ein In-Place-Upgrade von 1.13.0 auf 1.14.x mit bmctl 1.14.0 und dem Flag --use-bootstrap=false durchzuführen, wird das Upgrade nie abgeschlossen.

Ein Fehler mit dem Operator preflight-check führt dazu, dass der Cluster die erforderlichen Prüfungen nie plant. Das bedeutet, dass die Preflight-Prüfung nie abgeschlossen wird.


Workaround:

Führen Sie zuerst ein Upgrade auf Version 1.13.1 durch, bevor Sie ein Upgrade auf Version 1.14.x ausführen. Ein In-Place-Upgrade von 1.13.0 auf 1.13.1 sollte funktionieren. Oder Sie führen ein Upgrade von 1.13.0 auf 1.14.x ohne das Flag --use-bootstrap=false durch.
Upgrades und Updates, Sicherheit 1.13 und 1.14

Die Knoten der Steuerungsebene erfordern eine von zwei bestimmten Markierungen, um zu verhindern, dass Arbeitslast-Pods auf ihnen geplant werden. Wenn Sie ein Upgrade von Clustern der Version 1.13 auf Version 1.14.0 durchführen, verlieren die Knoten der Steuerungsebene die folgenden erforderlichen Taints:

  • node-role.kubernetes.io/master:NoSchedule
  • node-role.kubernetes.io/master:PreferNoSchedule

Dieses Problem führt nicht zu Upgrade-Fehlern, aber Pods, die nicht auf den Knoten der Steuerungsebene ausgeführt werden sollen, können dies tun. Diese Arbeitslast-Pods können die Knoten der Steuerungsebene überlasten und zu einer Instabilität des Clusters führen.

Prüfen, ob Sie betroffen sind

  1. Verwenden Sie den folgenden Befehl, um Knoten der Steuerungsebene zu finden: 
    kubectl get node -l 'node-role.kubernetes.io/control-plane' \
    -o name --kubeconfig KUBECONFIG_PATH
  2. Verwenden Sie den folgenden Befehl, um die Liste der Markierungen für einen Knoten aufzurufen: 
    kubectl describe node NODE_NAME \
    --kubeconfig KUBECONFIG_PATH

    Wenn keiner der erforderlichen Taints aufgeführt ist, sind Sie betroffen.

Problemumgehung

Führen Sie die folgenden Schritte für jeden Knoten der Steuerungsebene Ihres betroffenen Clusters der Version 1.14.0 aus, um die ordnungsgemäße Funktion wiederherzustellen. Diese Schritte gelten für die node-role.kubernetes.io/master:NoSchedule-Taint und die zugehörigen Pods. Wenn die Knoten der Steuerungsebene das PreferNoSchedule-Taint verwenden sollen, passen Sie die Schritte entsprechend an.
Vorgang, VM Runtime on GDC 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30, 1.31

Das Erstellen einer neuen VM mit dem Befehl kubectl virt create vm schlägt während des Image-Uploads nur selten fehl. Dieses Problem tritt sowohl bei Linux- als auch bei Windows-VMs auf. Der Fehler sieht in etwa so aus: 

PVC default/heritage-linux-vm-boot-dv not found DataVolume default/heritage-linux-vm-boot-dv created
Waiting for PVC heritage-linux-vm-boot-dv upload pod to be ready... Pod now ready
Uploading data to https://10.200.0.51

 2.38 MiB / 570.75 MiB [>----------------------------------------------------------------------------------]   0.42% 0s

fail to upload image: unexpected return value 500,  ...

Problemumgehung

Führen Sie den Befehl kubectl virt create vm noch einmal aus, um die VM zu erstellen.
Upgrades und Updates, Logging und Monitoring 1.11

Komponenten für die verwaltete Erfassung sind Teil von Managed Service for Prometheus. Wenn Sie verwaltete Erfassung-Komponenten manuell im gmp-system-Namespace Ihrer Version 1.11-Cluster bereitgestellt haben, werden die zugehörigen Ressourcen nicht beibehalten, wenn Sie auf Version 1.12 aktualisieren.

Ab Version 1.12.0 werden Managed Service for Prometheus-Komponenten in Clustern im Namespace gmp-system und zugehörige benutzerdefinierte Ressourcendefinitionen von stackdriver-operator mit dem Feld enableGMPForApplications verwaltet. Das Feld enableGMPForApplications hat standardmäßig den Wert true. Wenn Sie also Managed Service for Prometheus-Komponenten vor dem Upgrade auf Version 1.12 manuell im Namespace bereitstellen, werden die Ressourcen von stackdriver-operator gelöscht.

Problemumgehung

So behalten Sie manuell verwaltete Sammlungsressourcen bei:

  1. Sichern Sie alle vorhandenen benutzerdefinierten PodMonitoring-Ressourcen.
  2. Aktualisieren Sie den Cluster auf Version 1.12 und aktivieren Sie Managed Service for Prometheus.
  3. Stellen Sie die benutzerdefinierten PodMonitoring-Ressourcen in Ihrem aktualisierten Cluster noch einmal bereit.
Upgrades und Updates 1.13

Wenn in einem Cluster der Version 1.12, der die Docker-Containerlaufzeit verwendet, die folgende Annotation fehlt, kann er nicht auf Version 1.13 aktualisiert werden:

baremetal.cluster.gke.io/allow-docker-container-runtime:  "true"

Wenn Sie von diesem Problem betroffen sind, schreibt bmctl den folgenden Fehler in die Datei upgrade-cluster.log im Ordner bmctl-workspace:

Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=Cluster": admission webhook
"vcluster.kb.io" denied the request: Spec.NodeConfig.ContainerRuntime: Forbidden: Starting with Anthos Bare Metal version 1.13 Docker container
runtime will not be supported. Before 1.13 please set the containerRuntime to containerd in your cluster resources.

Although highly discouraged, you can create a cluster with Docker node pools until 1.13 by passing the flag "--allow-docker-container-runtime" to bmctl
create cluster or add the annotation "baremetal.cluster.gke.io/allow-docker- container-runtime: true" to the cluster configuration file.

Dies tritt am wahrscheinlichsten bei Docker-Clustern der Version 1.12 auf, die von Version 1.11 aktualisiert wurden, da für dieses Upgrade die Annotation nicht erforderlich ist, um die Docker-Containerlaufzeit beizubehalten. In diesem Fall haben Cluster beim Upgrade auf Version 1.13 keine Annotation. Ab Version 1.13 ist containerd die einzige zulässige Containerlaufzeit.

Workaround:

Wenn Sie von diesem Problem betroffen sind, aktualisieren Sie die Clusterressource mit der fehlenden Annotation. Sie können die Anmerkung entweder während des Upgrades oder nach dem Abbrechen und vor dem erneuten Versuch hinzufügen.
Installation 1.11

Die Clustererstellung kann für Google Distributed Cloud-Version 1.11.0 fehlschlagen (dieses Problem wird in Google Distributed Cloud-Release 1.11.1 behoben). In einigen Fällen wird der Befehl bmctl create cluster vorzeitig beendet und Fehler wie die folgenden in die Logs geschrieben:

Error creating cluster: error waiting for applied resources: provider cluster-api watching namespace USER_CLUSTER_NAME not found in the target cluster

Problemumgehung

Der fehlgeschlagene Vorgang erzeugt Artefakte, der Cluster ist jedoch nicht funktionsfähig. Wenn dieses Problem Sie betrifft, führen Sie die folgenden Schritte aus, um Artefakte zu bereinigen und einen Cluster zu erstellen:
Installation, VM Runtime on GDC 1.11, 1.12

Der Vorgang zur Clustererstellung kann einen Fehler wie den folgenden melden:

I0423 01:17:20.895640 3935589 logs.go:82]  "msg"="Cluster reconciling:" "message"="Internal error occurred: failed calling webhook \"vvmruntime.kb.io\": failed to call webhook: Post \"https://vmruntime-webhook-service.kube-system.svc:443/validate-vm-cluster-gke-io-v1vmruntime?timeout=10s\": dial tcp 10.95.5.151:443: connect: connection refused" "name"="xxx" "reason"="ReconciliationError"

Problemumgehung

Dieser Fehler ist harmlos und kann ignoriert werden.
Installation 1.10, 1.11, 1.12

Die Clustererstellung schlägt fehl, wenn die folgende Kombination von Bedingungen vorliegt:

  • Der Cluster ist so konfiguriert, dass containerd als Containerlaufzeit verwendet wird (nodeConfig.containerRuntime ist in der Clusterkonfigurationsdatei auf containerd gesetzt), der Standard für Google Distributed Cloud-Version 1.13 und höher.
  • Der Cluster ist so konfiguriert, dass mehrere Netzwerkschnittstellen mit mehreren NICs für Pods bereitgestellt werden (clusterNetwork.multipleNetworkInterfaces ist in der Cluster-Konfigurationsdatei auf true gesetzt).
  • Der Cluster ist für die Verwendung eines Proxys konfiguriert (spec.proxy.url wird in der Clusterkonfigurationsdatei angegeben). Obwohl die Clustererstellung fehlschlägt, wird diese Einstellung übernommen, wenn Sie versuchen, einen Cluster zu erstellen. Diese Proxyeinstellung wird möglicherweise als Umgebungsvariable HTTPS_PROXY oder in der Konfiguration containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf) angezeigt.

Problemumgehung

Hängen Sie Dienst-CIDRs (clusterNetwork.services.cidrBlocks) an die Umgebungsvariable NO_PROXY auf allen Knotenmaschinen an.
Installation 1.10, 1.11, 1.12

Mit Google Distributed Cloud-Release 1.10.0 wurde eine Funktion für eine Steuerungsebene ohne Root eingeführt, die alle Komponenten der Steuerungsebene als Nicht-Root-Nutzer ausführt. Die Ausführung aller Komponenten als Nicht-Root-Nutzer kann zu Installations- oder Upgradefehlern auf Systemen mit der restriktiveren umask-Einstellung 0077 führen.


Problemumgehung

Setzen Sie die Knoten der Steuerungsebene zurück und ändern Sie die umask-Einstellung in 0022 auf allen Maschinen der Steuerungsebene. Wiederholen Sie die Installation, nachdem die Maschinen aktualisiert wurden.

Alternativ können Sie die Verzeichnis- und Dateiberechtigungen von /etc/kubernetes auf den Maschinen der Steuerungsebene ändern, damit die Installation oder das Upgrade fortgesetzt wird.

  • /etc/kubernetes und alle zugehörigen Unterverzeichnisse allgemein lesbar machen: chmod o+rx.
  • Alle Dateien von Nutzer root im Verzeichnis (rekursiv) /etc/kubernetes allgemein lesbar machen (chmod o+r). Private Schlüsseldateien (.key) von diesen Änderungen ausschließen, da sie bereits mit den richtigen Eigentumsrechten und Berechtigungen erstellt wurden.
  • /usr/local/etc/haproxy/haproxy.cfg allgemein lesbar machen.
  • /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml allgemein lesbar machen.
Installation 1.10, 1.11, 1.12, 1.13

Kontrollgruppe v2 (cgroup v2) wird in Versionen 1.13 und früher von Google Distributed Cloud nicht unterstützt. In Version 1.14 wird cgroup v2 jedoch als Vorschau -Funktion unterstützt. Das Vorhandensein von /sys/fs/cgroup/cgroup.controllers gibt an, dass Ihr System cgroup v2 verwendet.


Problemumgehung

Wenn Ihr System cgroup v2 verwendet, führen Sie ein Upgrade Ihres Clusters auf Version 1.14 durch.
Installation 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29

Bei Installationen, die durch Administrator- oder Hybridcluster ausgelöst werden, also Cluster, die nicht mit bmctl erstellt wurden, wie etwa Nutzercluster, werden bei der Preflight-Prüfung die Anmeldedaten des Google Cloud -Dienstkontos oder deren zugehörigen Berechtigungen nicht geprüft.
Installation 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30

Wenn Sie Bare-Metal-Cluster auf vSphere-VMs installieren, müssen Sie die Flags tx-udp_tnl-segmentation und tx-udp_tnl-csum-segmentation deaktivieren. Diese Flags beziehen sich auf die Auslagerung der Hardwaresegmentierung von vSphere. Treiber-VMXNET3 und funktionieren nicht mit dem GENEVE-Tunnel von Bare-Metal-Clustern.


Problemumgehung

Führen Sie auf jedem Knoten den folgenden Befehl aus, um die aktuellen Werte für diese Flags zu prüfen:

ethtool -k NET_INTFC | grep segm

Ersetzen Sie NET_INTFC durch die Netzwerkschnittstelle, die der IP-Adresse des Knotens zugeordnet ist.

Die Antwort sollte Einträge wie die folgenden enthalten:

...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
 Manchmal zeigt ethtool in RHEL 8.4 an, dass diese Flags deaktiviert sind, obwohl sie aktiv sind. Um diese Flags explizit zu deaktivieren, aktivieren und deaktivieren Sie die Flags mit folgenden Befehlen: 
ethtool -K ens192 tx-udp_tnl-segmentation on ethtool -K ens192 \
    tx-udp_tnl-csum-segmentation on
ethtool -K ens192 tx-udp_tnl-segmentation off ethtool -K ens192 \
    tx-udp_tnl-csum-segmentation off

Diese Flag-Änderung bleibt bei Neustarts nicht bestehen. Konfigurieren Sie die Startskripts so, dass diese Flags beim Systemstart explizit festgelegt werden.
Upgrades und Updates 1.10

Über die bmctl-Befehlszeile kann kein Nutzercluster mit einer niedrigeren Nebenversion erstellt, aktualisiert oder zurückgesetzt werden, unabhängig von der Version des Administratorclusters. Sie können beispielsweise bmctl mit einer Version von 1.N.X nicht verwenden, um einen Nutzercluster der Version 1.N-1.Y zurückzusetzen, auch wenn der Administratorcluster ebenfalls die Version 1.N.X hat.

Wenn Sie von diesem Problem betroffen sind, sollten Sie bei der Verwendung von bmctl ähnliche Logs wie die folgenden sehen:

[2022-06-02 05:36:03-0500] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred:

*   cluster version 1.8.1 isn't supported in bmctl version 1.9.5, only cluster version 1.9.5 is supported

Workaround:

Verwenden Sie kubectl, um die benutzerdefinierte Ressource des Nutzerclusters im Administratorcluster zu erstellen, zu bearbeiten oder zu löschen.

Die Möglichkeit, Nutzercluster zu aktualisieren, ist nicht betroffen.
Upgrades und Updates 1.12

Das Upgraden von Clustern auf Version 1.12.1 kommt manchmal zum Stillstand, weil der API-Server nicht mehr verfügbar ist. Dieses Problem betrifft alle Clustertypen und alle unterstützten Betriebssysteme. Wenn dieses Problem auftritt, kann der bmctl upgrade cluster-Befehl an mehreren Stellen fehlschlagen, auch während der zweiten Phase der Preflight-Prüfungen.


Problemumgehung

Sie können in Ihren Upgradeprotokollen nachsehen, ob Sie von diesem Problem betroffen sind. Upgrade-Logs befinden sich standardmäßig in /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP.

Das Formular „upgrade-cluster.log“ enthält möglicherweise Fehler wie die folgenden:

Failed to upgrade cluster: preflight checks failed: preflight check failed
 Das Maschinenlog enthält möglicherweise Fehler wie die folgenden (wiederholte Fehler deuten darauf hin, dass Sie von diesem Problem betroffen sind): 
FAILED - RETRYING: Query CNI health endpoint (30 retries left). FAILED - RETRYING: Query CNI health endpoint (29 retries left).
FAILED - RETRYING: Query CNI health endpoint (28 retries left). ...

HAProxy und Keepalived müssen auf jedem Knoten der Steuerungsebene ausgeführt werden, bevor Sie versuchen, Ihren Cluster noch einmal auf Version 1.12.1 zu aktualisieren. Prüfen Sie mit der crictl-Befehlszeilenschnittstelle auf jedem Knoten, ob die Container haproxy und keepalived ausgeführt werden:

docker/crictl ps | grep haproxy docker/crictl ps | grep keepalived

Wenn HAProxy oder Keepalived auf einem Knoten nicht ausgeführt wird, starten Sie kubelet auf dem Knoten neu:

systemctl restart kubelet
Upgrades und Updates, VM Runtime on GDC 1.11, 1.12

In Clustern der Version 1.12.0 werden alle Ressourcen, die sich auf die VM Runtime on GDC beziehen, zum Namespace vm-system migriert, um den GA-Release der VM Runtime on GDC besser zu unterstützen. Wenn Sie die VM Runtime on GDC in einem Cluster der Version 1.11.x oder niedriger aktiviert haben, schlägt das Upgrade auf Version 1.12.0 oder höher fehl, sofern Sie nicht zuerst die VM Runtime on GDC deaktivieren. Wenn Sie von diesem Problem betroffen sind, wird beim Upgrade-Vorgang der folgende Fehler gemeldet:

Failed to upgrade cluster: cluster isn't upgradable with vmruntime enabled from
version 1.11.x to version 1.12.0: please disable VMruntime before upgrade to
1.12.0 and higher version

Problemumgehung

So deaktivieren Sie die VM Runtime on GDC:

  1. Bearbeiten Sie die benutzerdefinierte VMRuntime-Ressource: 
    kubectl edit vmruntime
  2. Legen Sie enabled in der Spezifikation auf false fest: 
    apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: false
  ...
  3. Speichern Sie die benutzerdefinierte Ressource in Ihrem Editor.
  4. Sobald das Clusterupgrade abgeschlossen ist, aktivieren Sie die VM Runtime on GDC wieder.

Weitere Informationen finden Sie unter VM Runtime on GDC aktivieren oder deaktivieren.

Upgrades und Updates 1.10, 1.11, 1.12

In einigen Situationen können Clusterupgrades nicht abgeschlossen werden und die bmctl-Befehlszeile reagiert nicht mehr. Dieses Problem kann durch eine falsch aktualisierte Ressource verursacht werden. So können Sie feststellen, ob Sie von diesem Problem betroffen sind, und es beheben: Prüfen Sie die anthos-cluster-operator-Logs und suchen Sie nach Fehlern, die den folgenden Einträgen ähneln:

controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred: ... {RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update

Diese Einträge sind ein Symptom einer falsch aktualisierten Ressource, wobei {RESOURCE_NAME} der Name der problematischen Ressource ist.


Problemumgehung

Wenn diese Fehler in Ihren Logs auftreten, führen Sie die folgenden Schritte aus:

  1. Entfernen Sie die Annotation kubectl.kubernetes.io/last-applied-configuration aus der Ressource aus der Lognachricht mit kubectl edit.
  2. Speichern Sie die Änderungen und wenden Sie sie auf die Ressource an.
  3. Wiederholen Sie das Clusterupgrade.
Upgrades und Updates 1.10, 1.11, 1.12

Clusterupgrades von 1.10.x auf 1.11.x schlagen bei Clustern fehl, die entweder ein NAT-Gateway für ausgehenden Traffic oder gebündeltes Load-Balancing mit BGP verwenden. Beide Funktionen verwenden das Network Gateway for GDC. Clusterupgrades bleiben bei der Befehlszeilenmeldung Waiting for upgrade to complete... hängen und der anthos-cluster-operator protokolliert Fehler wie die folgenden:

apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field
is immutable...

Problemumgehung

Führen Sie die folgenden Befehle für den Cluster aus, für den Sie ein Upgrade durchführen, um die Blockierung des Upgrades aufzuheben:

kubectl -n kube-system delete deployment \
    ang-controller-manager-autoscaler
kubectl -n kube-system delete deployment \
    ang-controller-manager
kubectl -n kube-system delete ds ang-node
Upgrades und Updates 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

Mit dem Befehl bmctl update kann der Abschnitt maintenanceBlocks nicht aus der Konfiguration der Clusterressource entfernt oder geändert werden.


Problemumgehung

Weitere Informationen, einschließlich Anweisungen zum Entfernen von Knoten aus dem Wartungsmodus, finden Sie unter Knoten in den Wartungsmodus versetzen.
Vorgang 1.10, 1.11, 1.12

Wenn Sie Cluster der Version 1.12.0 (anthosBareMetalVersion: 1.12.0) oder niedriger ausführen und kubectl cordon manuell auf einem Knoten verwenden, kann es sein, dass Google Distributed Cloud for Bare Metal den Knoten aufhebt, bevor Sie bereit sind, um den erwarteten Status abzugleichen.


Problemumgehung

Verwenden Sie für Cluster mit Version 1.12.0 und niedriger den Wartungsmodus, um Knoten sicher abzusichern und zu leeren.

In Version 1.12.1 (anthosBareMetalVersion: 1.12.1) oder höher werden Ihre Knoten in Google Distributed Cloud für Bare Metal nicht unerwartet aus dem Cordon entfernt, wenn Sie kubectl cordon verwenden.
Vorgang 1.11

Wenn Ihr Administratorcluster die Version 1.11 hat und einen Registry-Spiegel verwendet, kann er keine Nutzercluster verwalten, die eine niedrigere Nebenversion haben. Dieses Problem wirkt sich auf das Zurücksetzen, Aktualisieren und Upgraden von Vorgängen im Nutzercluster aus.

Prüfen Sie Ihre Logs auf Clustervorgänge wie Erstellen, Upgrade oder Zurücksetzen, um festzustellen, ob dieses Problem Sie betrifft. Diese Logs befinden sich standardmäßig im Ordner bmctl-workspace/CLUSTER_NAME/. Wenn das Problem von Ihnen betroffen ist, enthalten Ihre Logs die folgende Fehlermeldung:

flag provided but not defined: -registry-mirror-host-to-endpoints
Vorgang 1.10, 1.11

Der Befehl bmctl check cluster überschreibt bei Ausführung in Nutzerclustern das kubeconfig-Secret des Nutzerclusters mit der Administratorcluster-kubeconfig. Das Überschreiben der Datei führt dazu, dass Standard-Clustervorgänge wie das Aktualisieren und Upgraden für betroffene Nutzercluster fehlschlagen. Dieses Problem betrifft die Clusterversionen 1.11.1 und früher.

Führen Sie den folgenden Befehl aus, um festzustellen, ob dieses Problem einen Nutzercluster betrifft:

kubectl --kubeconfig ADMIN_KUBECONFIG \
    get secret -n USER_CLUSTER_NAMESPACE \
    USER_CLUSTER_NAME -kubeconfig \
    -o json  | jq -r '.data.value'  | base64 -d

Ersetzen Sie Folgendes:

  • ADMIN_KUBECONFIG: der Pfad zur kubeconfig-Datei des Administratorclusters.
  • USER_CLUSTER_NAMESPACE: der Namespace für den Cluster. Standardmäßig sind die Namen der Cluster-Namespaces der Name des Clusters, dem cluster- vorangestellt ist. Wenn Sie Ihren Cluster beispielsweise test nennen, lautet der standardmäßige Namespace cluster-test.
  • USER_CLUSTER_NAME: der Name des zu prüfenden Nutzerclusters.

Wenn der Clustername in der Ausgabe (siehe contexts.context.cluster in der folgenden Beispielausgabe) der Name des Administratorclusters ist, ist der angegebene Nutzercluster betroffen.

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:LS0tLS1CRU...UtLS0tLQo=
    server: https://10.200.0.6:443
  name: ci-aed78cdeca81874
contexts:
- context:
    cluster: ci-aed78cdeca81
    user: ci-aed78cdeca81-admin
  name: ci-aed78cdeca81-admin@ci-aed78cdeca81
current-context: ci-aed78cdeca81-admin@ci-aed78cdeca81
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81-admin
  user:
    client-certificate-data: LS0tLS1CRU...UtLS0tLQo=
    client-key-data: LS0tLS1CRU...0tLS0tCg==

Problemumgehung

Mit den folgenden Schritten stellen Sie die Funktion in einem betroffenen Nutzercluster wieder her (USER_CLUSTER_NAME):

  1. Suchen Sie die kubeconfig-Datei des Nutzerclusters. Google Distributed Cloud for Bare Metal generiert die kubeconfig-Datei auf der Administrator-Workstation, wenn Sie einen Cluster erstellen. Die Datei befindet sich standardmäßig im Verzeichnis bmctl-workspace/USER_CLUSTER_NAME.
  2. Prüfen Sie, ob die kubeconfig-Datei die richtige Nutzercluster-kubeconfig ist: 
    kubectl get nodes \
    --kubeconfig PATH_TO_GENERATED_FILE
     Ersetzen Sie PATH_TO_GENERATED_FILE durch den Pfad zur Kubeconfig-Datei des Nutzerclusters. In der Antwort werden Details zu den Knoten für den Nutzercluster zurückgegeben. Prüfen Sie, ob die Maschinennamen für Ihren Cluster korrekt sind.
  3. Führen Sie den folgenden Befehl aus, um die beschädigte kubeconfig-Datei im Administratorcluster zu löschen: 
    kubectl delete secret \
    -n USER_CLUSTER_NAMESPACE \
    USER_CLUSTER_NAME-kubeconfig
  4. Führen Sie den folgenden Befehl aus, um das richtige kubeconfig-Secret wieder im Administratorcluster zu speichern: 
    kubectl create secret generic \
    -n USER_CLUSTER_NAMESPACE \
    USER_CLUSTER_NAME-kubeconfig \
    --from-file=value=PATH_TO_GENERATED_FILE
Vorgang 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30

Wenn Sie containerd als Containerlaufzeit verwenden, muss zur Ausführung eines Snapshots als Nicht-Root-Nutzer /usr/local/bin im PATH des Nutzers enthalten sein. Andernfalls schlägt der Vorgang mit dem Fehler crictl: command not found fehl.

Wenn Sie nicht als Root-Nutzer angemeldet sind, wird sudo zum Ausführen der Snapshot-Befehle verwendet. Der PATH sudo kann sich vom Root-Profil unterscheiden und darf nicht /usr/local/bin enthalten.


Problemumgehung

Aktualisieren Sie secure_path in /etc/sudoers, um /usr/local/bin einzuschließen. Alternativ können Sie einen symbolischen Link für crictl in einem anderen /bin-Verzeichnis erstellen.
Logging und Monitoring 1.10

Wenn der CRI-Parser (Container Runtime Interface) einen falschen regulären Ausdruck zum Parsen der Zeit verwendet, enthalten die Logs für den stackdriver-log-forwarder-Pod Fehler und Warnungen wie die folgenden:

[2022/03/04 17:47:54] [error] [parser] time string length is too long [2022/03/04 20:16:43] [ warn] [parser:cri] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2022-03-04T20:16:43.680484387Z'

Workaround:
Logging und Monitoring 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

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

  • Anwendungsmonitoring ist aktiviert (enableStackdriverForApplications=true)
  • Managed Service for Prometheus ist nicht aktiviert (enableGMPForApplications)
  • Anwendungs-Pods haben die Annotation prometheus.io/scrap=true.

Um festzustellen, ob Sie von diesem Problem betroffen sind, listen Sie Ihre benutzerdefinierten Messwerte auf. Wenn Sie die Abrechnung für unerwünschte Messwerte sehen, gilt dieses Problem.


Problemumgehung

Wenn Sie von diesem Problem betroffen sind, empfehlen wir Ihnen, ein Upgrade Ihrer Cluster auf Version 1.12 durchzuführen und zur neuen Lösung für das Anwendungsmonitoring managed-service-for-prometheus zu wechseln, die dieses Problem behebt:

  • Separate Flags zum Steuern der Erfassung von Anwendungslogs und Anwendungsstatistiken
  • Google Cloud Managed Service for Prometheus im Paket

    • Wenn Sie kein Upgrade auf Version 1.12 durchführen können, gehen Sie so vor:

    1. Suchen Sie die Quell-Pods und -Dienste mit den unerwünschten Abrechnungen: 
      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.
    Logging und Monitoring 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

    Eine hohe Pod-Dichte kann in extremen Fällen zu einem übermäßigen Logging- und Monitoring-Overhead führen, was dazu führt, dass Metrics Server beendet und neu gestartet wird. Sie können die ConfigMap metrics-server-config bearbeiten, um weitere Ressourcen zuzuweisen, damit Metrics Server weiter ausgeführt wird. Aufgrund des Abgleichs können Änderungen an metrics-server-config jedoch während eines Clusteraktualisierungs- oder Upgradevorgangs auf den Standardwert zurückgesetzt werden. Der Metrics Server ist nicht sofort betroffen, aber beim nächsten Neustart wird der zurückgesetzte ConfigMap-Objekt verwendet und ist wieder für übermäßigen Overhead anfällig.


    Problemumgehung

    Bei Version 1.11.x können Sie ein Skript für die ConfigMap-Bearbeitung erstellen und es mit Aktualisierungen oder Upgrades des Clusters ausführen. Bei Version 1.12 und höher wenden Sie sich bitte an den Support.
    Logging und Monitoring 1.11, 1.12

    Mehrere Google Distributed Cloud-Messwerte, die nur Software betreffen, wurden verworfen. Ab Google Distributed Cloud-Release 1.11 werden keine Daten mehr für diese verworfenen Messwerte erfasst. Wenn Sie diese Messwerte in einer Ihrer Benachrichtigungsrichtlinien verwenden, gibt es keine Daten, die die Benachrichtigungsbedingung auslösen.

    In der folgenden Tabelle sind die einzelnen Messwerte aufgeführt, die verworfen wurden, und der Messwert, der sie ersetzt.

    Verworfene Messwerte Ersatzmesswert
    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

    In Clusterversionen unter 1.11 verwendet die Richtliniendefinitionsdatei für die empfohlene Anthos on baremetal node cpu usage exceeds 80 percent (critical)-Benachrichtigung die verworfenen Messwerte. Die JSON-Definitionsdatei node-cpu-usage-high.json wird für die Versionen 1.11.0 und höher aktualisiert.


    Problemumgehung

    Führen Sie die folgenden Schritte aus, um zu den Ersatzmesswerten zu migrieren:

    1. Wählen Sie in der Google Cloud Console Monitoring aus oder klicken Sie auf die folgende Schaltfläche:
      Zu Monitoring
    2. Wählen Sie im Navigationsbereich Dashboards aus und löschen Sie das Dashboard für den Anthos-Clusterknotenstatus.
    3. Klicken Sie auf den Tab Beispielbibliothek und installieren Sie das Dashboard für den Anthos-Clusterknotenstatus neu.
    4. Folgen Sie der Anleitung unter Benachrichtigungsrichtlinien erstellen, um eine Richtlinie mit der aktualisierten Richtliniendefinitionsdatei node-cpu-usage-high.json zu erstellen.
    Logging und Monitoring 1.10, 1.11

    In manchen Situationen kann der Logging-Agent fluent-bit bei der Verarbeitung beschädigter Chunks hängen bleiben. Wenn der Logging-Agent beschädigte Blöcke nicht umgehen kann, stellen Sie möglicherweise fest, dass stackdriver-log-forwarder weiterhin mit dem Fehler CrashloopBackOff abstürzt. Wenn dieses Problem auftritt, haben Ihre Logs folgende Einträge:

    [2022/03/09 02:18:44] [engine] caught signal (SIGSEGV) #0  0x5590aa24bdd5
in  validate_insert_id() at plugins/out_stackdriver/stackdriver.c:1232
#1  0x5590aa24c502      in  stackdriver_format() at plugins/out_stackdriver/stackdriver.c:1523
#2  0x5590aa24e509      in  cb_stackdriver_flush() at plugins/out_stackdriver/stackdriver.c:2105
#3  0x5590aa19c0de      in  output_pre_cb_flush() at include/fluent-bit/flb_output.h:490
#4  0x5590aa6889a6      in  co_init() at lib/monkey/deps/flb_libco/amd64.c:117 #5  0xffffffffffffffff  in  ???() at ???:0

    Workaround:

    Bereinigen Sie die Puffer-Chunks für den Stackdriver Log Forwarder.

    Hinweis: Ersetzen Sie in den folgenden Befehlen KUBECONFIG durch den Pfad zur kubeconfig-Datei des Administratorclusters.

    1. Beenden Sie alle stackdriver-log-forwarder-Pods: 
      kubectl --kubeconfig KUBECONFIG -n kube-system patch daemonset \
    stackdriver-log-forwarder -p \
    '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
       Prüfen Sie, ob die stackdriver-log-forwarder-Pods gelöscht wurden, bevor Sie mit dem nächsten Schritt fortfahren.
    2. Stellen Sie das folgende DaemonSet bereit, um beschädigte Daten in fluent-bit-Puffern zu bereinigen: 
      kubectl --kubeconfig KUBECONFIG -n kube-system apply -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. Verwenden Sie die folgenden Befehle, um zu prüfen, ob das DaemonSet alle Knoten bereinigt hat: 
      kubectl --kubeconfig KUBECONFIG logs \
    -n kube-system -l \
    app=fluent-bit-cleanup | grep "cleaned up" | wc -l
kubectl --kubeconfig KUBECONFIG -n \
    kube-system get pods -l \
    app=fluent-bit-cleanup --no-headers | wc -l
       Die Ausgabe der beiden Befehle sollte der Anzahl der Knoten in Ihrem Cluster entsprechen.
    4. Löschen Sie das Bereinigungs-Daemonset: 
      kubectl --kubeconfig KUBECONFIG -n \
    kube-system delete ds fluent-bit-cleanup
    5. Starten Sie die Logweiterleitungs-Pods neu: 
      kubectl --kubeconfig 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, 1.28

    gke-metrics-agent ist ein DaemonSet, das Messwerte auf jedem Knoten erfasst und an Cloud Monitoring weiterleitet. Es werden möglicherweise Protokolle wie die folgenden erstellt:

    Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    Ähnliche Fehler können bei anderen Messwerttypen auftreten, unter anderem bei:

    • 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 Fehlerlogs können ignoriert werden, da die darin enthaltenen Messwerte nicht unterstützt werden und für das Monitoring nicht kritisch sind.
    Logging und Monitoring 1.10, 1.11

    Bei Clustern kann es zu Unterbrechungen beim normalen, kontinuierlichen Export von Messwerten oder zu fehlenden Messwerten auf einigen Knoten kommen. Wenn dieses Problem Ihre Cluster betrifft, können Datenlücken für die folgenden Messwerte (mindestens) auftreten:

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

    Problemumgehung

    Aktualisieren Sie Ihre Cluster auf Version 1.11.1 oder höher.

    Wenn Sie kein Upgrade durchführen können, führen Sie die folgenden Schritte aus:

    1. Öffnen Sie die Ressource stackdriver zum Bearbeiten: 
      kubectl -n 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 zu erhöhen: 
      spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
       Ihre bearbeitete Ressource sollte in etwa so aussehen: 
      spec:
  anthosDistribution: baremetal
  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: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
    3. Speichern Sie die Änderungen und schließen Sie den Texteditor.
    4. Führen Sie den folgenden Befehl aus, um zu prüfen, ob Ihre Änderungen wirksam wurden: 
      kubectl -n kube-system get daemonset \
    gke-metrics-agent -o yaml | grep "cpu: 50m"
       Der Befehl sucht cpu: 50m, wenn Ihre Änderungen wirksam wurden.
    Netzwerk 1.10

    Wenn Sie mehrere Standardgateways in einem Knoten haben, kann dies zu einer unterbrochenen Verbindung von einem Pod zu externen Endpunkten wie google.com führen.

    Führen Sie den folgenden Befehl auf dem Knoten aus, um festzustellen, ob Sie von diesem Problem betroffen sind:

    ip route show

    Mehrere Instanzen von default in der Antwort geben an, dass Sie betroffen sind.
    Netzwerk 1.12

    In Clustern der Version 1.12.x können Sie benutzerdefinierte Netzwerkressourcen in Ihrem Nutzercluster manuell bearbeiten. Google Distributed Cloud gleicht benutzerdefinierte Ressourcen in den Nutzerclustern mit den benutzerdefinierten Ressourcen in Ihrem Administratorcluster während Clusterupgrades ab. Bei diesem Abgleich werden alle Änderungen überschrieben, die direkt an den benutzerdefinierten Netzwerkressourcen im Nutzercluster vorgenommen wurden. Die benutzerdefinierten Netzwerkressourcen sollten nur im Administratorcluster geändert werden. In Clustern der Version 1.12.x wird diese Anforderung jedoch nicht erzwungen.

    Für erweiterte Netzwerkfunktionen wie gebündeltes Load-Balancing mit BGP, NAT-Gateway für ausgehenden Traffic, SR-IOV-Netzwerk, flacher Modus mit BGP und mehrere NICs für Pods werden die folgenden benutzerdefinierten Ressourcen verwendet:

    • BGPLoadBalancer
    • BGPPeer
    • NetworkGatewayGroup
    • NetworkAttachmentDefinition
    • ClusterCIDRConfig
    • FlatIPMode

    Sie bearbeiten diese benutzerdefinierten Ressourcen in Ihrem Administratorcluster. Im Abgleichsschritt werden die Änderungen auf Ihre Nutzercluster angewendet.


    Problemumgehung

    Wenn Sie eine der oben genannten benutzerdefinierten Ressourcen in einem Nutzercluster geändert haben, müssen Sie die entsprechenden benutzerdefinierten Ressourcen in Ihrem Administratorcluster vor dem Upgrade anpassen. So wird sichergestellt, dass Ihre Konfigurationsänderungen beibehalten werden. Bei Clusterversionen 1.13.0 und höher können Sie die benutzerdefinierten Netzwerkressourcen in Ihren Nutzerclustern nicht direkt ändern.
    Netzwerk 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

    Google Distributed Cloud konfiguriert die Filterung für umgekehrte Pfade auf Knoten, um die Quellvalidierung zu deaktivieren (net.ipv4.conf.all.rp_filter=0). Wenn die Einstellung rp_filter in 1 oder 2 geändert wird, schlagen Pods fehl, da außerhalb der Knoten das Kommunikationszeitlimit überschritten wird.

    Die Filterung für umgekehrte Pfade wird mit rp_filter-Dateien im IPv4-Konfigurationsordner (net/ipv4/conf/all) festgelegt. Dieser Wert kann auch von sysctl überschrieben werden. Damit werden Einstellungen der Filterung für umgekehrte Pfade in einer Netzwerksicherheitskonfigurationsdatei gespeichert, z. B. /etc/sysctl.d/60-gce-network-security.conf.


    Problemumgehung

    Die Pod-Verbindung kann durch eine der folgenden Problemumgehungen wiederhergestellt werden:

    Legen Sie den Wert für net.ipv4.conf.all.rp_filter manuell wieder auf 0 fest und führen Sie dann sudo sysctl -p aus, um die Änderung zu übernehmen.

    Oder

    Starten Sie den anetd-Pod neu, um net.ipv4.conf.all.rp_filter wieder auf 0 zurückzusetzen. Für einen Neustart des anetd-Pods verwenden Sie die folgenden Befehle, um den anetd-Pod zu ermitteln und zu löschen und einen neuen anetd-Pod an seiner Stelle zu starten:

    kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ

    Ersetzen Sie ANETD_XYZ durch den Namen des anetd-Pods.

    Prüfen Sie nach der Ausführung einer der beiden Problemumgehungen, ob der Wert net.ipv4.conf.all.rp_filter auf 0 gesetzt ist. Führen Sie dazu sysctl net.ipv4.conf.all.rp_filter auf jedem Knoten aus.
    Netzwerk 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30, 1.31, 1.32, 1.33, 1.34

    192.168.122.0/24 und 10.96.0.0/27 sind die Standard-Pod- und Dienst-CIDRs, die vom Bootstrap-Cluster (Typ) verwendet werden. Preflight-Prüfungen schlagen fehl, wenn sie sich mit IP-Adressen von Clusterknoten überschneiden.


    Problemumgehung

    Zur Vermeidung des Konflikts können Sie die Flags --bootstrap-cluster-pod-cidr und --bootstrap-cluster-service-cidr an bmctl übergeben, um andere Werte anzugeben.
    Betriebssystem 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

    Im Dezember 2020 gaben die CentOS-Community und Red Hat die Einstellung von CentOS bekannt. Am 31. Januar 2022 hat CentOS 8 das Ende des Produktzyklus (End of Life, EOL) erreicht. Aufgrund der EOL-Dauer funktionieren yum-Repositories nicht mehr für CentOS, was dazu führt, dass Clustererstellung und Cluster-Upgrade-Vorgänge fehlschlagen. Dies gilt für alle unterstützten Versionen von CentOS und betrifft alle Versionen von Clustern.


    Problemumgehung
    Sicherheit 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

    Wenn Sie containerd als Containerlaufzeit verwenden und auf Ihrem Betriebssystem SELinux aktiviert ist, ist das in der Anwendungs-Dockerfile definierte VOLUME möglicherweise nicht beschreibbar. Beispielsweise können Container, die mit dem folgenden Dockerfile erstellt wurden, nicht in den Ordner /tmp schreiben.

    FROM ubuntu:20.04 RUN chmod -R 777 /tmp VOLUME /tmp

    Führen Sie den folgenden Befehl auf dem Knoten aus, auf dem der problematische Container gehostet wird, um zu prüfen, ob Sie von diesem Problem betroffen sind:

    ausearch -m avc

    Wenn Sie von diesem Problem betroffen sind, wird ein denied-Fehler wie der folgende angezeigt:

    time->Mon Apr  4 21:01:32 2022 type=PROCTITLE msg=audit(1649106092.768:10979): proctitle="bash" type=SYSCALL msg=audit(1649106092.768:10979): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=55eeba72b320 a2=241 a3=1b6 items=0 ppid=75712 pid=76042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="bash" exe="/usr/bin/bash" subj=system_u:system_r:container_t:s0:c701,c935 key=(null) type=AVC msg=audit(1649106092.768:10979): avc:  denied { write } for  pid=76042 comm="bash" name="aca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c" dev="sda2" ino=369501097 scontext=system_u:system_r: container_t:s0:c701,c935 tcontext=system_u:object_r: container_ro_file_t:s0 tclass=dir permissive=0

    Problemumgehung

    Führen Sie eine der folgenden Änderungen aus, um dieses Problem zu umgehen:

    • Deaktivieren Sie SELinux.
    • Verwenden Sie die VOLUME-Funktion nicht in Dockerfile.
    Upgrades und Updates 1.10, 1.11, 1.12

    Wenn Sie Cluster aktualisieren, ist der Node Problem Detector nicht standardmäßig aktiviert. Dieses Problem tritt bei Upgrades von Version 1.10 auf Version 1.12.1 auf und wurde in Version 1.12.2 behoben.


    Workaround:

    So aktivieren Sie den Node Problem Detector:

    1. Prüfen Sie, ob der node-problem-detector systemd-Dienst auf dem Knoten ausgeführt wird.
      1. Stellen Sie mit dem SSH-Befehl eine Verbindung zum Knoten her.
      2. Prüfen Sie, ob der node-problem-detector systemd-Dienst auf dem Knoten ausgeführt wird: 
        systemctl is-active node-problem-detector
         Wenn im Ergebnis des Befehls inactive angezeigt wird, wird der Node Problem Detector nicht auf dem Knoten ausgeführt.
    2. Wenn Sie Node Problem Detector aktivieren möchten, verwenden Sie den Befehl kubectl edit und bearbeiten Sie die ConfigMap node-problem-detector-config. Weitere Informationen finden Sie unter Node Problem Detector.
    Vorgang 1.9, 1.10

    Der Befehl bmctl backup cluster schlägt fehl, wenn nodeAccess.loginUser auf einen Nicht-Root-Nutzernamen festgelegt ist.]


    Workaround:

    Dieses Problem betrifft die Versionen 1.9.x, 1.10.0 und 1.10.1 und wurde in Version 1.10.2 und höher behoben.
    Netzwerk 1.10, 1.11, 1.12

    In anetd gibt es einen Fehler, bei dem Pakete für LoadBalancer-Dienste verworfen werden, wenn die Backend-Pods sowohl auf dem Steuerungsebenenknoten ausgeführt werden als auch das Feld hostNetwork: true in der Spezifikation des Containers verwenden.

    Der Fehler tritt in Version 1.13 oder höher nicht auf.


    Workaround:

    Die folgenden Problemumgehungen können helfen, wenn Sie einen LoadBalancer-Dienst verwenden, der von hostNetwork-Pods unterstützt wird:

    1. Führen Sie sie auf Worker-Knoten (nicht auf Knoten der Steuerungsebene) aus.
    2. Verwenden Sie externalTrafficPolicy: local in der Dienstspezifikation und , um sicherzustellen, dass Ihre Arbeitslasten auf Load-Balancer-Knoten ausgeführt werden.
    Upgrades und Updates 1.12, 1.13

    Beim Upgrade von Clustern von Version 1.12.x auf 1.13.x kann es zu einem Fehler bei einem anthos-version-$version$-Pod mit dem Fehler „ImagePullBackOff“ kommen. Dies liegt an der Race Condition, die beim Upgrade von anthos-cluster-operator auftritt. Sie sollte sich nicht auf die regulären Clusterfunktionen auswirken.

    Der Fehler tritt in Version 1.13 oder höher nicht auf.


    Workaround:

    Löschen Sie den Job von dynamic-version-installer mit kubectl delete job anthos-version-$version$ -n kube-system .
    Upgrades und Updates 1.13

    Cluster der Version 1.12, die von Version 1.11 aktualisiert wurden, können nicht auf Version 1.13.0 aktualisiert werden. Dieses Upgrade-Problem betrifft keine Cluster, die mit Version 1.12 erstellt wurden.

    Prüfen Sie die Logs des Upgrade-Jobs, der den String upgrade-first-no* im Administratorcluster enthält, um festzustellen, ob Sie betroffen sind. Wenn Sie die folgende Fehlermeldung sehen, sind Sie betroffen.

    TASK [kubeadm_upgrade_apply : Run kubeadm upgrade apply] *******
...
[upgrade/config] FATAL: featureGates: Invalid value: map[string]bool{\"IPv6DualStack\":false}: IPv6DualStack isn't a valid feature name.
...

    Workaround:

    So umgehen Sie dieses Problem:

    1. Führen Sie die folgenden Befehle auf Ihrer Administrator-Workstation aus: 
      echo '[{ "op": "remove", "path": \
    "/spec/clusterConfiguration/featureGates" }]' \
    > remove-feature-gates.patch
export KUBECONFIG=$ADMIN_KUBECONFIG
kubectl get kubeadmconfig -A --no-headers | xargs -L1 bash -c \
    'kubectl patch kubeadmconfig $1 -n $0 --type json \
    --patch-file remove-feature-gates.patch'
    2. Wiederholen Sie das Clusterupgrade.
    Logging und Monitoring 1.16.2, 1.16.3

    Es gibt ein Problem in stackdriver-operator, das dazu führt, dass mehr CPU-Zeit als normal benötigt wird. Die normale CPU-Auslastung beträgt weniger als 50 milliCPU (50m) für stackdriver-operator im Leerlauf. Die Ursache ist eine Diskrepanz zwischen den Zertifikatsressourcen, die stackdriver-operator anwendet, und den Erwartungen von cert-manager. Diese Diskrepanz führt zu einer Wettlaufbedingung zwischen cert-manager und stackdriver-operator beim Aktualisieren dieser Ressourcen.

    Dieses Problem kann zu einer geringeren Leistung auf Clustern mit begrenzter CPU-Verfügbarkeit führen.


    Workaround:

    Bis Sie auf eine Version aktualisieren können, in der dieser Fehler behoben wurde, können Sie so vorgehen:

    1. Wenn Sie stackdriver-operator vorübergehend auf 0 Replikate herunterskalieren möchten, wenden Sie eine benutzerdefinierte AddonConfiguration-Ressource an: 
      kubectl scale deploy stackdriver-operator --replicas=0
    2. Nachdem Sie ein Upgrade auf eine Version durchgeführt haben, in der dieses Problem behoben wurde, können Sie stackdriver-operator wieder hochskalieren: 
      kubectl scale deploy stackdriver-operator --replicas=1
    Logging und Monitoring 1.16.0, 1.16.1

    In der Google Distributed Cloud-Nebenversion 1.16 ist das Feld enableStackdriverForApplications in der Spezifikation der benutzerdefinierten Ressource stackdriver veraltet. Dieses Feld wird in der benutzerdefinierten Stackdriver-Ressource durch die beiden Felder enableCloudLoggingForApplications und enableGMPForApplications ersetzt.

    Wir empfehlen, Google Cloud Managed Service for Prometheus zum Überwachen Ihrer Arbeitslasten zu verwenden. Verwenden Sie das Feld enableGMPForApplications, um diese Funktion zu aktivieren.

    Wenn Sie sich auf die Erfassung von Messwerten verlassen, die durch prometheus.io/scrape-Annotationen für Ihre Arbeitslasten ausgelöst werden, können Sie das alte Verhalten mit dem Feature-Gate-Flag annotationBasedApplicationMetrics beibehalten. Es gibt jedoch ein Problem, das verhindert, dass annotationBasedApplicationMetrics richtig funktioniert. Dadurch können keine Messwerte aus Ihren Anwendungen in Cloud Monitoring erfasst werden.


    Workaround:

    Aktualisieren Sie Ihren Cluster auf Version 1.16.2 oder höher, um dieses Problem zu beheben.

    Bei der Erfassung von Arbeitslastmesswerten auf Grundlage von Annotationen, die durch das Feature-Gate annotationBasedApplicationMetrics aktiviert wird, werden Messwerte für Objekte mit der Annotation prometheus.io/scrape erfasst. Viele Softwaresysteme mit Open-Source-Ursprung verwenden möglicherweise diese Annotation. Wenn Sie diese Methode zur Erfassung von Messwerten weiterhin verwenden, sollten Sie sich dieser Abhängigkeit bewusst sein, damit Sie nicht von Gebühren für Messwerte in Cloud Monitoring überrascht werden.
    Logging und Monitoring 1.15, 1.16, 1.28.0-1.28.900, 1.29.0-1.29.400, 1.30.0, 1.30.100

    Cloud-Audit-Logs erfordert eine spezielle Berechtigungseinrichtung, die vom Clusteroperator über GKE Hub automatisch ausgeführt wird.

    Wenn jedoch ein Administratorcluster mehrere Cluster mit unterschiedlichen Projekt-IDs verwaltet, würde ein Fehler im Clusteroperator dazu führen, dass dasselbe Dienstkonto wiederholt an die Zulassungsliste angehängt wird. Die Anfrage für die Zulassungsliste würde aufgrund der Größenbeschränkung fehlschlagen. Dies würde dazu führen, dass Audit-Logs aus einigen oder allen dieser Cluster nicht in Google Cloudeingefügt werden können.

    Das Symptom ist eine Reihe von Permission Denied-Fehlern im Pod audit-proxy im betroffenen Cluster.

    Ein weiteres Symptom ist der Fehlerstatus und eine lange Liste mit doppelten Dienstkonten, wenn Sie die Zulassungsliste für Cloud-Audit-Logs über GKE Hub prüfen:

    curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging

{
  "name": "projects/PROJECT_ID/locations/global/features/cloudauditlogging",
  "spec": {
    "cloudauditlogging": {
      "allowlistedServiceAccounts": [
        "SERVICE-ACCOUNT-EMAIL",
        ...
        ... multiple lines of the same service account
      ]
    }
  },
  "state": {
    "state": {
      "code": "ERROR"
    }
  }
}

    Um das Problem zu beheben, können Sie Ihren Cluster auf mindestens Version 1.28.1000, 1.29.500 oder 1.30.200 aktualisieren, in denen das Problem behoben wurde. Alternativ können Sie den folgenden Workaround anwenden:
    Konfiguration Alle Patchversionen in 1.29 und früher, 1.30.400 und früher sowie 1.31.0

    Die Konfiguration des Registry-Spiegels auf Knoten wird nicht aktualisiert, wenn nur das Feld hosts geändert wird.

    Wenn Sie das Feld containerRuntime.registryMirrors.hosts für einen Registry-Mirror-Endpunkt in der Clusterspezifikation aktualisieren, werden die Änderungen nicht automatisch auf die Clusterknoten angewendet. Dieses Problem tritt auf, weil die Abgleichslogik Änderungen, die ausschließlich am Feld hosts vorgenommen wurden, nicht erkennt. Folglich werden die Maschinen-Updatejobs, die für die Aktualisierung der containerd-Konfiguration auf den Knoten zuständig sind, nicht ausgelöst.

    Überprüfung:

    Sie können dieses Problem überprüfen, indem Sie nur das Feld hosts für einen Registry-Mirror ändern und dann die containerd-Konfigurationsdatei auf einem Worker-Knoten prüfen. Der Pfad kann je nach Version und Einrichtung /etc/containerd/config.toml oder /etc/containerd/config.d/01-containerd.conf sein. In der Datei wird die aktualisierte hosts-Liste für den Spiegelendpunkt nicht angezeigt.

    Workaround:

    Wählen Sie eine der folgenden Optionen aus:

    1. Upgrade auf eine Version mit dem Fix:Aktualisieren Sie Ihre Cluster auf 1.30.500-gke.126 oder höher, 1.31.100-gke.136 oder höher oder 1.32.0.
    2. Update über eine NodePool-Änderung auslösen:Nehmen Sie eine triviale Änderung an der NodePool-Spezifikation für die betroffenen Knoten vor. Fügen Sie beispielsweise ein temporäres Label oder eine Annotation hinzu. Dadurch wird der Aktualisierungsprozess für die Maschine ausgelöst, bei dem die Änderungen am Registry-Mirror übernommen werden. Sie können die unwichtige Änderung später wieder entfernen.

    Nächste Schritte

    Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care. Weitere Informationen zu Supportressourcen finden Sie unter Support. Dazu gehören:

    • Voraussetzungen für das Eröffnen eines Supportfalls.
    • Tools zur Fehlerbehebung, z. B. Ihre Umgebungskonfiguration, Logs und Messwerte.
    • Unterstützte Komponenten.