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äß beendet, mit Ausnahme kritischer System-Pods wie des API-Servers. Außerdem verhindert der Wartungsmodus, dass der Knoten neue Podzuweisungen erhält. Im Wartungsmodus können Sie auf Ihren Knoten arbeiten, ohne den Pod-Traffic möglicherweise zu beeinträchtigen.

Funktionsweise

Mit Google Distributed Cloud können Sie Knoten in den Wartungsmodus versetzen. So können andere Clusterkomponenten richtig erkennen, dass sich der Knoten im Wartungsmodus befindet. Wenn Sie einen Knoten in den Wartungsmodus versetzen, können auf dem Knoten keine zusätzlichen Pods geplant werden und vorhandene Pods werden angehalten.

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

Wenn Sie den Wartungsmodus verwenden, geschieht Folgendes:

1,29

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

  • In Google Distributed Cloud wird die Eviction API verwendet, um jeden Pod zu entfernen. Bei dieser Methode zum Beenden von Knoten per Drain 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 Unterbrechungen für eine Gruppe von Pods an. Wenn Sie Knoten auf diese Weise per Drain beenden, sind Sie besser vor Arbeitslaststörungen geschützt. Das bereinigungsbasierte Beenden von Knoten per Drain ist in Version 1.29 als GA 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 jedoch überschritten wird, wird der Knoten in den Wartungsmodus versetzt. Dieses Zeitlimit verhindert, dass durch die Ausführung von Pods Upgrades blockiert werden.

1.28 und früher

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

  • Google Distributed Cloud fügt die baremetal.cluster.gke.io/maintenance:NoExecute-Markierung hinzu. Aufgrund der NoExecute-Markierung stoppt der Google Distributed Cloud-kube-scheduler Pods und beendet den Knoten. Bei dieser Methode zum Beenden von Knoten per Drain 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 jedoch überschritten wird, wird der Knoten in den Wartungsmodus versetzt. Dieses Zeitlimit verhindert, dass durch die Ausführung von Pods Upgrades blockiert werden.

Bereinigungsbasiertes Beenden von Knoten per Drain

Der Wechsel von einem bereinigungsbasierten zu einem markierungsbasierten Knotenbeendigungsverfahren führt nicht zu Verfahrensänderungen. Die Umstellung wirkt sich nur auf die Abgleichlogik aus.

Diese Funktion ist nicht in derselben Markteinführungsphase für alle unterstützten Versionen:

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

Reihenfolge des Beendens per Drain

Vor Version 1.29 wurde beim markierungsbasierten Beenden von Knoten, das vom Google Distributed Cloud-kube-scheduler ausgeführt wird, kein bestimmter Algorithmus verwendet, um Pods in einem Knoten per Drain zu beenden. Beim bereinigungsbasierten Beenden von Knoten werden Pods in einer bestimmten Reihenfolge auf Grundlage der Priorität bereinigt. Die Bereinigungspriorität ist mit bestimmten Pod-Kriterien verknüpft, wie in der folgenden Tabelle dargestellt:

Reihenfolge des Beendens per Drain Pod-Kriterien (alle müssen übereinstimmen) und
1

Pods, die die folgenden Kriterien erfüllen, werden bereinigt:

  • Pods ohne spec.prorityClassName
  • Pods, die keinem bekannten CSI-Namen (Container Storage Interface) entsprechen
  • Pods, die keinem DaemonSet zugewiesen sind
2

Pods, die die folgenden Kriterien erfüllen, werden bereinigt:

  • Pods, die zu einem DaemonSet gehören
  • Pods haben keine PriorityClass
  • Pods, die keinem bekannten CSI-Namen (Container Storage Interface) entsprechen
3

Pods, die die folgenden Kriterien erfüllen, werden bereinigt:

  • Pods mit Spec.ProrityClassName
  • Pods, die keinem bekannten CSI-Namen (Container Storage Interface) entsprechen

Die Reihenfolge der Bereinigung für übereinstimmende Pods basiert auf PriorityClass.value, von niedrig nach hoch.
4

Warten Sie, bis CSI die PV/PVC-Bindungen bereinigt, nachdem alle Pods entfernt wurden. Mit Node.Status.VolumesInUse geben Sie an, dass alle Volumes bereinigt wurden.
5

Pods, die die folgenden Kriterien erfüllen, werden bereinigt:

  • Pods, die mit einem bekannten CSI-Namen (Container Storage Interface) übereinstimmen

Diese Pods müssen trotzdem per Drain beendet werden, da kubelet keine direkten Upgrades unterstützt.

Da beim bereinigungsbasierten Beenden von Knoten per Drain PDBs berücksichtigt werden, können PDB-Einstellungen das Beenden von Knoten unter bestimmten Umständen blockieren. Informationen zur Fehlerbehebung beim Beenden eines Knotenpools finden Sie unter Prüfen, warum ein Knoten seit langer Zeit per Drain beendet wurde.

Bereinigungsbasiertes Beenden von Knoten per Drain deaktivieren

Das bereinigungsbasierte Beenden von Knoten per Drain ist standardmäßig für Cluster mit der Nebenversion 1.29 oder für Cluster aktiviert, die auf die Nebenversion 1.29 aktualisiert werden. Wenn das bereinigungsbasierte Beenden von Knoten per Drain zu Problemen mit Cluster-Upgrades oder der Clusterwartung führt, können Sie zu einem markierungsbasierten Beenden von Knoten zurückkehren, indem Sie Ihrer Clusterressource die Annotation baremetal.cluster.gke.io/maintenance-mode-ignore-pdb: true hinzufügen.

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

    Dabei gilt:

    • 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 können weiterhin geplant werden, aber Markierungen verhindern, 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 auch folgende 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

    Dabei gilt:

    • 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 Sie einen vollständigen Cluster herunterfahren müssen, folgen Sie der Anleitung in den folgenden Abschnitten, um den Cluster herunterzufahren und wieder sicher zu starten.

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 Clustertypen von Google Distributed Cloud.

  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 der STATUS für einen Knoten nicht Ready ist, empfehlen wir dringend, die Fehlerbehebung für den Knoten durchzuführen und erst fortzufahren, wenn alle Knoten Ready sind.

  2. Wenn Sie einen Nutzercluster herunterfahren, prüfen Sie den Status der Administratorclusterknoten:

    kubectl get nodes --kubeconfig ADMIN_KUBECONFIG

    Ersetzen Sie dabei ADMIN_KUBECONFIG durch den Pfad der kubeconfig-Datei für den verwaltenden Cluster.

    Die nachfolgenden Schritte hängen vom Administratorcluster ab. Wenn der STATUS für einen Knoten nicht Ready ist, empfehlen wir dringend, die Fehlerbehebung für den Knoten durchzuführen und erst 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: der Name des Clusters, den Sie prüfen.

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

    Beheben Sie alle gemeldeten Probleme, bevor Sie fortfahren.

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

  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 der Cluster wiederhergestellt werden kann, falls beim Neustart Probleme auftreten. Eine Beschädigung von Etcd, Hardwarefehler an Knoten, Probleme mit der Netzwerkverbindung und möglicherweise andere Bedingungen können verhindern, dass der Cluster ordnungsgemäß neu gestartet wird.

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

    Dadurch wird die Anzahl der Schreibvorgänge in etcd minimiert. Die Wahrscheinlichkeit, dass beim Neustart des Clusters eine große Anzahl von etcd-Schreibworgängen abgeglichen werden muss, wird verringert.

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

    Dadurch werden beschädigte Schreibvorgänge für zustandsorientierte Arbeitslasten beim Herunterfahren des Knotens verhindert.

  8. Schalten Sie die 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 endend mit dem etcd-Leader

      Wenn Sie einen Hochverfügbarkeitscluster (HA) haben, können Sie den etcd-Leader finden, indem Sie mit 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 eine IS LEADER-Spalte, die true zurückgibt, wenn der Knoten der etcd-Leader ist.

Ihr Cluster ist jetzt vollständig heruntergefahren. Nachdem Sie die erforderliche Wartung durchgeführt haben, können Sie Ihren 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 ausgeschaltet wurde.

  1. Schalten Sie die Knotencomputer in umgekehrter Reihenfolge zur Abschaltreihenfolge ein.

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

    Eine Anleitung finden Sie unter Knoten aus dem Wartungsmodus entfernen.

  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 wie eine etcd-Absturzschleife verhindert, dass der Cluster ordnungsgemäß neu gestartet wird, versuchen Sie, den Cluster aus der letzten bekannten 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 Ihres Clusters für Knoten, auf denen Arbeitslasten ausgeführt werden können. Wenn Sie einen Knoten in den Wartungsmodus versetzen, werden ihm die Markierungen NoExecute und NoSchedule hinzugefügt. Die Abrechnung wird dadurch jedoch nicht deaktiviert. Nachdem Sie einen Knoten in den Wartungsmodus versetzt haben, sperren Sie ihn (kubectl cordon NODE_NAME), um ihn als nicht planbar zu kennzeichnen. Sobald ein Knoten als nicht planbar gekennzeichnet ist, werden der Knoten und die zugehörigen vCPUs von der Abrechnung ausgeschlossen.

Wie auf der Preisseite beschrieben, können Sie mit kubectl die vCPU-Kapazität (für die Abrechnung) Ihrer Nutzercluster aufrufen. Der Befehl berücksichtigt nicht, ob der Knoten planbar ist. Er gibt nur die Anzahl der vCPUs 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 des Nutzerclusters.