Cluster-Autoscaling-Ereignisse ansehen

Auf dieser Seite finden Sie Informationen zu Sichtbarkeitsereignissen, die von Cluster Autoscaler in der Google Kubernetes Engine (GKE) ausgegeben werden. Wenn Sie diese Ereignisse analysieren, erhalten Sie Informationen dazu, wie Cluster Autoscaler die Skalierung Ihres Clusters verwaltet, und können die Gründe für die jeweiligen Entscheidungen nachvollziehen.

GKE Cluster Autoscaler gibt Sichtbarkeitsereignisse aus, die als Logeinträge in Cloud Logging verfügbar sind. Die in dieser Anleitung beschriebenen Ereignisse unterscheiden sich von den Kubernetes-Ereignissen, die von Cluster Autoscaler erzeugt werden.

Voraussetzungen

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 im 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 die Knoten durch Cluster Autoscaler herunterskaliert wurden:

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

Ersetzen Sie Folgendes:

  • 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 sich das Ereignis scale-down auch auf den Knoten ansehen, auf denen keine Arbeitslast ausgeführt wird (in der Regel nur System-Pods, die von DaemonSets erstellt wurden).

Verwenden Sie die folgende Abfrage, um die Ereignisprotokolle 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")

Ersetzen Sie dabei Folgendes:

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

Meldungen

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

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

Meldung Details Parameter Risikominderung
"scale.up.error.out.of.resources" Ressourcenfehler treten auf, wenn Sie versuchen, neue Ressourcen in einer Zone anzufordern, die aufgrund der aktuellen Nichtverfügbarkeit einer Compute Engine-Ressource (z. B. GPUs oder CPUs) Ihre Anfrage nicht bearbeiten kann. IDs der fehlgeschlagenen MIGs. Folgen Sie der Fehlerbehebung für die Ressourcenverfügbarkeit in der Compute Engine-Dokumentation.
"scale.up.error.quota.exceeded" Das scaleUp-Ereignis ist fehlgeschlagen, da einige MIGs aufgrund eines überschrittenen Compute Engine-Kontingents nicht erhöht werden konnten. IDs der fehlgeschlagenen MIGs. Auf dem Tab Fehler der MIG in der Google Cloud Console können Sie sehen, welches Kontingent überschritten wird. Wenn Sie wissen, welches Kontingent überschritten wird, folgen Sie der Anleitung, um eine Kontingenterhöhung anzufordern.
"scale.up.error.waiting.for.instances.timeout" Das Hochskalieren der verwalteten Instanzgruppe ist aufgrund einer Zeitüberschreitung fehlgeschlagen. IDs der fehlgeschlagenen MIGs. Diese Meldung sollte nur temporär sein. Wenn sie weiterhin angezeigt wird, wenden Sie sich an Cloud Customer Care, um weitere Unterstützung zu erhalten.
"scale.up.error.ip.space.exhausted" Hochskalieren nicht möglich, da Instanzen in einigen der verwalteten Instanzgruppen keine IP-Adressen mehr zur Verfügung hatten. Das bedeutet, dass der Cluster nicht genügend nicht zugewiesenen IP-Adressbereich hat, um neue Knoten oder Pods hinzuzufügen. IDs der fehlgeschlagenen MIGs. Folgen Sie der Anleitung unter Zu wenig freier IP-Adressbereich für Pods.
"scale.up.error.service.account.deleted" Hochskalieren nicht möglich, da das Dienstkonto gelöscht wurde. IDs der fehlgeschlagenen MIGs. Versuchen Sie, das Dienstkonto wiederherzustellen. Wenn das nicht funktioniert, wenden Sie sich an Cloud Customer Care, um das Problem weiter untersuchen zu lassen.

Gründe für ein noScaleUp-Ereignis

Ein noScaleUp-Ereignis wird regelmäßig ausgegeben, wenn der Cluster nicht planbare Pods enthält und von Cluster Autoscaler nicht hochskaliert werden kann, um die Pods zu planen. noScaleUp-Ereignisse sind Best-Effort-Ereignisse und decken nicht alle potenziellen Fälle ab.

Gründe auf oberster Ebene für "NoScaleUp"

Meldungen mit Gründen auf oberster Ebene für noScaleUp-Ereignisse werden im Feld noDecisionStatus.noScaleUp.reason angezeigt. Die Meldung enthält einen Grund auf oberster Ebene, warum Cluster Autoscaler den Cluster nicht hochskalieren kann.

Meldung Details Risikominderung
"no.scale.up.in.backoff" Hochskalieren nicht möglich, da der Vorgang in einen Backoff-Zeitraum fällt (vorübergehend blockiert ist). Diese Meldung kann während einer vertikalen Skalierung mit einer großen Anzahl von Pods auftreten. Diese Meldung sollte nur temporär sein. Prüfen Sie diesen Fehler nach einigen Minuten noch einmal. Wenn diese Meldung weiterhin angezeigt wird, wenden Sie sich an Cloud Customer Care, um das Problem untersuchen zu lassen.

Gründe auf oberster Ebene für "noScaleUp" in Bezug auf die automatische Knotenbereitstellung

Meldungen mit Gründen auf oberster Ebene für noScaleUp-Ereignisse in Bezug auf die automatische Knotenbereitstellung werden im Feld noDecisionStatus.noScaleUp.napFailureReason angezeigt. Die Meldung enthält einen Grund auf oberster Ebene, warum Cluster Autoscaler keine neuen Knotenpools bereitstellen kann.

Meldung Details Risikominderung
"no.scale.up.nap.disabled"

Die automatische Knotenbereitstellung konnte nicht hochskaliert werden, da sie auf Clusterebene nicht aktiviert ist.

Wenn die automatische Knotenbereitstellung deaktiviert ist, werden neue Knoten nicht automatisch bereitgestellt, wenn der ausstehende Pod Anforderungen hat, die von vorhandenen Knotenpools nicht erfüllt werden können.

 Prüfen Sie die Clusterkonfiguration und lesen Sie den Abschnitt Automatische Knotenbereitstellung aktivieren.

Gründe auf MIG-Ebene für "noScaleUp"

Meldungen mit Gründen auf MIG-Ebene für noScaleUp-Ereignisse werden in den Feldern noDecisionStatus.noScaleUp.skippedMigs[].reason und noDecisionStatus.noScaleUp.unhandledPodGroups[].rejectedMigs[].reason angezeigt. Die Meldung enthält einen Grund, warum Cluster Autoscaler die Größe einer bestimmten MIG nicht erhöhen kann.

Meldung Details Parameter Risikominderung
"no.scale.up.mig.skipped" Eine MIG kann nicht hochskaliert werden, da sie während der Simulation übersprungen wurde. Gründe, warum die MIG übersprungen wurde (z. B. fehlende Pod-Anforderung). Prüfen Sie die in der Fehlermeldung enthaltenen Parameter und geben Sie an, warum die MIG übersprungen wurde.
"no.scale.up.mig.failing.predicate" Hochskalieren eines Knotenpools aufgrund eines fehlgeschlagenen Planungsprädikats für die ausstehenden Pods nicht möglich. Name des fehlgeschlagenen Prädikats und Gründe für den Fehler. Überprüfen Sie sowohl Pod-Anforderungen wie Affinitätsregeln, Markierungen oder Toleranzen als auch Ressourcenanforderungen.

Gründe auf Pod-Gruppenebene für "noScaleUp" in Bezug auf die automatische Knotenbereitstellung

Meldungen mit Gründen auf Pod-Gruppenebene für noScaleUp-Ereignisse in Bezug auf die automatische Knotenbereitstellung werden im Feld noDecisionStatus.noScaleUp.unhandledPodGroups[].napFailureReasons[] angezeigt. Die Meldung enthält einen Grund, warum Cluster Autoscaler keinen neuen Knotenpool zur Planung einer bestimmten Pod-Gruppe bereitstellen kann.

Meldung Details Parameter Risikominderung
"no.scale.up.nap.pod.gpu.no.limit.defined" Die automatische Knotenbereitstellung konnte keine Knotengruppe bereitstellen, da ein ausstehender Pod eine GPU-Anfrage hat, die GPU-Ressourcenlimits jedoch nicht auf Clusterebene definiert sind. Angeforderter GPU-Typ. Prüfen Sie die GPU-Anfrage des ausstehenden Pods und aktualisieren Sie die Konfiguration des Knotens für die automatische Bereitstellung von GPU-Limits auf Clusterebene.
"no.scale.up.nap.pod.gpu.type.not.supported" Die automatische Knotenbereitstellung hat keine Knotengruppe für den Pod bereitgestellt, da sie Anfragen für einen unbekannten GPU-Typ enthält. Angeforderter GPU-Typ. Prüfen Sie, ob die Konfiguration des ausstehenden Pods des GPU-Typs mit einem unterstützten GPU-Typ übereinstimmt.
"no.scale.up.nap.pod.zonal.resources.exceeded" Die automatische Knotenbereitstellung hat keine Knotengruppe für den Pod in dieser Zone bereitgestellt, da dies entweder gegen die maximalen Ressourcenlimits von Clustern verstoßen oder die verfügbaren Ressourcen in der Zone überschreiten würde. Oder es gibt keinen Maschinentyp, der in die Anfrage passen könnte. Name der betreffenden Zone. Prüfen und aktualisieren Sie clusterweite maximale Ressourcenlimits, die Pod-Ressourcenanfragen oder die verfügbaren Zonen für die automatische Knotenbereitstellung.
"no.scale.up.nap.pod.zonal.failing.predicates" Die automatische Knotenbereitstellung hat aufgrund fehlgeschlagener Prädikate keine Knotengruppe für den Pod in dieser Zone bereitgestellt. Name der betreffenden Zone und Gründe, warum Prädikate fehlgeschlagen sind. Prüfen Sie die Anforderungen des ausstehenden Pods, z. B. Affinitätsregeln, Markierungen, Toleranzen oder Ressourcenanforderungen.

ScaleDown-Fehler

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

Ereignisnachricht Details Parameter Risikominderung
"scale.down.error.failed.to.mark.to.be.deleted" Ein Knoten konnte nicht zum Löschen markiert werden. Name des fehlgeschlagenen Knotens. Diese Meldung sollte nur temporär sein. Wenn sie weiterhin angezeigt wird, wenden Sie sich an Cloud Customer Care, um weitere Unterstützung zu erhalten.
"scale.down.error.failed.to.evict.pods" Cluster Autoscaler kann nicht herunterskalieren, da einige Pods nicht aus einem Knoten entfernt werden konnten. Name des fehlgeschlagenen Knotens. Überprüfen Sie das PodDisruptionBudget für den Pod und achten Sie darauf, dass die Regeln das Entfernen von Anwendungsreplikaten nach Möglichkeit zulassen. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Unterbrechungsbudget für Ihre Anwendung festlegen.
"scale.down.error.failed.to.delete.node.min.size.reached" Cluster Autoscaler kann nicht herunterskalieren, da ein Knoten aufgrund der bereits erreichten Mindestgröße des Clusters nicht gelöscht werden konnte. Name des fehlgeschlagenen Knotens. Prüfen Sie den für Autoscaling von Knotenpools festgelegten Mindestwert und passen Sie die Einstellungen nach Bedarf an. Weitere Informationen finden Sie unter Fehler: Knoten im Cluster haben die Mindestgröße erreicht.

Gründe für ein noScaleDown-Ereignis

Ein noScaleDown-Ereignis wird regelmäßig ausgegeben, wenn Knoten blockiert sind und daher nicht von Cluster Autoscaler gelöscht werden können. noScaleDown-Ereignisse sind Best-Effort-Ereignisse und decken nicht alle potenziellen Fälle ab.

Gründe auf oberster Ebene für "NoScaleDown"

Meldungen mit Gründen auf oberster Ebene für noScaleDown-Ereignisse werden im Feld noDecisionStatus.noScaleDown.reason angezeigt. Die Meldung enthält einen Grund auf oberster Ebene, warum Cluster Autoscaler den Cluster nicht herunterskalieren kann.

Ereignisnachricht Details Risikominderung
"no.scale.down.in.backoff" Cluster Autoscaler kann nicht herunterskalieren, da dieser Vorgang in einen Backoff-Zeitraum fällt (vorübergehend blockiert ist).

Diese Meldung sollte nur vorübergehend sein und kann auftreten, wenn in letzter Zeit hochskaliert wurde.

Wenn die Meldung weiterhin angezeigt wird, wenden Sie sich an Cloud Customer Care, um das Problem untersuchen zu lassen.
"no.scale.down.in.progress"

Cluster Autoscaler kann nicht herunterskalieren, da noch eine vorherige Herunterskalierung ausgeführt wurde.

 Diese Meldung sollte nur temporär sein, da der Pod letztendlich entfernt wird. Wenn diese Meldung häufig angezeigt wird, prüfen Sie den Kulanzzeitraum für die Beendigung der Pods, die das Herunterskalieren verhindern. Wenn das Problem schneller behoben werden soll, können Sie den Pod auch löschen, wenn er nicht mehr benötigt wird.

Gründe auf Knotenebene für "noScaleDown"

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

Ereignisnachricht Details Parameter Risikominderung
"no.scale.down.node.scale.down.disabled.annotation" Cluster Autoscaler kann einen Knoten nicht aus dem Knotenpool entfernen, da der Knoten mit cluster-autoscaler.kubernetes.io/scale-down-disabled: true gekennzeichnet ist. – Cluster Autoscaler überspringt Knoten mit dieser Annotation, ohne ihre Auslastung zu berücksichtigen. Diese Meldung wird unabhängig vom Auslastungsfaktor des Knotens protokolliert. Wenn Cluster Autoscaler diese Knoten herunterskalieren soll, entfernen Sie die Annotation.
"no.scale.down.node.node.group.min.size.reached"

Cluster Autoscaler kann nicht herunterskalieren, wenn die Größe der Knotengruppe das Mindestgrößenlimit überschritten hat.

Das liegt daran, dass das Entfernen von Knoten gegen die clusterweiten Mindestressourcenlimits verstoßen würde, die in den Einstellungen für die automatische Knotenbereitstellung festgelegt sind.

 – Prüfen Sie den für das Autoscaling von Knotenpools festgelegten Mindestwert. Wenn Sie möchten, dass Cluster Autoscaler diesen Knoten herunterskaliert, passen Sie den Mindestwert an.
"no.scale.down.node.minimal.resource.limits.exceeded"

Cluster Autoscaler kann Knoten nicht herunterskalieren, da dies gegen clusterweite Mindestressourcenlimits verstoßen würde.

Dies sind die Ressourcenlimits, die für die automatische Knotenbereitstellung festgelegt sind.

 – Prüfen Sie die Limits für Arbeitsspeicher und vCPU. Wenn Cluster Autoscaler diesen Knoten herunterskalieren soll, erhöhen Sie die Limits.
"no.scale.down.node.no.place.to.move.pods" Cluster Autoscaler kann nicht herunterskalieren, da es keinen Ort gibt, an den Pods verschoben werden können. – Wenn Sie davon ausgehen, dass der Pod neu geplant werden sollte, prüfen Sie die Planungsanforderungen der Pods auf dem nicht ausgelasteten Knoten. So können Sie feststellen, ob sie zu einem anderen Knoten im Cluster verschoben werden können. Weitere Informationen finden Sie unter Fehler: Kein Ort zum Verschieben von Pods.
"no.scale.down.node.pod.not.backed.by.controller"

Der Pod blockiert das Herunterskalieren, da er nicht von einem Controller gestützt wird.

Cluster Autoscaler kann einen nicht ausgelasteten Knoten vor allem nicht herunterskalieren, da ein Pod keinen erkannten Controller hat. Zu den zulässigen Controllern gehören ReplicationController, DaemonSet, Job, StatefulSet oder ReplicaSet.

 Name des blockierenden Pods. Legen Sie die Annotation "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" für den Pod fest oder definieren Sie einen zulässigen Controller.
"no.scale.down.node.pod.has.local.storage" Der Pod blockiert das Herunterskalieren, da er lokalen Speicher hat. Name des blockierenden Pods. Legen Sie für den Pod eine "cluster-autoscaler.kubernetes.io/safe-to-evict": "true"-Annotation fest, wenn die Daten im lokalen Speicher für den Pod nicht kritisch sind. Dieser Fehler tritt nur bei Clustern auf, die eine Version vor 1.22 verwenden.
"no.scale.down.node.pod.not.safe.to.evict.annotation" Ein Pod auf dem Knoten hat die Annotation safe-to-evict=false. Name des blockierenden Pods. Wenn der Pod sicher entfernt werden kann, bearbeiten Sie das Manifest des Pods und aktualisieren Sie die 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. Name des blockierenden Pods.

Standardmäßig werden Pods im Namespace kube-system nicht von Cluster Autoscaler entfernt.

Um dieses Problem zu beheben, fügen Sie entweder ein PodDisruptionBudget für die kube-system-Pods hinzu oder verwenden Sie eine Kombination aus Knotenpoolmarkierungen und ‑toleranzen, um kube-system-Pods von Ihren Anwendungs-Pods zu trennen. Weitere Informationen finden Sie unter Fehler: kube-system-Pod kann nicht verschoben werden.
"no.scale.down.node.pod.not.enough.pdb" Der Pod blockiert das Herunterskalieren, da nicht genügend PodDisruptionBudget vorhanden ist. Name des blockierenden Pods. Sehen Sie sich das PodDisruptionBudget für den Pod an und stellen Sie es gegebenenfalls weniger restriktiv ein. Weitere Informationen finden Sie unter Fehler: Nicht genügend PodDisruptionBudget.
"no.scale.down.node.pod.controller.not.found" Der Pod blockiert das Herunterskalieren, da der Controller (z. B. Deployment oder ReplicaSet) nicht gefunden werden kann. – Prüfen Sie die Logs, um festzustellen, welche Maßnahmen ergriffen wurden, durch die ein Pod weiterhin ausgeführt wurde, nachdem der Controller entfernt wurde. Löschen Sie den Pod manuell, um das Problem zu beheben.
"no.scale.down.node.pod.unexpected.error" Der Pod blockiert das Herunterskalieren aufgrund eines unerwarteten Fehlers. – Die Ursache dieses Fehlers ist unbekannt. Wenden Sie sich an das Cloud Customer Care-Team, um das Problem genauer untersuchen zu lassen.

Nächste Schritte