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äß entleert, ausgenommen kritische System-Pods wie den API-Server. 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 per Drain zu beenden. 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. Mit diesem Ansatz können andere Clusterkomponenten korrekt darüber informiert werden, dass sich der Knoten im Wartungsmodus befindet. Wenn Sie einen Knoten in den Wartungsmodus versetzen, können keine zusätzlichen Pods für den Knoten geplant werden und vorhandene Pods werden angehalten.

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

Wenn Sie den Wartungsmodus verwenden, geht Google Distributed Cloud so vor:

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 Eviction API, um jeden Pod zu entfernen. Diese Methode zum Draining von Knoten berücksichtigt PodDisruptionBudgets (PDBs). Sie können PDBs konfigurieren, um Ihre Arbeitslasten zu schützen. Dazu geben Sie mithilfe der Felder minAvailable und maxUnavailable ein tolerierbares Maß an Unterbrechung für eine Reihe von Pods an. Das Leeren von Knoten auf diese Weise bietet besseren Schutz vor Arbeitslastunterbrechungen. Der bereinigte Knotenausgleich ist ab Version 1.29 allgemein verfügbar.

• Damit Knoten während des Beendens 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 Finalizer haben. Google Distributed Cloud versucht, alle Pods zu beenden. Wenn das Zeitlimit überschritten wird, wird der Knoten in den Wartungsmodus versetzt. Durch dieses Zeitlimit wird verhindert, dass Upgrades durch ausgeführte Pods blockiert werden.

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. Mithilfe der Markierung NoExecute beendet kube-scheduler von Google Distributed Cloud Pods und leert den Knoten. Bei dieser Methode zum Leeren von Knoten werden PDBs nicht berücksichtigt.

• Damit Knoten während des Beendens 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 Finalizer haben. Google Distributed Cloud versucht, alle Pods zu beenden. Wenn das Zeitlimit überschritten wird, wird der Knoten in den Wartungsmodus versetzt. Durch dieses Zeitlimit wird verhindert, dass Upgrades durch ausgeführte Pods blockiert werden.

Bereinigungsbasiertes Ausgleichen

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

Diese Funktion ist nicht bei allen unterstützten Versionen in der gleichen Startphase:

• 1.29: Allgemeine Verfügbarkeit
• 1.28: Nicht verfügbar
• 1.16: Nicht verfügbar

Draining-Auftrag

Vor Version 1.29 verwendet der von Google Distributed Cloud kube-scheduler durchgeführte markierungsbasierte Knotenausgleich keinen bestimmten Algorithmus zum Draining von Pods aus einem Knoten. Beim bereinigten Knotenausgleich werden Pods je nach Priorität in einer bestimmten Reihenfolge entfernt. Die Bereinigungspriorität ist mit bestimmten Pod-Kriterien verknüpft, wie in der folgenden Tabelle dargestellt:

Draining-Auftrag	Pod-Kriterien (muss mit allen übereinstimmen) und
1	Pods, die den folgenden Kriterien entsprechen, werden entfernt: Pods ohne spec.prorityClassName Pods, die keinem bekannten CSI-Namen (Container Storage Interface) entsprechen 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 nicht PriorityClass Pods, die keinem bekannten CSI-Namen (Container Storage Interface) entsprechen
3	Pods, die den folgenden Kriterien entsprechen, werden entfernt: Pods mit Spec.ProrityClassName Pods, die keinem bekannten CSI-Namen (Container Storage Interface) entsprechen Die Entfernungsreihenfolge für übereinstimmende Pods basiert auf PriorityClass.value und ist von niedrig nach hoch.
4	Warten Sie, bis CSI die PV/PVC-Bereitstellungen bereinigt hat, nachdem alle Pods entfernt wurden. Verwenden Sie Node.Status.VolumesInUse, um anzugeben, dass alle Volumes bereinigt wurden.
5	Pods, die den folgenden Kriterien entsprechen, werden entfernt: Pods, die einem bekannten CSI-Namen (Container Storage Interface) entsprechen Diese Pods müssen trotzdem per Drain beendet werden, da kubelet keine Kompatibilität mit direkten Upgrades bietet.

Da beim bereinigten Knotenausgleich PDBs berücksichtigt werden, kann der Knotenausgleich durch die PDB-Einstellungen unter bestimmten Umständen blockiert werden. Informationen zur Fehlerbehebung beim Draining von Knotenpools finden Sie unter Prüfen, warum ein Knoten seit langer Zeit den Status des Draining hat.

Auf Bereinigung basierenden Knotenausgleich deaktivieren

Der bereinigte Knotenausgleich ist für Cluster mit der Nebenversion 1.29 oder Cluster, die auf Nebenversion 1.29 aktualisiert werden, standardmäßig aktiviert. Wenn der bereinigte Knotenausgleich Probleme mit Clusterupgrades oder Clusterwartung verursacht, können Sie zum markierungsbasierten Knotenausgleich zurückkehren. Dazu fügen Sie 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
   

   Die Knoten sind weiterhin planbar, doch durch Markierungen wird verhindert, dass Pods (ohne 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 so 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 Knoten außerdem die folgenden Markierungen hinzu, wenn sie in den Wartungsmodus versetzt werden:

   • 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 es erforderlich wird, einen vollständigen Cluster herunterzufahren, folgen Sie der Anleitung in den folgenden Abschnitten, um einen Cluster herunterzufahren und sicher wieder zu aktivieren.

Cluster herunterfahren

Wenn Sie einen Cluster beenden, der Nutzercluster verwaltet, müssen Sie zuerst alle verwalteten Nutzercluster beenden. 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 die STATUS für einen Knoten nicht Ready ist, wird dringend empfohlen, Fehler am Knoten zu beheben und nur fortzufahren, wenn alle Knoten Ready sind.

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 verwaltenden Cluster.

   Die nachfolgenden Schritte sind vom Administratorcluster abhängig. Wenn STATUS für einen Knoten nicht Ready ist, wird dringend empfohlen, Fehler am Knoten zu beheben und nur fortzufahren, wenn alle Knoten Ready sind.

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 ist der Name des Clusters, den Sie prüfen.

   • ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei für den verwaltenden Cluster.

   Beheben Sie alle gemeldeten Probleme, bevor Sie fortfahren.

4. Prüfen Sie für den Cluster, den Sie herunterfahren, ob 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 der STATUS für einen Pod nicht Running ist, empfehlen wir dringend, eine Fehlerbehebung für den Pod durchzuführen und nur fortzufahren, wenn alle Pods Running sind.

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

   Es ist wichtig, eine etcd-Sicherung zu erstellen, bevor Sie den Cluster herunterfahren, damit er wiederhergestellt werden kann, falls beim Neustart des Clusters Probleme auftreten. Eine Beschädigung der ETCD, 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, setzen Sie die Worker-Knoten in den Wartungsmodus.

   Durch diesen Schritt wird die Menge an Schreibvorgängen in etcd minimiert. Dadurch wird die Wahrscheinlichkeit verringert, dass beim Neustart des Clusters eine große Anzahl von etcd-Schreibvorgängen abgeglichen werden muss.

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

   Dieser Schritt verhindert beschädigte Schreibvorgänge für zustandsorientierte Arbeitslasten während des Herunterfahrens 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 über SSH eine Verbindung zu jedem Knoten der Steuerungsebene herstellen und den folgenden etcdctl-Befehl ausfü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 die Spalte IS LEADER, die true zurückgibt, wenn der Knoten der etcd-Leader ist.

   Hinweis: Es ist davon auszugehen, dass der API-Server ausgefallen ist, wenn die etcd-Follower ausgefallen sind. Das liegt daran, dass der API-Server keine Anfragen verarbeiten kann, wenn der etcd-Cluster das Quorum verliert, was beim Herunterfahren zu erwarten ist. „ETCD“ ist wieder online, sobald alle Knoten der Steuerungsebene wieder online sind.

Zu diesem Zeitpunkt ist Ihr Cluster vollständig heruntergefahren. Nachdem Sie alle erforderlichen Wartungsarbeiten 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 Cluster neu zu starten, der vollständig heruntergefahren wurde.

1. Schalten Sie die Knotenmaschinen in umgekehrter Reihenfolge zum Herunterfahren der Maschine ein.

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

   Eine Anleitung finden Sie unter Knoten aus dem Wartungsmodus entfernen.

   Hinweis: Sie müssen die Maschinen nicht einzeln aus dem Wartungsmodus entfernen. Es empfiehlt sich jedoch, mit einem einzelnen Knoten zu beginnen, darauf zu achten, dass er fehlerfrei ist, und die Anzahl der Knoten dann langsam im Laufe der Zeit zu erhöhen.

3. Entfernen Sie Worker-Knoten aus dem Wartungsmodus.

4. Führen Sie Cluster-Systemdiagnosen aus, um zu prüfen, ob der Cluster ordnungsgemäß funktioniert:

   bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

5. Wenn ein Problem wie etcd-Absturzschleife den Neustart des Clusters verhindert, versuchen Sie, den Cluster aus der letzten bekanntermaßen fehlerfreien Sicherung wiederherzustellen. Eine Anleitung finden Sie unter Cluster wiederherstellen.

Abrechnungs- und Wartungsmodus

Die Abrechnung für Google Distributed Cloud basiert auf der Anzahl der vCPUs, die Ihr Cluster für Knoten hat, die Arbeitslasten ausführen können. Wenn Sie einen Knoten in den Wartungsmodus versetzen, werden die Markierungen NoExecute und NoSchedule zum Knoten hinzugefügt. Die Abrechnung wird dadurch jedoch nicht deaktiviert. Nachdem Sie einen Knoten in den Wartungsmodus versetzt haben, sperren Sie den Knoten (kubectl cordon NODE_NAME), um ihn als nicht planbar zu kennzeichnen. Sobald ein Knoten als nicht planbar markiert ist, werden der Knoten und seine zugehörigen vCPUs von der Abrechnung ausgeschlossen.

Wichtig: Das Herunterfahren eines Knotens ändert nicht seinen Abrechnungsstatus. 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
• Knoten in den Wartungsmodus versetzen und absichern, damit er nicht mehr planbar ist

Wie auf der Seite „Preise“ beschrieben, können Sie mit kubectl die (zur Abrechnung verwendete) vCPU-Kapazität jedes Ihrer Nutzercluster abrufen. Der Befehl berücksichtigt nicht, ob der Knoten planbar ist oder nicht, er gibt nur eine vCPU-Anzahl pro Knoten an.

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.