Cluster Autoscaler-Ereignisse ansehen

Auf dieser Seite werden die Entscheidungen beschrieben, die der Cluster Autoscaler von Google Kubernetes Engine (GKE) über Autoscaling trifft.

GKE Cluster Autoscaler gibt Sichtbarkeitsereignisse aus, die als Logeinträge in Cloud Logging verfügbar sind.

Hinweis: Die in dieser Anleitung beschriebenen Ereignisse unterscheiden sich von den Kubernetes-Ereignissen, die von Cluster Autoscaler erzeugt werden.

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

Damit Autoscaling-Ereignisse angezeigt werden, müssen Sie in Ihrem Cluster Cloud Logging aktivieren. Die Ereignisse werden nicht erstellt, wenn Logging deaktiviert ist.

Termine 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. Sie können diese Ereignisse auch in den Benachrichtigungen auf der Google Kubernetes Engine-Seite in der Google Cloud Console aufrufen.

Sichtbarkeits-Ereignisprotokolle ansehen

So sehen Sie sich die Logs an:

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

    Zu „Kubernetes-Cluster“

  2. Wählen Sie den Namen des Clusters aus, um die jeweilige Seite mit den Clusterdetails aufzurufen.

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

  4. Klicken Sie auf dem Tab Logs auf den Tab Autoscaling-Logs, um die Logs aufzurufen.

  5. (Optional) Wenn Sie erweiterte Filter anwenden möchten, um die Ergebnisse einzugrenzen, klicken Sie auf die Schaltfläche mit dem Pfeil rechts auf der Seite, um die Logs im Log-Explorer aufzurufen.

Benachrichtigungen zu Sichtbarkeitsereignissen ansehen

Führen Sie die folgenden Schritte aus, um Sichtbarkeitsereignisbenachrichtigungen auf der Google Kubernetes Engine-Seite aufzurufen:

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

    Zur Seite „Google Kubernetes Engine“

  2. In der Spalte Benachrichtigungen finden Sie Benachrichtigungen zu bestimmten Clustern.

  3. Klicken Sie auf die Benachrichtigung, um detaillierte Informationen, empfohlene Maßnahmen und den Zugriff auf die Logs für dieses Ereignis aufzurufen.

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. Autoscaling erhöht die Größe der Knotenpools des Clusters, indem die zugrunde liegenden verwalteten Instanzgruppen (MIGs) für die Knotenpools hochskaliert werden. Weitere Informationen zur Funktionsweise von vertikalem Hochskalieren finden Sie in den FAQ zum Kubernetes Cluster Autoscaler unter Funktionsweise von vertikalem Hochskalieren.

Das Ereignis enthält Informationen darüber, welche 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. Weitere Informationen zur Funktionsweise von vertikalem Herunterskalieren finden Sie in den FAQ zum Kubernetes Cluster Autoscaler unter Funktionsweise von vertikalem Herunterskalieren.

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.

Mit der folgenden Abfrage können Sie prüfen, ob Cluster Autoscaler die Knoten herunterskaliert hat.

resource.type="k8s_cluster" \
resource.labels.location=COMPUTE_REGION \
resource.labels.cluster_name=CLUSTER_NAME \
log_id("container.googleapis.com/cluster-autoscaler-visibility") \
( "decision" NOT "noDecisionStatus" )

Dabei gilt:

  • CLUSTER_NAME ist der Name des Clusters.

  • COMPUTE_REGION: Die Compute Engine-Region des Clusters, z. B. us-central1.

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"
          }
        }
      ]
    }
  }
}

Sie können das Ereignis scale-down auch auf den Knoten anzeigen, ohne dass Arbeitslast ausgeführt wird (in der Regel nur System-Pods, die von DaemonSets erstellt wurden). Verwenden Sie die folgende Abfrage, um die Ereignislogs aufzurufen:

resource.type="k8s_cluster" \
resource.labels.project_id=PROJECT_ID \
resource.labels.location=COMPUTE_REGION \
resource.labels.cluster_name=CLUSTER_NAME \
severity>=DEFAULT \
logName="projects/PROJECT_ID/logs/events" \
("Scale-down: removing empty node")

Dabei gilt:

  • PROJECT_ID ist Ihre Projekt-ID.

  • CLUSTER_NAME ist der Name des Clusters.

  • COMPUTE_REGION: Die Compute Engine-Region des Clusters, z. B. us-central1.

EventResult-Ereignis

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 zugrundeliegenden 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"
      }
    }
  }
}

Fehlerbehebung bei Skalierungsproblemen

In diesem Abschnitt finden Sie Anleitungen zur Fehlerbehebung bei 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 im Log-Explorer 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 im Log-Explorer 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.

Messages

Die von Cluster Autoscaler ausgegebenen Ereignisse verwenden parametrisierte Meldungen, um Erläuterungen für das Ereignis zu liefern. Das Feld parameters ist mit dem Feld messageId verfügbar, z. B. in diesem Beispiellog für ein NoScaleUp-Ereignis.

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

 Folgen Sie den Schritten zur Fehlerbehebung für die Ressourcenverfügbarkeit.
"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.

 Auf dem Tab Fehler der MIG in der Google Cloud Console können Sie sehen, welches Kontingent überschritten wird. Folgen Sie der Anleitung, um eine Kontingenterhöhung anzufordern.
"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.

 Diese Nachricht ist nur temporär. Wenn die Nachricht weiterhin angezeigt wird, wenden Sie sich an den Google Cloud-Support.
"scale.up.error.ip.space.exhausted" Das scaleUp-Ereignis ist fehlgeschlagen, da der Cluster keinen ausreichenden nicht zugewiesenen IP-Adressbereich hat, der zum Hinzufügen neuer Knoten oder Pods verwendet werden kann.

Parameter: IDs der fehlgeschlagenen MIGs.

 Lesen Sie die Schritte zur Fehlerbehebung, um den fehlenden IP-Adressbereich für die Knoten oder Pods zu beheben.
"scale.up.error.service.account.deleted" Das scaleUp-Ereignis ist fehlgeschlagen, da ein von Cluster Autoscaler verwendetes Dienstkonto gelöscht wurde.

Parameter: IDs der fehlgeschlagenen MIGs.

 Wenden Sie sich zur weiteren Prüfung an den Google Cloud-Support.

ScaleDown-Fehler

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

Meldung Beschreibung Risikominderung
"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.

 Diese Nachricht ist nur temporär. Wenn die Nachricht weiterhin angezeigt wird, wenden Sie sich an den Google Cloud-Support.
"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.

 Lesen Sie die Best Practices für Budgets für Pod-Störungen, um sicherzustellen, dass die Regeln das Entfernen von Anwendungsreplikaten nach Möglichkeit zulassen.
"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.

 Prüfen Sie den für Autoscaling von Knotenpools festgelegten Mindestwert und passen Sie die Einstellungen nach Bedarf an.

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 Risikominderung
"no.scale.up.in.backoff" Ein noScaleUp-Ereignis ist aufgetreten, da das Hochskalieren in einen Backoff-Zeitraum fällt (vorübergehend blockiert ist). Dies ist eine temporäre Nachricht, die während einer vertikalen Skalierung mit einer großen Anzahl von Pods auftreten kann. Wenn diese Meldung weiterhin angezeigt wird, wenden Sie sich an den Google Cloud-Support.

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 Risikominderung
"no.scale.up.nap.disabled" Die automatische Knotenbereitstellung ist auf Clusterebene nicht aktiviert. 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 Bereitstellung von Knoten 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 Beschreibung Risikominderung
"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 (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" Eine MIG kann nicht hochskaliert werden, da sie die Prädikatsanforderungen für die ausstehenden Pods nicht erfüllt.

Parameter: Name des fehlgeschlagenen Prädikats; für Menschen lesbare 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 für eine bestimmte Pod-Gruppe bereitstellen kann.

Meldung Beschreibung 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.

Parameter: 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.

Parameter: 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.

Parameter: 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.

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

 Prüfen Sie die Anforderungen des ausstehenden Pods, z. B. Affinitätsregeln, Markierungen, Toleranzen oder Ressourcenanforderungen.

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 Risikominderung
"no.scale.down.in.backoff" Ein noScaleDown-Ereignis ist aufgetreten, da das Herunterskalieren in einen Backoff-Zeitraum fällt (vorübergehend blockiert ist). Dieses Ereignis sollte nur vorübergehend sein und auftreten, wenn es in letzter Zeit ein Hochskalierungsereignis gab. Folgen Sie den Schritten zur Behebung, die mit den untergeordneten Gründen für das Fehlschlagen des Herunterskalierens verbunden sind. Wenn die zugrunde liegenden Gründe behoben wurden, beendet Cluster Autoscaler den Backoff. Wenn die Nachricht noch immer angezeigt wird, nachdem Sie die zugrunde liegenden Gründe behoben haben, wenden Sie sich an den Google Cloud-Support.
"no.scale.down.in.progress" Ein noScaleDown-Ereignis ist aufgetreten, da das Herunterskalieren blockiert wird, bis der vorherige Knoten, der gelöscht werden soll, gelöscht wird. Dieses Ereignis sollte nur vorübergehend auftreten, da der Pod letztendlich zwangsweise entfernt wird. Wenn diese Meldung häufig angezeigt wird, können Sie den Wert gracefulTerminationPeriod für die Pods prüfen, die das Herunterskalieren verhindern. Wenn das Problem schneller behoben werden soll, können Sie den Pod auch zwangsweise 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 Feld noDecisionStatus.noScaleDown.nodes[].reason angezeigt. Die Meldung enthält einen Grund, warum Cluster Autoscaler einen bestimmten Knoten nicht entfernen kann.

Meldung Beschreibung Risikominderung
"no.scale.down.node.scale.down.disabled.annotation" Der Knoten kann nicht entfernt werden, da er die Annotation scale-down-disabled hat. Beachten Sie die Annotation, die das Herunterskalieren verhindert. Folgen Sie dazu der Anleitung in den FAQ zum 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. Prüfen Sie den für Autoscaling von Knotenpools festgelegten Mindestwert und passen Sie ihn an.
"no.scale.down.node.minimal.resource.limits.exceeded" Das Herunterskalieren eines nicht ausgelasteten Knotens wird blockiert, da es gegen die clusterweiten Mindestressourcenlimits für die automatische Knotenbereitstellung verstoßen würde. Prüfen Sie die clusterweiten Mindestressourcenlimits.
"no.scale.down.node.no.place.to.move.pods" Das Herunterskalieren eines nicht ausgelasteten Knotens wird blockiert, da er einen Pod ausführt, der nicht auf einen anderen Knoten im Cluster verschoben werden kann. 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. Diese Nachricht wird erwartet, wenn Sie nicht davon ausgehen, dass der Pod neu geplant wird, da es keine anderen Knoten gibt, für die er geplant werden kann.
"no.scale.down.node.pod.not.backed.by.controller" Der Pod blockiert das Herunterskalieren eines nicht ausgelasteten Knotens, da der Pod keinen dem Kubernetes Cluster Autoscaler bekannten Controller hat (ReplicationController, DaemonSet, Job, StatefulSet oder ReplicaSet). Weitere Informationen dazu, welche Pod-Typen Cluster Autoscaler am Entfernen von Knoten hindern können, finden Sie in den FAQ zu Kubernetes Cluster Autoscaler.

Parameter: Name des blockierenden Pods.

 Legen Sie für den Pod eine Annotation "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" fest oder definieren Sie einen Controller (ReplicationController, DaemonSet, Job, StatefulSet oder ReplicaSet).
"no.scale.down.node.pod.has.local.storage" Der Pod blockiert das Herunterskalieren, da er lokalen Speicher anfordert. Weitere Informationen dazu, welche Pod-Typen Cluster Autoscaler am Entfernen von Knoten hindern können, finden Sie in den FAQ zu Kubernetes Cluster Autoscaler.

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

 Wenn der Pod sicher entfernt werden kann, aktualisieren Sie die Annotation auf "cluster-autoscaler.kubernetes.io/safe-to-evict": "true".
"no.scale.down.node.pod.kube.system.unmovable" Der Pod blockiert das Herunterskalieren, da er ein Nicht-DaemonSet und nicht gespiegelter Pod ohne PodDisruptionBudget im kube-system-Namespace ist.

Parameter: Name des blockierenden Pods.

 Folgen Sie der Anleitung in den FAQ zu Kubernetes Cluster Autoscaler, um einen PodDisruptionBudget festzulegen, damit Cluster Autoscaler Pods im Namespace kube-system verschieben kann.
"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.

 Prüfen Sie den PodDisruptionBudget für den Pod. Weitere Informationen finden Sie unter Best Practices für PodDisruptionBudget. Sie können die Nachricht möglicherweise auflösen, indem Sie die Anwendung skalieren oder PodDisruptionBudget ändern, um mehr nicht verfügbare Pods zu ermöglichen.
"no.scale.down.node.pod.controller.not.found" Der Pod blockiert das Herunterskalieren, da der Controller (z. B. Deployment oder ReplicaSet) nicht gefunden werden kann. Prüfen Sie die Logs, um festzustellen, welche Maßnahmen ergriffen wurden, wodurch ein Pod weiterhin ausgeführt wurde, nachdem der Controller entfernt wurde. Zur Behebung können Sie den Pod manuell löschen.
"no.scale.down.node.pod.unexpected.error" Das Herunterskalieren eines nicht ausgelasteten Knotens wird blockiert, da er einen Pod mit einem unerwarteten Fehlerstatus enthält. Wenden Sie sich zur weiteren Prüfung an den GCP-Support.

Nächste Schritte