Probleme mit Distributed Cloud Connected beheben

Google überwacht und wartet die Google Distributed Cloud Connected-Bereitstellungen per Fernzugriff. Zu diesem Zweck haben Google-Techniker Secure Shell-Zugriff (SSH) auf die Distributed Cloud Connected-Hardware. Wenn Google ein Problem erkennt, setzt sich ein Google-Techniker mit Ihnen in Verbindung, um das Problem zu beheben. Wenn Sie selbst ein Problem festgestellt haben, wenden Sie sich sofort an den Google-Support, um es zu diagnostizieren und zu beheben.

Softwareupgrades für Distributed Cloud Connected

In diesem Abschnitt wird beschrieben, wie Sie mit dem Metrics Explorer prüfen, ob für einen mit Distributed Cloud verbundenen Cluster ein Softwareupgrade 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 der Distributed Cloud an, auf die der Cluster aktualisiert wird.

Damit Sie die Schritte in diesem Abschnitt ausführen können, 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-Betrachter, mit der Sie Monitoring-Messwerte aufrufen können.
  3. (Optional) Der machine_id-Wert der Distributed Cloud Connected-Zielmaschine zum Filtern der zurückgegebenen Ergebnisse.

Mit dem Metrics Explorer die aktuelle und die Zielsoftwareversion 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 die vollständige Ressourcen-ID 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 Bereich Messwert nach dem Wert current_cluster_version.

    2. Wählen Sie den Messwert Maschinenlaufzeit aus. Der vollständige Pfad lautet 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 Bereich Messwert nach dem Wert target_cluster_version.

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

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

  5. Prüfen Sie den Status des Softwareupgrades des Clusters im angezeigten Diagramm.

    • Wenn die Zeilen Aktuelle Clusterversion und Zielclusterversion jeweils unterschiedliche Werte enthalten, wird ein Softwareupgrade für den Cluster durchgeführt.

    • Wenn die Zeilen Aktuelle Clusterversion und Zielclusterversion denselben Wert enthalten, wird für den Cluster kein Softwareupgrade 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 Softwareupgrade durchgeführt.
    • Wenn die Werte der Felder clusterVersion und targetVersion unterschiedlich sind, vergleichen Sie sie mit den vom Metrics Explorer zurückgegebenen Werten.

Was bedeuten die Ergebnisse?

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

Clusterstatus Diagnose Lösung
Fehlerfrei
currentVersion- und targetVersion-Werte stimmen überein
`status`-Wert ist RUNNING
 Auf dem Cluster wird die Zielversion der Distributed Cloud Connected-Software ausgeführt. Keine.
Upgrade wird ausgeführt
Der Wert von currentVersion ist kleiner als targetVersion
Der Wert von `status` ist UPDATING
 Der Cluster wird auf die Zielversion der Distributed Cloud-Software aktualisiert. Beobachten Sie den Cluster im Metrics Explorer, bis die Werte für die aktuelle und die Zielclusterversion übereinstimmen.
Blockiert
currentVersion-Wert ist unbegrenzt niedriger als targetVersion
`status`-Wert ist unbegrenzt UPDATING
 Das Upgrade auf die Zielversion der mit Distributed Cloud verbundenen Software ist auf mindestens einem Knoten im Cluster fehlgeschlagen. Prüfen Sie die Maschinenverbindung und die Systemprotokolle. Wenden Sie sich an Google, um Unterstützung zu erhalten.
Rollback
currentVersion-Wert ist höher als targetVersion
`status`-Wert ist UPDATING
 Der Cluster wird auf eine frühere Version der Distributed Cloud Connected-Software zurückgesetzt. Wenden Sie sich an Google, um den Grund für den Rollback zu erfahren.

Wenn das Softwareupgrade auf dem Cluster fehlgeschlagen ist oder der Cluster auf eine vorherige Softwareversion zurückgesetzt wurde, prüfen Sie Folgendes:

  • Knotenzustand. Prüfen Sie, ob jede physische mit Distributed Cloud verbundene Maschine eine Netzwerkverbindung hat und die Betriebszeit meldet, wie im nächsten Abschnitt beschrieben.
  • Wartungsfenster Prüfen Sie, ob das Softwareupgrade aufgrund eines Wartungsausschlussfensters pausiert wurde.
  • Systemprotokolle. Prüfen Sie Ihre Systemprotokolle, um mögliche Gründe für den Fehler beim Softwareupgrade zu ermitteln, z. B. Zeitüberschreitungen bei der Pod-Entfernung.

Wenn das Problem durch die in der Tabelle aufgeführten Schritte nicht behoben wird, wenden Sie sich an den Google-Support und geben Sie den machine_id-Wert der betroffenen Maschine und den Zeitstempel des Ausfalls an.

Neustarts von Distributed Cloud Connected-Maschinen

In diesem Abschnitt wird beschrieben, wie Sie mit dem Metrics Explorer prüfen, ob ein mit Distributed Cloud verbundener physischer Computer neu gestartet wurde, und den Grund für den Neustart ermitteln. Durch das Monitoring von Neustarts können Sie feststellen, ob sie Teil einer geplanten Wartung waren oder das Ergebnis eines Hardwarefehlers oder einer Stromunterbrechung.

Bei diesem Verfahren werden die folgenden Monitoring-Messwerte verwendet:

  • Maschinenbetriebszeit (/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 seiner Bereitstellung an.

Damit Sie die Schritte in diesem Abschnitt ausführen können, 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-Betrachter, mit der Sie Monitoring-Messwerte aufrufen können.
  3. (Optional) Der machine_id-Wert der Distributed Cloud Connected-Zielmaschine zum Filtern der zurückgegebenen Ergebnisse.

Mit dem Metrics Explorer die Maschinenlaufzeit und die Anzahl der Neustarts 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 die vollständige Ressourcen-ID edgecontainer.googleapis.com/Machine verwenden.

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

  3. Prüfen Sie die Betriebszeit der Maschine:

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

    2. Wählen Sie den Messwert Maschinenlaufzeit aus. Der vollständige Pfad lautet 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ügbarkeitsgrafik kontinuierlich ansteigt. Wenn der Wert für die Betriebszeit zu irgendeinem Zeitpunkt auf null fällt und neu startet, bedeutet dies, dass die Maschine neu gestartet wurde.

  4. Prüfen Sie die Anzahl der Neustarts des Computers:

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

    2. Wählen Sie den Messwert Maschinenneustarts 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 stattgefunden haben. Wenn die Linie zu einem beliebigen Zeitpunkt auf 1 ansteigt, bedeutet dies, dass die Maschine neu gestartet wurde. Notieren Sie sich 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 Abschnitt Aggregation der Seite auf, setzen Sie das Feld Ausrichtungszeitraum auf 1 minute und das Feld Ausrichtung pro Reihe auf Delta.

Was bedeuten die Ergebnisse?

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

Maschinenzustand Diagnose Lösung
Stabil
Der Messwert „Maschinenlaufzeit“ steigt kontinuierlich an.
Das Delta des Messwerts „Maschinenneustarts“ ist 0.
 Die Maschine wurde nicht neu gestartet. Keine.
Sauberer Neustart
Der Messwert „Maschinenlaufzeit“ sinkt auf 0
Der Messwert „Maschineneustarts“ steigt auf 1
 Die Maschine wurde neu gestartet und die Verbindung zu Google Cloudwiederhergestellt. Prüfen Sie die Systemprotokolle, um den Grund für den Neustart zu ermitteln.
Stromausfall
Das Diagramm für den Messwert „Maschinenlaufzeit“ weist eine Lücke ohne Daten auf.
Der Messwert „Maschinenneustarts“ hat sich während der Lücke in der Maschinenlaufzeit nicht geändert.
 Die Stromversorgung oder Netzwerkverbindung der Maschine wurde unterbrochen, bevor sie neu gestartet werden konnte. Prüfen Sie die Strom- und Netzwerkkabel, die lokale Netzwerkkonfiguration und den Status der LED-Anzeige.
Zeitweise
Der Messwert „Maschine verbunden“ wechselt zwischen 0 und 1
Der Messwert „Network Connectivity“ wechselt zwischen 0 und 1
 Instabile Netzwerkverbindung, Paketverlust oder übermäßige Latenz. Prüfen Sie Ihr lokales Netzwerk auf Überlastung und fehlerhafte Hardware.

Wenn das Problem durch die in der Tabelle aufgeführten Schritte nicht behoben wird, wenden Sie sich an den Google-Support und geben Sie den machine_id-Wert der betroffenen Maschine und den Zeitstempel des Ausfalls an.

Konnektivität von Distributed Cloud Connected-Maschinen

In diesem Abschnitt wird beschrieben, wie Sie die Internet- und Google Cloud -Verbindung für Ihre mit Distributed Cloud verbundenen Maschinen mithilfe des Metrics Explorer-Features von Cloud Monitoring prüfen.

Bei diesem Verfahren werden die folgenden Monitoring-Messwerte verwendet:

  • Maschine verbunden (/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.

Damit Sie die Schritte in diesem Abschnitt ausführen können, 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-Betrachter, mit der Sie Monitoring-Messwerte aufrufen können.
  3. (Optional) Der machine_id-Wert der Distributed Cloud Connected-Zielmaschine zum Filtern der zurückgegebenen Ergebnisse.

Maschinenkonnektivität mit dem Metrics Explorer 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 die vollständige Ressourcen-ID edgecontainer.googleapis.com/Machine verwenden.

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

  3. Prüfen Sie die Verbindung des Computers zu Google Cloud:

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

    2. Wählen Sie den Messwert Machine Connected aus. Der vollständige Pfad lautet edgecontainer.googleapis.com/machine/connected.

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

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

  4. Prüfen Sie die Internetverbindung des Computers:

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

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

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

    4. Prüfen Sie im angezeigten Zeitdiagramm, ob die Linie Fehlerfrei durchgehend bei 100 % bleibt. Wenn dieser Wert zu irgendeinem Zeitpunkt 0% Fehlerhaft beträgt, hatte die Maschine zum angegebenen Zeitpunkt keine Internetverbindung.

Was bedeuten die Ergebnisse?

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

Maschinenzustand Diagnose Lösung
Fehlerfrei
Der Wert des Messwerts „Maschine verbunden“ ist 1
Der Wert des Messwerts „Network Connectivity“ ist 1
 Normaler Betrieb. Keine.
Getrennt
Messwert „Maschine verbunden“ ist 0
Messwert „Network Connectivity“ ist 1
 Der Computer 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 mit Distributed Cloud verbundenen Agents auf dem Computer ausgeführt werden.
Isoliert
Messwert „Maschine verbunden“ ist 0
Messwert „Network Connectivity“ ist 0
 Die Maschine hat keine Internetverbindung. Prüfen Sie die Strom- und Netzwerkkabel, die lokale Netzwerkkonfiguration und den Status der LED-Anzeige. Prüfen Sie die VLAN- und Routingkonfiguration.
Zeitweise
Der Messwert „Maschine verbunden“ wechselt zwischen 0 und 1
Der Messwert „Network Connectivity“ wechselt zwischen 0 und 1
 Instabile Netzwerkverbindung, Paketverlust oder übermäßige Latenz. Prüfen Sie Ihr lokales Netzwerk auf Überlastung und fehlerhafte Hardware.

Wenn Sie für einen der beiden Messwerte anhaltende Werte von 0 feststellen, führen Sie die in der Tabelle beschriebenen Schritte zur Fehlerbehebung aus, um das Problem zu beheben. Wenn das Problem weiterhin besteht, wenden Sie sich an den Google-Support und geben Sie den machine_id-Wert der betroffenen Maschine und den Zeitstempel des Ausfalls an.

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 im Speicher der virtuellen Maschine vor.
  • Der Zielknoten ist mit einer Markierung versehen.

So beheben Sie das Problem:

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

  2. Rufen Sie Informationen zur betroffenen virtuellen Maschine ab:

    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 Nachrichten, die auf Ressourcenbeschränkungen, Planungsfehler, Speicherfehler und andere Probleme hinweisen können.

  3. Prüfen Sie die Ausgabe, um die Ursachen des Planungsfehlers zu ermitteln, wie in den nächsten Abschnitten erläutert.

Unzureichende Ressourcen

Möglicherweise wird eine Meldung angezeigt, dass Ressourcen wie CPU, Arbeitsspeicher oder Speicherplatz nicht ausreichen. Beispiel:

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

Prüfen Sie zur Behebung dieses Problems die Ressourcen, die den betroffenen virtuellen Maschinen und anderen auf dem Knoten geplanten Arbeitslasten zugewiesen sind, und gehen Sie dann je nach Ihren geschäftlichen Anforderungen so vor:

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

Markierte Knoten

Möglicherweise wird eine Meldung angezeigt, dass der Zielknoten eine Markierung hat. 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. Verwenden Sie den folgenden Befehl, um den Status der PersistentVolumeClaims (PVCs) im Namespace der betroffenen virtuellen Maschine abzurufen:

    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 der 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 prüfen und dafür sorgen, dass die entsprechende StorageClass verfügbar ist.

Planungssperren, die durch fehlgeschlagene Zulassungs-Webhooks verursacht werden

Mit Zulassungs-Webhooks können Sie Anfragen an den Kubernetes API-Server abfangen, bevor das Objekt beibehalten wird. Webhooks sind zwar nützlich, um benutzerdefinierte Sicherheitsrichtlinien durchzusetzen, aber falsch konfigurierte Webhooks können zu clusterweiten Ausfällen führen, insbesondere bei kritischen Vorgängen wie Softwareupgrades und Zertifikatsaktualisierungen. Insbesondere kann ein blockierter oder nicht verfügbarer Admission Webhook die Kubernetes-Steuerungsebene blockieren und so die Planung weiterer Arbeitslasten im Cluster verhindern.

Deadlock der Steuerungsebene

Ein Deadlock durch einen Zirkelbezug kann auftreten, wenn ein Zulassungs-Webhook für die Validierung von Ressourcen verantwortlich ist, die für die Wiederherstellung des Webhooks selbst erforderlich sind. Wenn beispielsweise ein Zulassungs-Webhook für die Validierung von Pods konfiguriert ist und dieser 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 wechselt 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 jede Zeitüberschreitung zwischen dem API-Server und dem Webhook zur Ablehnung der API-Anfrage. Dies führt zu folgenden Problemen:

  • Softwareupgrades schlagen fehl: Systemkomponenten und VMs können während und nach einem Softwareupgrade für Knoten nicht geplant werden.
  • Systemdienste können nicht gestartet werden: Infrastruktur-Pods wie Symcloud Storage und VM Runtime on GDC können nicht gestartet werden.
  • Knoten im Wartungsmodus hängen geblieben: 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 zuvor beschriebenen Deadlock der Steuerungsebene zu vermeiden. Diese Best Practices gelten für alle ValidatingWebhookConfiguration- und MutatingWebhookConfiguration-Objekte.

failurePolicy: Ignore verwenden

Sofern Ihre Geschäftsanforderungen nicht vorschreiben, dass eine API-Anfrage fehlschlagen muss, wenn sie nicht validiert werden kann, setzen Sie das Feld failurePolicy immer auf Ignore. So wird sichergestellt, dass der Kubernetes API-Server auch dann funktioniert, wenn der betroffene Webhook-Dienst ausgefallen ist, sodass systemkritische Pods geplant und wiederhergestellt werden können.

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 Verwaltungs-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 durch fehlgeschlagene Webhooks blockiert ist

Wenn Ihr Cluster durch fehlgeschlagene Webhooks blockiert ist und Ihre kubectl-Befehle zum Erstellen von Ressourcen eine Zeitüberschreitung oder Fehler zurückgeben, liegt das in der Regel daran, dass der Webhook failurePolicy auf Fail gesetzt hat. Folgen Sie den Schritten in diesem Abschnitt, um den Cluster aus dem Deadlock wiederherzustellen. Wenn der fehlerhafte Webhook ein mutierender Webhook ist, verwenden Sie mutatingwebhookconfiguration anstelle von validatingwebhookconfiguration.

  1. Identifizieren Sie die fehlgeschlagenen Webhooks:

    1. Listen Sie die im Cluster bereitgestellten validierenden Webhooks auf:

      kubectl get validatingwebhookconfigurations

    2. Listen Sie die im Cluster bereitgestellten mutierenden Webhooks auf:

      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, verarbeitet der Kubernetes API-Server wieder Anfragen, löst den Deadlock auf und lässt blockierte Prozesse abschließen.