Fehlerbehebung, wenn Cluster Autoscaler nicht hochskaliert

Wenn Ihre Pods in Google Kubernetes Engine (GKE) im Status Pending hängen bleiben und keine neuen Knoten hinzugefügt werden, deutet dies häufig auf ein Problem mit der Hochskalierungsfunktion des Cluster Autoscalers hin. Dieses Problem kann dazu führen, dass Ihre Anwendungen nicht skaliert werden, um die Nachfrage zu decken, Bereitstellungen verzögert werden und die Dienstverfügbarkeit beeinträchtigt wird.

Auf dieser Seite können Sie häufige Probleme diagnostizieren und beheben, die verhindern, dass Cluster Autoscaler neue Knoten hinzufügt. Wenn Sie diese Probleme beheben, kann der Kubernetes-Planer Ihre Arbeitslasten zeitnah platzieren und Ihr Cluster kann sich an die steigende Last anpassen.

Diese Informationen sind wichtig für Anwendungsentwickler, die ihre Anwendungen und Dienste zuverlässig planen und ausführen müssen, sowie für Plattformadministratoren und -betreiber, die dafür verantwortlich sind, dass der Cluster Ressourcen dynamisch bereitstellen kann, um die Anforderungen an Arbeitslasten zu erfüllen und Service-Level aufrechtzuerhalten. Weitere Informationen zu den gängigen Rollen und Beispielaufgaben, auf die wir in Inhalten von Google Cloud verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Wann Cluster Autoscaler Ihre Knoten hochskaliert

Bevor Sie mit den Schritten zur Fehlerbehebung fortfahren, sollten Sie sich darüber informieren, wann Cluster Autoscaler versucht, Ihre Knoten hochzuskalieren. Cluster Autoscaler fügt nur dann Knoten hinzu, wenn die vorhandenen Ressourcen nicht ausreichen.

Alle 10 Sekunden prüft Cluster Autoscaler, ob es nicht planbare Pods gibt. Ein Pod wird nicht planbar, wenn der Kubernetes-Planer ihn aufgrund unzureichender Ressourcen, Knoteneinschränkungen oder nicht erfüllter Pod-Anforderungen auf keinem 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 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 hochskaliert werden muss:

  1. Rufen Sie in der Google Cloud Console die Seite Arbeitslasten auf.

    Zu Arbeitslasten

  2. Geben Sie im Feld Filter den Wert unschedulable ein und drücken Sie die Eingabetaste.

    Wenn Pods aufgeführt sind, haben Sie nicht planbare Pods. 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 Cluster Autoscaler häufig hochskaliert werden. In den folgenden Abschnitten erfahren Sie, wie Sie Fehler identifizieren und beheben, die speziell beim Cluster-Autoscaling auftreten.

    Wenn keine Pods aufgeführt sind, muss Cluster Autoscaler nicht hochskaliert werden und funktioniert wie erwartet.

Prüfen, ob Sie zuvor nicht planbare Pods hatten

Wenn Sie die Ursache für einen Fehler von Cluster Autoscaler in der Vergangenheit untersuchen, prüfen Sie, ob es zuvor nicht planbare Pods gab:

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

    Zum Log-Explorer

  2. Geben Sie einen Zeitraum für die Logeinträge an, die Sie aufrufen möchten.

  3. 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.

  4. 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 Ihr Problem mit Cluster Autoscaler nicht durch eine der Einschränkungen für Cluster Autoscaler verursacht wird.

Cloud Monitoring-Messwerte auf Probleme beim Hochskalieren analysieren

Das GKE-Cluster-Autoscaling stellt Messwerte für Cloud Monitoring bereit, die Einblicke in seine Entscheidungen geben, insbesondere in Bezug auf ComputeClasses. Diese Messwerte sind in GKE-Version 1.37 und höher verfügbar und umfassen Folgendes:

  • Ausstehende Pods: kubernetes.io/autoscaler/cluster_pending_pods_per_ccc zeigt Pods an, die der Autoscaler zu planen versucht.
  • Bereitstellungsversuche: kubernetes.io/autoscaler/cluster_node_provisioning_attempts_count_per_ccc erfasst, wie oft Autoscaling versucht, Knoten hinzuzufügen.
  • Bereitstellungsfehler: kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc zeigt fehlgeschlagene Versuche, Knoten zu erstellen, und die Gründe dafür an.

Diese Messwerte verwenden den Ressourcentyp k8s_entity, wobei der Wert des Felds resource.labels.entity_type ComputeClass ist. Der Wert des Felds resource.labels.entity_name gibt den Namen der ComputeClass an. Wenn das Feld entity_name einen leeren String ("") als Wert hat, bezieht sich der Messwert auf Entscheidungen des Cluster-Autoscalers, die nicht mit einer ComputeClass zusammenhängen.

Verwenden Sie den Metrics Explorer, um Ergebnisse nach dem Feld entity_name zu filtern und zu gruppieren. Verwenden Sie beispielsweise den String resource.labels.entity_name = "", um Aktivitäten zu sehen, die nicht mit ComputeClasses zusammenhängen, und Messwertlabels (wie reason), um zu sehen, ob Probleme beim Hochskalieren spezifisch für eine ComputeClass sind.

Beispiele für Abfragen finden Sie unter Knotenbereitstellung überwachen und Ausstehenden Pod-Status überwachen.

Fehler ansehen

Die Ursache von Problemen beim Hochskalieren lässt sich oft anhand von Fehlermeldungen diagnostizieren:

Fehler in Benachrichtigungen ansehen

Wenn das Problem vor weniger als 72 Stunden aufgetreten ist, rufen Sie Benachrichtigungen zu Fehlern in der Google Cloud Console auf. Diese Benachrichtigungen liefern wertvolle Informationen darüber, warum Cluster Autoscaler nicht hochskaliert wurde, und bieten Hinweise zur Behebung des Fehlers und zum Aufrufen relevanter Logs für weitere Untersuchungen.

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 bei der Hochskalierung verknüpft:

    • Can't scale up
    • Can't scale up pods
    • Can't scale up a node pool

  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 Hochskalierungsereignissen finden Sie unter Cluster-Autoscaling-Ereignisse ansehen.

Wenn Sie nach dem Lesen der Hinweise in der Benachrichtigung weiterhin Probleme haben, finden Sie in den Tabellen mit Fehlermeldungen weitere Hilfe.

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 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 prüfen 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 den Button mit dem Pfeil rechts auf der Seite, um die Logs im Log-Explorer aufzurufen.

Weitere Informationen zu Ereignissen für das Hochskalieren finden Sie unter Cluster-Autoscaling-Ereignisse ansehen. Ein Beispiel für die Verwendung von Cloud Logging finden Sie im folgenden Beispiel zur Fehlerbehebung.

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

Im folgenden Beispiel wird gezeigt, wie Sie ein Problem mit einem Cluster, der nicht hochskaliert wird, untersuchen und beheben können.

Szenario: Ein Pod wurde in der letzten Stunde als nicht planbar markiert. Cluster Autoscaler hat keine neuen Knoten zur Planung des Pods bereitgestellt.

Lösung:

  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 scaleUp-Ereignissen, die den Pod, den Sie untersuchen, im Feld triggeringPods 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 Ereignisse zum Hochskalieren. Wenn Sie dies jedoch getan haben, können Sie versuchen, ein EventResult zu finden, das dieselbe eventId wie das scaleUp-Ereignis enthält. Sie können sich dann das Feld errorMsg ansehen und die Liste der möglichen scaleUp-Fehlermeldungen aufrufen.

  5. Da Sie keine scaleUp-Ereignisse gefunden haben, suchen Sie weiter nach noScaleUp-Ereignissen und prüfen 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.

  6. Sie sind auf ein noScaleUp-Ereignis für Ihren Pod gestoßen und alle MIGs im Feld rejectedMigs haben dieselbe Grundmeldungs-ID "no.scale.up.mig.failing.predicate" mit den zwei Parametern "NodeAffinity" und "node(s) did not match node selector".

Lösung:

Nach Durchsicht der Liste der Fehlermeldungen stellen Sie fest, dass Cluster Autoscaler einen Knotenpool aufgrund eines fehlgeschlagenen Planungsprädikats für die ausstehenden Pods nicht hochskalieren kann. Die Parameter sind der Name des fehlgeschlagenen Prädikats und der Grund für den Fehler.

Zum Beheben des Problems prüfen Sie das Manifest des Pods und stellen fest, dass es eine Knotenauswahl enthält, die keiner MIG im Cluster entspricht. Sie löschen die Auswahl 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 Hochskalieren beheben

Wenn Sie benutzerdefinierte ComputeClasses verwenden und die Probleme beim Hochskalieren mit den spezifischen Knotenkonfigurationen in Ihrer ComputeClass zusammenhängen, lesen Sie den Abschnitt Probleme mit benutzerdefinierten ComputeClasses beheben.

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

ScaleUp-Fehler

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

Wenn ein Hochskalierungsvorgang fehlschlägt, weil ein Kontingent überschritten wird, handelt es sich um einen Fehler bei der Knotenerstellung, der einen Backoff-Zeitraum des Systems auslöst, der bis zu 30 Minuten dauern kann. Weitere Informationen finden Sie unter Backoff-Zeiträume.

Nachricht 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. Wenn die Instanzen gestartet, aber nicht bei der Steuerungsebene registriert werden, folgen Sie der Anleitung unter Instanz mit fehlgeschlagener Knotenregistrierung suchen. Weitere Ursachen finden Sie unter MIG-Instanzen wurden nicht rechtzeitig angezeigt. Dieser Fehler ist in der Regel vorübergehend. Wenn der Fehler weiterhin auftritt, wenden Sie sich an Cloud Customer Care, um das Problem untersuchen zu lassen.
"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 verfügbarer 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 der automatischen Knotenbereitstellung für 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 finden Sie Informationen dazu, wie Sie den Log-Explorer und gcpdiag verwenden, um zusätzliche Informationen zu Ihren Fehlern zu erhalten.

Fehler im Log-Explorer untersuchen

Wenn Sie die Fehlermeldung genauer untersuchen möchten, rufen Sie die Logs für Ihren Fehler auf:

  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.up.error.out.of.resources.

  3. Klicken Sie auf Abfrage ausführen.

Fehler mit gcpdiag beheben

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

Wenn eine der folgenden Fehlermeldungen angezeigt wird, können Sie das Problem mithilfe von gcpdiag 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 bei der Hochskalierung beheben

In den folgenden Abschnitten finden Sie Informationen zum Beheben von Fehlern, die mehrere Schritte erfordern oder für die keine Ereignisnachricht vom Cluster-Autoscaling vorliegt.

Pod passt nicht auf Knoten

Symptome:

Ihre Pods bleiben im Status Pending mit der Fehlermeldung PodUnschedulable oder Ihr Cluster zeigt die Fehlermeldung Pods unschedulable an und Cluster Autoscaler skaliert nicht hoch, um Knoten hinzuzufügen.

Ursache:

Cluster Autoscaler fügt einem Knotenpool nur dann Knoten hinzu, wenn der Maschinentyp genügend Ressourcen wie CPUs, GPUs, Arbeitsspeicher und Speicher für einen ausstehenden Pod bereitstellt. Wenn die Ressourcenanfragen eines Pods die Ressourcen eines einzelnen Knotens überschreiten, wird Cluster Autoscaler nicht hochskaliert, da der Pod immer noch nicht auf einen neuen Knoten passt.

Außerdem sind die zuweisbaren Ressourcen eines Knotens geringer als seine Gesamtressourcen, da Systemkomponenten einen Teil dieser Ressourcen reservieren. Weitere Informationen dazu, wie GKE zuweisbare Ressourcen berechnet, finden Sie unter Zuweisbare Knotenressourcen.

Lösung:

Führen Sie die folgenden Schritte aus, um zu prüfen, ob die Ressourcenanfragen eines Pods die von Ihren Knoten bereitgestellten Ressourcen überschreiten, und das Problem zu beheben. In diesem Beispiel werden CPU-Ressourcen geprüft. Dieselben Schritte gelten jedoch auch für GPUs, Arbeitsspeicher und Speicherressourcen:

  1. Rufen Sie in der Google Cloud Console die Seite Arbeitslasten auf.

    Zu Arbeitslasten

  2. Klicken Sie auf die Fehlermeldung PodUnschedulable.

  3. Klicken Sie im Bereich Details auf den Namen des Pods. Wenn mehrere Pods vorhanden sind, beginnen Sie mit dem ersten Pod und wiederholen Sie den folgenden Vorgang für jeden Pod.

  4. Klicken Sie auf der Seite Pod-Details auf den Tab YAML.

  5. Notieren Sie sich die Ressourcenanfragen der einzelnen Container im Pod, um die Gesamtressourcenanfragen zu ermitteln. In der folgenden Pod-Konfiguration benötigt der Pod beispielsweise 2 vCPUs:

    resources:
  limits:
    cpu: "3"
  requests:
    cpu: "2"

  6. Rufen Sie die Knotenpooldetails aus dem Cluster mit dem nicht geplanten Pod auf:

    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 mit der Fehlermeldung Pods unschedulable.

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

    4. Notieren Sie sich im Abschnitt Knotenpools den Wert in der Spalte Maschinentyp, z. B. n1-standard-1.

  7. Vergleichen Sie die Ressourcenanfrage mit den vCPUs, die vom Maschinentyp bereitgestellt werden. Wenn ein Pod beispielsweise 2 vCPUs anfordert, die verfügbaren Knoten jedoch den Maschinentyp n1-standard-1 verwenden, haben die Knoten nur 1 vCPU. Bei einer solchen Konfiguration löst Cluster Autoscaler keine Hochskalierung aus, da der Pod immer noch nicht auf einen neuen Knoten passt. Weitere Informationen zu verfügbaren Maschinentypen finden Sie in der Compute Engine-Dokumentation unter Ressourcen- und Vergleichsanleitung für Maschinenfamilien.

  8. Beheben Sie die Abweichung entsprechend den Anforderungen Ihrer Arbeitslast:

    • Wenn der Pod die angeforderten Ressourcen benötigt: Erstellen Sie einen Knotenpool mit einem Maschinentyp, der die Ressourcenanfragen des Pods unterstützen kann.
    • Wenn die Ressourcenanfragen des Pods nicht korrekt sind: Aktualisieren Sie die Definition des Pods, damit er auf vorhandene Knoten passt.

MIG-Instanzen wurden nicht rechtzeitig angezeigt

Symptome:

Es wird eine der folgenden Fehlermeldungen angezeigt:

  • In der Google Cloud Console wird für den Cluster die folgende Benachrichtigung angezeigt:

    Can't scale up because instances in managed instance groups hosting node pools failed to appear in time

  • In Logging enthält das eventResult-Ereignis für die Hochskalierung die folgende Fehlermeldung:

    scale.up.error.waiting.for.instances.timeout

Ursache:

Compute Engine kann keine Knoten in der MIG erstellen oder die neuen Knoten können sich nicht bei der Steuerungsebene registrieren, bevor die Zeitüberschreitung für den Hochskalierungsvorgang erreicht ist. Dieses Problem kann folgende Ursachen haben:

  • Fehlgeschlagene Knotenregistrierung: Compute Engine erstellt die Knoten, aber sie werden aufgrund einer oder mehrerer Firewallregeln, einer kürzlichen Änderung am Zugriff auf private Dienste oder VPC-Netzwerk-Peering oder eines fehlenden IAM-Dienstkontos (Identity and Access Management) nicht bei der Steuerungsebene registriert.
  • Projektkontingente überschritten: Neue Instanzen in der MIG werden nicht angezeigt, weil Ihr Projekt ein Kontingent für CPUs, IP-Adressen oder eine andere Ressource überschreitet.
  • Nicht verfügbare IP-Adressen: Das Subnetz hat nicht genügend verfügbare IP-Adressen, um neue Knoten zu erstellen.
  • Ungültige Instanzvorlage: Die MIG verwendet eine ungültige Instanzvorlage, z. B. eine Vorlage mit einem fehlenden Image, was eine Hochskalierung verhindert.
  • Unzureichende Ressourcen: Die Zone verfügt nicht über genügend Compute Engine-Ressourcen wie GPUs oder CPUs, um einen neuen Knoten zu erstellen.
  • Nicht zugängliche APIs: Eine erforderliche API wie compute.googleapis.com ist aufgrund einer Firewallregel oder eines VPC Service Controls-Perimeters nicht zugänglich.
  • Netzwerklatenz: Eine erhebliche Netzwerklatenz verzögert die Erstellung oder Nutzbarkeit eines neuen Knotens.

Lösung:

  1. Um die Ursache der Zeitüberschreitung zu ermitteln, listen Sie die Instanzfehler in der MIG auf und prüfen Sie dann das Ergebnis:

    • In der verwalteten Instanzgruppe werden keine Fehler aus der Zeit des Fehlers aufgeführt: Compute Engine hat die Knoten erstellt, aber die Knoten wurden vor dem Zeitlimit nicht bei der Steuerungsebene registriert. Beginnen Sie im nächsten Schritt mit Fehlgeschlagene Knotenregistrierung. Wenn die Knoten registriert wurden, aber zu lange gebraucht haben, lesen Sie den Abschnitt Netzwerklatenz.

    • In der MIG werden Fehler zum Zeitpunkt des Ausfalls aufgeführt: Compute Engine konnte die Knoten nicht erstellen. Verwenden Sie den Fehlercode und die Fehlermeldung, um im nächsten Schritt die Ursache zu finden. Häufige Fehlercodes:

      • QUOTA_EXCEEDED: Projektkontingente überschritten
      • IP_SPACE_EXHAUSTED: nicht verfügbare IP-Adressen
      • ZONE_RESOURCE_POOL_EXHAUSTED: unzureichende Ressourcen

      Einige Fehlercodes haben das Suffix _WITH_DETAILS und enthalten weitere Informationen in der Fehlermeldung. Wenn in der Fehlermeldung eine nicht vorhandene Ressource wie ein Quell-Image gemeldet wird, lesen Sie den Punkt Ungültige Instanzvorlage.

  2. Verwenden Sie die Lösung, die der Ursache Ihres Problems entspricht:

    • Fehlgeschlagene Knotenregistrierung: Folgen Sie der Anleitung unter Instanz mit fehlgeschlagener Knotenregistrierung suchen. Sie können auch nach kürzlich vorgenommenen Konfigurationsänderungen suchen:

      • Firewallregeln: Wenn Sie prüfen möchten, ob eine Firewallregel vor Kurzem erstellt, aktualisiert oder gelöscht wurde, führen Sie die folgende Abfrage im Log-Explorer aus:

        resource.type="gce_firewall_rule"
log_id("cloudaudit.googleapis.com/activity")

        Wenn eine Änderung den Traffic zwischen den Knoten und der Steuerungsebene oder zu Google APIs blockiert, aktualisieren oder ersetzen Sie die Firewallregel. Weitere Informationen zur erforderlichen Konnektivität finden Sie unter Voraussetzungen für eine erfolgreiche Knotenregistrierung.

      • IAM-Dienstkonto: Wenn ein Dienstkonto fehlt, finden Sie Informationen dazu in der Zeile scale.up.error.service.account.deleted der Tabelle ScaleUp-Fehler.

      • Zugriff auf private Dienste: Informationen zu den letzten Änderungen in Audit-Logs finden Sie unter Audit-Logging für den Zugriff auf private Dienste.

      • VPC-Netzwerk-Peering: Wenn Sie prüfen möchten, ob Peering vor Kurzem hinzugefügt, aktualisiert oder entfernt wurde, führen Sie im Log-Explorer für jedes Peering-Projekt die folgende Abfrage aus:

        log_id("cloudaudit.googleapis.com/activity")
resource.type="gce_network"
protoPayload.methodName:("compute.networks.addPeering" OR
"compute.networks.updatePeering" OR
"compute.networks.removePeering")

        Wenn eine Peering-Änderung die Verbindung zur Steuerungsebene unterbrochen hat, aktualisieren Sie die Peering-Verbindung. Wenn die Verbindung gelöscht wurde, finden Sie weitere Informationen unter VPC-Netzwerk-Peering-Verbindung wurde versehentlich gelöscht.

    • Projektkontingente überschritten: Weitere Informationen finden Sie in der Zeile scale.up.error.quota.exceeded in der Tabelle ScaleUp-Fehler.

    • Nicht verfügbare IP-Adressen: Siehe die Zeile scale.up.error.ip.space.exhausted in der Tabelle ScaleUp-Fehler.

    • Ungültige Instanzvorlage: Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Die Instanzvorlage ist ungültig.

    • Unzureichende Ressourcen: Weitere Informationen finden Sie in der Zeile scale.up.error.out.of.resources in der Tabelle ScaleUp-Fehler.

    • Nicht zugängliche APIs: Führen Sie im Log-Explorer eine Abfrage aus, um nach Aktivitäten im Zusammenhang mit Firewallregeln oder VPC Service Controls-Perimetern zu suchen:

      • Wenn Sie prüfen möchten, ob eine Firewallregel vor Kurzem geändert wurde, führen Sie die Audit-Log-Abfrage im Aufzählungspunkt Firewallregeln unter Fehlgeschlagene Knotenregistrierung aus. Wenn Sie das Firewallregel-Logging für Ihre Regeln aktiviert haben, können Sie sich auch die Verbindungen ansehen, die von Ihren Regeln abgelehnt wurden. Führen Sie dazu die folgende Abfrage aus:

        resource.type="gce_subnetwork"
log_id("compute.googleapis.com/firewall")
jsonPayload.disposition="DENIED"

        Wenn die Logs eine Firewallregel enthalten, die Traffic zu erforderlichen Google APIs blockiert, aktualisieren oder ersetzen Sie die Firewallregel, um den Traffic zuzulassen. Weitere Informationen zu den Netzwerkanforderungen finden Sie unter Voraussetzungen für die Netzwerkverbindung zu Google APIs und Google-Diensten.

      • Wenn Sie VPC Service Controls verwenden, wählen Sie Ihre Organisation in der Google Cloud Konsole aus und führen Sie die folgende Abfrage im Log-Explorer aus, um zu prüfen, ob vor Kurzem ein Perimeter hinzugefügt oder geändert wurde:

        logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity"
protoPayload.serviceName="accesscontextmanager.googleapis.com"

        Ersetzen Sie ORGANIZATION_ID durch Ihre Organisations-ID.

        Sie können auch die folgenden Filter hinzufügen, um die Aktualisierung oder Erstellung eines VPC Service Controls-Perimeters zu finden:

        severity=NOTICE
protoPayload.methodName=("google.identity.accesscontextmanager.v1.AccessContextManager.CreateServicePerimeter"
OR "google.identity.accesscontextmanager.v1.AccessContextManager.UpdateServicePerimeter")

        Wenn ein neuer oder geänderter Perimeter den Zugriff auf erforderliche Google APIs blockiert, rufen Sie VPC Service Controls-Fehler aus Audit-Logs ab, um den blockierten Dienst zu identifizieren, und aktualisieren Sie den Dienstperimeter, um den Zugriff zu ermöglichen. Weitere Informationen zur Verwendung von Cluster Autoscaler in einem Perimeter finden Sie unter Autoscaler funktioniert nicht in Perimetern, in denen zugängliche Dienste und eingeschränkte Dienste aktiviert sind.

    • Netzwerklatenz: Vorübergehende Netzwerklatenz wird in der Regel bei nachfolgenden Hochskalierungsversuchen behoben. Informationen zu anhaltender Latenz finden Sie in der Compute Engine-Dokumentation unter Häufige Netzwerkprobleme beheben.

Fehlerhafte Cluster verhindern das Hochskalieren

Symptome:

Cluster Autoscaler hält alle Skalierungsvorgänge an und die ConfigMap cluster-autoscaler-status enthält ein Ereignis mit dem Typ Warning und ClusterUnhealthy als Grund.

Führen Sie den folgenden Befehl aus, um die ConfigMap cluster-autoscaler-status aufzurufen:

kubectl describe configmap cluster-autoscaler-status -n kube-system

Ursache:

Cluster Autoscaler führt keine Hochskalierung durch, wenn ein Cluster als fehlerhaft eingestuft wird. Der Cluster Autoscaler bestimmt den Zustand des Clusters anhand des Verhältnisses von fehlerfreien und bereiten Knoten, nicht anhand des Zustands der Steuerungsebene. Wenn 45% der Knoten in einem Cluster fehlerhaft oder nicht bereit sind, hält Cluster Autoscaler alle Vorgänge an.

Cluster Autoscaler betrachtet einen bereiten Knoten auch als NotReady, wenn der Knoten eine Markierung mit dem Präfix ignore-taint.cluster-autoscaler.kubernetes.io/ hat. Cluster Autoscaler behandelt den Knoten als NotReady, solange diese Markierung vorhanden ist.

Lösung:

Verringern Sie die Anzahl der fehlerhaften Knoten, um dieses Problem zu beheben. Führen Sie dazu eine oder beide der folgenden Aktionen aus:

  • Untersuchen und reparieren Sie fehlerhafte oder NotReady-Knoten, sodass weniger als 45 % der Knoten im Cluster fehlerhaft sind.
  • Wenn bereite Knoten eine Markierung mit dem Präfix ignore-taint.cluster-autoscaler.kubernetes.io/ haben, entfernen Sie die Markierung.

Nächste Schritte