Cluster Autoscaler-Ereignisse ansehen


Cluster Autoscaler von Google Kubernetes Engine (GKE) gibt Sichtbarkeitsereignisse aus, die als Logeinträge in Cloud Logging verfügbar sind. Auf dieser Seite wird gezeigt, wie Sie diese protokollierten Ereignisse aufrufen und damit feststellen können, wann und warum GKE Cluster Autoscaler Entscheidungen trifft.

Verfügbarkeitsanforderungen

Protokollierte Cluster Autoscaler-Ereignisse können in folgenden Clusterversionen aufgerufen werden:

Ereignistyp Clusterversion
status, scaleUp, scaleDown, eventResult 1.15.4-gke.7 und höher
nodePoolCreated, nodePoolDeleted. 1.15.4-gke.18 und höher
noScaleUp 1.16.6-gke.3 und höher
noScaleDown 1.16.8-gke.2 und höher

Ereignisse ansehen

Die Sichtbarkeitsereignisse für Cluster Autoscaler werden in einem Cloud Logging-Log im selben Projekt gespeichert, in dem sich auch Ihr GKE-Cluster befindet.

So sehen Sie sich die Logs an:

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

    Zur Loganzeige

  2. Suchen Sie mithilfe der einfachen oder erweiterten Abfrageoberfläche nach den Logs.

    So suchen Sie mit der einfachen Abfrageoberfläche nach Logs:

    1. Wählen Sie in der Drop-down-Liste "Ressourcen" die Option Kubernetes-Cluster und dann den Ort und Namen des Clusters aus.
    2. Wählen Sie in der Drop-down-Liste "Logtyp" die Option container.googleapis.com/cluster-autoscaler-visibility aus.
    3. Wählen Sie in der Drop-down-Liste "Zeitraum" den gewünschten Zeitraum aus.

    Wenden Sie den folgenden erweiterten Filter an, um mit der erweiterten Abfrageoberfläche nach Logs zu suchen:

    resource.type="k8s_cluster"
    resource.labels.location="cluster-location"
    resource.labels.cluster_name="cluster-name"
    logName="projects/project-id/logs/container.googleapis.com%2Fcluster-autoscaler-visibility"
    

    Dabei gilt:

    • cluster-location ist der Standort des Clusters, den Sie prüfen.
    • cluster-name ist der Name des Clusters.
    • project-id ist die ID des Projekts.

Ereignistypen

Alle protokollierten Ereignisse liegen im JSON-Format vor und sind im Feld jsonPayload eines Logeintrags enthalten. Alle Zeitstempel in den Ereignissen sind UNIX-Zeitstempel in Sekunden.

Im Folgenden werden die von Cluster Autoscaler ausgegebenen Ereignistypen zusammengefasst:

Ereignistyp Beschreibung
status Tritt regelmäßig auf und beschreibt die von Cluster Autoscaler beobachtete tatsächliche Größe und Zielgröße aller automatisch skalierten Knotenpools.
scaleUp Tritt auf, wenn Cluster von Cluster Autoscaler hochskaliert werden.
scaleDown Tritt auf, wenn Cluster von Cluster Autoscaler herunterskaliert werden.
eventResult Tritt auf, wenn ein scaleUp- oder scaleDown-Ereignis erfolgreich oder nicht erfolgreich abgeschlossen wird.
nodePoolCreated Tritt auf, wenn ein neuer Knotenpool bei aktivierter automatischer Knotenbereitstellung von Cluster Autoscaler erstellt wird.
nodePoolDeleted Tritt auf, wenn ein Knotenpool bei aktivierter automatischer Knotenbereitstellung von Cluster Autoscaler gelöscht wird.
noScaleUp Tritt auf, wenn der Cluster nicht planbare Pods enthält und von Cluster Autoscaler nicht hochskaliert werden kann, um die Pods bereitzustellen.
noScaleDown Tritt auf, wenn Knoten blockiert sind und daher nicht von Cluster Autoscaler gelöscht werden können.

Ereignis "status"

Ein status-Ereignis wird regelmäßig ausgegeben und beschreibt die von Cluster Autoscaler beobachtete tatsächliche Größe und Zielgröße aller automatisch skalierten Knotenpools.

Beispiel

Das folgende Logbeispiel zeigt ein status-Ereignis:

{
  "status": {
    "autoscaledNodesCount": 4,
    "autoscaledNodesTarget": 4,
    "measureTime": "1582898536"
  }
}

Ereignis "scaleUp"

Ein scaleUp-Ereignis wird ausgegeben, wenn der Cluster von Cluster Autoscaler hochskaliert wird. Dieses Ereignis enthält Informationen darüber, welche verwalteten Instanzgruppen (Managed Instance Groups, MIGs) um wie viele Knoten hochskaliert wurden und welche nicht planbaren Pods das Ereignis ausgelöst haben.

Die Liste der auslösenden Pods wird auf 50 beliebige Einträge gekürzt. Die tatsächliche Anzahl der auslösenden Pods finden Sie im Feld triggeringPodsTotalCount.

Beispiel

Das folgende Logbeispiel zeigt ein scaleUp-Ereignis:

{
  "decision": {
    "decideTime": "1582124907",
    "eventId": "ed5cb16d-b06f-457c-a46d-f75dcca1f1ee",
    "scaleUp": {
      "increasedMigs": [
        {
          "mig": {
            "name": "test-cluster-default-pool-a0c72690-grp",
            "nodepool": "default-pool",
            "zone": "us-central1-c"
          },
          "requestedNodes": 1
        }
      ],
      "triggeringPods": [
        {
          "controller": {
            "apiVersion": "apps/v1",
            "kind": "ReplicaSet",
            "name": "test-85958b848b"
          },
          "name": "test-85958b848b-ptc7n",
          "namespace": "default"
        }
      ],
      "triggeringPodsTotalCount": 1
    }
  }
}

Ereignis "scaleDown"

Ein scaleDown-Ereignis wird ausgegeben, wenn der Cluster von Cluster Autoscaler herunterskaliert wird. Dieses Ereignis enthält Informationen darüber, welche Knoten entfernt werden und welche Pods aus diesem Grund entfernt werden müssen.

Die Felder cpuRatio und memRatio beschreiben die CPU- und Arbeitsspeicherauslastung des Knotens in Prozent. Diese Auslastung ist die Summe der Pod-Anfragen geteilt durch die zuweisbaren Knoten und nicht die tatsächliche Auslastung.

Die Liste der entfernten Pods wird auf 50 beliebige Einträge gekürzt. Die tatsächliche Anzahl der entfernten Pods finden Sie im Feld evictedPodsTotalCount.

Beispiel

Das folgende Logbeispiel zeigt ein scaleDown-Ereignis:

{
  "decision": {
    "decideTime": "1580594665",
    "eventId": "340dac18-8152-46ff-b79a-747f70854c81",
    "scaleDown": {
      "nodesToBeRemoved": [
        {
          "evictedPods": [
            {
              "controller": {
                "apiVersion": "apps/v1",
                "kind": "ReplicaSet",
                "name": "kube-dns-5c44c7b6b6"
              },
              "name": "kube-dns-5c44c7b6b6-xvpbk"
            }
          ],
          "evictedPodsTotalCount": 1,
          "node": {
            "cpuRatio": 23,
            "memRatio": 5,
            "mig": {
              "name": "test-cluster-default-pool-c47ef39f-grp",
              "nodepool": "default-pool",
              "zone": "us-central1-f"
            },
            "name": "test-cluster-default-pool-c47ef39f-p395"
          }
        }
      ]
    }
  }
}

Ereignis "eventResult"

Ein eventResult-Ereignis wird ausgegeben, wenn ein scaleUp- oder scaleDown-Ereignis erfolgreich oder nicht erfolgreich abgeschlossen wird. Dieses Ereignis enthält eine Liste von Ereignis-IDs (aus dem Feld eventId in scaleUp- oder scaleDown-Ereignissen) sowie Fehlermeldungen. Eine leere Fehlermeldung gibt an, dass das Ereignis erfolgreich abgeschlossen wurde. Die eventResult-Ereignisse werden im Feld results aufgelistet.

Informationen zur Diagnose von Fehlern finden Sie in den Abschnitten ScaleUp-Fehler und ScaleDown-Fehler.

Beispiel

Das folgende Logbeispiel zeigt ein eventResult-Ereignis:

{
  "resultInfo": {
    "measureTime": "1582878896",
    "results": [
      {
        "eventId": "2fca91cd-7345-47fc-9770-838e05e28b17"
      },
      {
        "errorMsg": {
          "messageId": "scale.down.error.failed.to.delete.node.min.size.reached",
          "parameters": [
            "test-cluster-default-pool-5c90f485-nk80"
          ]
        },
        "eventId": "ea2e964c-49b8-4cd7-8fa9-fefb0827f9a6"
      }
    ]
  }
}

Ereignis "nodePoolCreated"

Ein nodePoolCreated-Ereignis wird ausgegeben, wenn ein neuer Knotenpool bei aktivierter automatischer Knotenbereitstellung von Cluster Autoscaler erstellt wird. Dieses Ereignis enthält den Namen des erstellten Knotenpools und eine Liste seiner MIGs. Wenn der Knotenpool aufgrund eines scaleUp-Ereignisses erstellt wurde, ist die eventId des entsprechenden scaleUp-Ereignisses im Feld triggeringScaleUpId enthalten.

Beispiel

Das folgende Logbeispiel zeigt ein nodePoolCreated-Ereignis:

{
  "decision": {
    "decideTime": "1585838544",
    "eventId": "822d272c-f4f3-44cf-9326-9cad79c58718",
    "nodePoolCreated": {
      "nodePools": [
        {
          "migs": [
            {
              "name": "test-cluster-nap-n1-standard--b4fcc348-grp",
              "nodepool": "nap-n1-standard-1-1kwag2qv",
              "zone": "us-central1-f"
            },
            {
              "name": "test-cluster-nap-n1-standard--jfla8215-grp",
              "nodepool": "nap-n1-standard-1-1kwag2qv",
              "zone": "us-central1-c"
            }
          ],
          "name": "nap-n1-standard-1-1kwag2qv"
        }
      ],
      "triggeringScaleUpId": "d25e0e6e-25e3-4755-98eb-49b38e54a728"
    }
  }
}

Ereignis "nodePoolDeleted"

Ein nodePoolDeleted-Ereignis wird ausgegeben, wenn ein Knotenpool bei aktivierter automatischer Knotenbereitstellung von Cluster Autoscaler gelöscht wird.

Beispiel

Das folgende Logbeispiel zeigt ein nodePoolDeleted-Ereignis:

{
  "decision": {
    "decideTime": "1585830461",
    "eventId": "68b0d1c7-b684-4542-bc19-f030922fb820",
    "nodePoolDeleted": {
      "nodePoolNames": [
        "nap-n1-highcpu-8-ydj4ewil"
      ]
    }
  }
}

Ereignis "noScaleUp"

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

  • Ereignisse vom Typ "noScaleUp" sind Best-Effort-Ereignisse. Das bedeutet, dass diese Ereignisse nicht alle potenziellen Gründe abdecken, die ein Hochskalieren durch Cluster Autoscaler verhindern.
  • Ereignisse vom Typ "noScaleUp" werden gedrosselt, um das erzeugte Logvolumen zu begrenzen. Jeder andauernde Grund wird nur alle paar Minuten ausgegeben.
  • Alle Gründe können beliebig auf mehrere Ereignisse aufgeteilt werden. Es gibt beispielsweise keine Garantie dafür, dass alle abgelehnten MIG-Gründe für eine einzelne Pod-Gruppe im selben Ereignis angezeigt werden.
  • Die Liste der unbehandelten Pod-Gruppen wird auf 50 beliebige Einträge gekürzt. Die tatsächliche Anzahl der unbehandelten Pod-Gruppen finden Sie im Feld unhandledPodGroupsTotalCount.

Felder für den Grund

Die folgenden Felder verdeutlichen, warum kein Hochskalieren stattgefunden hat:

  • reason: gibt einen globalen Grund an, warum Cluster Autoscaler nicht hochskalieren konnte. Weitere Informationen finden Sie im Abschnitt Gründe auf oberster Ebene für "noScaleUp".
  • napFailureReason: gibt einen globalen Grund an, warum Cluster Autoscaler keine zusätzlichen Knotenpools bereitstellen konnte, z. B. aufgrund einer deaktivierten automatischen Knotenbereitstellung. Weitere Informationen finden Sie im Abschnitt Gründe auf oberster Ebene für "noScaleUp" in Bezug auf die automatische Knotenbereitstellung.
  • skippedMigs[].reason: enthält Informationen darüber, warum eine bestimmte MIG übersprungen wurde. Cluster Autoscaler überspringt während eines Hochskalierungsversuchs einige MIGs für einen Pod, z. B. weil das Hinzufügen eines weiteren Knotens Ressourcenlimits überschreiten würde. Weitere Informationen finden Sie im Abschnitt Gründe auf MIG-Ebene für "noScaleUp".
  • unhandledPodGroups: enthält Informationen darüber, warum eine bestimmte Gruppe nicht planbarer Pods kein Hochskalieren auslöst. Die Pods werden nach ihrem unmittelbaren Controller gruppiert. Pods ohne Controller befinden sich in Gruppen für sich allein. Jede Pod-Gruppe enthält einen beliebigen Beispiel-Pod und die Anzahl der Pods in der Gruppe sowie die folgenden Gründe:

Beispiel

Das folgende Logbeispiel zeigt ein noScaleUp-Ereignis:

{
  "noDecisionStatus": {
    "measureTime": "1582523362",
    "noScaleUp": {
      "skippedMigs": [
        {
          "mig": {
            "name": "test-cluster-nap-n1-highmem-4-fbdca585-grp",
            "nodepool": "nap-n1-highmem-4-1cywzhvf",
            "zone": "us-central1-f"
          },
          "reason": {
            "messageId": "no.scale.up.mig.skipped",
            "parameters": [
              "max cluster cpu limit reached"
            ]
          }
        }
      ],
      "unhandledPodGroups": [
        {
          "napFailureReasons": [
            {
              "messageId": "no.scale.up.nap.pod.zonal.resources.exceeded",
              "parameters": [
                "us-central1-f"
              ]
            }
          ],
          "podGroup": {
            "samplePod": {
              "controller": {
                "apiVersion": "v1",
                "kind": "ReplicationController",
                "name": "memory-reservation2"
              },
              "name": "memory-reservation2-6zg8m",
              "namespace": "autoscaling-1661"
            },
            "totalPodCount": 1
          },
          "rejectedMigs": [
            {
              "mig": {
                "name": "test-cluster-default-pool-b1808ff9-grp",
                "nodepool": "default-pool",
                "zone": "us-central1-f"
              },
              "reason": {
                "messageId": "no.scale.up.mig.failing.predicate",
                "parameters": [
                  "NodeResourcesFit",
                  "Insufficient memory"
                ]
              }
            }
          ]
        }
      ],
      "unhandledPodGroupsTotalCount": 1
    }
  }
}

Ereignis "noScaleDown"

Ein noScaleDown-Ereignis wird regelmäßig ausgegeben, wenn Knoten blockiert sind und daher nicht von Cluster Autoscaler gelöscht werden können.

  • Knoten, die aufgrund einer hohen Auslastung nicht entfernt werden können, werden nicht in noScaleDown-Ereignisse einbezogen.
  • Ereignisse vom Typ "noScaleDown" sind Best-Effort-Ereignisse. Das bedeutet, dass diese Ereignisse nicht alle potenziellen Gründe abdecken, die ein Herunterskalieren durch Cluster Autoscaler verhindern.
  • Ereignisse vom Typ "noScaleDown" werden gedrosselt, um das erzeugte Logvolumen zu begrenzen. Jeder andauernde Grund wird nur alle paar Minuten ausgegeben.
  • Die Liste der Knoten wird auf 50 beliebige Einträge gekürzt. Die tatsächliche Anzahl der Knoten finden Sie im Feld nodesTotalCount.

Felder für den Grund

Die folgenden Felder verdeutlichen, warum kein Herunterskalieren stattgefunden hat:

  • reason: gibt einen globalen Grund an, warum Cluster Autoscaler nicht herunterskalieren konnte, z. B. aufgrund eines Backoff-Zeitraums nach einer kürzlich erfolgten Hochskalierung. Weitere Informationen finden Sie im Abschnitt Gründe auf oberster Ebene für "noScaleDown".
  • nodes[].reason: gibt knotenbezogene Gründe an, warum Cluster Autoscaler einen bestimmten Knoten nicht löschen kann, z. B. weil es keinen Ort gibt, an den die Pods des Knotens verschoben werden können. Weitere Informationen finden Sie im Abschnitt Gründe auf Knotenebene für "noScaleDown".

Beispiel

Das folgende Logbeispiel zeigt ein noScaleDown-Ereignis:

{
  "noDecisionStatus": {
    "measureTime": "1582858723",
    "noScaleDown": {
      "nodes": [
        {
          "node": {
            "cpuRatio": 42,
            "mig": {
              "name": "test-cluster-default-pool-f74c1617-grp",
              "nodepool": "default-pool",
              "zone": "us-central1-c"
            },
            "name": "test-cluster-default-pool-f74c1617-fbhk"
          },
          "reason": {
            "messageId": "no.scale.down.node.no.place.to.move.pods"
          }
        }
      ],
      "nodesTotalCount": 1,
      "reason": {
        "messageId": "no.scale.down.in.backoff"
      }
    }
  }
}

Debuggingszenarien

In diesem Abschnitt finden Sie Anleitungen zum Debuggen von Skalierungsereignissen.

Cluster wird nicht hochskaliert

Szenario: Ich habe einen Pod in meinem Cluster erstellt, der aber seit einer Stunde im Status Ausstehend hängt. Cluster Autoscaler hat keine neuen Knoten für den Pod bereitgestellt.

Lösung:

  1. Suchen Sie in der Loganzeige nach den Logging-Details für Cluster Autoscaler-Ereignisse, wie im Abschnitt Ereignisse ansehen beschrieben.
  2. Suchen Sie nach scaleUp-Ereignissen, die den jeweiligen Pod im Feld triggeringPods enthalten. Sie können die Logeinträge filtern, auch nach einem bestimmten JSON-Feldwert. Weitere Informationen finden Sie unter Erweiterte Logabfragen.

    1. Suchen Sie nach einem EventResult, das dieselbe eventId wie das scaleUp-Ereignis enthält.
    2. Sehen Sie sich das Feld errorMsg an und konsultieren Sie die Liste der potenziellen scaleUp-Fehlermeldungen.

    Beispiel für einen scaleUp-Fehler: Sie stoßen bei einem scaleUp-Ereignis auf den Fehler "scale.up.error.quota.exceeded", der darauf hinweist, dass ein scaleUp-Ereignis fehlgeschlagen ist, weil einige der MIGs aufgrund eines überschrittenen Kontingents nicht erhöht werden konnten. Zum Beheben des Problems prüfen Sie Ihre Kontingenteinstellungen und erhöhen die Einstellungen, die bald überschritten werden. Cluster Autoscaler fügt einen neuen Knoten hinzu und der Pod wird geplant.

  3. Suchen Sie andernfalls nach noScaleUp-Ereignissen und sehen Sie sich folgende Felder an:

    • 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.
  4. In den folgenden Abschnitten finden Sie mögliche Gründe für noScaleUp-Ereignisse:

    Beispiel für "noScaleUp": 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". Nach Durchsicht der Liste der Fehlermeldungen stellen Sie fest, dass Sie eine MIG nicht hochskalieren können, weil ein Prädikat dafür fehlgeschlagen ist. Die Parameter geben den Namen des fehlgeschlagenen Prädikats und den jeweiligen Grund an. Zum Beheben des Problems prüfen Sie die Pod-Spezifikation und stellen fest, dass sie einen Knotenselektor enthält, der keiner MIG im Cluster entspricht. Sie löschen den Selektor aus der Pod-Spezifikation und erstellen den Pod neu. Cluster Autoscaler fügt einen neuen Knoten hinzu und der Pod wird geplant.

  5. Wenn keine noScaleUp-Ereignisse vorhanden sind, beheben Sie das Problem mit anderen Debuggingmethoden.

Cluster wird nicht herunterskaliert

Szenario: In meinem Cluster befindet sich ein Knoten, der in den letzten Tagen nur 10 % seiner CPU und seines Arbeitsspeichers genutzt hat. Trotz der geringen Auslastung hat Cluster Autoscaler den Knoten nicht wie erwartet gelöscht.

Lösung:

  1. Suchen Sie in der Loganzeige nach den Logging-Details für Cluster Autoscaler-Ereignisse, wie im Abschnitt Ereignisse ansehen beschrieben.
  2. Suchen Sie nach scaleDown-Ereignissen, die den jeweiligen Knoten im Feld nodesToBeRemoved enthalten. Sie können die Logeinträge filtern, auch nach einem bestimmten JSON-Feldwert. Weitere Informationen finden Sie unter Erweiterte Logabfragen.
    1. Suchen Sie im scaleDown-Ereignis nach einem EventResult-Ereignis, das die zugehörige eventId enthält.
    2. Sehen Sie sich das Feld errorMsg an und konsultieren Sie die Liste der potenziellen scaleDown-Fehlermeldungen.
  3. Suchen Sie andernfalls nach noScaleDown-Ereignissen, die den jeweiligen Knoten im Feld nodes enthalten. Prüfen Sie das Feld reason auf globale Gründe, die darauf hinweisen, dass das Herunterskalieren möglicherweise blockiert wird.
  4. In den folgenden Abschnitten finden Sie mögliche Gründe für noScaleDown-Ereignisse:

    Beispiel für "noScaleDown": Sie sind auf ein noScaleDown-Ereignis gestoßen, das einen knotenbezogenen Grund für Ihren Knoten enthält. Die Meldungs-ID lautet "no.scale.down.node.pod.has.local.storage" und enthält einen einzigen Parameter: "test-single-pod". Nach Durchsicht der Liste der Fehlermeldungen stellen Sie fest, dass der Pod das Herunterskalieren blockiert, weil er lokalen Speicher anfordert. Sie lesen die FAQ zu Kubernetes Cluster Autoscaler und finden heraus, dass sich das Problem durch Hinzufügen der Anmerkung "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" zum Pod lösen lässt. Nachdem die Anmerkung angewendet wurde, skaliert Cluster Autoscaler den Cluster korrekt herunter.

  5. Wenn keine noScaleDown-Ereignisse vorhanden sind, beheben Sie das Problem mit anderen Debuggingmethoden.

Meldungen

Die von Cluster Autoscaler ausgegebenen Ereignisse verwenden parametrisierte Meldungen (im Feld messageId) zur Erläuterung des Ereignisses.

In diesem Abschnitt werden verschiedene messageIds und die zugehörigen Parameter beschrieben. Der Abschnitt enthält jedoch nicht alle möglichen Meldungen und kann jederzeit erweitert werden.

ScaleUp-Fehler

Fehlermeldungen für scaleUp-Ereignisse werden im entsprechenden eventResult-Ereignis im Feld resultInfo.results[].errorMsg angezeigt.

Meldung Beschreibung

"scale.up.error.out.of.resources"
Das scaleUp-Ereignis ist fehlgeschlagen, da einige MIGs aufgrund fehlender Ressourcen nicht erhöht werden konnten.

Parameter: IDs der fehlgeschlagenen MIGs.


"scale.up.error.quota.exceeded"
Das scaleUp-Ereignis ist fehlgeschlagen, da einige MIGs aufgrund eines überschrittenen Compute Engine-Kontingents nicht erhöht werden konnten.

Parameter: IDs der fehlgeschlagenen MIGs.


"scale.up.error.waiting.for.instances.timeout"
Das scaleUp-Ereignis ist fehlgeschlagen, da Instanzen in einigen MIGs nicht rechtzeitig angezeigt wurden.

Parameter: IDs der fehlgeschlagenen MIGs.

ScaleDown-Fehler

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

Meldung Beschreibung

"scale.down.error.failed.to.mark.to.be.deleted"
Das scaleDown-Ereignis ist fehlgeschlagen, da ein Knoten nicht zum Löschen markiert werden konnte.

Parameter: Name des fehlgeschlagenen Knotens.


"scale.down.error.failed.to.evict.pods"
Das scaleDown-Ereignis ist fehlgeschlagen, da einige Pods nicht aus einem Knoten entfernt werden konnten.

Parameter: Name des fehlgeschlagenen Knotens.


"scale.down.error.failed.to.delete.node.min.size.reached"
Das scaleDown-Ereignis ist fehlgeschlagen, da ein Knoten aufgrund der bereits erreichten Mindestgröße des Clusters nicht gelöscht werden konnte.

Parameter: Name des fehlgeschlagenen Knotens.

Gründe für ein noScaleUp-Ereignis

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 Beschreibung

"no.scale.up.in.backoff"
Ein noScaleUp-Ereignis ist aufgetreten, da das Hochskalieren in einen Backoff-Zeitraum fällt (vorübergehend blockiert ist).

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 Beschreibung

"no.scale.up.nap.disabled"
Die automatische Knotenbereitstellung hat keine Knotengruppen bereitgestellt, da sie deaktiviert war. Weitere Informationen finden Sie unter Automatische Knotenbereitstellung aktivieren.

"no.scale.up.nap.no.locations.available"
Die automatische Knotenbereitstellung hat keine Knotengruppen bereitgestellt, da keine Orte für die automatische Knotenbereitstellung verfügbar waren.

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 Beschreibung

"no.scale.up.mig.skipped"
Eine MIG kann nicht hochskaliert werden, da sie während der Simulation übersprungen wurde.

Parameter: für Menschen lesbare Gründe für das Überspringen.


"no.scale.up.mig.failing.predicate"
Eine MIG kann nicht hochskaliert werden, da ein Prädikat für die MIG fehlgeschlagen ist.

Parameter: Name des fehlgeschlagenen Prädikats; für Menschen lesbare Gründe für den Fehler

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 für eine bestimmte Pod-Gruppe bereitstellen kann.

Meldung Beschreibung

"no.scale.up.nap.pod.gpu.no.limit.defined"
Die automatische Knotenbereitstellung hat keine Knotengruppe für den Pod bereitgestellt, da der Pod eine GPU-Anfrage gestellt hat und für die GPU kein Limit definiert ist.

Parameter: angeforderter GPU-Typ.


"no.scale.up.nap.pod.gpu.type.not.supported"
Die automatische Knotenbereitstellung hat keine Knotengruppe für den Pod bereitgestellt, da eine nicht unterstützte GPU angegeben ist. Weitere Informationen finden Sie unter GPU-Limits konfigurieren.

Parameter: angeforderter GPU-Typ.


"no.scale.up.nap.pod.gpu.other.error"
Die automatische Knotenbereitstellung hat aufgrund anderer Probleme mit der GPU-Konfiguration keine Knotengruppe für den Pod bereitgestellt. Weitere Informationen finden Sie unter GPU-Limits konfigurieren.

"no.scale.up.nap.pod.zonal.resources.exceeded"
Die automatische Knotenbereitstellung hat keine Knotengruppe für den Pod in dieser Zone bereitgestellt, da dies gegen die Ressourcenlimits verstoßen würde.

Parameter: Name der betreffenden Zone.


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

Parameter: Name der betreffenden Zone; für Menschen lesbare Gründe, warum Prädikate fehlgeschlagen sind.

Gründe für ein noScaleDown-Ereignis

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.

Meldung Beschreibung

"no.scale.down.in.backoff"
Ein noScaleDown-Ereignis ist aufgetreten, da das Herunterskalieren in einen Backoff-Zeitraum fällt (vorübergehend blockiert ist).

"no.scale.down.in.progress"
Ein noScaleDown-Ereignis ist aufgetreten, da ein vorheriges scaleDown-Ereignis noch läuft.

Gründe auf Knotenebene für "noScaleDown"

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

Meldung Beschreibung

"no.scale.down.node.scale.down.disabled.annotation"
Der Knoten kann nicht entfernt werden, da er die Anmerkung "scale down disabled" enthält. Weitere Informationen finden Sie in den FAQ zu Kubernetes Cluster Autoscaler.

"no.scale.down.node.node.group.min.size.reached"
Der Knoten kann nicht entfernt werden, da seine Knotengruppe bereits die Mindestgröße hat.

"no.scale.down.node.minimal.resource.limits.exceeded"
Der Knoten kann nicht entfernt werden, da dies gegen clusterweite Mindestressourcenlimits verstoßen würde.

"no.scale.down.node.no.place.to.move.pods"
Der Knoten kann nicht entfernt werden, da es keinen Ort gibt, an den seine Pods verschoben werden können.

"no.scale.down.node.pod.not.backed.by.controller"
Der Pod blockiert das Herunterskalieren, da er nicht von einem Controller gestützt wird. Weitere Informationen finden Sie in den FAQ zu Kubernetes Cluster Autoscaler.

Parameter: Name des blockierenden Pods.


"no.scale.down.node.pod.has.local.storage"
Der Pod blockiert das Herunterskalieren, da er lokalen Speicher anfordert. Weitere Informationen finden Sie in den FAQ zu Kubernetes Cluster Autoscaler.

Parameter: Name des blockierenden Pods.


"no.scale.down.node.pod.not.safe.to.evict.annotation"
Der Pod blockiert das Herunterskalieren, da er die Anmerkung "not safe to evict" enthält. Weitere Informationen finden Sie in den FAQ zu Kubernetes Cluster Autoscaler.

Parameter: Name des blockierenden Pods.


"no.scale.down.node.pod.kube.system.unmovable"
Der Pod blockiert das Herunterskalieren, da er ein nicht gespiegelter und nicht pdb-zugewiesener Kube-System-Pod ohne Daemonset ist. Weitere Informationen finden Sie in den FAQ zu Kubernetes Cluster Autoscaler.

Parameter: Name des blockierenden Pods.


"no.scale.down.node.pod.not.enough.pdb"
Der Pod blockiert das Herunterskalieren, da nicht genügend PodDisruptionBudget übrig ist. Weitere Informationen finden Sie in den FAQ zu Kubernetes Cluster Autoscaler.

Parameter: Name des blockierenden Pods.

Nächste Schritte