Automatische Knotenreparatur und Systemdiagnosen

In Google Distributed Cloud sind regelmäßige Systemdiagnosen und automatische Knotenreparaturen standardmäßig aktiviert.

Die automatische Reparatur von Knoten erkennt intakte Knoten in einem Cluster kontinuierlich und repariert sie.

Regelmäßige Systemdiagnosen werden alle 15 Minuten ausgeführt. Die Prüfungen sind mit jenen identisch, die von gkectl diagnose cluster ausgeführt werden. Die Ergebnisse werden als Logs und Ereignisse für Clusterobjekte im Administratorcluster angezeigt.

Achten Sie darauf, dass Ihre Administrator- und Nutzercluster jeweils eine zusätzliche IP-Adresse für die automatische Knotenreparatur haben.

Fehlerhafte Knotenbedingungen

Die folgenden Bedingungen geben an, dass ein Knoten fehlerhaft ist:

• Die Knotenbedingung NotReady beträgt ca. 10 Minuten true.

• Der Maschinenstatus lautet Unavailable für etwa zehn Minuten nach dem Erstellen.

• Der Maschinenstatus ist seit der VM-Erstellung etwa 30 Minuten lang nicht Available.

• Es gibt kein Knotenobjekt (nodeRef ist nil), das einer Maschine im Status Available ungefähr 10 Minuten entspricht.

• Die Knotenbedingung DiskPressure beträgt ca. 30 Minuten true.

Strategie der Knotenreparatur

Google Distributed Cloud initiiert eine Reparatur auf einem Knoten, wenn der Knoten mindestens eine der Bedingungen in der obigen Liste erfüllt.

Durch die Reparatur wird der fehlerhafte Knoten geleert und eine neue VM erstellt. Wenn der Knotensausgleich eine Stunde lang fehlschlägt, wird bei der Reparatur der Verbindungsausgleich erzwungen und die angehängten verwalteten Kubernetes-Laufwerke werden getrennt voneinander entfernt.

Wenn sich mehrere fehlerhafte Knoten im selben MachineDeployment befinden, wird die Reparatur nur auf einem dieser Knoten durchgeführt.

Die Anzahl der Reparaturen pro Stunde für einen Knotenpool ist auf Folgendes beschränkt:

• Drei
• 10 % der Anzahl der Knoten im Knotenpool

Knotenreparatur und Systemdiagnosen für einen neuen Cluster aktivieren

Legen Sie in der Clusterkonfigurationsdatei admin oder User den Wert autoRepair.enabled auf true fest:

autoRepair:
  enabled: true

Fahren Sie mit den Schritten zum Erstellen eines admin- oder Nutzerclusters fort.

Hinweis: Da sich die Knoten der Steuerungsebene des Nutzerclusters im Administratorcluster befinden, müssen Sie der Anleitung für den Administratorcluster folgen, wenn Sie die automatische Reparatur aktiviert haben möchten für die Nutzercluster-Steuerungsebenenknoten.

Knotenreparatur und Systemdiagnosen für einen vorhandenen Nutzercluster aktivieren

Legen Sie in der Konfigurationsdatei für Nutzercluster autoRepair.enabled auf true fest:

Aktualisieren Sie den Cluster:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Dabei gilt:

• ADMIN_CLUSTER_KUBECONFIG: Pfad der Datei "kubeconfig" Ihres Administratorclusters

• USER_CLUSTER_CONFIG: Pfad Ihrer Nutzercluster-Konfigurationsdatei

Knotenreparatur und Systemdiagnosen für einen vorhandenen Administratorcluster aktivieren

Legen Sie in der Administrator-Clusterkonfigurationsdatei autoRepair.enabled auf true fest:

Aktualisieren Sie den Cluster:

gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG

Ersetzen Sie ADMIN_CLUSTER_CONFIG durch den Pfad Ihrer Konfigurationsdatei für den Administratorcluster.

Logs einer Systemdiagnose aufrufen

Lassen Sie alle Pods der Systemdiagnose im Administratorcluster auflisten:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep cluster-health-controller

Die Ausgabe sieht etwa so aus:

kube-system       cluster-health-controller-6c7df455cf-zlfh7   2/2   Running
my-user-cluster   cluster-health-controller-5d5545bb75-rtz7c   2/2   Running

Rufen Sie die Logs für den Container cluster-health-controller in einem der Pods ab, um die Logs einer bestimmten Systemdiagnose aufzurufen. So rufen Sie beispielsweise die Logs für my-user-cluster in der vorherigen Ausgabe ab:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace my-user-cluster logs \
    cluster-health-controller-5d5545bb75-rtz7c cluster-health-controller

Anzeigen von Ereignissen in der Systemdiagnose

Listen Sie alle Clusterobjekte in Ihrem Administratorcluster auf:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get clusters --all-namespaces

Die Ausgabe sieht etwa so aus:

default            gke-admin-ldxh7   2d15h
my-user-cluster    my-user-cluster   2d12h

Zum Aufrufen der Ereignisse für einen bestimmten Cluster führen Sie kubectl describe cluster mit dem Flag --show-events aus. So rufen Sie beispielsweise die Ereignisse für my-user-cluster in der vorherigen Ausgabe auf:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace my-user-cluster \
    describe --show-events cluster my-user-cluster

Beispielausgabe:

Events:
  Type     Reason             Age   From                                 Message
  ----     ------             ----  ----                                 -------
  Warning  ValidationFailure  17s   cluster-health-periodics-controller  validator for Pod returned with status: FAILURE, reason: 1 pod error(s).

Knotenreparatur und Systemdiagnosen für einen Nutzercluster deaktivieren

Legen Sie in der Konfigurationsdatei für Nutzercluster autoRepair.enabled auf false fest:

Aktualisieren Sie den Cluster:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Knotenreparatur und Systemdiagnosen für Administratorcluster deaktivieren

Legen Sie in der Konfigurationsdatei des Administratorclusters autoRepair.enabled auf false fest:

Aktualisieren Sie den Cluster:

gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG

Fehlerbehebung bei der automatischen Reparatur von Knoten

Sie können Probleme mit der automatischen Knotenreparatur untersuchen, indem Sie die Maschinen- und Knotenobjekte im Administratorcluster beschreiben. Beispiel:

Listen Sie die Maschinenobjekte auf:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG  get machines

Beispielausgabe:

default     gke-admin-master-wcbrj
default     gke-admin-node-7458969ff8-5cg8d
default     gke-admin-node-7458969ff8-svqj7
default     xxxxxx-user-cluster-41-25j8d-567f9c848f-fwjqt

Beschreiben Sie eines der Maschinenobjekte:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG describe machine gke-admin-master-wcbrj

Suchen Sie in der Ausgabe nach Ereignissen aus cluster-health-controller.

Ebenso können Sie Knotenobjekte auflisten und beschreiben. Beispiele:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes
...
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG describe node gke-admin-master-wcbrj

Manuelle Knotenreparatur

Knoten der Administratorsteuerungsebene

Der Knoten der Administrator-Steuerungsebene hat einen dedizierten Reparaturbefehl, da die normale manuelle Reparatur nicht funktioniert.

Verwenden Sie gkectl repair admin-master, um den Knoten der Administrator-Steuerungsebene zu reparieren.

Knoten der Steuerungsebene des Nutzerclusters V2

Die Knoten der Steuerungsebene des Nutzerclusters der Steuerungsebene V2 werden anders als andere Knoten verwaltet.

Ähnlich wie bei kubeception-Nutzerclustern befinden sich die Maschinenobjekte der Steuerungsebene von Steuerungsebenen-V2-Nutzerclustern im Administratorcluster. Für die automatische Knotenreparatur die automatische Reparatur des Knotens des Administratorclusters.

Bei Knotenproblemen, die nicht von der Logik für die automatische Reparatur des Administratorclusterknotens abgedeckt sind, oder wenn Sie die automatische Reparatur des Administratorclusterknotens nicht aktiviert haben, können Sie eine manuelle Reparatur durchführen. Dadurch wird der Knoten gelöscht und neu erstellt.

1. Rufen Sie den Namen des Maschinenobjekts ab, das dem Knoten entspricht:

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME get machines
   

   Ersetzen Sie Folgendes:

   • ADMIN_CLUSTER_KUBECONFIG: der Pfad zu Ihrer Administrator-kubeconfig-Datei.
   • USER_CLUSTER_NAME: der Name des Zielnutzerclusters.

2. Fügen Sie dem Maschinenobjekt die Anmerkung repair hinzu:

   kubectl annotate --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME machine MACHINE_NAME onprem.cluster.gke.io/repair-machine=true
   

   Ersetzen Sie MACHINE_NAME durch den Namen des Maschinenobjekts.

3. Löschen Sie das Maschinenobjekt:

   kubectl delete --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME machine MACHINE_NAME
   

Erstellen Sie den Knoten einzeln für eine HA-Steuerungsebene neu. Andernfalls kann die Steuerungsebene unerwartet ausfallen.

Hinweis: Ein Nutzercluster der Steuerungsebene V2 enthält eine Kopie der Maschinenobjekte der Steuerungsebene im Nutzercluster selbst. Diese Maschinenobjekte dienen nur zu Informationszwecken. Das Löschen dieser Elemente wird nicht wirksam.

Sonstige Knoten

Warnung: Dies funktioniert nicht für das Maschinenobjekt der Administrator-Steuerungsebene. Verwenden Sie es nicht für das Maschinenobjekt der Administrator-Steuerungsebene.

Warnung: Dies funktioniert nicht für die Maschinenobjekte in den V2-Nutzerclustern der Steuerungsebene.

Bei Knotenproblemen, die nicht durch die automatische Reparaturlogik abgedeckt sind oder die automatische Reparatur für Knoten nicht aktiviert ist, können Sie eine manuelle Reparatur durchführen. Dadurch wird der Knoten gelöscht und neu erstellt.

Rufen Sie den Namen des Maschinenobjekts ab, das dem Knoten entspricht:

kubectl --kubeconfig CLUSTER_KUBECONFIG get machines

Ersetzen Sie CLUSTER_KUBECONFIG durch den Pfad der Kubeconfig-Datei des Administrator- oder Nutzerclusters.

Fügen Sie dem Maschinenobjekt die Anmerkung repair hinzu:

kubectl annotate --kubeconfig CLUSTER_KUBECONFIG machine MACHINE_NAME onprem.cluster.gke.io/repair-machine=true

Ersetzen Sie MACHINE_NAME durch den Namen des Maschinenobjekts.

Löschen Sie das Maschinenobjekt:

kubectl delete --kubeconfig CLUSTER_KUBECONFIG machine MACHINE_NAME