Durch das Budget für Pod-Störungen blockierte Knoten entfernen

Unter bestimmten Umständen können Sie mithilfe von Richtlinien zur Budget für Pod-Störungen-Richtlinie verhindern, dass Knoten erfolgreich aus Knotenpools entfernt werden. Unter diesen Bedingungen meldet der Knotenstatus Ready,SchedulingDisabled, auch wenn er entfernt wurde.

Budget für Pod-Störungen steht in Konflikt mit der Anzahl der verfügbaren Pods

Mit den PDB-Richtlinien können Sie die Anwendungsleistung gewährleisten, indem Sie verhindern, dass Pods gleichzeitig ausfallen, wenn Sie Änderungen am System vornehmen. Daher begrenzen PDB-Richtlinien die Anzahl gleichzeitig nicht verfügbarer Pods in einer replizierten Anwendung.

Die PDB-Richtlinie kann jedoch manchmal das Löschen von Knoten verhindern, wenn Sie einen Knoten entfernen möchten, denn das Entfernen eines Knotens verstößt gegen die Richtlinie.

Mit einer PDB-Richtlinie kann beispielsweise definiert sein, dass immer zwei Pods im System verfügbar sein sollen (.spec.minAvailable ist 2). Wenn Sie jedoch nur zwei Pods haben und versuchen, den Knoten zu entfernen, der einen enthält, dann war die PDB-Richtlinie wirksam und hat verhindert, dass der Knoten entfernt wird.

Wenn in der PDB-Richtlinie festgelegt ist, dass keine Pods mehr verfügbar sein sollen (.spec.maxUnavailable ist 0), verhindert die Richtlinie auch, dass alle verknüpften Knoten gelöscht werden. Auch wenn Sie versuchen, einen einzelnen Pod nach dem anderen zu entfernen, verhindert die PDB-Richtlinie, dass Sie den betroffenen Knoten löschen können.

Problemumgehung: PDB-Richtlinie deaktivieren und wieder aktivieren

Zur Behebung dieses Konflikts führen Sie eine Sicherung durch und entfernen dann die PDB-Richtlinie. Nachdem die PDB erfolgreich gelöscht wurde, wird der Knoten per Drain beendet und die zugehörigen Pods werden entfernt. Nachdem Sie die gewünschten Änderungen vorgenommen haben, können Sie die PDB-Richtlinie wieder aktivieren.

Das folgende Beispiel zeigt, wie ein Knoten in dieser Bedingung gelöscht wird, was alle Arten von GKE on Bare-Metal-Clustern betreffen kann: Administrator-, Hybrid-, eigenständige und Nutzercluster.

Das gleiche allgemeine Verfahren gilt für alle Clustertypen. Die spezifischen Befehle zum Löschen eines Knotens aus einem Administratorcluster-Knotenpool (für Administrator-, Hybrid- oder eigenständige Cluster) unterscheiden sich jedoch geringfügig von den Befehlen zum Löschen eines Knotens aus einem Nutzercluster-Knotenpool.

Befehlsvarianten für verschiedene Clustertypen

Der Einfachheit halber müssen Sie den Platzhalter ${KUBECONFIG} in den folgenden Befehlen angeben. Exportieren Sie je nach Clustertyp den Administratorcluster-kubeconfig (ADMIN_KUBECONFIG) oder den Nutzerclusterkubeconfig (USER_CLUSTER_CONFIG) nach $(KUBECONFIG) und führen Sie die folgenden Schritte aus.

  • So löschen Sie einen Knoten aus einem Nutzercluster, export KUBECONFIG=USER_CLUSTER_CONFIG:
  • So löschen Sie einen Knoten aus einem Administratorcluster, export KUBECONFIG=ADMIN_KUBECONFIG.

  1. (optional): Wenn Sie einen Knoten aus dem Knotenpool eines Nutzerclusters löschen, führen Sie den folgenden Befehl aus, um die kubeconfig-Datei des Nutzerclusters zu extrahieren. Beachten Sie, dass die Variable ADMIN_KUBECONFIG den Pfad zum Administratorcluster-kubeconfig und die Variable USER_CLUSTER_NAME den Namen des Clusters angibt:

    kubectl --kubeconfig ADMIN_KUBECONFIG -n cluster-USER_CLUSTER_NAME  \
get secret USER_CLUSTER_NAME-kubeconfig  \
-o 'jsonpath={.data.value}' | base64 -d > USER_CLUSTER_CONFIG

  2. Nachdem Sie den Knoten aus dem Knotenpool entfernt haben, prüfen Sie den Knotenstatus. Der betroffene Knoten meldet Ready, SchedulingDisabled:

    kubectl get nodes --kubeconfig ${KUBECONFIG}

    Der Knotenstatus sieht in etwa so aus:

    NAME        STATUS                    ROLES      AGE      VERSION
abmnewCP2   Ready                     Master     11m      v.1.18.6-gke.6600
abmnewCP3   Ready,SchedulingDisabled  <none>     9m22s    v.1.18.6-gke.6600
abmnewCP4   Ready                     <none>     9m18s    v.1.18.6-gke.6600

  3. Prüfen Sie die PDBs in Ihrem Cluster:

    kubectl get pdb --kubeconfig ${KUBECONFIG} -A

    Das System meldet PDBs, die den folgenden ähneln:

    NAMESPACE     NAME             MIN AVAILABLE    MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
gke-system    istio-ingress    1                N/A               1                     19m
gke-system    istiod           1                N/A               1                     19m
kube-system   coredns          1                N/A               0                     19m
kube-system   log-aggregator   N/A              0                 0                     19m
kube-system   prometheus       N/A              0                 0                     19m
 ```

  4. Überprüfen Sie die PDB. Sie müssen eine Übereinstimmung zwischen dem Pod-Label innerhalb der PDB und den übereinstimmenden Pods im Knoten finden. Diese Übereinstimmung gewährleistet, dass die richtige PDB deaktiviert wird, um den Knoten erfolgreich zu entfernen:

    kubectl --kubeconfig ${KUBECONFIG} get pdb log-aggregator -n kube-system -o 'jsonpath={.spec}'

    Das System gibt entsprechende Labelergebnisse in der PDB-Richtlinie zurück:

    {"maxUnavailable":0,"selector":{"matchLabels":{"app":"stackdriver-log-aggregator"}}}

  5. Suchen Sie nach Pods, die mit dem PDB-Richtlinienlabel übereinstimmen:

    kubectl --kubeconfig ${KUBECONFIG} get pods -A --selector=app=stackdriver-log-aggregator  \
-o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.nodeName}{"\n"}{end}'

    Der Befehl gibt eine Liste von Pods zurück, die mit dem PDB-Label übereinstimmen, und prüft die PDB-Richtlinie, die Sie entfernen müssen:

    stackdriver-log-aggregator-0    abmnewCP3
stackdriver-log-aggregator-1    abmnewCP3

  6. Nachdem Sie den betroffenen Pod bestätigt haben, erstellen Sie eine Sicherungskopie der PDB-Richtlinie, in diesem Beispiel der Richtlinie log-aggregator:

    kubectl get pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system  \
-o yaml >> log-aggregator.yaml

  7. Löschen Sie die spezifische PDB-Richtlinie, in diesem Fall die Richtlinie log-aggregator:

    kubectl delete pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system

    Nachdem Sie die PDB-Richtlinie gelöscht haben, wird der Knoten fortgesetzt. Es kann jedoch bis zu 30 Minuten dauern, bis der Knoten vollständig gelöscht ist. Prüfen Sie daher den Knotenstatus.

    Wenn Sie den Knoten dauerhaft entfernen und damit die zum Knoten gehörenden Speicherressourcen entfernen möchten, können Sie das tun, bevor Sie die PDB-Richtlinie wiederherstellen. Weitere Informationen finden Sie unter Speicherressourcen entfernen.

  8. Stellen Sie die PDB-Richtlinie aus Ihrer Kopie wieder her:

    kubectl apply -f log-aggregator.yaml --kubeconfig ${KUBECONFIG}

  9. Prüfen Sie, ob die gelöschten Pods erfolgreich neu erstellt wurden. Wenn es in diesem Beispiel zwei stackdriver-log-aggregator-x-Pods gab, werden sie neu erstellt:

    kubectl get pods -o wide --kubeconfig ${KUBECONFIG} -A

Wenn Sie den Knoten wiederherstellen möchten, bearbeiten Sie die entsprechende Knotenpoolkonfiguration und stellen Sie die IP-Adresse des Knotens wieder her.

Speicherressourcen aus endgültig gelöschten Knoten entfernen

Wenn Sie einen Knoten dauerhaft löschen und ihn nicht auf Ihrem System wiederherstellen möchten, können Sie auch die mit diesem Knoten verknüpften Speicherressourcen löschen.

Beachten Sie in den folgenden Befehlen die folgenden Variablen:

  • ADMIN-KUBECONFIG gibt den Pfad zum Administratorcluster an.
  • USER_CLUSTER_CONFIG gibt den Pfad zur YAML-Datei der Clusterkonfiguration an.

  1. Prüfen Sie den Namen des nichtflüchtigen Speichers (PV), der dem Knoten zugeordnet ist, und rufen Sie ihn ab:

    kubectl get pv --kubeconfig ${KUBECONFIG}  \
-A -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{.spec.claimRef.name}{":\t}  \
{.spec.nodeAffinity.required.nodeSelectorTerms[0].matchExpressions[0].values}{"\n"}{end}'

  2. Löschen Sie das mit dem Knoten verknüpfte PV:

    kubectl delete pv PV_NAME --kubeconfig ${KUBECONFIG}