Fehlerbehebung, wenn der Cluster-Autoscaler nicht herunterskaliert

Auf dieser Seite erfahren Sie, wie Sie Probleme diagnostizieren und beheben, die verhindern, dass der Cluster-Autoskalierungsmechanismus Ihre Google Kubernetes Engine-Knoten (GKE) herunterskaliert.

Diese Seite richtet sich an App-Entwickler, die eine unerwartete oder negative Situation mit ihrer App oder ihrem Dienst beheben möchten, sowie an Plattformadministratoren und -betreiber, die Unterbrechungen bei der Bereitstellung von Produkten und Diensten verhindern möchten.

Informationen dazu, wann Cluster Autoscaler Ihre Knoten herunterskaliert

Bevor Sie mit den Schritten zur Fehlerbehebung fortfahren, kann es hilfreich sein, zu verstehen, wann Cluster Autoscaler versucht, Ihre Knoten herunterzustufen. Möglicherweise hat Cluster Autoscaler den Cluster nicht herunterskaliert, weil dies nicht erforderlich war.

Cluster Autoscaler bestimmt, ob ein Knoten nicht ausgelastet ist und herunterskaliert werden kann, indem ein Auslastungsfaktor berechnet wird. Der Auslastungsfaktor wird berechnet, indem die von den Pods auf dem Knoten angeforderten vCPUs und der Arbeitsspeicher durch die zuweisbaren vCPUs und den Arbeitsspeicher auf dem Knoten geteilt werden.

Alle 10 Sekunden prüft Cluster Autoscaler den Auslastungsfaktor Ihrer Knoten, um festzustellen, ob er unter dem erforderlichen Grenzwert liegt. Wenn Sie ein balanced-Autoscaling-Profil verwenden, beträgt der Grenzwert für den Auslastungsfaktor 0,5. Wenn Sie das Profil optimize-utilization verwenden, variiert der Auslastungsfaktor. Wenn der Auslastungsfaktor sowohl für die vCPU als auch für den Arbeitsspeicher unter dem erforderlichen Grenzwert liegt, betrachtet der Cluster Autoscaler den Knoten als nicht ausgelastet.

Wenn ein Knoten nicht ausreichend ausgelastet ist, kennzeichnet Cluster Autoscaler den Knoten zum Entfernen und überwacht ihn die nächsten 10 Minuten, um sicherzustellen, dass der Auslastungsfaktor unter dem erforderlichen Grenzwert bleibt. Wenn der Knoten nach 10 Minuten immer noch nicht ausgelastet ist, sollte Cluster Autoscaler den Knoten entfernen.

Beispiel: Berechnung des Auslastungsfaktors

Sie haben einen Cluster mit aktivierter Cluster-Autoscaling-Funktion und verwenden das Autoscaling-Profil balanced. Ein Knoten in diesem Cluster wird mit dem Maschinentyp e2-standard-4 bereitgestellt, der 4 vCPUs und 16 GB Arbeitsspeicher bietet. Ein Pod auf diesem Knoten benötigt 0, 5 vCPU und 10 GB Arbeitsspeicher.Daher berechnet der Cluster-Autoscaler die folgenden Auslastungsfaktoren:

  • vCPU-Auslastungsfaktor: 0,5 vCPU ÷ 4 vCPUs = 0,125
  • Faktor für die Arbeitsspeicherauslastung: 10 GB ÷ 16 GB = 0,625

In diesem Szenario würde Cluster Autoscaler diesen Knoten nicht als nicht ausgelastet betrachten, da der Faktor für die Speicherauslastung (0,625) den Grenzwert von 0,5 überschreitet. Obwohl die vCPU-Auslastung niedrig ist, verhindert die höhere Arbeitsspeichernutzung das Herunterskalieren, damit für die Arbeitslast des Pods genügend Ressourcen verfügbar bleiben.

Prüfen, ob das Problem durch eine Einschränkung verursacht wird

Wenn Sie einen Cluster mit geringer Auslastung über einen Zeitraum von mehr als 10 Minuten beobachten und er nicht herunterskaliert wird, prüfen Sie, ob das Problem durch eine der Einschränkungen für das Cluster-Autoscaling verursacht wurde.

Fehler ansehen

Wenn das Problem nicht durch eine Einschränkung verursacht wurde, können Sie die Ursache oft anhand von Fehlermeldungen ermitteln:

Fehler in Benachrichtigungen ansehen

Wenn das Problem vor weniger als 72 Stunden aufgetreten ist, können Sie sich Benachrichtigungen zu Fehlern in der Google Cloud Console ansehen. Diese Benachrichtigungen liefern wertvolle Informationen dazu, warum der Cluster Autoscaler nicht herunterskaliert wurde. Außerdem erhalten Sie Tipps zur Fehlerbehebung und können relevante Protokolle zur weiteren Untersuchung aufrufen.

So rufen Sie die Benachrichtigungen in der Google Cloud Console auf:

  1. Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.

    Zur Seite "Kubernetes-Cluster"

  2. Sehen Sie sich die Spalte Benachrichtigungen an. Die folgenden Benachrichtigungen sind mit Problemen beim Herunterskalieren verbunden:

    • Can't scale down nodes
    • Scale down blocked by pod

  3. Klicken Sie auf die entsprechende Benachrichtigung, um einen Bereich mit Details zur Ursache des Problems und empfohlenen Maßnahmen zur Behebung aufzurufen.

  4. Optional: Klicken Sie auf Logs, um die Protokolle für dieses Ereignis aufzurufen. Dadurch gelangen Sie zum Log-Explorer mit einer vorab ausgefüllten Abfrage, mit der Sie das Skalierungsereignis weiter untersuchen können. Weitere Informationen zur Funktionsweise von Ereignissen zum Herunterskalieren finden Sie unter Cluster-Autoscaling-Ereignisse ansehen.

Wenn das Problem auch nach der Lektüre der Tipps in der Benachrichtigung weiterhin besteht, findest du in den Tabellen mit Fehlermeldungen weitere Informationen.

Fehler in Ereignissen ansehen

Wenn das Problem vor mehr als 72 Stunden aufgetreten ist, rufen Sie die Ereignisse in Cloud Logging auf. Wenn ein Fehler aufgetreten ist, wird er häufig in einem Ereignis aufgezeichnet.

So rufen Sie Cluster-Autoscaling-Logs in der Google Cloud Console auf:

  1. Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.

    Zur Seite "Kubernetes-Cluster"

  2. Wählen Sie den Namen des Clusters aus, den Sie untersuchen möchten, um die Seite Clusterdetails aufzurufen.

  3. Klicken Sie auf der Seite Clusterdetails auf den Tab Logs.

  4. Klicken Sie auf dem Tab Logs auf den Tab Autoscaling-Logs, um die Logs aufzurufen.

  5. Optional: Wenn Sie erweiterte Filter anwenden möchten, um die Ergebnisse einzugrenzen, klicken Sie auf die Schaltfläche mit dem Pfeil rechts auf der Seite, um die Logs im Log-Explorer aufzurufen.

Weitere Informationen zur Funktionsweise von Ereignissen zum Herunterskalieren finden Sie unter Cluster-Autoscaling-Ereignisse ansehen. Ein Beispiel für die Verwendung von Cloud Logging finden Sie im Beispiel zur Fehlerbehebung.

Beispiel: Probleme beheben, die älter als 72 Stunden sind

Im folgenden Beispiel wird gezeigt, wie Sie ein Problem untersuchen und beheben können, bei dem ein Cluster nicht herunterskaliert wird.

Szenario:

Vor einer Woche haben Sie sich das GKE Enterprise-Dashboard angesehen und festgestellt, dass Ihr Cluster nur 10 % seiner CPU und seines Arbeitsspeichers genutzt hat. Trotz der geringen Auslastung hat Cluster Autoscaler den Knoten nicht wie erwartet gelöscht. Wenn Sie sich das Dashboard jetzt ansehen, scheint das Problem behoben zu sein. Sie möchten jedoch herausfinden, was passiert ist, damit es nicht noch einmal auftritt.

Prüfung

  1. Da das Problem vor mehr als 72 Stunden aufgetreten ist, untersuchen Sie es mit Cloud Logging, anstatt sich die Benachrichtigungsmeldungen anzusehen.
  2. In Cloud Logging finden Sie die Logging-Details für Cluster Autoscaler-Ereignisse, wie im Abschnitt Fehler in Ereignissen ansehen beschrieben.
  3. Sie suchen im Feld nodesToBeRemoved nach scaleDown-Ereignissen, die die Knoten des untersuchten Clusters enthalten. Sie können die Logeinträge filtern, auch nach einem bestimmten JSON-Feldwert. Weitere Informationen finden Sie unter Erweiterte Logabfragen.
  4. Sie finden keine scaleDown-Ereignisse. Wenn Sie jedoch ein scaleDown-Ereignis gefunden haben, können Sie nach einem eventResult-Ereignis suchen, das die zugehörige eventId enthält. Sie können dann im Feld errorMsg nach einem Fehler suchen.

  5. Sie beschließen, Ihre Untersuchung fortzusetzen, indem Sie nach noScaleDown-Ereignissen suchen, die den untersuchten Knoten im Feld „Knoten“ enthalten.

    Sie finden ein noScaleDown-Ereignis, das einen Grund dafür enthält, dass Ihr Knoten nicht herunterskaliert wurde. Die Nachrichten-ID lautet "no.scale.down.node.pod.not.backed.by.controller" und enthält einen einzigen Parameter: "test-single-pod".

Lösung:

In der Tabelle mit Fehlermeldungen sehen Sie, dass diese Meldung bedeutet, dass der Pod das Herunterskalieren blockiert, da er nicht von einem Controller unterstützt wird. Sie stellen fest, dass sich das Problem durch Hinzufügen der Anmerkung "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" zum Pod lösen lässt. Sie sehen sich test-single-pod an und stellen fest, dass ein Kollege die Anmerkung hinzugefügt hat. Nachdem die Anmerkung angewendet wurde, hat Cluster Autoscaler den Cluster korrekt herunterskaliert. Sie beschließen, die Anmerkung allen anderen Pods hinzuzufügen, bei denen dies sicher möglich ist, um ein erneutes Auftreten des Problems zu vermeiden.

Fehler bei der Herunterskalierung beheben

Nachdem Sie den Fehler identifiziert haben, können Sie anhand der folgenden Tabellen herausfinden, was die Ursache dafür ist und wie Sie ihn beheben können.

ScaleDown-Fehler

Fehlermeldungen für scaleDown-Ereignisse finden Sie im entsprechenden eventResult-Ereignis im Feld resultInfo.results[].errorMsg.

Ereignisnachricht Details Parameter Risikominderung
"scale.down.error.failed.to.mark.to.be.deleted" Ein Knoten konnte nicht zum Löschen markiert werden. Name des fehlgeschlagenen Knotens. Diese Nachricht sollte nur temporär sein. Wenn das Problem weiterhin auftritt, wenden Sie sich an Cloud Customer Care, um weitere Unterstützung zu erhalten.
"scale.down.error.failed.to.evict.pods" Die Cluster-Autoskala kann nicht herunterskalieren, da einige Pods nicht aus einem Knoten entfernt werden konnten. Name des fehlgeschlagenen Knotens. Überprüfen Sie die PodDisruptionBudget für den Pod und achten Sie darauf, dass die Regeln das Entfernen von Anwendungsreplikaten nach Möglichkeit zulassen. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Unterbrechungsbudget für Ihre Anwendung festlegen.
"scale.down.error.failed.to.delete.node.min.size.reached" Cluster Autoscaler kann nicht herunterskalieren, da ein Knoten aufgrund der bereits erreichten Mindestgröße des Clusters nicht gelöscht werden konnte. Name des fehlgeschlagenen Knotens. Prüfen Sie den für Autoscaling von Knotenpools festgelegten Mindestwert und passen Sie die Einstellungen nach Bedarf an. Weitere Informationen finden Sie unter Fehler: Knoten im Cluster haben die Mindestgröße erreicht.

Gründe für ein noScaleDown-Ereignis

Ein noScaleDown-Ereignis wird regelmäßig ausgegeben, wenn Knoten blockiert sind und daher nicht von Cluster Autoscaler gelöscht werden können. noScaleDown-Ereignisse sind Best-Effort-Ereignisse und decken nicht alle potenziellen Fälle ab.

Gründe auf oberster Ebene für "NoScaleDown"

Meldungen mit Gründen auf oberster Ebene für noScaleDown-Ereignisse werden im Feld noDecisionStatus.noScaleDown.reason angezeigt. Die Meldung enthält einen Grund auf oberster Ebene, warum Cluster Autoscaler den Cluster nicht herunterskalieren kann.

Ereignisnachricht Details Risikominderung
"no.scale.down.in.backoff" Cluster Autoscaler kann nicht herunterskalieren, da der Vorgang in einen Backoff-Zeitraum fällt (vorübergehend blockiert ist).

Diese Meldung sollte nur vorübergehend sein und kann auftreten, wenn es in letzter Zeit ein Hochskalierungsereignis gab.

Wenn die Meldung weiterhin angezeigt wird, wenden Sie sich an Cloud Customer Care.
"no.scale.down.in.progress"

Cluster Autoscaler kann nicht herunterskalieren, da noch eine vorherige Herunterskalierung ausgeführt wurde.

 Diese Meldung sollte nur vorübergehend auftreten, da der Pod letztendlich entfernt wird. Wenn diese Meldung häufig angezeigt wird, prüfen Sie den Kulanzzeitraum für die Beendigung der Pods, die das Herunterskalieren verhindern. Wenn das Problem schneller behoben werden soll, können Sie den Pod auch löschen, wenn er nicht mehr benötigt wird.

Gründe auf Knotenebene für "noScaleDown"

Meldungen mit Gründen auf Knotenebene für noScaleDown-Ereignisse werden im noDecisionStatus.noScaleDown.nodes[].reason field angezeigt. Die Meldung enthält einen Grund, warum Cluster Autoscaler einen bestimmten Knoten nicht entfernen kann.

Ereignisnachricht Details Parameter Risikominderung
"no.scale.down.node.scale.down.disabled.annotation" Cluster Autoscaler kann einen Knoten nicht aus dem Knotenpool entfernen, da der Knoten mit cluster-autoscaler.kubernetes.io/scale-down-disabled: true gekennzeichnet ist. – Cluster Autoscaler überspringt Knoten mit dieser Anmerkung, ohne ihre Auslastung zu berücksichtigen. Diese Meldung wird unabhängig vom Auslastungsfaktor des Knotens protokolliert. Wenn der Cluster Autoscaler diese Knoten herunterskalieren soll, entfernen Sie die Anmerkung.
"no.scale.down.node.node.group.min.size.reached"

Cluster Autoscaler kann nicht herunterskalieren, wenn die Größe der Knotengruppe das Mindestgrößenlimit überschritten hat.

Das liegt daran, dass das Entfernen von Knoten gegen die clusterweiten Mindestressourcenlimits verstoßen würde, die in den Einstellungen für die automatische Knotenbereitstellung festgelegt sind.

 – Prüfen Sie den für das Autoscaling von Knotenpools festgelegten Mindestwert. Wenn Sie möchten, dass Cluster Autoscaler diesen Knoten herunterskaliert, passen Sie den Mindestwert an.
"no.scale.down.node.minimal.resource.limits.exceeded"

Cluster Autoscaler kann Knoten nicht herunterskalieren, da dies gegen clusterweite Mindestressourcenlimits verstoßen würde.

Dies sind die Ressourcenlimits, die für die automatische Knotenbereitstellung festgelegt sind.

 – Prüfen Sie die Limits für Arbeitsspeicher und vCPU. Wenn der Cluster-Autoscaler diesen Knoten herunterskalieren soll, erhöhen Sie die Limits.
"no.scale.down.node.no.place.to.move.pods" Cluster Autoscaler kann nicht herunterskaliert werden, da es keinen Ort gibt, an den Pods verschoben werden können. – Wenn Sie davon ausgehen, dass der Pod neu geplant werden sollte, prüfen Sie die Planungsanforderungen der Pods auf dem nicht ausgelasteten Knoten. So können Sie feststellen, ob sie zu einem anderen Knoten im Cluster verschoben werden können. Weitere Informationen finden Sie unter Fehler: Kein Ort zum Verschieben von Pods.
"no.scale.down.node.pod.not.backed.by.controller"

Der Pod blockiert das Herunterskalieren, da er nicht von einem Controller gestützt wird

Insbesondere kann der Cluster Autoscaler einen nicht ausgelasteten Knoten nicht herunterskalieren, da ein Pod keinen erkannten Controller hat. Zu den zulässigen Controllern gehören ReplicationController, DaemonSet, Job, StatefulSet oder ReplicaSet.

 Name des blockierenden Pods. Legen Sie die Annotation "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" für den Pod fest oder definieren Sie einen zulässigen Controller.
"no.scale.down.node.pod.has.local.storage" Der Pod blockiert das Herunterskalieren, da er lokalen Speicher hat. Name des blockierenden Pods. Legen Sie für den Pod eine Annotation "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" fest, wenn die Daten im lokalen Speicher für den Pod nicht kritisch sind. Dieser Fehler tritt nur bei Clustern auf, die eine Version vor 1.22 verwenden.
"no.scale.down.node.pod.not.safe.to.evict.annotation" Ein Pod auf dem Knoten hat die Annotation safe-to-evict=false. Name des blockierenden Pods. Wenn der Pod sicher entfernt werden kann, bearbeiten Sie das Manifest des Pods und aktualisieren Sie die Anmerkung auf "cluster-autoscaler.kubernetes.io/safe-to-evict": "true".
"no.scale.down.node.pod.kube.system.unmovable" Der Pod blockiert das Herunterskalieren, da er ein Nicht-DaemonSet und nicht gespiegelter Pod ohne PodDisruptionBudget im kube-system-Namespace ist. Name des blockierenden Pods.

Standardmäßig werden Pods im Namespace kube-system nicht von Cluster Autoscaler entfernt.

Um dieses Problem zu beheben, fügen Sie entweder eine PodDisruptionBudget für die kube-system-Pods hinzu oder verwenden Sie eine Kombination aus Knotenpoolmarkierungen und -toleranzen, um kube-system-Pods von Ihren Anwendungs-Pods zu trennen. Weitere Informationen finden Sie unter Fehler: kube-system-Pod kann nicht verschoben werden.
"no.scale.down.node.pod.not.enough.pdb" Der Pod blockiert das Herunterskalieren, da nicht genügend PodDisruptionBudget vorhanden ist. Name des blockierenden Pods. Sehen Sie sich die PodDisruptionBudget für den Pod an und machen Sie sie gegebenenfalls weniger restriktiv. Weitere Informationen finden Sie unter Fehler: Nicht genügend PodDisruptionBudget.
"no.scale.down.node.pod.controller.not.found" Der Pod blockiert das Herunterskalieren, da der Controller (z. B. Deployment oder ReplicaSet) nicht gefunden werden kann. – Prüfen Sie die Protokolle, um festzustellen, welche Maßnahmen ergriffen wurden, wodurch ein Pod weiterhin ausgeführt wurde, nachdem der Controller entfernt wurde. Löschen Sie den Pod manuell, um das Problem zu beheben.
"no.scale.down.node.pod.unexpected.error" Der Pod blockiert das Herunterskalieren aufgrund eines unerwarteten Fehlers – Die Ursache dieses Fehlers ist unbekannt. Wenden Sie sich an das Cloud Customer Care-Team, um das Problem genauer untersuchen zu lassen.

Weitere Untersuchungen durchführen

In den folgenden Abschnitten erfahren Sie, wie Sie mit dem Log-Explorer und gcpdiag zusätzliche Informationen zu Ihren Fehlern erhalten.

Fehler im Log-Explorer untersuchen

Wenn Sie die Fehlermeldung genauer untersuchen möchten, können Sie sich spezifische Protokolle für den Fehler ansehen:

  1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.

    Zum Log-Explorer

  2. Geben Sie im Bereich Abfrage die folgende Abfrage ein:

    resource.type="k8s_cluster"
log_id("container.googleapis.com/cluster-autoscaler-visibility")
jsonPayload.resultInfo.results.errorMsg.messageId="ERROR_MESSAGE"

    Ersetzen Sie ERROR_MESSAGE durch die Nachricht, die Sie untersuchen möchten. Beispiel: scale.down.error.failed.to.delete.node.min.size.reached

  3. Klicken Sie auf Abfrage ausführen.

Einige Fehler mit gcpdiag beheben

gcpdiag ist ein Open-Source-Tool, das mit Unterstützung von Google Cloud-Entwicklern erstellt wurde. Es ist kein offiziell unterstütztes Google Cloud-Produkt.

Wenn eine der folgenden Fehlermeldungen angezeigt wird, kannst du gcpdiag verwenden, um das Problem zu beheben:

  • scale.down.error.failed.to.evict.pods
  • no.scale.down.node.node.group.min.size.reached

Eine Liste und Beschreibung aller gcpdiag-Tool-Flags finden Sie in der gcpdiag-Nutzungsanleitung.

Komplexe Fehler beim Skalieren nach unten beheben

In den folgenden Abschnitten finden Sie Anleitungen zur Behebung von Fehlern, bei denen die Behebung mehrere Schritte umfasst, und Fehler, die nicht mit einer Cluster-Autoscaler-Ereignismeldung verknüpft sind.

Fehler: Die Knoten im Cluster haben die Mindestgröße erreicht

Wenn Sie die folgenden Fehler sehen, konnte Cluster Autoscaler keinen Knoten löschen, da die Anzahl der Knoten im Cluster bereits die Mindestgröße erreicht hatte:

Benachrichtigung

Das Herunterskalieren eines nicht ausgelasteten Knotens wird blockiert, da die Mindestressourcenlimits von Cluster Autoscaler erreicht sind.

Ereignis

"scale.down.error.failed.to.delete.node.min.size.reached"

Überprüfen und aktualisieren Sie die Mindestlimits für das Autoscaling, um dieses Problem zu beheben:

  1. Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.

    Zur Seite "Kubernetes-Cluster"

  2. Klicken Sie auf den Namen des Clusters, der in der Benachrichtigung oder in Cloud Logging angegeben ist.

  3. Rufen Sie auf der Seite Clusterdetails den Tab Knoten auf.

  4. Prüfen Sie den Wert in der Spalte Anzahl der Knoten und vergleichen Sie ihn mit der Mindestanzahl von Knoten in der Spalte Autoscaling. Wenn in der Spalte Autoscaling beispielsweise 4 bis 6 Knoten aufgeführt sind und die Anzahl der Knoten im Knotenpool 4 beträgt, entspricht die Anzahl der Knotenpools bereits der Mindestgröße. Cluster Autoscaler kann die Knoten also nicht weiter herunterskalieren.

  5. Wenn die Konfiguration korrekt ist und der Wert für die Anzahl der Knoten dem für das Autoscaling definierten Minimum entspricht, funktioniert der Cluster-Autoscaler wie vorgesehen. Wenn die Mindestanzahl von Knoten für Ihre Anforderungen zu hoch ist, verringern Sie die Mindestgröße, damit die Knoten herunterskaliert werden können.

Fehler: Es gibt keinen Ort, an den Pods verschoben werden können

Die folgenden Fehler treten auf, wenn Cluster Autoscaler versucht, einen Knoten herunterzufahren, dies aber nicht kann, weil ein Pod auf diesem Knoten nicht auf einen anderen Knoten verschoben werden kann:

Benachrichtigung

Das Herunterskalieren eines nicht ausgelasteten Knotens wird blockiert, da er einen Pod enthält, der nicht auf einen anderen Knoten im Cluster verschoben werden kann.

Ereignis

"no.scale.down.node.no.place.to.move.pods"

Wenn Sie nicht möchten, dass dieser Pod neu geplant wird, ist diese Meldung normal und es sind keine Änderungen erforderlich. Wenn der Pod neu geplant werden soll, prüfen Sie die folgenden Definitionen in pod.spec block im Manifest des Pods:

  • NodeAffinity: Prüfen Sie die Planungsanforderungen der Pods auf dem nicht ausgelasteten Knoten. Sie können diese Anforderungen prüfen, indem Sie das Pod-Manifest untersuchen und nach NodeAffinity- oder NodeSelector-Regeln suchen. Wenn für den Pod ein „nodeSelector“ definiert ist und es im Cluster keine anderen Knoten (aus anderen Knotenpools) gibt, die diesem Selector entsprechen, kann Cluster Autoscaler den Pod nicht auf einen anderen Knoten verschieben. Das verhindert wiederum, dass nicht ausgelastete Knoten entfernt werden.
  • maxPodConstraint: Wenn für maxPodConstraint eine andere Zahl als die Standardzahl 110 konfiguriert ist, bestätigen Sie, ob dies eine beabsichtigte Änderung war. Je niedriger dieser Wert ist, desto höher ist die Wahrscheinlichkeit von Problemen. Cluster Autoscaler kann Pods nicht auf andere Knoten umplanen, wenn alle anderen Knoten im Cluster bereits den in maxPodConstraint definierten Wert erreicht haben und kein Platz für neue Pods vorhanden ist. Wenn Sie den Wert für maxPodConstraint erhöhen, können mehr Pods auf Knoten geplant werden. Der Cluster Autoscaler hat dann die Möglichkeit, Pods neu zu planen und nicht ausgelastete Knoten herunterzufahren. Berücksichtigen Sie bei der Definition von maxPodConstraint, dass sich auf jedem Knoten ungefähr 10 System-Pods befinden.
  • hostPort: Wenn Sie für den Pod ein hostPort angeben, kann nur ein Pod auf diesem Knoten ausgeführt werden. Dies kann es für Cluster Autoscaler erschweren, die Anzahl der Knoten zu reduzieren, da der Pod möglicherweise nicht auf einen anderen Knoten verschoben werden kann, wenn der Port dieses Knotens bereits verwendet wird. Das ist ganz normal.

Fehler: kube-system-Pod kann nicht verschoben werden

Die folgenden Fehler treten auf, wenn ein System-Pod das Herunterskalieren verhindert:

Benachrichtigung

Der Pod blockiert das Herunterskalieren, da er ein Nicht-DaemonSet und nicht gespiegelter Pod ohne eine PodDisruptionBudget im kube-system-Namespace ist.

Ereignis

"no.scale.down.node.pod.kube.system.unmovable"

Ein Pod im Namespace kube-system gilt als System-Pod. Standardmäßig entfernt der Cluster-Autoscaler keine Pods im Namespace kube-system.

Wählen Sie eine der folgenden Auflösungen aus, um diesen Fehler zu beheben:

  • Fügen Sie PodDisruptionBudget für die kube-system-Pods hinzu. Weitere Informationen zum manuellen Hinzufügen eines PodDisruptionBudget für die kube-system-Pods finden Sie in den FAQs zum Kubernetes-Cluster-Autoscaling.

    Das Erstellen einer PodDisruptionBudget kann sich auf die Verfügbarkeit von Systemarbeitslasten auswirken und zu Ausfallzeiten im Cluster führen. Cluster Autoscaler plant diese Systemarbeitslasten während des Herunterskalierens auf verschiedenen Worker-Knoten neu.

  • Verwenden Sie eine Kombination aus Knotenpoolmarkierungen und -toleranzen, um kube-system-Pods von Ihren Anwendungs-Pods zu trennen. Weitere Informationen finden Sie unter Automatische Knotenbereitstellung in GKE.

Prüfen, ob die Knoten kube-system Pods haben

Wenn Sie nicht sicher sind, ob auf Ihren Knoten kube-system-Pods ausgeführt werden, führen Sie die folgenden Schritte aus:

  1. Rufen Sie in der Google Cloud Console den Log-Explorer auf.

    Zum Log-Explorer

  2. Klicken Sie auf Query Builder.

  3. Verwenden Sie die folgende Abfrage, um alle Logs der Netzwerkrichtlinien zu finden:

    - resource.labels.location="CLUSTER_LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
logName="projects/PROJECT_ID/logs/container.googleapis.com%2Fcluster-autoscaler-visibility"
jsonPayload.noDecisionStatus.noScaleDown.nodes.node.mig.nodepool="NODE_POOL_NAME"

    Dabei gilt:

    • CLUSTER_LOCATION ist die Region, in der sich der Cluster befindet.
    • CLUSTER_NAME ist der Name Ihres Clusters.
    • PROJECT_ID: die ID des Projekts, zu dem Ihr Cluster gehört.
    • NODE_POOL_NAME ist der Name des Knotenpools.

    Wenn in Ihrem Knotenpool kube-system-Pods ausgeführt werden, enthält die Ausgabe Folgendes:

    "no.scale.down.node.pod.kube.system.unmovable"

Fehler: Nicht genügend PodDisruptionBudget

Die folgenden Fehler treten auf, wenn Ihre PodDisruptionBudget das Herunterskalieren verhindert:

Benachrichtigung

Das Herunterskalieren eines nicht ausgelasteten Knotens wird blockiert, da ein Pod darauf ausgeführt wird, der nicht genügend PodDisruptionBudget hat, um die Entfernung des Pods zuzulassen.

Ereignis

NoScaleDownNodePodNotEnoughPdb: "no.scale.down.node.pod.not.enough.pdb"

Prüfen Sie die Einstellungen einer PodDisruptionBudget, um festzustellen, ob sie zu restriktiv ist:

kubectl get pdb --all-namespaces

Die Ausgabe sieht in etwa so aus:

NAMESPACE        NAME    MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
example-app-one  one_pdb       N/A             1                 1               12d
example-app-two  two_pdb       N/A             0                 0               12d

In diesem Beispiel werden keine Pods, die mit der Labelauswahl two_pdb übereinstimmen, von Cluster Autoscaler entfernt. Die Einstellung maxUnavailable: 0 in dieser PodDisruptionBudget legt fest, dass alle Replikate jederzeit verfügbar sein müssen. Außerdem verbietet disruptionsAllowed: 0 Unterbrechungen dieser Pods. Daher können Knoten, auf denen diese Pods ausgeführt werden, nicht herunterskaliert werden, da dies zu einer Unterbrechung führen und gegen die PodDisruptionBudget verstoßen würde.

Wenn Ihre PodDisruptionBudget wie gewünscht funktioniert, sind keine weiteren Maßnahmen erforderlich. Wenn Sie Ihre PodDisruptionBudget so anpassen möchten, dass Pods auf einem nicht optimal genutzten Knoten verschoben werden können, bearbeiten Sie das Manifest des PodDisruptionBudgets. Wenn Sie beispielsweise maxUnavailable auf 0 festgelegt haben, können Sie sie in 1 ändern, damit der Cluster-Autoscaler herunterskalieren kann.

Problem: Knoten bleibt im Status „Abgesichert“ und wird nicht entfernt

Fehler ähnlich dem folgenden treten auf, wenn der Cluster Autoscaler die Knotenpoolgröße nicht reduzieren kann, weil das Google-Dienstkonto nicht die Rolle Bearbeiter hat:

Required 'compute.instanceGroups.update' permission for 'INSTANCE_GROUP_NAME'.

Ein häufiges Symptom dieses Problems ist, dass der Cluster Autoscaler versucht, die Größe des Knotenpools zu verringern, der Status des Knotens sich aber nicht ändert.

Prüfen Sie, ob das Standarddienstkonto (PROJECT_NUMBER@cloudservices.gserviceaccount.com) die Rolle „Bearbeiter“ (roles/editor) für das Projekt hat. Wenn das Dienstkonto diese Rolle nicht hat, fügen Sie sie hinzu. GKE verwendet dieses Dienstkonto, um die Ressourcen Ihres Projekts zu verwalten. Eine Anleitung dazu finden Sie in der IAM-Dokumentation unter Einzelne Rolle zuweisen oder widerrufen.

Nächste Schritte