Knoten in den Wartungsmodus versetzen

Wenn Sie Knoten reparieren oder warten müssen, sollten Sie zuerst die Knoten in den Wartungsmodus versetzen. Dadurch werden vorhandene Pods und Arbeitslasten ordnungsgemäß per Drain beendet, wobei kritische System-Pods wie der API-Server ausgeschlossen werden. Der Wartungsmodus verhindert außerdem, dass der Knoten neue Pod-Zuweisungen erhält. Im Wartungsmodus können Sie an Ihren Knoten arbeiten, ohne den Pod-Traffic zu unterbrechen.

Hinweis: Wenn Sie einen Cluster upgraden, verwendet Google Distributed Cloud den auf dieser Seite beschriebenen Wartungsmodus, um Knoten vor dem Upgrade zu leeren. Weitere Informationen zum Upgradeprozess finden Sie unter Lebenszyklus und Phasen von Clusterupgrades.

Funktionsweise

Google Distributed Cloud bietet eine Möglichkeit, Knoten in den Wartungsmodus zu versetzen. Auf diese Weise können andere Clusterkomponenten korrekt erkennen, dass sich der Knoten im Wartungsmodus befindet. Wenn Sie einen Knoten in den Wartungsmodus versetzen, können keine weiteren Pods auf dem Knoten geplant werden und vorhandene Pods werden beendet.

Anstatt den Wartungsmodus zu verwenden, können Sie auch manuell Kubernetes-Befehle wie kubectl cordon und kubectl drain auf einem bestimmten Knoten verwenden.

Wenn Sie den Wartungsmodus verwenden, führt Google Distributed Cloud folgende Schritte aus:

1,29

• Google Distributed Cloud fügt den angegebenen Knoten die Markierung baremetal.cluster.gke.io/maintenance:NoSchedule hinzu, um die Planung neuer Pods auf dem Knoten zu verhindern.

• Google Distributed Cloud verwendet die Bereinigungs-API, um jeden Pod zu entfernen. Bei dieser Methode zum Ausgleichen von Knoten werden PodDisruptionBudgets (PDBs) berücksichtigt. Sie können PDBs konfigurieren, um Ihre Arbeitslasten zu schützen. Dazu geben Sie mit den Feldern minAvailable und maxUnavailable ein tolerierbares Maß an Unterbrechung für eine Reihe von Pods an. Das Draining von Knoten auf diese Weise bietet einen besseren Schutz vor Arbeitslastunterbrechungen. Der entfernungsbasierte Knotenausgleich ist ab Version 1.29 allgemein verfügbar.

• Damit Knoten beim Warten auf das Beenden von Pods nicht im Wartezustand verbleiben, wird ein Zeitlimit von 20 Minuten erzwungen. Pods werden möglicherweise nicht beendet, wenn sie so konfiguriert sind, dass sie alle Markierungen tolerieren oder Finaler haben. Google Distributed Cloud versucht, alle Pods zu beenden. Wenn das Zeitlimit jedoch überschritten wird, wird der Knoten in den Wartungsmodus versetzt. Dieses Zeitlimit verhindert, dass ausgeführte Pods Upgrades blockieren.

1.28 und niedriger

• Google Distributed Cloud fügt den angegebenen Knoten die Markierung baremetal.cluster.gke.io/maintenance:NoSchedule hinzu, um die Planung neuer Pods auf dem Knoten zu verhindern.

• Google Distributed Cloud fügt die Markierung baremetal.cluster.gke.io/maintenance:NoExecute hinzu. Durch die Wirkung der Markierung NoExecute stoppt Google Distributed Cloud kube-scheduler die Pods und entleert den Knoten. Bei dieser Methode zum Ausgleichen von Knoten werden PDBs nicht berücksichtigt.

• Damit Knoten beim Warten auf das Beenden von Pods nicht im Wartezustand verbleiben, wird ein Zeitlimit von 20 Minuten erzwungen. Pods werden möglicherweise nicht beendet, wenn sie so konfiguriert sind, dass sie alle Markierungen tolerieren oder Finaler haben. Google Distributed Cloud versucht, alle Pods zu beenden. Wenn das Zeitlimit jedoch überschritten wird, wird der Knoten in den Wartungsmodus versetzt. Dieses Zeitlimit verhindert, dass ausgeführte Pods Upgrades blockieren.

Entfernungsbasiertes Draining

Mit dem Wechsel zum markierungsbasierten Knotenausgleich vom markierungsbasierten Ausgleich sind keine Verfahrensänderungen verbunden. Der Wechsel wirkt sich nur auf die Abgleichslogik aus.

Diese Funktion befindet sich nicht bei allen unterstützten Versionen in der Startphase:

• 1.29: GA
• 1.28: Nicht verfügbar
• 1.16: Nicht verfügbar

Draining-Reihenfolge

Vor Version 1.29 wurde beim markierungsbasierten Knotenausgleich, der von Google Distributed Cloud kube-scheduler durchgeführt wird, kein bestimmter Algorithmus zum Entziehen von Pods aus einem Knoten verwendet. Beim entfernungsbasierten Knotenausgleich werden Pods in einer bestimmten Reihenfolge basierend auf der Priorität entfernt. Die Bereinigungspriorität ist mit bestimmten Pod-Kriterien verknüpft, wie in der folgenden Tabelle dargestellt:

Draining-Reihenfolge	Pod-Kriterien (muss mit allen übereinstimmen) und
1	Pods, die den folgenden Kriterien entsprechen, werden entfernt: Pods ohne spec.prorityClassName Pods, die mit keinem bekannten CSSI-Namen (Container Storage Interface) übereinstimmen Pods, die nicht zu einem DaemonSet gehören
2	Pods, die den folgenden Kriterien entsprechen, werden entfernt: Pods, die zu einem DaemonSet gehören Pods haben PriorityClass nicht Pods, die mit keinem bekannten CSSI-Namen (Container Storage Interface) übereinstimmen
3	Pods, die den folgenden Kriterien entsprechen, werden entfernt: Pods mit Spec.ProrityClassName Pods, die mit keinem bekannten CSSI-Namen (Container Storage Interface) übereinstimmen Die Bereinigungsreihenfolge für übereinstimmende Pods basiert auf PriorityClass.value, von niedrig nach hoch.
4	Warten Sie, bis die PV/PVC-Bereitstellungen von CSI bereinigt wurden, nachdem alle Pods entfernt wurden. Geben Sie mit Node.Status.VolumesInUse an, dass alle Volumes bereinigt wurden.
5	Pods, die den folgenden Kriterien entsprechen, werden entfernt: Pods, die mit einem bekannten CSSI-Namen (Container Storage Interface) übereinstimmen Diese Pods müssen weiterhin per Drain beendet werden, da Kubelet keine direkte Upgradekompatibilität bietet.

Da beim Entfernen von Knoten PDBs berücksichtigt werden, blockieren PDB-Einstellungen den Knotenausgleich unter Umständen. Informationen zur Fehlerbehebung beim Leeren von Knotenpools finden Sie unter Prüfen, warum ein Knoten lange Zeit per Drain beendet wurde.

Bereinigungsbasierter Knotenausgleich deaktivieren

Der auf Entfernungen basierende Knotenausgleich ist standardmäßig für Cluster ab Nebenversion 1.29 oder Cluster, die auf Nebenversion 1.29 aktualisiert werden, aktiviert. Wenn das Entfernen von Knoten zu Problemen mit Clusterupgrades oder Clusterwartung führt, können Sie zum markierungsbasierten Knotenausgleich zurückkehren. Fügen Sie dazu der Clusterressource die Annotation baremetal.cluster.gke.io/maintenance-mode-ignore-pdb: true hinzu.

Knoten in den Wartungsmodus versetzen

Wählen Sie in Ihrer Cluster-Konfigurationsdatei für die unter maintenanceBlocks ausgewählten Knoten die IP-Bereiche aus, die Sie in den Wartungsmodus versetzen möchten. Die Knoten, die Sie auswählen, müssen bereit sein und im Cluster funktionieren.

So versetzen Sie Knoten in den Wartungsmodus:

1. Bearbeiten Sie die Cluster-Konfigurationsdatei, um die Knoten auszuwählen, die Sie in den Wartungsmodus versetzen möchten.

   Sie können die Konfigurationsdatei mit einem Editor Ihrer Wahl bearbeiten oder die benutzerdefinierte Clusterressource direkt mit folgendem Befehl bearbeiten:

   kubectl -n CLUSTER_NAMESPACE edit cluster CLUSTER_NAME
   

   Ersetzen Sie Folgendes:

   • CLUSTER_NAMESPACE: den Namespace des Clusters.
   • CLUSTER_NAME ist der Name des Clusters.

2. Fügen Sie der Cluster-Konfigurationsdatei den maintenanceBlocks-Abschnitt hinzu, um entweder eine einzelne IP-Adresse oder einen Adressbereich für die Knoten anzugeben, die Sie in den Wartungsmodus versetzen möchten.

   Im folgenden Beispiel wird gezeigt, wie Sie durch die Angabe eines IP-Adressbereichs mehrere Knoten auswählen:

   metadata:
     name: my-cluster
     namespace: cluster-my-cluster
   spec:
     maintenanceBlocks:
       cidrBlocks:
       - 172.16.128.1-172.16.128.64
   

3. Speichern Sie die aktualisierte Cluster-Konfiguration und wenden Sie sie an.

   Google Distributed Cloud versetzt die Knoten in den Wartungsmodus.

4. Führen Sie folgenden Befehl aus, um den Status der Knoten in Ihrem Cluster abzurufen:

   kubectl get nodes --kubeconfig=KUBECONFIG
   

   Die Ausgabe sieht in etwa so aus:

   NAME                       STATUS   ROLES           AGE     VERSION
   user-anthos-baremetal-01   Ready    control-plane   2d22h   v1.27.4-gke.1600
   user-anthos-baremetal-04   Ready    worker          2d22h   v1.27.4-gke.1600
   user-anthos-baremetal-05   Ready    worker          2d22h   v1.27.4-gke.1600
   user-anthos-baremetal-06   Ready    worker          2d22h   v1.27.4-gke.1600
   

   Beachten Sie, dass die Knoten weiterhin planbar sind, aber Markierungen verhindern, dass Pods (ohne eine entsprechende Toleranz) auf dem Knoten geplant werden.

5. Führen Sie folgenden Befehl aus, um die Anzahl der Knoten im Wartungsmodus abzurufen:

   kubectl get nodepools --kubeconfig ADMIN_KUBECONFIG 
   

   Die Antwort sollte in etwa wie im folgenden Beispiel aussehen:

   NAME   READY   RECONCILING   STALLED   UNDERMAINTENANCE   UNKNOWN
   np1    3       0             0         1                  0
   

   Die Spalte UNDERMAINTENANCE in diesem Beispiel zeigt, dass sich ein Knoten im Wartungsmodus befindet.

   Google Distributed Cloud fügt den Knoten außerdem die folgenden Markierungen hinzu, wenn sie sich im Wartungsmodus befinden:

   • baremetal.cluster.gke.io/maintenance:NoExecute
   • baremetal.cluster.gke.io/maintenance:NoSchedule

Knoten aus dem Wartungsmodus entfernen

So holen Sie Knoten aus dem Wartungsmodus:

1. Bearbeiten Sie die Cluster-Konfigurationsdatei, um die Knoten zu löschen, die Sie aus dem Wartungsmodus holen möchten.

   Sie können die Konfigurationsdatei mit einem Editor Ihrer Wahl bearbeiten oder die benutzerdefinierte Clusterressource direkt mit folgendem Befehl bearbeiten:

   kubectl -n CLUSTER_NAMESPACE edit cluster CLUSTER_NAME
   

   Ersetzen Sie Folgendes:

   • CLUSTER_NAMESPACE: den Namespace des Clusters.
   • CLUSTER_NAME ist der Name des Clusters.

2. Bearbeiten Sie entweder die IP-Adressen, um bestimmte Knoten aus dem Wartungsmodus zu holen, oder entfernen Sie den maintenanceBlocks-Abschnitt, um alle Knoten aus dem Wartungsmodus zu holen.

3. Speichern Sie die aktualisierte Cluster-Konfiguration und wenden Sie sie an.

4. Mit kubectl-Befehlen können Sie den Status Ihrer Knoten prüfen.

Cluster herunterfahren und neu starten

Wenn ein vollständiger Cluster heruntergefahren werden muss, folgen Sie der Anleitung in den folgenden Abschnitten, um den Cluster herunterzufahren und sicher wieder hochzufahren.

Cluster herunterfahren

Wenn Sie einen Cluster herunterfahren, der Nutzercluster verwaltet, müssen Sie zuerst alle verwalteten Nutzercluster herunterfahren. Die folgende Anleitung gilt für alle Google Distributed Cloud-Clustertypen.

1. Prüfen Sie den Status aller Clusterknoten:

   kubectl get nodes --kubeconfig CLUSTER_KUBECONFIG
   

   Ersetzen Sie CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei für den Cluster.

   Die Ausgabe sieht in etwa so aus:

   NAME        STATUS   ROLES           AGE    VERSION
   control-0   Ready    control-plane   202d   v1.27.4-gke.1600
   control-1   Ready    control-plane   202d   v1.27.4-gke.1600
   control-2   Ready    control-plane   202d   v1.27.4-gke.1600
   worker-0    Ready    worker          202d   v1.27.4-gke.1600
   worker-1    Ready    worker          202d   v1.27.4-gke.1600
   worker-2    Ready    worker          202d   v1.27.4-gke.1600
   worker-3    Ready    worker          202d   v1.27.4-gke.1600
   worker-4    Ready    worker          154d   v1.27.4-gke.1600
   worker-5    Ready    worker          154d   v1.27.4-gke.1600
   worker-6    Ready    worker          154d   v1.27.4-gke.1600
   worker-7    Ready    worker          154d   v1.27.4-gke.1600
   worker-8    Ready    worker          154d   v1.27.4-gke.1600
   worker-9    Ready    worker          154d   v1.27.4-gke.1600
   

   Wenn STATUS für einen Knoten nicht Ready ist, wird dringend empfohlen, dass Sie den Knotenfehler beheben und erst fortfahren, wenn alle Knoten den Status Ready haben.

2. Wenn Sie einen Nutzercluster herunterfahren, prüfen Sie den Status der Knoten des Administratorclusters:

   kubectl get nodes --kubeconfig ADMIN_KUBECONFIG
   

   Ersetzen Sie ADMIN_KUBECONFIG durch den Pfad der kubeconfig-Datei für den Verwaltungscluster.

   Die nachfolgenden Schritte hängen vom Administratorcluster ab. Wenn STATUS für einen Knoten nicht Ready ist, wird dringend empfohlen, eine Fehlerbehebung für den Knoten durchzuführen und erst fortzufahren, wenn alle Knoten den Status Ready haben.

3. Prüfen Sie den Status des Clusters, den Sie herunterfahren möchten:

   bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

   Ersetzen Sie Folgendes:

   • CLUSTER_NAME: der Name des Clusters, den Sie prüfen.

   • ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei für den Verwaltungscluster

   Beheben Sie alle gemeldeten Probleme, bevor Sie fortfahren.

4. Achten Sie darauf, dass für den Cluster, den Sie herunterfahren, alle etcd-Pods ausgeführt werden:

   kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \
       -l component=etcd
   

   Ersetzen Sie CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei für den Cluster.

   Die Ausgabe sieht in etwa so aus:

   NAMESPACE     NAME                   READY   STATUS    RESTARTS   AGE
   kube-system   etcd-control-0-admin   1/1     Running   0          2d22h
   kube-system   etcd-control-1-admin   1/1     Running   0          2d22h
   kube-system   etcd-control-2-admin   1/1     Running   0          2d22h
   

   Wenn STATUS für einen Pod nicht Running ist, empfehlen wir dringend, dass Sie den Fehler im Pod beheben und nur fortfahren, wenn alle Pods den Status Running haben.

5. Führen Sie eine Sicherung wie unter Cluster sichern beschrieben durch.

   Es ist wichtig, vor dem Herunterfahren des Clusters eine etcd-Sicherung zu erstellen, damit er wiederhergestellt werden kann, falls beim Neustart des Clusters Probleme auftreten. Etcd-Beschädigungen, Knotenhardwarefehler, Probleme mit der Netzwerkverbindung und möglicherweise andere Bedingungen können einen ordnungsgemäßen Neustart des Clusters verhindern.

6. Wenn Sie einen Cluster mit Worker-Knoten herunterfahren, versetzen Sie die Worker-Knoten in den Wartungsmodus.

   Dieser Schritt minimiert den Schreibumfang in etcd, was die Wahrscheinlichkeit verringert, dass eine große Anzahl von etcd-Schreibvorgängen beim Neustart des Clusters abgeglichen werden muss.

7. Versetzen Sie die Knoten der Steuerungsebene in den Wartungsmodus.

   Dieser Schritt verhindert beschädigte Schreibvorgänge für zustandsorientierte Arbeitslasten beim Herunterfahren von Knoten.

8. Schalten Sie Clusterknoten in der folgenden Reihenfolge aus:

   1. Worker-Knoten
   2. Load-Balancer-Knoten der Steuerungsebene

   3. Knoten der Steuerungsebene, beginnend mit den etcd-Followern und enden mit dem etcd-Leader

      Wenn Sie einen Hochverfügbarkeitscluster haben, können Sie den etcd-Leader ermitteln, indem Sie SSH verwenden, um eine Verbindung zu jedem Knoten der Steuerungsebene herzustellen und den folgenden etcdctl-Befehl auszuführen:

      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 \
          --write-out=table endpoint status
      

      Die Antwort enthält eine IS LEADER-Spalte, die true zurückgibt, wenn der Knoten der etcd-Leader ist.

   Hinweis: Es ist zu erwarten, dass der API-Server ausgefallen ist, wenn die etcd-Follower ausfallen. Dies liegt daran, dass der API-Server keine Anfragen verarbeiten kann, wenn der etcd-Cluster das Quorum verliert, wie es beim Herunterfahren erwartet wird. Etcd erhält wieder das Quorum, sobald alle Knoten der Steuerungsebene wieder online sind.

Zu diesem Zeitpunkt ist der Cluster vollständig heruntergefahren. Nachdem Sie die erforderliche Wartung durchgeführt haben, können Sie den Cluster wie im nächsten Abschnitt beschrieben neu starten.

Cluster neu starten

Führen Sie die folgenden Schritte aus, um einen vollständig heruntergefahrenen Cluster neu zu starten.

1. Schalten Sie Knotenmaschinen in umgekehrter Reihenfolge zur Abschaltungsreihenfolge ein.

2. Entfernen Sie die Knoten der Steuerungsebene aus dem Wartungsmodus.

   Eine Anleitung finden Sie unter Knoten aus dem Wartungsmodus entfernen.

   Hinweis: Der Wartungsmodus muss nicht nacheinander beendet werden, aber es empfiehlt sich, mit einem einzelnen Knoten zu beginnen, zu prüfen, ob dieser fehlerfrei ist, und dann die Knotenanzahl langsam im Laufe der Zeit zu erhöhen.

3. Entfernen Sie Worker-Knoten aus dem Wartungsmodus.

4. Führen Sie Cluster-Systemdiagnosen aus, um sicherzustellen, dass der Cluster ordnungsgemäß funktioniert:

   bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

5. Wenn ein Problem, z. B. eine etcd-Absturzschleife, dazu führt, dass der Cluster nicht ordnungsgemäß neu gestartet wird, versuchen Sie, den Cluster aus der letzten als funktionierend bekannten Sicherung wiederherzustellen. Eine Anleitung dazu finden Sie unter Cluster wiederherstellen.

Abrechnungs- und Wartungsmodus

Die Abrechnung für Google Distributed Cloud richtet sich nach der Anzahl der vCPUs Ihres Clusters für Knoten, auf denen Arbeitslasten ausgeführt werden können. Wenn Sie einen Knoten in den Wartungsmodus versetzen, werden dem Knoten die Markierungen NoExecute und NoSchedule hinzugefügt, die Abrechnung wird jedoch nicht deaktiviert. Nachdem Sie einen Knoten in den Wartungsmodus verlegt haben, sperren Sie den Knoten (kubectl cordon NODE_NAME), um ihn als nicht planbar zu markieren. Sobald ein Knoten als nicht planbar markiert ist, werden der Knoten und die zugehörigen vCPUs von der Abrechnung ausgeschlossen.

Wichtig: Durch das Herunterfahren eines Knotens ändert sich sein Abrechnungsstatus nicht. Führen Sie eine der folgenden Aktionen aus, um einen Knoten von der Abrechnung auszuschließen:

• Einzelnen Knoten aus einem Knotenpool entfernen
• Knotenpool aus dem Cluster entfernen
• Versetzen Sie einen Knoten in den Wartungsmodus und sperren Sie ihn, damit er nicht mehr planbar ist.

Wie auf der Preisseite beschrieben, können Sie mit kubectl die vCPU-Kapazität (zur Abrechnung) jedes Ihrer Nutzercluster sehen. Der Befehl berücksichtigt nicht, ob der Knoten planbar ist oder nicht. Er stellt nur eine vCPU-Anzahl pro Knoten bereit.

So ermitteln Sie die Anzahl der vCPUs pro Knoten für Ihren Nutzercluster:

kubectl get nodes \
    --kubeconfig USER_KUBECONFIG \
    -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"} \
    {.status.capacity.cpu}{\"\n\"}{end}"

Ersetzen Sie USER_KUBECONFIG durch den Pfad der kubeconfig-Datei für Ihren Nutzercluster.