Fehlerbehebung, wenn der Cluster-Autoscaler nicht herunterskaliert

Wenn Ihre Google Kubernetes Engine-Knoten (GKE) nicht wie erwartet skaliert werden, liegt das häufig daran, dass der Cluster-Autoscaler sie nicht entfernen kann. Dies führt zu unnötigen Kosten und einer ineffizienten Ressourcennutzung.

Auf dieser Seite erfahren Sie, wie Sie häufige Probleme diagnostizieren und beheben, die das Herunterskalieren von Clustern durch den Autoscaler verhindern. Wenn Sie diese Probleme beheben, können Sie sicherstellen, dass Ihr Cluster kostengünstig arbeitet und sich an Änderungen der Arbeitslast anpasst.

Diese Informationen sind wichtig für Plattformadministratoren und ‑operatoren, die für die Clustereffizienz, Kostenoptimierung und Ressourcenverwaltung verantwortlich sind. Anwendungsentwickler benötigen diese Informationen möglicherweise auch, wenn ihre Arbeitslastkonfigurationen (z. B. PodDisruptionBudgets oder Knotenselektoren) unbeabsichtigt verhindern, dass Knoten entfernt werden. Weitere Informationen zu den gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Informationen dazu, wann der Cluster-Autoscaler Ihre Knoten herunterskaliert

Bevor Sie mit der Fehlerbehebung fortfahren, kann es hilfreich sein, zu verstehen, wann Cluster Autoscaler versucht, Ihre Knoten herunterzuskalieren. Es kann sein, dass Cluster Autoscaler nicht herunterskaliert hat, weil dies nicht erforderlich war.

Cluster Autoscaler ermittelt, ob ein Knoten unterlastet ist und für das Herunterskalieren infrage kommt, indem er einen Auslastungsfaktor berechnet. Der Auslastungsfaktor wird berechnet, indem die von den Pods auf dem Knoten angeforderten vCPU und der Arbeitsspeicher durch die zuweisbaren vCPU und den Arbeitsspeicher auf dem Knoten dividiert werden.

Cluster Autoscaler prüft alle 10 Sekunden den Auslastungsfaktor Ihrer Knoten, um festzustellen, ob er unter dem erforderlichen Schwellenwert 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 vCPU als auch für Arbeitsspeicher unter dem erforderlichen Schwellenwert liegt, betrachtet der Cluster Autoscaler den Knoten als unterlastet.

Wenn ein Knoten unterlastet ist, markiert Cluster Autoscaler den Knoten zum Entfernen und überwacht ihn in den nächsten 10 Minuten, um sicherzustellen, dass der Auslastungsfaktor unter dem erforderlichen Schwellenwert 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 aktiviertem Cluster Autoscaler 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 fordert 0, 5 vCPU und 10 GB Arbeitsspeicher an.Cluster Autoscaler berechnet daher 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 unterlastet betrachten, da der Speicherauslastungsfaktor (0,625) den Grenzwert von 0,5 überschreitet. Obwohl die vCPU-Auslastung niedrig ist, wird durch die höhere Speichernutzung ein Herunterskalieren verhindert, damit genügend Ressourcen für die Arbeitslast des Pods 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 skaliert wird, prüfen Sie, ob das Problem durch eine der Einschränkungen für das Cluster-Autoscaling verursacht wird.

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, das Sie beobachtet haben, vor weniger als 72 Stunden aufgetreten ist, sehen Sie sich die Benachrichtigungen zu Fehlern in der Google Cloud -Konsole an. Diese Benachrichtigungen liefern wertvolle Informationen dazu, warum Cluster Autoscaler nicht herunterskaliert wurde, und bieten Ratschläge, wie Sie den Fehler beheben und relevante Logs für weitere Untersuchungen ansehen können.

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

  1. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster auf.

    Zur Seite "Kubernetes-Cluster"

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

    • 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 Empfehlungen zur Behebung aufzurufen.

  4. Optional: Klicken Sie auf Logs, um die Protokolle für dieses Ereignis aufzurufen. Sie werden zum Log-Explorer weitergeleitet, wo eine Abfrage vorab ausgefüllt ist, mit der Sie das Skalierungsereignis weiter untersuchen können. Weitere Informationen zur Funktionsweise von Herunterskalierungsereignissen finden Sie unter Cluster-Autoscaling-Ereignisse ansehen.

Wenn nach dem Lesen der Hinweise in der Benachrichtigung weiterhin Probleme auftreten, sehen Sie in den Tabellen mit Fehlermeldungen nach.

Fehler in Ereignissen ansehen

Wenn das Problem, das Sie beobachtet haben, vor mehr als 72 Stunden aufgetreten ist, sehen Sie sich die Ereignisse in Cloud Logging an. Wenn ein Fehler aufgetreten ist, wird er oft 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 Kubernetes-Cluster 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 zu Herunterskalierungsereignissen finden Sie unter Cluster-Autoscaling-Ereignisse ansehen. Ein Beispiel für die Verwendung von Cloud Logging finden Sie im folgenden Beispiel für die Fehlerbehebung.

Beispiel: Ein Problem beheben, das älter als 72 Stunden ist

Das folgende Beispiel zeigt, wie Sie ein Problem mit einem Cluster, der nicht skaliert wird, untersuchen und beheben können.

Szenario:

Vor einer Woche haben Sie sich das GKE-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 aber 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 Benachrichtigungen anzusehen.
  2. In Cloud Logging finden Sie die Logging-Details für Cluster Autoscaler-Ereignisse, wie unter Fehler in Ereignissen ansehen beschrieben.
  3. Suchen Sie nach scaleDown-Ereignissen, die die Knoten des Clusters, den Sie untersuchen, im Feld nodesToBeRemoved 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 und nach noScaleDown-Ereignissen zu suchen, die den Knoten, den Sie untersuchen, im Feld „nodes“ enthalten.

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

Lösung:

Sie sehen in der Tabelle mit Fehlermeldungen nach und stellen fest, dass diese Meldung bedeutet, dass der Pod das Herunterskalieren blockiert, weil er nicht von einem Controller gestützt wird. Sie finden heraus, dass eine Lösung darin besteht, dem Pod die Anmerkung "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" hinzuzufügen. Sie untersuchen test-single-pod 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 Annotation allen anderen Pods hinzuzufügen, bei denen dies sicher ist, um das Problem in Zukunft zu vermeiden.

Fehler bei der Herunterskalierung beheben

Nachdem Sie den Fehler identifiziert haben, können Sie anhand der folgenden Tabellen die Ursache des Fehlers und die Vorgehensweise zur Behebung ermitteln.

ScaleDown-Fehler

Fehlerereignismeldungen 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 Meldung sollte nur temporär sein. Wenn sie weiterhin angezeigt wird, wenden Sie sich an Cloud Customer Care, um weitere Unterstützung zu erhalten.
"scale.down.error.failed.to.evict.pods" Cluster Autoscaler kann nicht herunterskalieren, da einige Pods nicht aus einem Knoten entfernt werden konnten. Name des fehlgeschlagenen Knotens. Überprüfen Sie das 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 dieser Vorgang in einen Backoff-Zeitraum fällt (vorübergehend blockiert ist).

Diese Meldung sollte nur vorübergehend sein und kann auftreten, wenn in letzter Zeit hochskaliert wurde.

Wenn die Meldung weiterhin angezeigt wird, wenden Sie sich an Cloud Customer Care, um das Problem untersuchen zu lassen.
"no.scale.down.in.progress"

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

 Diese Meldung sollte nur temporär sein, 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 Annotation, ohne ihre Auslastung zu berücksichtigen. Diese Meldung wird unabhängig vom Auslastungsfaktor des Knotens protokolliert. Wenn Cluster Autoscaler diese Knoten herunterskalieren soll, entfernen Sie die Annotation.
"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 Cluster Autoscaler diesen Knoten herunterskalieren soll, verringern Sie die Limits.
"no.scale.down.node.no.place.to.move.pods" Cluster Autoscaler kann nicht herunterskalieren, 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.

Cluster Autoscaler kann einen nicht ausgelasteten Knoten vor allem 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.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 Annotation 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.

In GKE-Versionen vor 1.32.4-gke.1236000 entfernt Cluster Autoscaler keine Pods im Namespace kube-system. Ab Version 1.32.4-gke.1236000 berücksichtigt der Cluster Autoscaler diese Pods nach einer Stunde nach der Erstellung für das Entfernen.

Um dieses Problem zu beheben, fügen Sie entweder ein 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 das PodDisruptionBudget für den Pod an und stellen Sie es gegebenenfalls weniger restriktiv ein. 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 Logs, um festzustellen, welche Maßnahmen ergriffen wurden, durch die 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 finden Sie Informationen dazu, wie Sie den Log-Explorer und gcpdiag verwenden können, um zusätzliche Informationen zu Ihren Fehlern zu erhalten.

Fehler im Log-Explorer untersuchen

Wenn Sie die Fehlermeldung genauer untersuchen möchten, können Sie die entsprechenden Logs aufrufen:

  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 technischen Experten von Google Cloudentwickelt wurde. Es ist kein offiziell unterstütztes Google Cloud -Produkt.

Wenn eine der folgenden Fehlermeldungen angezeigt wird, können Sie 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 Herunterskalieren beheben

Die folgenden Abschnitte enthalten Anleitungen zum Beheben von Fehlern, bei denen die Maßnahmen mehrere Schritte umfassen, und von Fehlern, denen keine Cluster-Autoscaler-Ereignismeldung zugeordnet ist.

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

Wenn Sie die folgenden Fehler sehen, konnte Cluster Autoscaler einen Knoten nicht 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 für Cluster Autoscaler erreicht sind.

Ereignis

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

So beheben Sie das Problem:

  1. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster 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 der Knoten, die in der Spalte Autoscaling aufgeführt ist. Wenn beispielsweise in der Spalte Autoscaling 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 Autoscaling definierten Mindestwert entspricht, funktioniert Cluster Autoscaler wie vorgesehen. Wenn die Mindestanzahl von Knoten für Ihre Anforderungen zu hoch ist, reduzieren Sie die Mindestgröße, damit die Knoten herunterskaliert werden können.

Fehler: Kein Ort zum Verschieben von Pods

Die folgenden Fehler treten auf, wenn Cluster Autoscaler versucht, einen Knoten herunterzuskalieren, dies aber nicht möglich ist, 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 Nachricht zu erwarten und es sind keine Änderungen erforderlich. Wenn Sie möchten, dass der Pod neu geplant wird, untersuchen 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 keine anderen Knoten (aus anderen Knotenpools) im Cluster gibt, die diesem Selektor entsprechen, kann Cluster Autoscaler den Pod nicht auf einen anderen Knoten verschieben. Dadurch wird verhindert, dass nicht ausgelastete Knoten entfernt werden.
  • maxPodConstraint: Wenn maxPodConstraint auf eine andere Zahl als die Standardzahl 110 konfiguriert ist, prüfen Sie, ob dies eine beabsichtigte Änderung war. Wenn Sie diesen Wert verringern, steigt die Wahrscheinlichkeit von Problemen. Cluster Autoscaler kann Pods nicht auf anderen Knoten neu planen, wenn alle anderen Knoten im Cluster bereits den in maxPodConstraint definierten Wert erreicht haben und somit kein Platz für die Planung neuer Pods vorhanden ist. Wenn Sie den Wert von maxPodConstraint erhöhen, können mehr Pods auf Knoten geplant werden. Der Cluster Autoscaler hat dann mehr Spielraum, um Pods neu zu planen und unterlastete Knoten herunterzuskalieren. Berücksichtigen Sie beim Definieren von maxPodConstraint, dass auf jedem Knoten etwa 10 System-Pods vorhanden sind.
  • hostPort: Wenn Sie eine hostPort für den Pod angeben, kann nur ein Pod auf diesem Knoten ausgeführt werden. Dies kann es Cluster Autoscaler erschweren, die Anzahl der Knoten zu verringern, 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.
  • Sitzungsspezifischer Speicher: Pods verwenden sitzungsspezifischen Speicher für temporäre Daten. Unzureichender flüchtiger Speicher auf Knoten kann die Pod-Planung behindern und das Herunterskalieren nicht ausgelasteter Knoten verhindern. Beispiel: Ein Pod, der 6 GB sitzungsspezifischen Speicher benötigt, kann nicht auf Knoten mit weniger als 6 GB freiem sitzungsspezifischen Speicher geplant werden, auch wenn sie über genügend CPU- und Arbeitsspeicherressourcen verfügen. Um die Einschränkungen des sitzungsspezifischen Speichers zu umgehen, erhöhen Sie die bereitgestellte Kapazität des sitzungsspezifischen Speichers für Ihre Knoten. So ist ausreichend Kapazität für die Verlagerung und Skalierung von Pods vorhanden.

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"

Pods im Namespace kube-system gelten als System-Pods. In GKE-Version 1.32.4-gke.1236000 und höher kann der Cluster Autoscaler Knoten herunterskalieren, indem er System-Pods entfernt, die seit mindestens einer Stunde ausgeführt werden. In früheren GKE-Versionen entfernt Cluster Autoscaler keine Pods im Namespace kube-system, was das Herunterskalieren auf unbestimmte Zeit verhindern kann.

Wählen Sie eine der folgenden Optionen, 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 eines 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 Herunterskalierungsprozesses auf anderen 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 Knoten kube-system-Pods haben

Wenn Sie nicht sicher sind, ob auf Ihren Knoten kube-system-Pods ausgeführt werden, und dies überprüfen möchten, führen Sie die folgenden Schritte aus:

  1. Rufen Sie in der Google Cloud Console die Seite 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 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"

So prüfen Sie, ob die Einstellungen eines PodDisruptionBudget zu restriktiv sind:

kubectl get pdb --all-namespaces

Die Ausgabe sieht 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 alle Pods, die mit der Labelauswahl two_pdb übereinstimmen, nicht von Cluster Autoscaler entfernt. Die Einstellung maxUnavailable: 0 in diesem PodDisruptionBudget gibt vor, dass alle Replikate jederzeit verfügbar sein müssen. Außerdem sind gemäß disruptionsAllowed: 0 Unterbrechungen dieser Pods verboten. Folglich 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, müssen Sie nichts weiter tun. Wenn Sie Ihre PodDisruptionBudget so anpassen möchten, dass Pods auf einem nicht optimal genutzten Knoten verschoben werden können, bearbeiten Sie das Manifest der PodDisruptionBudget. Wenn Sie beispielsweise maxUnavailable auf 0 festgelegt haben, können Sie es in 1 ändern, damit Cluster Autoscaler herunterskalieren kann.

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

Fehler wie der folgende treten auf, wenn Cluster Autoscaler die Größe des Knotenpools 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, wenn Cluster Autoscaler versucht, die Knotenpoolgröße zu verringern, der Status des Knotens sich jedoch nicht ändert.

Prüfen Sie, ob dem Standarddienstkonto (PROJECT_NUMBER@cloudservices.gserviceaccount.com) die Rolle „Bearbeiter“ (roles/editor) für das Projekt zugewiesen ist. 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