Probleme mit Distributed Cloud Connected beheben

Google überwacht und wartet die Google Distributed Cloud Connected-Hardware per Fernzugriff. Zu diesem Zweck haben Google-Techniker Secure Shell-Zugriff (SSH) auf die Distributed Cloud Connected-Hardware. Wenn Google ein Problem erkennt, wendet sich ein Google-Techniker an Sie, um es zu beheben. Wenn Sie selbst ein Problem festgestellt haben, wenden Sie sich sofort an den Google-Support, damit es diagnostiziert und behoben werden kann.

Softwareupgrades für Distributed Cloud Connected

In diesem Abschnitt wird beschrieben, wie Sie mit Metrics Explorer prüfen, ob für einen mit Distributed Cloud verbundenen Cluster ein Software-Upgrade durchgeführt wird.

Bei diesem Verfahren werden die folgenden Monitoring-Messwerte verwendet:

  • Aktuelle Clusterversion (/edge_cluster/current_cluster_version): Gibt die aktuelle Version der Distributed Cloud Connected-Software an, die auf dem Cluster ausgeführt wird.

  • Zielversion des Clusters (/edge_cluster/target_cluster_version): Gibt die Zielversion von Distributed Cloud Connected an, auf die der Cluster aktualisiert wird.

Für die Schritte in diesem Abschnitt müssen die folgenden Voraussetzungen erfüllt sein:

  1. Zugriff auf die Google Cloud Console und Ihr mit Distributed Cloud verbundenes Google Cloud Projekt.
  2. Die IAM-Rolle Monitoring Viewer, mit der Sie Monitoring-Messwerte ansehen können.
  3. Optional: Der machine_id-Wert der Zielmaschine für Distributed Cloud Connected zum Filtern der zurückgegebenen Ergebnisse.

Mit dem Metrics Explorer die aktuellen und Zielsoftwareversionen des Clusters prüfen

  1. Rufen Sie den Metrics Explorer auf:

    1. Rufen Sie in der Google Cloud Console den Bereich Monitoring auf.

    2. Klicken Sie im linken Navigationsbaum auf Metrics Explorer.

  2. Wählen Sie den Zielressourcentyp aus:

    1. Rufen Sie auf der Seite „Metrics Explorer“ die Seite Konfiguration auf.

    2. Klicken Sie auf Messwert auswählen.

    3. Suchen Sie über die Suchleiste nach dem Ressourcentyp Cluster. Sie können auch den vollständigen Ressourcen-Identifier edgecontainer.googleapis.com/Cluster verwenden.

    4. Klicken Sie in den zurückgegebenen Ergebnissen auf den Ressourcentyp Cluster.

  3. Rufen Sie die aktuelle Softwareversion des Clusters ab:

    1. Suchen Sie im Abschnitt Messwert nach dem Wert current_cluster_version.

    2. Wählen Sie den Messwert Maschinenbetriebszeit aus. Der vollständige Pfad ist edgecontainer.googleapis.com/edge_cluster/current_cluster_version.

    3. Optional: Filtern Sie im Bereich Filter nach dem Zielwert machine_id.

  4. Rufen Sie die Zielsoftwareversion des Clusters ab:

    1. Klicken Sie auf Abfrage hinzufügen.

    2. Suchen Sie im Abschnitt Messwert nach dem Wert target_cluster_version.

    3. Wählen Sie den Messwert Zielclusterversion aus. Der vollständige Pfad ist edgecontainer.googleapis.com/edge_cluster/target_cluster_version.

    4. Optional: Filtern Sie im Bereich Filter nach dem Zielwert machine_id.

  5. Sehen Sie sich den Software-Upgradestatus des Clusters im angezeigten Diagramm an.

    • Wenn die Zeilen Aktuelle Clusterversion und Ziel-Clusterversion jeweils unterschiedliche Werte enthalten, wird für den Cluster ein Software-Upgrade durchgeführt.

    • Wenn in den Zeilen Aktuelle Clusterversion und Ziel-Clusterversion derselbe Wert angegeben ist, wird für den Cluster kein Software-Upgrade durchgeführt.

  6. Prüfen Sie das Ergebnis des vorherigen Schritts mit dem folgenden Befehl:

    gcloud edge-cloud container clusters describe CLUSTER_ID --location=REGION

    Ersetzen Sie Folgendes:

    • CLUSTER_ID: Die ID des Zielclusters.
    • REGION: die Google Cloud Region, in der der Cluster erstellt wurde.

    Notieren Sie sich in der Ausgabe des Befehls die Werte der folgenden Felder:

    • Wenn der Wert des Felds status UPDATING ist, wird für den Cluster ein Software-Upgrade durchgeführt.
    • Wenn sich die Werte der Felder clusterVersion und targetVersion unterscheiden, vergleichen Sie sie mit den Werten, die vom Metrics Explorer zurückgegeben werden.

Ergebnisse nachvollziehen

In der folgenden Tabelle werden die Ergebnisse erläutert, die vom Metrics Explorer und vom Befehl gcloud zurückgegeben werden.

Clusterstatus Diagnose Lösung
Gut
Die Werte für currentVersion und targetVersion stimmen überein.
Der Wert für „status“ ist RUNNING.
 Auf dem Cluster wird die Zielversion der Distributed Cloud Connected-Software ausgeführt. Keine.
Upgrade
Der currentVersion-Wert ist niedriger als targetVersion
Der Wert für „status“ ist UPDATING
 Der Cluster wird auf die Zielversion der Software mit Verbindung zu Distributed Cloud aktualisiert. Behalten Sie den Cluster im Metrics Explorer im Blick, bis die Werte für die aktuelle und die Zielclusterversion übereinstimmen.
Stuck
Der currentVersion-Wert ist auf unbestimmte Zeit niedriger als targetVersion.
Der Wert für „status“ ist auf unbestimmte Zeit UPDATING.
 Das Upgrade auf die Zielversion der Software mit Verbindung zu Distributed Cloud ist auf mindestens einem Knoten im Cluster fehlgeschlagen. Prüfen Sie die Verbindung des Geräts und die Systemprotokolle. Wenden Sie sich an Google, um Unterstützung zu erhalten.
Wird zurückgesetzt
Der Wert von currentVersion ist höher als targetVersion
Der Wert von „status“ ist UPDATING
 luster führt ein Rollback auf eine frühere Version der Distributed Cloud Connected-Software durch. Wenden Sie sich an Google, um den Grund für das Rollback zu erfahren.

Wenn das Software-Upgrade auf dem Cluster fehlgeschlagen ist oder der Cluster auf eine frühere Softwareversion zurückgesetzt wurde, prüfen Sie Folgendes:

  • Knotenzustand: Prüfen Sie, ob jede physische Distributed Cloud-Maschine, die verbunden ist, eine Netzwerkverbindung hat und die Betriebszeit wie im nächsten Abschnitt beschrieben gemeldet wird.
  • Wartungsfenster: Prüfen Sie, ob das Software-Upgrade aufgrund eines Wartungsausschlusszeitraums pausiert wurde.
  • Systemprotokolle Sehen Sie sich Ihre Systemlogs an, um mögliche Gründe für den fehlgeschlagenen Software-Upgrade zu ermitteln, z. B. Pod-Entfernungs-Timeouts.

Wenn das Problem durch die in der Tabelle aufgeführten Schritte zur Fehlerbehebung nicht behoben wird, wenden Sie sich mit dem machine_id-Wert des betroffenen Geräts und dem Zeitstempel des Ausfalls an den Google-Support.

Neustarts von Distributed Cloud Connected-Maschinen

In diesem Abschnitt wird beschrieben, wie Sie mit Metrics Explorer prüfen, ob eine mit Distributed Cloud verbundene physische Maschine neu gestartet wurde, und den Grund für den Neustart ermitteln. Durch das Monitoring von Neustarts lässt sich feststellen, ob sie Teil einer geplanten Wartung waren oder auf einen Hardwarefehler oder eine Stromunterbrechung zurückzuführen sind.

Bei diesem Verfahren werden die folgenden Monitoring-Messwerte verwendet:

  • Betriebszeit der Maschine (/machine/uptime): Gibt die Zeit in Sekunden seit dem letzten Neustart an.

  • Geräteneustarts (/machine/restart_count): Gibt die Gesamtzahl der Neustarts für das Zielgerät seit der Bereitstellung an.

Für die Schritte in diesem Abschnitt müssen die folgenden Voraussetzungen erfüllt sein:

  1. Zugriff auf die Google Cloud Console und Ihr mit Distributed Cloud verbundenes Google Cloud Projekt.
  2. Die IAM-Rolle Monitoring Viewer, mit der Sie Monitoring-Messwerte ansehen können.
  3. Optional: Der machine_id-Wert der Zielmaschine für Distributed Cloud Connected zum Filtern der zurückgegebenen Ergebnisse.

Mit dem Metrics Explorer die Betriebszeit und die Anzahl der Neustarts von Maschinen prüfen

  1. Rufen Sie den Metrics Explorer auf:

    1. Rufen Sie in der Google Cloud Console den Bereich Monitoring auf.

    2. Klicken Sie im linken Navigationsbaum auf Metrics Explorer.

  2. Wählen Sie den Zielressourcentyp aus:

    1. Rufen Sie auf der Seite „Metrics Explorer“ die Seite Konfiguration auf.

    2. Klicken Sie auf Messwert auswählen.

    3. Suchen Sie über die Suchleiste nach dem Ressourcentyp Machine. Sie können auch den vollständigen Ressourcen-Identifier edgecontainer.googleapis.com/Machine verwenden.

    4. Klicken Sie in den zurückgegebenen Ergebnissen auf den Ressourcentyp Machine (Maschine).

  3. So prüfen Sie die Betriebszeit der Maschine:

    1. Suchen Sie im Abschnitt Messwert nach dem Wert uptime.

    2. Wählen Sie den Messwert Maschinenbetriebszeit aus. Der vollständige Pfad ist edgecontainer.googleapis.com/machine/uptime.

    3. Optional: Filtern Sie im Bereich Filter nach dem Zielwert machine_id.

    4. Prüfen Sie im angezeigten Zeitdiagramm, ob die Verfügbarkeitskurve kontinuierlich ansteigt. Wenn der Uptime-Wert irgendwann auf null sinkt und neu startet, bedeutet das, dass der Computer neu gestartet wurde.

  4. Prüfen Sie, wie oft das Gerät neu gestartet wurde:

    1. Suchen Sie im Abschnitt Messwert nach dem Wert restart_count.

    2. Wählen Sie den Messwert Geräteneustarts aus. Der vollständige Pfad lautet edgecontainer.googleapis.com/machine/restart_count.

    3. Optional: Filtern Sie im Bereich Filter nach dem Zielwert machine_id.

    4. Prüfen Sie im angezeigten Zeitdiagramm, ob die Diagrammlinie bei 0 bleibt. Das bedeutet, dass keine Neustarts erfolgt sind. Wenn die Linie an irgendeiner Stelle auf 1 ansteigt, bedeutet das, dass das Gerät neu gestartet wurde. Notieren Sie den genauen Zeitstempel des Neustarts für die weitere Fehlerbehebung.

    5. Optional: Wenn Sie einzelne Ereignisse anstelle eines Diagramms sehen möchten, rufen Sie den Bereich Aggregation auf der Seite auf, stellen Sie das Feld Abstimmungszeitraum auf 1 minute und das Feld Abstimmung pro Serie auf Delta ein.

Ergebnisse nachvollziehen

In der folgenden Tabelle werden die vom Metrics Explorer zurückgegebenen Ergebnisse erläutert.

Maschinenstatus Diagnose Lösung
Stabil
Der Messwert „Betriebszeit des Geräts“ steigt stetig.
Das Delta des Messwerts „Neustarts des Geräts“ ist 0.
 Die Maschine wurde nicht neu gestartet. Keine.
Kaltstart
Der Messwert „Betriebszeit des Geräts“ sinkt auf 0
Der Messwert „Neustarts des Geräts“ steigt auf 1
 Die Maschine wurde neu gestartet und hat die Verbindung zu Google Cloudwiederhergestellt. Prüfen Sie die Systemprotokolle, um den Grund für den Neustart zu ermitteln.
Stromausfall
Im Diagramm für den Messwert „Betriebszeit der Maschine“ ist eine Unterbrechung ohne Daten zu sehen.
Der Messwert „Neustarts der Maschine“ hat sich während der Unterbrechung der Betriebszeit der Maschine nicht geändert.
 Die Stromversorgung oder die Netzwerkverbindung des Geräts wurde unterbrochen, bevor es neu gestartet werden konnte. Prüfe die Strom- und Netzwerkverkabelung, die Konfiguration des lokalen Netzwerks und den Status der LED-Anzeige.
Unterbrochen
Der Messwert „Machine Connected“ (Gerät verbunden) wechselt zwischen 0 und 1.
Der Messwert „Network Connectivity“ (Netzwerkverbindung) wechselt zwischen 0 und 1.
 Instabile Netzwerkverbindung, Paketverlust oder übermäßige Latenz. Prüfe dein lokales Netzwerk auf Überlastung und defekte Hardware.

Wenn das Problem durch die in der Tabelle aufgeführten Schritte zur Fehlerbehebung nicht behoben wird, wenden Sie sich mit dem machine_id-Wert des betroffenen Geräts und dem Zeitstempel des Ausfalls an den Google-Support.

Konnektivität von Distributed Cloud Connected-Maschinen

In diesem Abschnitt wird beschrieben, wie Sie die Internet- und Google Cloud Verbindung Ihrer mit Distributed Cloud verbundenen Maschinen mit der Funktion Metrics Explorer“ von Cloud Monitoring prüfen.

Bei diesem Verfahren werden die folgenden Monitoring-Messwerte verwendet:

  • Machine Connected (/machine/connected): Gibt an, ob die Maschine mit Google Cloudverbunden ist.

  • Netzwerkverbindung (/machine/network/connectivity): Gibt an, ob die primäre Netzwerkschnittstelle des Computers eine Internetverbindung hat.

Für die Schritte in diesem Abschnitt müssen die folgenden Voraussetzungen erfüllt sein:

  1. Zugriff auf die Google Cloud Console und Ihr mit Distributed Cloud verbundenes Google Cloud Projekt.
  2. Die IAM-Rolle Monitoring Viewer, mit der Sie Monitoring-Messwerte ansehen können.
  3. Optional: Der machine_id-Wert der Zielmaschine für Distributed Cloud Connected zum Filtern der zurückgegebenen Ergebnisse.

Mit dem Metrics Explorer die Maschinenkonnektivität prüfen

  1. Rufen Sie den Metrics Explorer auf:

    1. Rufen Sie in der Google Cloud Console den Bereich Monitoring auf.

    2. Klicken Sie im linken Navigationsbaum auf Metrics Explorer.

  2. Wählen Sie den Zielressourcentyp aus:

    1. Rufen Sie auf der Seite „Metrics Explorer“ die Seite Abfragen auf.

    2. Suchen Sie über die Suchleiste nach dem Ressourcentyp Machine. Sie können auch den vollständigen Ressourcen-Identifier edgecontainer.googleapis.com/Machine verwenden.

    3. Klicken Sie in den zurückgegebenen Ergebnissen auf den Ressourcentyp Machine (Maschine).

  3. Prüfen Sie die Verbindung der Maschine zu Google Cloud:

    1. Suchen Sie im Abschnitt Messwert nach dem Wert connected.

    2. Wählen Sie den Messwert Machine Connected (Maschine verbunden) aus. Der vollständige Pfad ist edgecontainer.googleapis.com/machine/connected.

    3. Optional: Filtern Sie im Bereich Filter nach dem Zielwert machine_id.

    4. Prüfen Sie im eingeblendeten Zeitdiagramm, ob die Linie Fehlerfrei durchgehend bei 100 % bleibt. Wenn dieser Wert zu einem beliebigen Zeitpunkt 0% oder Nicht fehlerfrei ist, hat die Maschine zum angegebenen Zeitpunkt die Verbindung zu Google Cloud verloren.

  4. Prüfen Sie die Internetverbindung der Maschine:

    1. Suchen Sie im Abschnitt Messwert nach dem Wert connectivity.

    2. Wählen Sie den Messwert Netzwerkverbindung aus. Der vollständige Pfad ist edgecontainer.googleapis.com/machine/network/connectivity.

    3. Optional: Filtern Sie im Bereich Filter nach dem Zielwert machine_id.

    4. Prüfen Sie im eingeblendeten Zeitdiagramm, ob die Linie Fehlerfrei durchgehend bei 100 % bleibt. Wenn dieser Wert zu einem beliebigen Zeitpunkt 0% Unhealthy beträgt, hat die Maschine zum angegebenen Zeitpunkt die Internetverbindung verloren.

Ergebnisse nachvollziehen

In der folgenden Tabelle werden die vom Metrics Explorer zurückgegebenen Ergebnisse erläutert.

Maschinenstatus Diagnose Lösung
Gut
Der Messwert „Machine Connected“ (Maschine verbunden) ist 1
Der Messwert „Network Connectivity“ (Netzwerkverbindung) ist 1
 Normaler Betrieb Keine.
Getrennt
Messwert „Machine Connected“ ist 0
Messwert „Network Connectivity“ ist 1
 Die Maschine hat eine Internetverbindung, kann aber keine Verbindung zu Google Cloudherstellen. Prüfen Sie Ihre Firewallregeln für Google-Dienste und API-Endpunkte. Prüfen Sie, ob die Distributed Cloud Connected-Agents auf dem Computer ausgeführt werden.
Isoliert
Der Messwert „Machine Connected“ (Gerät verbunden) ist 0
Der Messwert „Network Connectivity“ (Netzwerkverbindung) ist 0
 Die Maschine hat keine Internetverbindung. Prüfe die Strom- und Netzwerkverkabelung, die Konfiguration des lokalen Netzwerks und den Status der LED-Anzeige. Prüfen Sie Ihre VLAN- und Routingkonfiguration.
Unterbrochen
Der Messwert „Machine Connected“ (Gerät verbunden) wechselt zwischen 0 und 1.
Der Messwert „Network Connectivity“ (Netzwerkverbindung) wechselt zwischen 0 und 1.
 Instabile Netzwerkverbindung, Paketverlust oder übermäßige Latenz. Prüfe dein lokales Netzwerk auf Überlastung und defekte Hardware.

Wenn Sie für einen der beiden Messwerte dauerhaft den Wert 0 feststellen, folgen Sie der Anleitung zur Fehlerbehebung in der Tabelle, um das Problem zu beheben. Wenn das Problem weiterhin besteht, wenden Sie sich mit dem machine_id-Wert des betroffenen Geräts und dem Zeitstempel des Ausfalls an den Google-Support.

Virtuelle Maschinen hängen im Zustand Pending fest

Eine VM-Arbeitslast kann im Status Pending hängen bleiben und nicht auf einem Knoten geplant werden, wenn einer der folgenden Fälle eintritt:

  • Distributed Cloud Connected kann der virtuellen Maschine die angeforderten Ressourcen wie CPU-Zeit, Arbeitsspeicher oder Speicherplatz nicht zuweisen.
  • Die Konfiguration der virtuellen Maschine ist fehlerhaft.
  • Es liegt ein Fehler mit dem Speicher der virtuellen Maschine vor.
  • Der Zielknoten ist manipuliert.

So beheben Sie das Problem:

  1. Rufen Sie Clusteranmeldedaten ab, wie unter Anmeldedaten für einen Cluster abrufen beschrieben.

  2. Informationen zur betroffenen VM abrufen:

    kubectl describe virtualmachine VM_NAME -n NAMESPACE

    Ersetzen Sie Folgendes:

    • VM_NAME: Der Name der Ziel-VM.
    • NAMESPACE: Der Namespace der Ziel-VM.

    Die Ausgabe des Befehls sieht in etwa so aus:

    Status:
...
State:                    Pending
...
Events:
Type     Reason                  Age   From                       Message
----     ------                  ----  ----                       -------
Normal   SuccessfulCreate        15m   virtualmachine-controller  Created virtual machine my-stuck-vm
Warning  DiskProvisioningFailed  14m   virtualmachine-controller  Failed to provision disk: DataVolume my-stuck-vm-data-disk not ready
Warning  PVCNotBound             14m   virtualmachine-controller  PersistentVolumeClaim my-stuck-vm-data-disk is in phase Pending
Warning  VMINotCreated           10m   virtualmachine-controller  VirtualMachineInstance cannot be created: dependencies not ready

    Die Ausgabe des Befehls enthält Meldungen, die auf Ressourcenbeschränkungen, Planungsfehler, Speicherfehler und andere Probleme hinweisen können.

  3. Sehen Sie sich die Ausgabe an, um die Ursachen für den Planungsfehler zu ermitteln, wie in den nächsten Abschnitten beschrieben.

Unzureichende Ressourcen

Möglicherweise wird eine Meldung angezeigt, die auf unzureichende Ressourcen wie CPU, Arbeitsspeicher oder Speicherplatz hinweist. Beispiel:

5/8 nodes are available: 3 Insufficient memory, 3 Insufficient CPU.

Um dieses Problem zu beheben, prüfen Sie die den betroffenen virtuellen Maschinen und anderen auf dem Knoten geplanten Arbeitslasten zugewiesenen Ressourcen und gehen Sie dann je nach Ihren geschäftlichen Anforderungen so vor:

  • Andere Arbeitslasten, die auf dem Knoten geplant sind, herunterskalieren
  • Reduzieren Sie die Menge der Ressourcen, die der betroffenen VM zugewiesen sind.
  • Fügen Sie dem betroffenen Cluster weitere Maschinen hinzu.

Markierungsknoten

Möglicherweise wird eine Meldung angezeigt, die darauf hinweist, dass der Zielknoten beschädigt ist. Beispiel:

5/8 nodes are available: 3 node(s) had taint {<taint-key>:<taint-value>}, that the pod didn't tolerate.

So beheben Sie das Problem:

  1. Verwenden Sie den folgenden Befehl, um nach Markierungen auf dem Knoten zu suchen:

    kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

    Die Ausgabe des Befehls sieht in etwa so aus:

    NAME                           TAINTS
node-name-1   [map[effect:PreferNoSchedule key:node-role.kubernetes.io/master] map[effect:PreferNoSchedule key:node-role.kubernetes.io/control-plane]]
node-name-2   <none>

  2. Führen Sie einen der folgenden Schritte aus:

Speicherfehler

Möglicherweise wird eine Meldung angezeigt, die auf einen Fehler im Speicher der virtuellen Maschine hinweist. Beispiel:

5/8 nodes are available: 3 node(s) had volume node affinity conflict, 3 node(s) had unbound immediate PersistentVolumeClaims.

Diese Meldung kann darauf hinweisen, dass das entsprechende nichtflüchtige Volume nicht auf dem Zielknoten bereitgestellt werden kann.

So beheben Sie das Problem:

  1. Mit dem folgenden Befehl können Sie den Status der PersistentVolumeClaims (PVCs) im Namespace der betroffenen VM abrufen:

    kubectl get pvc -n NAMESPACE

    Ersetzen Sie NAMESPACE durch den Namen des Ziel-Namespace.

    Die Ausgabe des Befehls sieht in etwa so aus:

    NAME                                               STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS            AGE
windows-robin-disk-0                               Bound     pvc-b1a1d264-84bf-4e58-857d-f37f629d5082   25Gi       RWX            robin-block-immediate   30h
windows-robin-disk-1                               Bound     pvc-0130b9a8-7fed-4df0-8226-d79273792a16   25Gi       RWX            robin-block-immediate   30h
windows-robin-vm-0-restored-windows-robin-disk-0   Pending                                                                        gce-pd-gkebackup-in     26m

  2. Prüfen Sie, ob das entsprechende PVC den Status Bound hat. Wenn der Status Pending lautet, konnte das Speichersubsystem das Volume nicht bereitstellen. In solchen Fällen müssen Sie die Konfiguration des Speichersubsystems beheben und dafür sorgen, dass die entsprechende StorageClass verfügbar ist.

Sperrungen planen, die durch fehlgeschlagene Zulassungs-Webhooks verursacht werden

Mit Zulassungs-Webhooks können Sie Anfragen an den Kubernetes API-Server abfangen, bevor das Objekt persistent wird. Falsch konfigurierte Webhooks können zwar nützlich sein, um benutzerdefinierte Sicherheitsrichtlinien zu erzwingen, aber auch zu clusterweiten Ausfällen führen, insbesondere bei kritischen Vorgängen wie Software-Upgrades und Zertifikatsaktualisierungen. Insbesondere kann ein blockierter oder nicht verfügbarer Admission-Webhook die Kubernetes-Steuerungsebene zum Stillstand bringen und verhindern, dass weitere Arbeitslasten im Cluster geplant werden.

Deadlock der Steuerungsebene

Ein Deadlock aufgrund einer zirkulären Abhängigkeit kann auftreten, wenn ein Zulassungs-Webhook für die Validierung von Ressourcen verantwortlich ist, die für die eigene Wiederherstellung des Webhooks erforderlich sind. Wenn beispielsweise ein Zulassungs-Webhook zum Validieren von Pods konfiguriert ist und der Webhook-Pod während eines Knotensoftware-Upgrades neu geplant werden muss, versucht der Kubernetes API-Server möglicherweise, den Webhook zu kontaktieren, um die Erstellung des neuen Pods zu autorisieren. Wenn der Webhook nicht erreichbar ist, schlägt die Anfrage fehl, der Pod wird nicht erstellt und der Cluster gerät in einen Deadlock-Zustand, in dem keine neuen Arbeitslasten geplant werden können.

Wenn ein Webhook mit failurePolicy: Fail konfiguriert ist, führt jeder Kommunikationsfehler oder jedes Zeitlimit zwischen dem API-Server und dem Webhook zur Ablehnung der API-Anfrage. Das führt zu folgenden Problemen:

  • Software-Upgrades schlagen fehl: Systemkomponenten und VMs können während und nach einem Knotensoftware-Upgrade nicht geplant werden.
  • Systemdienste können nicht gestartet werden: Infrastruktur-Pods wie Symcloud Storage und VM-Laufzeit auf GDC können nicht gestartet werden.
  • Knoten bleiben im Wartungsmodus hängen: Knoten im Wartungsmodus können nicht abgeglichen oder beendet werden, da der Controller durch die Zulassungslogik blockiert wird.

Best Practices für die Webhook-Konfiguration

Befolgen Sie die in diesem Abschnitt beschriebenen Best Practices, um den oben beschriebenen Deadlock auf der Steuerungsebene zu vermeiden. Diese Best Practices gelten für alle ValidatingWebhookConfiguration- und MutatingWebhookConfiguration-Objekte.

failurePolicy: Ignore verwenden

Sofern Ihre geschäftlichen Anforderungen nicht vorsehen, dass eine API-Anfrage unbedingt fehlschlagen muss, wenn sie nicht validiert werden kann, sollten Sie das Feld failurePolicy immer auf Ignore festlegen. So wird sichergestellt, dass der Kubernetes API-Server auch dann weiterhin funktioniert, wenn der betroffene Webhook-Dienst nicht verfügbar ist. Dadurch können systemkritische Pods geplant und wiederhergestellt werden.

Reservierte Namespaces ausschließen

Ihre Webhooks dürfen niemals Anfragen für Ressourcen in reservierten Namespaces abfangen. Sie müssen diese Namespaces mit dem Feld namespaceSelector aus Ihrer Webhook-Konfiguration ausschließen. Eine vollständige Liste der reservierten Namespaces finden Sie unter Einschränkungen für Management-Namespaces. Beispiel:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: "customer-policy-webhook"
webhooks:
- name: "validate-labels.example.com"
  failurePolicy: Ignore
  sideEffects: None
  admissionReviewVersions: ["v1"]
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system
      - kube-node-lease
      - kube-public
      - capi-system
      - capi-kubeadm-bootstrap-system
      - gke-system
      - gke-connect
      - gke-operators
      - gke-managed-metrics-server
      - anthos-identity-service
      - anthos-creds
      - robinio
      - robin-admin
      - vm-system
      - cert-manager
      - cert-manager-cluster-resources
      - dns-system
      - g-istio-system
      - nf-operator
      - prom-monitoring
      - gpu-system
      - oclcm-system
      - saas-system
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["*"]
    apiVersions: ["*"]
    resources: ["pods", "deployments"]

Cluster wiederherstellen, der aufgrund fehlgeschlagener Webhooks blockiert ist

Wenn Ihr Cluster durch fehlgeschlagene Webhooks blockiert wurde und für Ihre kubectl-Befehle zum Erstellen von Ressourcen Zeitüberschreitungen auftreten oder Fehler zurückgegeben werden, liegt das in der Regel daran, dass für den Webhook failurePolicy auf Fail festgelegt ist. Führen Sie die Schritte in diesem Abschnitt aus, um den Cluster aus dem Deadlock zu befreien. Wenn der fehlgeschlagene Webhook ein Mutating-Webhook ist, verwenden Sie mutatingwebhookconfiguration anstelle von validatingwebhookconfiguration.

  1. Fehlgeschlagene Webhooks identifizieren:

    1. Listen Sie die im Cluster bereitgestellten Validierungs-Webhooks auf:

      kubectl get validatingwebhookconfigurations

    2. Lassen Sie die im Cluster bereitgestellten mutierenden Webhooks auflisten:

      kubectl get mutatingwebhookconfigurations

  2. Prüfen Sie, ob die Pods, die diese Webhooks unterstützen, ausgeführt werden:

    kubectl get pods -A | grep WEBHOOK_SERVICE

    Ersetzen Sie WEBHOOK_SERVICE durch den Namen des Dienstes des Ziel-Webhooks.

  3. Legen Sie den failurePolicy des fehlgeschlagenen Webhooks auf Ignore fest:

    kubectl patch validatingwebhookconfiguration WEBHOOK_CONFIG \
  --type='json' \
  -p='[{"op": "replace", "path": "/webhooks/0/failurePolicy", "value":"Ignore"}]'

    Ersetzen Sie WEBHOOK_SERVICE durch den Namen des Dienstes des Ziel-Webhooks.

  4. (Optional) Wenn der vorherige Schritt fehlgeschlagen ist, erzwingen Sie das Löschen der Konfiguration des betroffenen Webhooks:

    kubectl delete validatingwebhookconfiguration WEBHOOK_CONFIG --timeout=10s

    Ersetzen Sie WEBHOOK_CONFIG durch den Namen der Konfiguration des Ziel-Webhooks.

Nachdem Sie die Konfiguration des Webhooks geändert oder das Löschen erzwungen haben, setzt der Kubernetes API-Server die Verarbeitung von Anfragen fort. Dadurch wird der Deadlock aufgehoben und blockierte Prozesse können abgeschlossen werden.