Auf dieser Seite erfahren Sie, wie Sie Probleme erkennen und beheben, wenn der Cluster-Autoskalator keine Knoten in Ihren Google Kubernetes Engine-Clustern (GKE) hochskaliert.
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 hochskaliert
Bevor Sie mit den Schritten zur Fehlerbehebung fortfahren, kann es hilfreich sein, zu verstehen, wann Cluster Autoscaler versucht, Ihre Knoten zu skalieren. Cluster Autoscaler fügt nur Knoten hinzu, wenn die vorhandenen Ressourcen nicht ausreichen.
Alle 10 Sekunden prüft Cluster Autoscaler, ob es Pods gibt, die nicht planbar sind. Ein Pod kann nicht mehr geplant werden, wenn der Kubernetes-Planer ihn aufgrund unzureichender Ressourcen, Knotenbeschränkungen oder nicht erfüllter Podanforderungen nicht auf einem vorhandenen Knoten platzieren kann.
Wenn Cluster Autoscaler nicht planbare Pods findet, wird geprüft, ob der Pod durch Hinzufügen eines Knotens geplant werden kann. Wenn durch das Hinzufügen eines Knotens ein Pod geplant werden kann, fügt der Cluster Autoscaler der verwalteten Instanzgruppe (MIG) einen neuen Knoten hinzu. Der Kubernetes-Planer kann den Pod dann auf dem neu bereitgestellten Knoten planen.
Prüfen, ob nicht planbare Pods vorhanden sind
Prüfen Sie, ob nicht geplante Pods vorhanden sind, um festzustellen, ob Ihr Cluster skaliert werden muss:
Rufen Sie in der Google Cloud Console die Seite Arbeitslasten auf.
Geben Sie im Feld
Filter den Wertunschedulable
ein und drücken Sie die Eingabetaste.Wenn Pods aufgeführt sind, sind Pods vorhanden, die nicht geplant werden können. Informationen zur Fehlerbehebung bei nicht planbaren Pods finden Sie unter Fehler: Pod nicht planbar. Wenn Sie die zugrunde liegende Ursache für nicht planbare Pods beheben, kann der Cluster Autoscaler oft hochskaliert werden. In den folgenden Abschnitten erfahren Sie, wie Sie Fehler, die speziell für Cluster Autoscaler gelten, identifizieren und beheben.
Wenn keine Pods aufgeführt sind, muss Cluster Autoscaler nicht hochskalieren und funktioniert wie erwartet.
Prüfen, ob Sie zuvor nicht planbare Pods hatten
Wenn Sie herausfinden möchten, was in der Vergangenheit zu einem Fehler bei Cluster Autoscaler geführt hat, prüfen Sie, ob zuvor nicht planbare Pods vorhanden sind:
Rufen Sie in der Google Cloud -Konsole die Seite Log-Explorer auf.
Geben Sie einen Zeitraum für die Logeinträge an, die Sie sich ansehen möchten.
Geben Sie im Bereich „Abfrage“ die folgende Abfrage ein:
logName="projects/PROJECT_ID/logs/events" jsonPayload.source.component="default-scheduler" jsonPayload.reason="FailedScheduling"
Ersetzen Sie
PROJECT_ID
durch Ihre Projekt-ID.Klicken Sie auf Abfrage ausführen.
Wenn Ergebnisse aufgeführt sind, gab es im angegebenen Zeitraum nicht planbare Pods.
Prüfen, ob das Problem durch eine Einschränkung verursacht wird
Nachdem Sie bestätigt haben, dass Sie nicht geplante Pods haben, prüfen Sie, ob das Problem mit dem Cluster-Autoscaler durch eine der Einschränkungen für das Cluster-Autoscaling verursacht wurde.
Fehler ansehen
Die Ursache von Problemen beim Skalieren lässt sich 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: Sie können sich 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 -Konsole ansehen. Diese Benachrichtigungen liefern wertvolle Informationen dazu, warum der Cluster Autoscaler nicht hochskaliert 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 -Konsole die Seite Kubernetes-Cluster auf.
Sehen Sie sich die Spalte Benachrichtigungen an. Die folgenden Benachrichtigungen beziehen sich auf Probleme beim Skalieren:
Can't scale up
Can't scale up pods
Can't scale up a node pool
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 für das Hochskalieren finden Sie unter Cluster Autoscaler-Ereignisse ansehen.
Wenn die Probleme auch nach der Lektüre der Tipps in der Benachrichtigung weiterhin auftreten, finden Sie 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 -Konsole die Seite Kubernetes-Cluster 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 für das vertikale Hochskalieren 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 mit einem Cluster untersuchen und beheben können, der nicht skaliert wird.
Szenario: Seit einer Stunde wird ein Pod als nicht planbar angezeigt. Cluster Autoscaler hat keine neuen Knoten für die Planung des Pods bereitgestellt.
Lösung:
- 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
triggeringPods
nachscaleUp
-Ereignissen, die den untersuchten Pod enthalten. Sie können die Logeinträge filtern, auch nach einem bestimmten JSON-Feldwert. Weitere Informationen finden Sie unter Erweiterte Logabfragen.Sie finden keine Ereignisse für die Skalierung. Falls ja, können Sie versuchen, nach einem
EventResult
zu suchen, das dieselbeeventId
wie dasscaleUp
-Ereignis enthält. Sehen Sie sich dann das FelderrorMsg
an und konsultieren Sie die Liste der potenziellen scaleUp-Fehlermeldungen.Da Sie keine
scaleUp
-Ereignisse gefunden haben, suchen Sie weiter nachnoScaleUp
-Ereignissen und prüfen Sie die folgenden Felder:unhandledPodGroups
: enthält Informationen zum Pod (oder zum Controller des Pods).reason
: gibt globale Gründe an, warum das Hochskalieren möglicherweise blockiert wird.skippedMigs
: gibt Gründe an, warum einige MIGs möglicherweise übersprungen werden.
Sie finden ein
noScaleUp
-Ereignis für Ihren Pod und alle MIGs im FeldrejectedMigs
haben dieselbe Grundmeldungs-ID"no.scale.up.mig.failing.predicate"
mit den beiden Parametern"NodeAffinity"
und"node(s) did not match node selector"
.
Lösung:
In der Liste der Fehlermeldungen sehen Sie, dass Cluster Autoscaler einen Knotenpool aufgrund eines fehlgeschlagenen Planungsprädikats für die ausstehenden Pods nicht hochskalieren kann. Die Parameter geben den Namen des fehlgeschlagenen Prädikats und den jeweiligen Grund an.
Zum Beheben des Problems prüfen Sie das Manifest des Pods und stellen fest, dass es einen Knotenselektor enthält, der keiner MIG im Cluster entspricht. Sie löschen den Selektor aus dem Manifest des Pods und erstellen den Pod neu. Cluster Autoscaler fügt einen neuen Knoten hinzu und der Pod wird geplant.
Fehler beim Skalieren 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.
ScaleUp-Fehler
Ereignisfehlermeldungen für scaleUp
-Ereignisse finden Sie im entsprechenden eventResult
-Ereignis im Feld resultInfo.results[].errorMsg
.
Meldung | Details | Parameter | Risikominderung |
---|---|---|---|
"scale.up.error.out.of.resources" |
Ressourcenfehler treten auf, wenn Sie versuchen, neue Ressourcen in einer Zone anzufordern, die aufgrund der aktuellen Nichtverfügbarkeit einer Compute Engine-Ressource (z. B. GPUs oder CPUs) Ihre Anfrage nicht bearbeiten kann. | IDs der fehlgeschlagenen MIGs. | Folgen Sie der Fehlerbehebung für die Ressourcenverfügbarkeit in der Compute Engine-Dokumentation. |
"scale.up.error.quota.exceeded" |
Das scaleUp-Ereignis ist fehlgeschlagen, da einige MIGs aufgrund eines überschrittenen Compute Engine-Kontingents nicht erhöht werden konnten. | IDs der fehlgeschlagenen MIGs. | Auf dem Tab Fehler der MIG in der Google Cloud -Console können Sie sehen, welches Kontingent überschritten wird. Wenn Sie wissen, welches Kontingent überschritten wird, folgen Sie der Anleitung, um eine Kontingenterhöhung anzufordern. |
"scale.up.error.waiting.for.instances.timeout" |
Das Hochskalieren der verwalteten Instanzgruppe ist aufgrund einer Zeitüberschreitung fehlgeschlagen. | IDs der fehlgeschlagenen MIGs. | 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.up.error.ip.space.exhausted" |
Hochskalieren nicht möglich, da Instanzen in einigen der verwalteten Instanzgruppen keine IP-Adressen mehr zur Verfügung hatten. Das bedeutet, dass der Cluster nicht genügend nicht zugewiesenen IP-Adressbereich hat, um neue Knoten oder Pods hinzuzufügen. | IDs der fehlgeschlagenen MIGs. | Folgen Sie der Anleitung unter Zu wenig freier IP-Adressbereich für Pods. |
"scale.up.error.service.account.deleted" |
Hochskalieren nicht möglich, da das Dienstkonto gelöscht wurde. | IDs der fehlgeschlagenen MIGs. | Versuchen Sie, das Dienstkonto wiederherzustellen. Wenn das nicht funktioniert, wenden Sie sich an Cloud Customer Care, um das Problem weiter untersuchen zu lassen. |
Gründe für ein noScaleUp-Ereignis
Ein noScaleUp
-Ereignis wird regelmäßig ausgegeben, wenn der Cluster nicht planbare Pods enthält und von Cluster Autoscaler nicht hochskaliert werden kann, um die Pods zu planen. noScaleUp
-Ereignisse sind Best-Effort-Ereignisse und decken nicht alle potenziellen Fälle ab.
Gründe auf oberster Ebene für "NoScaleUp"
Meldungen mit Gründen auf oberster Ebene für noScaleUp
-Ereignisse werden im Feld noDecisionStatus.noScaleUp.reason
angezeigt. Die Meldung enthält einen Grund auf oberster Ebene, warum Cluster Autoscaler den Cluster nicht hochskalieren kann.
Meldung | Details | Risikominderung |
---|---|---|
"no.scale.up.in.backoff" |
Hochskalieren nicht möglich, da der Vorgang in einen Backoff-Zeitraum fällt (vorübergehend blockiert ist). Diese Meldung kann während einer vertikalen Skalierung mit einer großen Anzahl von Pods auftreten. | Diese Meldung sollte nur temporär sein. Prüfen Sie diesen Fehler nach einigen Minuten noch einmal. Wenn diese Meldung weiterhin angezeigt wird, wenden Sie sich an Cloud Customer Care, um das Problem untersuchen zu lassen. |
Gründe auf oberster Ebene für "noScaleUp" in Bezug auf die automatische Knotenbereitstellung
Meldungen mit Gründen auf oberster Ebene für noScaleUp
-Ereignisse in Bezug auf die automatische Knotenbereitstellung werden im Feld noDecisionStatus.noScaleUp.napFailureReason
angezeigt. Die Meldung enthält einen Grund auf oberster Ebene, warum Cluster Autoscaler keine neuen Knotenpools bereitstellen kann.
Meldung | Details | Risikominderung |
---|---|---|
"no.scale.up.nap.disabled" |
Die automatische Knotenbereitstellung konnte nicht hochskaliert werden, da sie auf Clusterebene nicht aktiviert ist. Wenn die automatische Knotenbereitstellung deaktiviert ist, werden neue Knoten nicht automatisch bereitgestellt, wenn der ausstehende Pod Anforderungen hat, die von vorhandenen Knotenpools nicht erfüllt werden können. |
Prüfen Sie die Clusterkonfiguration und lesen Sie den Abschnitt Automatische Knotenbereitstellung aktivieren. |
Gründe auf MIG-Ebene für "noScaleUp"
Meldungen mit Gründen auf MIG-Ebene für noScaleUp
-Ereignisse werden in den Feldern noDecisionStatus.noScaleUp.skippedMigs[].reason
und noDecisionStatus.noScaleUp.unhandledPodGroups[].rejectedMigs[].reason
angezeigt.
Die Meldung enthält einen Grund, warum Cluster Autoscaler die Größe einer bestimmten MIG nicht erhöhen kann.
Meldung | Details | Parameter | Risikominderung |
---|---|---|---|
"no.scale.up.mig.skipped" |
Eine MIG kann nicht hochskaliert werden, da sie während der Simulation übersprungen wurde. | Gründe, warum die MIG übersprungen wurde (z. B. fehlende Pod-Anforderung). | Prüfen Sie die in der Fehlermeldung enthaltenen Parameter und geben Sie an, warum die MIG übersprungen wurde. |
"no.scale.up.mig.failing.predicate" |
Hochskalieren eines Knotenpools aufgrund eines fehlgeschlagenen Planungsprädikats für die ausstehenden Pods nicht möglich. | Name des fehlgeschlagenen Prädikats und Gründe für den Fehler. | Überprüfen Sie sowohl Pod-Anforderungen wie Affinitätsregeln, Markierungen oder Toleranzen als auch Ressourcenanforderungen. |
Gründe auf Pod-Gruppenebene für "noScaleUp" in Bezug auf die automatische Knotenbereitstellung
Meldungen mit Gründen auf Pod-Gruppenebene für noScaleUp
-Ereignisse in Bezug auf die automatische Knotenbereitstellung werden im Feld noDecisionStatus.noScaleUp.unhandledPodGroups[].napFailureReasons[]
angezeigt. Die Meldung enthält einen Grund, warum Cluster Autoscaler keinen neuen Knotenpool zur Planung einer bestimmten Pod-Gruppe bereitstellen kann.
Meldung | Details | Parameter | Risikominderung |
---|---|---|---|
"no.scale.up.nap.pod.gpu.no.limit.defined" |
Die automatische Knotenbereitstellung konnte keine Knotengruppe bereitstellen, da ein ausstehender Pod eine GPU-Anfrage hat, die GPU-Ressourcenlimits jedoch nicht auf Clusterebene definiert sind. | Angeforderter GPU-Typ. | Prüfen Sie die GPU-Anfrage des ausstehenden Pods und aktualisieren Sie die Konfiguration des Knotens für die automatische Bereitstellung von GPU-Limits auf Clusterebene. |
"no.scale.up.nap.pod.gpu.type.not.supported" |
Die automatische Knotenbereitstellung hat keine Knotengruppe für den Pod bereitgestellt, da sie Anfragen für einen unbekannten GPU-Typ enthält. | Angeforderter GPU-Typ. | Prüfen Sie, ob die Konfiguration des ausstehenden Pods des GPU-Typs mit einem unterstützten GPU-Typ übereinstimmt. |
"no.scale.up.nap.pod.zonal.resources.exceeded" |
Die automatische Knotenbereitstellung hat keine Knotengruppe für den Pod in dieser Zone bereitgestellt, da dies entweder gegen die maximalen Ressourcenlimits von Clustern verstoßen oder die verfügbaren Ressourcen in der Zone überschreiten würde. Oder es gibt keinen Maschinentyp, der in die Anfrage passen könnte. | Name der betreffenden Zone. | Prüfen und aktualisieren Sie clusterweite maximale Ressourcenlimits, die Pod-Ressourcenanfragen oder die verfügbaren Zonen für die automatische Knotenbereitstellung. |
"no.scale.up.nap.pod.zonal.failing.predicates" |
Die automatische Knotenbereitstellung hat aufgrund fehlgeschlagener Prädikate keine Knotengruppe für den Pod in dieser Zone bereitgestellt. | Name der betreffenden Zone und Gründe, warum Prädikate fehlgeschlagen sind. | Prüfen Sie die Anforderungen des ausstehenden Pods, z. B. Affinitätsregeln, Markierungen, Toleranzen oder Ressourcenanforderungen. |
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 ansehen:
Rufen Sie in der Google Cloud -Konsole 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.up.error.out.of.resources
.Klicken Sie auf Abfrage ausführen.
Einige Fehler mit gcpdiag beheben
gcpdiag
ist ein Open-Source-Tool, das mit Unterstützung von Google Cloudentwickelt 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.up.error.out.of.resources
scale.up.error.quota.exceeded
scale.up.error.waiting.for.instances.timeout
scale.up.error.ip.space.exhausted
scale.up.error.service.account.deleted
Eine Liste und Beschreibung aller gcpdiag
-Tool-Flags finden Sie in der gcpdiag
-Nutzungsanleitung.
Komplexe Fehler beim Skalieren beheben
In den folgenden Abschnitten finden Sie Anleitungen zum Beheben von Fehlern, bei denen die Abhilfemaßnahmen mehrere Schritte umfassen, und von Fehlern, die nicht mit einer Cluster-Autoskalaierungs-Ereignismeldung verknüpft sind.
Problem: Pod passt nicht auf den Knoten
Der Cluster-Autoscaler plant einen Pod nur auf einem Knoten, wenn ein Knoten mit ausreichenden Ressourcen wie GPUs, Arbeitsspeicher und Speicherplatz vorhanden ist, um die Anforderungen des Pods zu erfüllen. Um festzustellen, ob dies der Grund dafür ist, dass Cluster Autoscaler nicht hochskaliert hat, vergleichen Sie die Ressourcenanfragen mit den bereitgestellten Ressourcen.
Im folgenden Beispiel wird gezeigt, wie Sie CPU-Ressourcen prüfen. Dieselben Schritte gelten jedoch auch für GPUs, Arbeitsspeicher und Speicherressourcen. So vergleichen Sie CPU-Anfragen mit bereitgestellten CPUs:
Rufen Sie in der Google Cloud Console die Seite Arbeitslasten auf.
Klicken Sie auf die Fehlermeldung
PodUnschedulable
.Klicken Sie im Bereich Details auf den Namen des Pods. Wenn es mehrere Pods gibt, beginnen Sie mit dem ersten und wiederholen Sie die folgenden Schritte für jeden Pod.
Rufen Sie auf der Seite mit den Pod-Details den Tab Ereignisse auf.
Wechseln Sie vom Tab Ereignisse zum Tab YAML.
Notieren Sie sich die Ressourcenanfragen der einzelnen Container im Pod, um die Gesamtzahl der Ressourcenanfragen zu ermitteln. In der folgenden Pod-Konfiguration benötigt der Pod beispielsweise 2 vCPUs:
resources: limits: cpu: "3" requests: cpu: "2"
Rufen Sie die Knotenpooldetails des Clusters mit dem nicht geplanten Pod auf:
Rufen Sie in der Google Cloud -Konsole die Seite Kubernetes-Cluster auf.
Klicken Sie auf den Namen des Clusters, für den die
Pods unschedulable
-Fehlermeldung angezeigt wird.Rufen Sie auf der Seite Clusterdetails den Tab Knoten auf.
Notieren Sie sich im Abschnitt Knotenpools den Wert in der Spalte Maschinentyp. Beispiel:
n1-standard-1
Vergleichen Sie die Ressourcenanfrage mit den vCPUs, die vom Maschinentyp bereitgestellt werden. Wenn ein Pod beispielsweise 2 vCPUs anfordert, die verfügbaren Knoten aber den Maschinentyp
n1-standard-1
haben, haben die Knoten nur eine vCPU. Bei einer solchen Konfiguration würde Cluster Autoscaler keine vertikale Skalierung auslösen, da dieser Pod auch dann nicht auf einem neuen Knoten passen würde, wenn dieser hinzugefügt würde. Weitere Informationen zu verfügbaren Maschinentypen finden Sie in der Compute Engine-Dokumentation unter Ressourcen- und Vergleichsanleitung für Maschinenfamilien.
Beachten Sie außerdem, dass die zuweisbaren Ressourcen eines Knotens geringer sind als die Gesamtressourcen, da ein Teil für die Ausführung von Systemkomponenten benötigt wird. Weitere Informationen zur Berechnung finden Sie unter Zuweisbare Ressourcen für Knoten.
Um dieses Problem zu beheben, müssen Sie entscheiden, ob die für die Arbeitslast definierten Ressourcenanforderungen für Ihre Anforderungen geeignet sind. Wenn der Maschinentyp nicht geändert werden soll, erstellen Sie einen Knotenpool mit einem Maschinentyp, der die vom Pod ausgehende Anfrage unterstützen kann. Wenn die Pod-Ressourcenanforderungen nicht korrekt sind, aktualisieren Sie die Pod-Definition so, dass die Pods auf den Knoten passen.
Problem: Fehlerhafte Cluster verhindern das Hochskalieren
Der Cluster Autoscaler führt möglicherweise kein Hochskalieren durch, wenn er einen Cluster als nicht fehlerfrei einstuft. Die Fehlerbehebung im Cluster hängt nicht davon ab, ob die Steuerungsebene fehlerfrei ist, sondern vom Verhältnis zwischen fehlerfreien und bereiten Knoten. Wenn 45% der Knoten in einem Cluster nicht betriebsbereit oder nicht fehlerfrei sind, beendet Cluster Autoscaler alle Vorgänge.
Wenn dies der Grund ist, warum Cluster Autoscaler nicht hochskaliert, gibt es in der ConfigMap von Cluster Autoscaler ein Ereignis vom Typ Warning
mit ClusterUnhealthy
als Grund.
Führen Sie den folgenden Befehl aus, um die ConfigMap aufzurufen:
kubectl describe configmap cluster-autoscaler-status -n kube-system
Reduzieren Sie die Anzahl der fehlerhaften Knoten, um dieses Problem zu beheben.
Es ist auch möglich, dass einige der Knoten bereit sind, aber von Cluster Autoscaler nicht als bereit eingestuft werden. Das passiert, wenn ein Knoten eine Beschädigung mit dem Präfix ignore-taint.cluster-autoscaler.kubernetes.io/
aufweist. Cluster Autoscaler betrachtet einen Knoten als NotReady
, solange diese Beschädigung vorhanden ist.
Wenn das Verhalten durch die Anwesenheit einer ignore-taint.cluster-autoscaler.kubernetes.io/.*
-Beschädigung verursacht wird, entfernen Sie sie.
Nächste Schritte
- Lesen Sie die häufig gestellten Fragen zum Kubernetes Cluster Autoscaler.
- 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.