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:
Wenn Sie bereits eine Fehlermeldung erhalten haben, finden Sie in der Tabelle mit Fehlermeldungen Tipps zum Beheben des Fehlers.
Wenn Sie noch keine Meldung erhalten haben, haben Sie folgende Möglichkeiten:
- Probleme, die vor weniger als 72 Stunden aufgetreten sind: Fehlerbenachrichtigungen in der Google Cloud Console ansehen
- Probleme, die älter als 72 Stunden sind: Fehler in Ereignissen in Cloud Logging ansehen
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:
Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.
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
Klicken Sie auf die entsprechende Benachrichtigung, um einen Bereich mit Details zur Ursache des Problems und empfohlenen Maßnahmen zur Behebung aufzurufen.
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:
Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.
Wählen Sie den Namen des Clusters aus, den Sie untersuchen möchten, um die Seite Clusterdetails aufzurufen.
Klicken Sie auf der Seite Clusterdetails auf den Tab Logs.
Klicken Sie auf dem Tab Logs auf den Tab Autoscaling-Logs, um die Logs aufzurufen.
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
- Da das Problem vor mehr als 72 Stunden aufgetreten ist, untersuchen Sie es mit Cloud Logging, anstatt sich die Benachrichtigungsmeldungen anzusehen.
- In Cloud Logging finden Sie die Logging-Details für Cluster Autoscaler-Ereignisse, wie im Abschnitt Fehler in Ereignissen ansehen beschrieben.
- Sie suchen im Feld
nodesToBeRemoved
nachscaleDown
-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. - Sie finden keine
scaleDown
-Ereignisse. Wenn Sie jedoch einscaleDown
-Ereignis gefunden haben, können Sie nach einemeventResult
-Ereignis suchen, das die zugehörigeeventId
enthält. Sie können dann im FelderrorMsg
nach einem Fehler suchen. 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 Um dieses Problem zu beheben, fügen Sie entweder eine PodDisruptionBudget für die |
"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:
Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.
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
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:
Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.
Klicken Sie auf den Namen des Clusters, der in der Benachrichtigung oder in Cloud Logging angegeben ist.
Rufen Sie auf der Seite Clusterdetails den Tab Knoten auf.
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.
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ürmaxPodConstraint
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 inmaxPodConstraint
definierten Wert erreicht haben und kein Platz für neue Pods vorhanden ist. Wenn Sie den Wert fürmaxPodConstraint
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 vonmaxPodConstraint
, dass sich auf jedem Knoten ungefähr 10 System-Pods befinden.hostPort
: Wenn Sie für den Pod einhostPort
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 diekube-system
-Pods hinzu. Weitere Informationen zum manuellen Hinzufügen einesPodDisruptionBudget
für diekube-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:
Rufen Sie in der Google Cloud Console den Log-Explorer auf.
Klicken Sie auf Query Builder.
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
Weitere Informationen finden Sie in den FAQs zum Kubernetes-Cluster-Autoscaling:
In diesem YouTube-Video erfahren Sie, wie Sie Fehler und Skalierungsprobleme beheben.
Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.