Fehlerbehebung beim horizontalen Pod-Autoscaling

Wenn das horizontale Pod-Autoscaling in Google Kubernetes Engine (GKE) nicht wie erwartet funktioniert, werden Ihre Arbeitslasten möglicherweise nicht richtig skaliert. Dieses Problem kann dazu führen, dass Anwendungen die Last nicht verarbeiten können, was zu Leistungsproblemen oder Ausfällen führen kann. Möglicherweise stellen Sie fest, dass die Anzahl der Pods trotz hoher CPU-Auslastung nicht zunimmt, dass die Messwertwerte in Ihrem HorizontalPodAutoscaler-Status als <unknown> angezeigt werden oder dass Skalierungsvorgänge überhaupt nicht stattfinden.

In diesem Dokument erfahren Sie, wie Sie häufige Probleme mit dem horizontalen Pod-Autoscaling diagnostizieren und beheben können. Die Probleme reichen von anfänglichen Fehlkonfigurationen in Ihren HorizontalPodAutoscaler-Objekten bis hin zu komplexeren Fehlern in der Messwerte-Pipeline. Wenn Sie diese Schritte zur Fehlerbehebung ausführen, können Sie dafür sorgen, dass Ihre Anwendungen je nach Bedarf effizient und zuverlässig skaliert werden und die HorizontalPodAutoscaler-Ressource effektiv genutzt wird.

Diese Informationen sind wichtig für Anwendungsentwickler, die HorizontalPodAutoscaler-Objekte konfigurieren und dafür sorgen müssen, dass ihre Anwendungen richtig skaliert werden. Außerdem können Plattformadministratoren und ‑operatoren damit Probleme mit der Messwertpipeline oder der Clusterkonfiguration beheben, die sich auf alle automatisch skalierten Arbeitslasten auswirken. Weitere Informationen zu den gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Hinweis

  • Verwenden Sie HorizontalPodAutoscaler-Objekte mit skalierbaren Arbeitslasten wie Deployments und StatefulSets. Sie können horizontales Pod-Autoscaling nicht für Arbeitslasten verwenden, die nicht skaliert werden können, z. B. DaemonSets.

  • Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für Ihr Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zur Fehlerbehebung bei der horizontalen Pod-Autoskalierung in GKE benötigen, einschließlich der Prüfung von HorizontalPodAutoscaler-Objekten und der Anzeige von Clusterlogs:

    • GKE-Ressourcen prüfen: GKE Viewer (roles/container.viewer)
    • Cluster-Logs ansehen: Loganzeige (roles/logging.viewer)

    Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

    Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

  • Konfigurieren Sie das kubectl-Befehlszeilentool für die Kommunikation mit Ihrem GKE-Cluster:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location LOCATION \
    --project PROJECT_ID

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • LOCATION: die Compute Engine-Region oder -Zone (z. B. us-central1 oder us-central1-a) für den Cluster.
    • PROJECT_ID: Projekt-ID in Google Cloud .

Probleme mit HorizontalPodAutoscaler diagnostizieren

Wenn Sie Probleme mit einem HorizontalPodAutoscaler diagnostizieren möchten, prüfen Sie den Status und die Konfiguration mit kubectl-Befehlen oder der Google Cloud Console.

HorizontalPodAutoscaler beschreiben

Verwenden Sie den Befehl kubectl describe hpa, um Echtzeitberechnungen und aktuelle Skalierungsentscheidungen aufzurufen:

kubectl describe hpa HPA_NAME -n NAMESPACE_NAME

Ersetzen Sie Folgendes:

  • HPA_NAME: Der Name Ihres HorizontalPodAutoscaler-Objekts.
  • NAMESPACE_NAME: der Namespace Ihres HorizontalPodAutoscaler-Objekts.

Die Ausgabe sieht etwa so aus:

Name:                                                  php-apache-hpa
Namespace:                                             default
Reference:                                             Deployment/php-apache
Metrics: ( current / target )
  resource cpu on pods (as a percentage of request):   1% (1m) / 50%
Min replicas:                                          1
Max replicas:                                          10
Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     True    ReadyForNewScale    recommended size matches current size
  ScalingActive   True    ValidMetricFound    the HorizontalPodAutoscaler was able to successfully calculate a replica count
Events:
  Type     Reason              Age   From                       Message
  ----     ------              ----  ----                       -------
  Normal   SuccessfulRescale   39m   horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization...
  Normal   SuccessfulRescale   26m   horizontal-pod-autoscaler  New size: 1; reason: cpu resource utilization...

Die folgenden drei Abschnitte in der Ausgabe helfen Ihnen, das Problem zu diagnostizieren:

  • Metrics: Hier werden die aktuellen Messwerte im Vergleich zu den Zielvorhaben angezeigt. Ein <unknown>-Messwert gibt an, dass der HorizontalPodAutoscaler den Messwert nicht abgerufen hat oder dass die Messwertpipeline unterbrochen ist.
  • Conditions: Gibt an, ob der HorizontalPodAutoscaler Messwerte abrufen (AbleToScale) und Skalierungsberechnungen durchführen (ScalingActive) kann. Der Status False in einer dieser Bedingungen weist auf einen Fehler hin.
  • Events: Protokolliert die letzten Skalierungsaktionen, Warnungen und Fehler des HorizontalPodAutoscaler-Controllers. Dort finden Sie oft als Erstes spezifische Fehlermeldungen oder Gründe, z. B. FailedGetScale oder FailedGetResourceMetric.

HorizontalPodAutoscaler-Manifest prüfen

Im YAML-Manifest Ihres HorizontalPodAutoscaler-Objekts können Sie Informationen zur Konfiguration und zum aktuellen Status aufrufen.

Wählen Sie eine der folgenden Optionen aus, um das YAML-Manifest aufzurufen:

Console

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

    Zum Objektbrowser

  2. Wählen Sie in der Liste Objektarten das Kästchen HorizontalPodAutoscaler aus und klicken Sie auf OK.

  3. Rufen Sie die API-Gruppe autoscaling auf und klicken Sie dann auf den Erweiterungspfeil für HorizontalPodAutoscaler.

  4. Klicken Sie auf den Namen des HorizontalPodAutoscaler-Objekts, das Sie untersuchen möchten.

  5. Sehen Sie sich den Abschnitt YAML an, in dem die vollständige Konfiguration des HorizontalPodAutoscaler-Objekts angezeigt wird.

kubectl

Führen Sie dazu diesen Befehl aus:

kubectl get hpa HPA_NAME -n NAMESPACE_NAME -o yaml

Ersetzen Sie Folgendes:

  • HPA_NAME: Der Name Ihres HorizontalPodAutoscaler-Objekts.
  • NAMESPACE_NAME: der Namespace Ihres HorizontalPodAutoscaler-Objekts.

Suchen Sie nach dem Abrufen des Manifests nach den folgenden wichtigen Abschnitten:

  • spec (Ihre Konfiguration):
    • scaleTargetRef: die Arbeitslast (z. B. ein Deployment), die der HorizontalPodAutoscaler skalieren soll.
    • minReplicas und maxReplicas: die Einstellungen für die Mindest- und Höchstzahl von Replikaten.
    • metrics: Die für die Skalierung konfigurierten Messwerte, z. B. CPU-Auslastung oder benutzerdefinierte Messwerte.
  • status (der Live-Status des HorizontalPodAutoscaler):
    • currentMetrics: die letzten Messwerte, die der HorizontalPodAutoscaler beobachtet hat.
    • currentReplicas und desiredReplicas: die aktuelle Anzahl der Pods und die Anzahl, auf die der HorizontalPodAutoscaler skalieren möchte.
    • conditions: Zeigt den Zustand des HorizontalPodAutoscaler an:
      • AbleToScale: Gibt an, ob der HorizontalPodAutoscaler sein Ziel und seine Messwerte finden kann.
      • ScalingActive: Gibt an, ob der HorizontalPodAutoscaler die Skalierung berechnen und ausführen darf.
      • ScalingLimited: Gibt an, ob der HorizontalPodAutoscaler skaliert werden soll, aber durch Ihre Einstellungen für minReplicas oder maxReplicas begrenzt wird.

Ereignisprotokolle ansehen

Wenn Sie mehr über Ihr HorizontalPodAutoscaler-Objekt erfahren möchten, können Sie die folgenden Logtypen verwenden:

  • HorizontalPodAutoscaler-Ereignisse in Cloud Logging ansehen: Verwenden Sie einen Logfilter, um alle HorizontalPodAutoscaler-Ereignisse für einen bestimmten Cluster zu finden. Beispiel:

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

      Zum Log-Explorer

    2. Geben Sie im Bereich „Abfrage“ die folgende Abfrage ein:

      resource.type="k8s_cluster"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
logName="projects/PROJECT_ID/logs/events"
jsonPayload.involvedObject.kind="HorizontalPodAutoscaler"

      Ersetzen Sie Folgendes:

      • CLUSTER_NAME: der Name des Clusters, zu dem der HorizontalPodAutoscaler gehört.
      • LOCATION: die Compute Engine-Region oder -Zone (z. B. us-central1 oder us-central1-a) für den Cluster.
      • PROJECT_ID: Ihre Projekt-ID.

    3. Klicken Sie auf Abfrage ausführen und sehen Sie sich die Ausgabe an.

  • Ereignisse für horizontales Pod-Autoscaling ansehen: Diese Logs enthalten strukturierte, menschenlesbare Logs, in denen erläutert wird, wie der HorizontalPodAutoscaler eine Empfehlung berechnet. Sie bieten detaillierte Einblicke in den Entscheidungsprozess.

Fehlerbehebung bei Konfigurationsfehlern von HorizontalPodAutoscaler

In den folgenden Abschnitten werden Fehlkonfigurationen im HorizontalPodAutoscaler-Manifest behandelt, z. B. falsch geschriebene Felder, ungültige Messwertziele oder in Konflikt stehende Konfigurationen.

Zielarbeitslast nicht gefunden

Symptome

Der Abschnitt Events hat die Bedingung FailedGetScale mit einer Meldung wie der folgenden:

the HorizontalPodAutoscaler controller was unable to get the target's current scale: WORKLOAD_TYPE.apps "TARGET_WORKLOAD" not found

Diese Ausgabe enthält die folgenden Werte:

  • WORKLOAD_TYPE: der Typ der Arbeitslast, z. B. Deployment oder StatefulSet.
  • TARGET_WORKLOAD: Der Name der Arbeitslast.

Ursache

Der HorizontalPodAutoscaler-Controller kann die Arbeitslast (z. B. ein Deployment oder StatefulSet) nicht finden, für die er konfiguriert ist. Dieses Problem tritt aufgrund einer Fehlkonfiguration im Feld scaleTargetRef im Manifest des HorizontalPodAutoscaler auf. Die angegebene Ressource ist möglicherweise nicht vorhanden, wurde gelöscht oder enthält einen Rechtschreibfehler.

Lösung

Versuchen Sie Folgendes:

  1. Prüfen Sie das Feld scaleTargetRef des HorizontalPodAutoscaler-Manifests: Achten Sie darauf, dass die Werte von name, kind und apiVersion im Feld scaleTargetRef genau mit den entsprechenden Metadaten Ihrer Zielarbeitslast übereinstimmen. Wenn der Name der Arbeitslast falsch ist, aktualisieren Sie das Feld scaleTargetRef des HorizontalPodAutoscalers, sodass es auf den richtigen Namen verweist.
  2. Prüfen, ob die Arbeitslast vorhanden ist: Prüfen Sie, ob die Zielarbeitslast im selben Namespace wie der HorizontalPodAutoscaler vorhanden ist. Sie können dies mit einem Befehl wie kubectl get deployment DEPLOYMENT_NAME prüfen. Wenn Sie die Arbeitslast absichtlich gelöscht haben, löschen Sie das entsprechende HorizontalPodAutoscaler-Objekt, um den Cluster zu bereinigen. Wenn Sie die Arbeitslast neu erstellen müssen, findet der HorizontalPodAutoscaler sie automatisch, sobald sie verfügbar ist, und der Fehler wird behoben.
  3. Prüfen Sie, ob sich der HorizontalPodAutoscaler und die Arbeitslast im selben Namespace befinden: Der HorizontalPodAutoscaler und die zugehörige Zielarbeitslast müssen sich im selben Namespace befinden. Wenn Sie beim Erstellen eines Objekts mit kubectl-Befehlen keinen Namespace angeben, platziert Kubernetes das Objekt im Namespace default. Dieses Verhalten kann zu einer Diskrepanz führen, wenn sich Ihr HorizontalPodAutoscaler im Namespace default und Ihre Arbeitslast in einem anderen Namespace befindet oder umgekehrt. Prüfen Sie den Namespace für beide Objekte und vergewissern Sie sich, dass sie übereinstimmen.

Nachdem der HorizontalPodAutoscaler sein Ziel erfolgreich gefunden hat, ändert sich die Bedingung AbleToScale in True und die Meldung ändert sich in: the HorizontalPodAutoscaler controller was able to get the target's current scale.

Ungültige Messwerte

Symptome

Wenn der HorizontalPodAutoscaler die erforderlichen Replikate aufgrund eines Konfigurationsproblems nicht berechnen kann, wird im Abschnitt Events der Grund FailedComputeMetricsReplicas mit einer Meldung ähnlich der folgenden angezeigt:

invalid metrics (1 invalid out of 1)

Ursache

Dieser Fehler bedeutet in der Regel, dass der Messwert type und der target, den Sie in Ihrem HorizontalPodAutoscaler-Manifest definiert haben, nicht übereinstimmen. Beispiel: Sie haben für type den Wert Utilization angegeben, aber einen Zielwert von averageValue anstelle von averageUtilization.

Lösung

Korrigieren Sie das HorizontalPodAutoscaler-Manifest, sodass der Wert des Felds target mit dem Messwert type übereinstimmt:

  • Wenn type den Wert Utilization hat, muss der Wert im Feld target averageUtilization sein.
  • Wenn type den Wert AverageValue hat, muss der Wert im Feld target averageValue sein.

Messwertlabel ist nicht zulässig

Symptome

Der folgende Fehler wird angezeigt:

unable to fetch metrics from external metrics API: googleapi: Error 400: Metric label: 'LABEL_NAME' is not allowed

In dieser Ausgabe ist LABEL_NAME der Name des falschen Labels.

Ursache

Im HorizontalPodAutoscaler-Manifest wird im Abschnitt metric.selector.matchLabels ein ungültiger Labelschlüssel angegeben. Cloud Monitoring erkennt oder erlaubt diesen Schlüssel für den Messwert nicht.

Lösung

So beheben Sie das Problem:

  1. Ermitteln Sie den unzulässigen Labelnamen anhand der Fehlermeldung.
  2. Entfernen oder korrigieren Sie diesen Label-Schlüssel im Abschnitt metric.selector.matchLabels Ihres HorizontalPodAutoscaler-Manifests.
  3. Einen gültigen, filterbaren Labelschlüssel finden Sie in der Cloud Monitoring-Dokumentation für diesen Messwert.

Mehrere HorizontalPodAutoscaler sind auf dieselbe Arbeitslast ausgerichtet

Symptome

Es gibt keinen spezifischen Condition oder Reason im Status eines HorizontalPodAutoscalers, der direkt auf diesen Konflikt hinweist. Stattdessen können folgende Symptome auftreten:

  • Die Anzahl der Replikate der Arbeitslast kann unerwartet schwanken.
  • Skalierungsentscheidungen entsprechen möglicherweise nicht den in einem einzelnen HorizontalPodAutoscaler definierten Messwerten.
  • Wenn Sie sich Ereignisse ansehen, werden möglicherweise abwechselnde oder widersprüchliche SuccessfulRescale-Ereignisse von verschiedenen HorizontalPodAutoscaler-Objekten angezeigt.

Ursache

Dieses Problem tritt auf, weil in mehr als einem HorizontalPodAutoscaler-Objekt im selben Namespace genau dieselbe Arbeitslast im Feld spec.scaleTargetRef angegeben ist. Jeder HorizontalPodAutoscaler berechnet unabhängig die Anzahl der Replikate und versucht, die Arbeitslast basierend auf seinen eigenen Messwerten und Zielen zu skalieren. Kubernetes blockiert diese Konfiguration nicht, sie führt aber zu unregelmäßigen Skalierungsanpassungen, da die HorizontalPodAutoscaler miteinander konkurrieren.

Lösung

Definieren Sie alle Skalierungsmesswerte in einem einzigen HorizontalPodAutoscaler-Objekt, um Konflikte zu vermeiden. Jedes HorizontalPodAutoscaler-Objekt berechnet die Skalierungsanforderungen aus seinem eigenen spec.metrics-Feld. Wenn Sie sie zusammenführen, kann das ausgewählte HorizontalPodAutoscaler-Objekt alle Faktoren wie CPU und Anfragen pro Sekunde berücksichtigen:

  1. Rufen Sie das YAML-Manifest für jedes HorizontalPodAutoscaler-Objekt ab, um herauszufinden, welche HorizontalPodAutoscaler auf dieselbe Arbeitslast abzielen. Achten Sie genau auf das Feld spec.scaleTargetRef in der Ausgabe.

    kubectl get hpa -n NAMESPACE_NAME -o yaml

    Ersetzen Sie NAMESPACE_NAME durch den Namespace Ihres HorizontalPodAutoscaler-Objekts.

    Suchen Sie nach Instanzen, bei denen verschiedene HorizontalPodAutoscaler-Ressourcen im Feld scaleTargetRef dieselben Werte für apiVersion, kind und name haben.

  2. Messwerte in einem einzelnen HorizontalPodAutoscaler-Objekt zusammenfassen:

    1. Wählen Sie ein HorizontalPodAutoscaler-Objekt aus, das Sie behalten möchten. Diesen HorizontalPodAutoscaler werden Sie ändern.
    2. Sehen Sie sich den Abschnitt spec.metrics im Manifest der anderen HorizontalPodAutoscaler-Objekte an, die auf denselben Workload ausgerichtet sind.
    3. Kopieren Sie die Messwertdefinitionen, die Sie behalten möchten, aus den spec.metrics-Abschnitten der doppelten HorizontalPodAutoscaler-Objekte.
    4. Fügen Sie diese kopierten Messwertdefinitionen in das spec.metrics-Array des HorizontalPodAutoscaler ein, den Sie behalten möchten.

  3. Wenden Sie Ihre Änderungen an:

    kubectl apply -f MANIFEST_NAME

    Ersetzen Sie MANIFEST_NAME durch den Namen des HorizontalPodAutoscaler-Manifests, das Sie beibehalten möchten.

  4. Löschen Sie die anderen HorizontalPodAutoscaler-Objekte, die auf dieselbe Arbeitslast ausgerichtet waren:

    kubectl delete hpa DUPLICATE_MANIFEST_NAME -n NAMESPACE_NAME

    Ersetzen Sie DUPLICATE_MANIFEST_NAME durch den Namen des redundanten HorizontalPodAutoscaler-Objekts, das Sie löschen möchten.

Arbeitslast- und Dienstfehler beheben

In den folgenden Abschnitten werden Fehler behandelt, die durch die Zielarbeitslast oder die zugehörigen Dienste und nicht durch das HorizontalPodAutoscaler-Objekt selbst verursacht werden.

Fehlende Ressourcenanfragen für die Skalierungsberechnung

Symptome

Die Bedingung ScalingActive ist False mit einem Reason von FailedGetResourceMetric. Normalerweise wird auch eine Meldung ähnlich der folgenden angezeigt:

the HorizontalPodAutoscaler was unable to compute the replica count

Ursache

Der HorizontalPodAutoscaler muss die Ressourcenauslastung als Prozentsatz berechnen, um die Arbeitslast zu skalieren. Diese Berechnung kann jedoch nicht durchgeführt werden, da in der Pod-Spezifikation für mindestens einen Container die resources.requests-Definition für die entsprechende Ressource (cpu oder memory) fehlt.

Lösung

Um dieses Problem zu beheben, aktualisieren Sie das Pod-Manifest in Ihrem Deployment, StatefulSet oder einem anderen Controller, sodass es ein Feld resources.requests für die Ressource (cpu oder memory) enthält, für die der HorizontalPodAutoscaler alle Container im Pod skaliert. Beispiel:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
# Multiple lines are omitted here
spec:
  containers:
  - name: example-container
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"

Pod-Messwerte können nicht abgerufen werden

Symptome

Es wird eine Meldung wie die folgende angezeigt:

unable to fetch pod metrics for pod

Es ist normal, dass diese Meldung beim Start des Messwertservers vorübergehend angezeigt wird.

Ursache

Wenn Sie die Skalierung auf der Grundlage des prozentualen Anteils der Ressourcenauslastung (z. B. cpu oder memory) durchführen möchten, muss für jeden Container in den Pods, auf die das HorizontalPodAutoscaler-Objekt ausgerichtet ist, das Feld resources.requests für die jeweilige Ressource definiert sein. Andernfalls kann das horizontale Pod-Autoscaling die erforderlichen Berechnungen nicht ausführen und unternimmt keine Aktion in Bezug auf diesen Messwert.

Lösung

Wenn diese Fehlermeldungen weiterhin angezeigt werden und Sie feststellen, dass Pods nicht für Ihre Arbeitslast skaliert werden, müssen Sie für jeden Container in Ihrer Arbeitslast angegebene Ressourcenanforderungen angegeben haben.

Mehrere Dienste wählen dasselbe Ziel aus

Symptome

Der folgende Fehler wird angezeigt:

multiple services selecting the same target of HPA_NAME: SERVICE_NAME

Diese Ausgabe enthält die folgenden Werte:

  • HPA_NAME: Der Name des HorizontalPodAutoscaler.
  • SERVICE_NAME: der Name eines Dienstes.

Ursache

Das traffic-basierte Autoscaling ist konfiguriert, aber mehr als ein Kubernetes-Service ist auf das Feld scaleTargetRef des HorizontalPodAutoscaler ausgerichtet. Das traffic-basierte Autoscaling unterstützt nur eine 1:1-Beziehung zwischen dem Dienst und der automatisch skalierten Arbeitslast.

Lösung

Um dieses Problem zu beheben, muss der Label-Selektor nur eines Dienstes mit den Pods Ihres Workloads übereinstimmen:

  1. Suchen Sie die Pod-Labels Ihrer Arbeitslast:

    kubectl get deployment HPA_TARGET_DEPLOYMENT \
    -n NAMESPACE \
    -o jsonpath='{.spec.template.metadata.labels}'

    Ersetzen Sie Folgendes:

    • HPA_TARGET_DEPLOYMENT: Der Name des Deployments, auf das der HorizontalPodAutoscaler ausgerichtet ist.
    • NAMESPACE: der Namespace des Deployments.

    Die Ausgabe sieht etwa so aus:

    {"app":"my-app", "env":"prod"}

  2. Suchen Sie alle Dienste, die diesen Labels entsprechen, indem Sie das Feld spec.selector für alle Dienste im Namespace prüfen.

    kubectl get services -n NAMESPACE -o yaml

    Ermitteln Sie alle Dienste, deren Selektor mit den Labels aus dem vorherigen Schritt übereinstimmt. Beispielsweise entsprechen sowohl {"app": "my-app"} als auch {"app": "my-app", "env": "prod"} den Beispiel-Pod-Labels.

  3. Beheben Sie den Konflikt, indem Sie eine der folgenden Optionen auswählen:

    • Machen Sie den Selektor des gewünschten Dienstes eindeutig, indem Sie dem Feld spec.template.metadata.labels Ihrer Bereitstellung ein neues, eindeutiges Label hinzufügen. Aktualisieren Sie dann das Feld spec.selector des einen vorgesehenen Dienstes, um dieses neue Label einzuschließen.
    • Machen Sie andere Service-Selektoren restriktiver, indem Sie das Feld spec.selector aller anderen in Konflikt stehenden Services so ändern, dass sie restriktiver sind und nicht mehr mit den Pods Ihrer Arbeitslast übereinstimmen.

  4. Wenden Sie Ihre Änderungen an:

    kubectl apply -f MANIFEST_NAME

    Ersetzen Sie MANIFEST_NAME durch den Namen der YAML-Datei, die das aktualisierte Dienst- oder Deployment-Manifest enthält.

Fehlerbehebung bei der Metrics API und der Datenverfügbarkeit

In den folgenden Abschnitten erfahren Sie, wie Sie Fehler beheben, die auftreten, wenn der HorizontalPodAutoscaler versucht, mit einer Messwert-API zu kommunizieren oder ein Messwert-Backend abzufragen.

Fehlerbehebung bei benutzerdefinierten und externen Messwerten

Wenn Ihr HorizontalPodAutoscaler auf Messwerten aus anderen Quellen als der Standard-CPU oder dem Standardspeicher basiert, können Probleme in der Pipeline für benutzerdefinierte oder externe Messwerte auftreten. Diese Pipeline besteht aus dem HorizontalPodAutoscaler-Controller, dem Kubernetes-Messwert-API-Server, dem Messwertadapter und der Messwertquelle (z. B. Cloud Monitoring oder Prometheus), wie im folgenden Diagramm dargestellt:

HPA-Messwertpipeline mit den Komponenten: HPA-Controller, Kubernetes API-Server, Messwertadapter und Messwertquelle.

Symptome

Die häufigsten Symptome für ein Problem in der Messwerte-Pipeline sind:

  • Der Messwert wird als <unknown> angezeigt.
  • In HorizontalPodAutoscaler-Ereignissen werden Fehler wie FailedGetExternalMetric oder FailedGetCustomMetric angezeigt.

Ursache

Es liegt ein Problem in der Pipeline für benutzerdefinierte oder externe Messwerte vor.

Lösung

Mit den folgenden Schritten können Sie Fehler in der Pipeline beheben:

  1. Prüfen, ob der Messwerte-Adapter registriert und verfügbar ist: Der Messwerte-Adapter muss sich beim Haupt-Kubernetes API-Server registrieren, um Messwerte bereitzustellen. Diese Aktion ist die direkteste Möglichkeit, um zu prüfen, ob der Adapter ausgeführt wird und vom API-Server erreichbar ist:

    kubectl get apiservice | grep -E 'NAME|metrics.k8s.io'

    In der Ausgabe sollten die Einträge v1beta1.custom.metrics.k8s.io oder v1beta1.external.metrics.k8s.io und in der Spalte Available der Wert True angezeigt werden. Beispiel:

    NAME                   SERVICE                      AVAILABLE   AGE
v1beta1.metrics.k8s.io kube-system/metrics-server   True        18d

    • Wenn der Wert in der Spalte Available False ist oder fehlt, ist Ihr Adapter wahrscheinlich abgestürzt oder falsch konfiguriert. Prüfen Sie die Pod-Logs des Adapters im Namespace kube-system oder custom-metrics auf Fehler im Zusammenhang mit Berechtigungen, Netzwerkverbindungen zur Messwertquelle oder Nachrichten, die darauf hinweisen, dass der Messwert nicht gefunden werden konnte.

    • Wenn der Wert True ist, fahre mit dem nächsten Schritt fort.

  2. Metrics API direkt abfragen: Wenn der Adapter verfügbar ist, umgehen Sie den HorizontalPodAutoscaler und fragen Sie die Kubernetes API direkt nach Ihrem Messwert ab. Mit diesem Befehl wird die gesamte Pipeline getestet, vom API-Server über den Messwertadapter bis zur Datenquelle.

    Führen Sie den folgenden Befehl aus, um externe Messwerte abzufragen:

    kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/NAMESPACE_NAME/METRIC_NAME" | jq .

    Führen Sie den folgenden Befehl aus, um benutzerdefinierte Pod-Messwerte abzufragen:

    kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/NAMESPACE_NAME/pods/*/METRIC_NAME" | jq .

    Ersetzen Sie Folgendes:

    • NAMESPACE_NAME: der Namespace, in dem Ihre Pods ausgeführt werden.
    • METRIC_NAME: Der Name des benutzerdefinierten oder externen Messwerts, den Sie abfragen möchten. Beispiel: requests_per_second oder queue_depth.

  3. Befehlsausgabe analysieren: Das Ergebnis der vorherigen Befehle zeigt Ihnen, wo das Problem liegt. Wählen Sie das Szenario aus, das Ihrer Ausgabe entspricht:

    • Erfolgreiche JSON-Antwort mit einem Wert: Die Pipeline für Messwerte funktioniert korrekt. Das Problem ist wahrscheinlich ein Konfigurationsproblem in Ihrem HorizontalPodAutoscaler-Manifest. Prüfen Sie, ob der Messwertname Rechtschreibfehler enthält oder ob der matchLabels falsch ist.

    • Error: Error from server (Service Unavailable): Dieser Fehler weist in der Regel auf ein Problem mit der Netzwerkverbindung hin, das häufig ein Firewallproblem in Clustern ist, die Netzwerkisolation verwenden.

      1. Ermitteln Sie den Metrics-Adapter-Dienst. Sie befindet sich in der Regel im Namespace custom-metrics oder kube-system:

        kubectl get service -n custom-metrics,kube-system | grep -E 'adapter|metrics'

      2. Ermitteln Sie den Port, an dem der Adapter empfangsbereit ist:

        kubectl get service ADAPTER_SERVICE -n ADAPTER_NAMESPACE -o yaml

        Ersetzen Sie Folgendes:

        • ADAPTER_SERVICE: der Name des Kubernetes-Dienstes, der dem von Ihnen bereitgestellten Messwertadapter zugeordnet ist. Dieser Dienst ist der Dienst, den Sie im vorherigen Schritt gefunden haben. Dieser Dienst macht die Funktionalität des Adapters für andere Teile des Clusters verfügbar, einschließlich des Kubernetes API-Servers.
        • ADAPTER_NAMESPACE: der Namespace, in dem sich der Adapterservice befindet (z. B. custom-metrics oder kube-system).

      3. Suchen Sie die Firewallregeln für eingehenden Traffic für die Steuerungsebene Ihres Clusters:

        gcloud compute firewall-rules list \
    --filter="name~gke-CLUSTER_NAME-[0-9a-z]*-master"

        Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Clusters.

      4. Fügen Sie der Regel die targetPort des Adapters hinzu:

        einbeziehen.

        1. Beschreiben Sie die aktuelle Regel, um die vorhandenen zulässigen Ports zu sehen:

          gcloud compute firewall-rules describe FIREWALL_RULE_NAME

          Ersetzen Sie FIREWALL_RULE_NAME durch den Namen der Firewallregel, die den Netzwerkverkehr zur Steuerungsebene Ihres Kubernetes-Clusters regelt.

        2. Aktualisieren Sie die Regel, um den Adapterport der Liste hinzuzufügen:

          gcloud compute firewall-rules update FIREWALL_RULE_NAME \
    --allow tcp:443,tcp:10250,tcp:ADAPTER_PORT

          Ersetzen Sie ADAPTER_PORT durch den Netzwerkport, an dem der Messwerte-Adapter empfangsbereit ist.

      5. Achten Sie darauf, dass Kubernetes-Netzwerkrichtlinien den Traffic zu den Pods des Messwerteadapters nicht blockieren:

        kubectl get networkpolicy -n custom-metrics,kube-system

        Prüfen Sie alle Richtlinien, um sicherzustellen, dass eingehender Traffic von der Steuerungsebene oder dem API-Server zum ADAPTER_SERVICE auf dem ADAPTER_PORT zulässig ist.

    • Eine leere Liste []: Diese Ausgabe bedeutet, dass der Adapter ausgeführt wird, aber die spezifische Messwertquelle nicht abrufen kann. Das deutet auf ein Problem mit der Konfiguration des Adapters oder der Messwertquelle selbst hin.

      • Probleme mit dem Adapter-Pod: Prüfen Sie die Logs des Metrics Adapter-Pods oder der Pods auf Fehler im Zusammenhang mit API-Aufrufen, Authentifizierung oder dem Abrufen von Messwerten. So prüfen Sie die Logs:

        1. Suchen Sie den Namen des Adapter-Pods:

          kubectl get pods -n ADAPTER_NAMESPACE

        2. So rufen Sie die Logs auf:

          kubectl logs ADAPTER_POD_NAME \
    -n ADAPTER_NAMESPACE

          Ersetzen Sie Folgendes:

          • ADAPTER_POD_NAME: Der Name des Adapter-Pods, den Sie im vorherigen Schritt identifiziert haben.
          • ADAPTER_NAMESPACE: Der Namespace, in dem sich der Adapter-Pod befindet (z. B. custom-metrics oder kube-system).

      • Keine Daten in der Quelle: Der Messwert ist im Quellsystem möglicherweise nicht vorhanden. Verwenden Sie ein Monitoring-Tool wie den Metrics Explorer, um zu prüfen, ob der Messwert vorhanden ist und den richtigen Namen und die richtigen Labels hat.

Messwertversionen nicht gefunden oder Adapter nicht verfügbar

Symptome

Der folgende Fehler wird angezeigt:

unable to fetch metrics from custom metrics API: no known available metric versions found

Ursache

Dieser Fehler weist auf einen Kommunikationsfehler innerhalb des Clusters hin, nicht auf ein Problem mit der Messwertquelle (z. B. Cloud Monitoring). Häufige Ursachen:

  • Der Kubernetes API-Server ist vorübergehend nicht verfügbar (z. B. während eines Clusterupgrades oder einer Reparatur der Steuerungsebene).
  • Die Messwerte-Adapter-Pods (z. B. custom-metrics-stackdriver-adapter) sind fehlerhaft, werden nicht ausgeführt oder sind nicht korrekt beim API-Server registriert.

Lösung

Dieses Problem ist oft nur vorübergehend. Wenn das Problem weiterhin besteht, versuche Folgendes:

  1. Systemdiagnose der Kubernetes-Steuerungsebene prüfen:

    1. In der Google Cloud -Console können Sie den Zustand und Status Ihres Clusters aufrufen.

      1. Rufen Sie die Seite Kubernetes-Cluster auf.

        Zur Seite "Kubernetes-Cluster"

    2. Sehen Sie sich die Spalten Status und Benachrichtigungen für Ihren Cluster an.

    3. Klicken Sie auf Benachrichtigungen, um nach laufenden Vorgängen wie Upgrades oder Reparaturen zu suchen. Der API-Server ist in diesen Zeiträumen möglicherweise kurzzeitig nicht verfügbar.

    4. Prüfen Sie die Cloud-Audit-Logs auf Fehler im Zusammenhang mit Steuerungsebenenkomponenten. Informationen zum Aufrufen dieser Logs finden Sie unter Informationen zum Audit-Logging in GKE.

  2. Prüfen Sie den Status und die Logs der Pods des Messwertadapters: Achten Sie darauf, dass die Pods des Messwertadapters den Status Running haben und in letzter Zeit nicht neu gestartet wurden:

    kubectl get pods -n custom-metrics,kube-system -o wide

    Wenn der Status eines Pods nicht Running ist oder er eine hohe Anzahl von Neustarts hat, untersuchen Sie den Pod, um die Ursache zu finden. Tipps zur Fehlerbehebung finden Sie in der Kubernetes-Dokumentation unter Pods debuggen.

  3. Prüfen Sie, ob die Messwert-APIs registriert und verfügbar sind:

    kubectl get apiservice | grep metrics.k8s.io

    Wenn die Metrics-APIs fehlerfrei sind, sieht die Ausgabe in etwa so aus:

    NAME                            SERVICE                                             AVAILABLE   AGE
v1beta1.custom.metrics.k8s.io   custom-metrics/custom-metrics-stackdriver-adapter   True        18d
v1beta1.external.metrics.k8s.io custom-metrics/custom-metrics-stackdriver-adapter   True        18d
v1beta1.metrics.k8s.io          kube-system/metrics-server                          True        18d

    Wenn die Spalte AVAILABLE den Wert False hat, enthält die Spalte Message im vollständigen APIService-Manifest möglicherweise weitere Details.

    Mit dem folgenden Befehl können Sie das vollständige Manifest aufrufen:

    kubectl get apiservice API_SERVICE_NAME -o yaml

    Ersetzen Sie API_SERVICE_NAME durch den Namen des APIService-Objekts, z. B. v1beta1.custom.metrics.k8s.io.

Bei der Messwertabfrage werden keine Zeitreihen zurückgegeben

Symptome

Der folgende Fehler wird angezeigt:

unable to fetch metrics from custom or external metrics API: googleapi: Error
400: The supplied filter [...] query will not return any time series

Ursache

Die an Cloud Monitoring gesendete Abfrage war gültig, hat aber keine Daten zurückgegeben. Das bedeutet, dass keine Datenpunkte vorhanden sind, die Ihrem Filter entsprechen. Dies ist nicht dasselbe wie das Finden eines Messwerts mit dem Wert 0. Der wahrscheinlichste Grund für dieses Problem ist, dass die Anwendung oder Arbeitslast, die für die Generierung des benutzerdefinierten Messwerts verantwortlich ist, während des Zeitraums, in dem die Fehler gemeldet wurden, keine Daten in Cloud Monitoring geschrieben hat.

Lösung

Versuchen Sie Folgendes:

  1. Konfiguration prüfen: Achten Sie darauf, dass die Messwertnamen und Labels in Ihrem HorizontalPodAutoscaler-Objekt genau mit denen übereinstimmen, die von der Anwendung ausgegeben werden.
  2. Berechtigungen prüfen: Prüfen Sie, ob die Anwendung mit den erforderlichen Berechtigungen und API-Endpunkten konfiguriert ist, um Messwerte in Cloud Monitoring zu veröffentlichen.
  3. Anwendungsaktivität bestätigen: Prüfen Sie, ob die für den Messwert verantwortliche Anwendung betriebsbereit war und versucht hat, Daten an Cloud Monitoring zu senden, während des Zeitraums, in dem die HorizontalPodAutoscaler-Warnungen aufgetreten sind.
  4. Fehler untersuchen: Prüfen Sie die Anwendungslogs aus demselben Zeitraum auf explizite Fehler im Zusammenhang mit der Messwertübermittlung, z. B. Verbindungsfehler, ungültige Anmeldedaten oder Formatierungsprobleme.

Fehlerbehebung bei erwarteter, aber unerwarteter Skalierung

In den folgenden Abschnitten werden Szenarien behandelt, in denen die HorizontalPodAutoscaler-Konfiguration gültig ist und Messwerte verfügbar sind, aber Skalierungsaktionen nicht wie erwartet erfolgen.

HorizontalPodAutoscaler ist fehlerfrei, wird aber nicht skaliert

Symptome

Der HorizontalPodAutoscaler ist fehlerfrei, seine Bedingungen melden True und es werden keine Fehler in seinen Ereignissen angezeigt. Es werden jedoch weiterhin keine Skalierungsmaßnahmen ergriffen.

Ursache

Dafür kann es mehrere Gründe geben:

  • Replikatlimits: Die aktuelle Anzahl der Replikate liegt bereits am Grenzwert, der durch das Feld minReplicas oder maxReplicas in der HorizontalPodAutoscaler-Konfiguration festgelegt ist.
  • Toleranzfenster: Kubernetes verwendet ein Standardtoleranzfenster von 10 %, um eine Skalierung bei geringfügigen Messwertschwankungen zu verhindern. Die Skalierung erfolgt nur, wenn das Verhältnis des aktuellen Messwerts zum Zielmesswert außerhalb des Bereichs von 0,9 bis 1,1 liegt. Wenn das Ziel beispielsweise 85% CPU-Auslastung und die aktuelle Nutzung 93 % beträgt, liegt das Verhältnis bei etwa 1,094 (93/85 ≈ 1,094). Da dieser Wert kleiner als 1,1 ist, wird der HorizontalPodAutoscaler nicht hochskaliert.
  • Nicht bereite Pods: Der HorizontalPodAutoscaler berücksichtigt bei seinen Skalierungsberechnungen nur Pods mit dem Status Ready. Pods, die im Status Pending hängen bleiben oder nicht Ready werden (aufgrund von fehlgeschlagenen Systemdiagnosen oder Ressourcenproblemen), werden ignoriert und können die Skalierung verhindern.
  • Verzögerung des Synchronisierungszeitraums: Der HorizontalPodAutoscaler-Controller prüft Messwerte regelmäßig. Eine Verzögerung von 15 bis 30 Sekunden zwischen dem Überschreiten des Grenzwerts für eine Messwert und dem Beginn einer Skalierungsmaßnahme ist normal.
  • Latenz bei neuen Messwerten: Wenn ein HorizontalPodAutoscaler zum ersten Mal einen neuen benutzerdefinierten Messwert verwendet, kann es zu einer einmaligen Latenz von mehreren Minuten kommen. Diese Verzögerung tritt auf, weil das Monitoringsystem (z. B. Cloud Monitoring) die neue Zeitreihe erstellen muss, wenn der erste Datenpunkt geschrieben wird.
  • Berechnung mit mehreren Messwerten: Wenn Sie mehrere Messwerte konfigurieren, berechnet der HorizontalPodAutoscaler die erforderliche Replikatanzahl für jeden Messwert unabhängig und wählt dann den höchsten berechneten Wert als endgültige Anzahl von Replikaten aus. Aufgrund dieses Verhaltens wird Ihre Arbeitslast so skaliert, dass sie den Anforderungen des Messwerts mit den höchsten Anforderungen entspricht. Wenn beispielsweise CPU-Messwerte einen Bedarf von 9 Replikaten berechnen, ein Messwert für Anfragen pro Sekunde jedoch einen Bedarf von 15 Replikaten, skaliert der HorizontalPodAutoscaler das Deployment auf 15 Replikate.

Lösung

Versuchen Sie Folgendes:

  • Replikatlimits: Prüfen Sie die Werte minReplicas und maxReplicas in Ihrem HorizontalPodAutoscaler-Manifest oder in der Ausgabe des Befehls kubectl describe. Passen Sie diese Limits an, wenn sie eine notwendige Skalierung verhindern.
  • Toleranzbereich: Wenn eine Skalierung innerhalb der Standardtoleranz erforderlich ist, konfigurieren Sie einen anderen Toleranzwert. Warten Sie andernfalls, bis der Messwert außerhalb des Bereichs von 0,9 bis 1,1 liegt.
  • Nicht bereite Pods: Untersuchen Sie, warum Pods Pending oder nicht Ready sind, und beheben Sie die zugrunde liegenden Probleme (z. B. Ressourcenbeschränkungen, fehlgeschlagene Bereitschaftstests). Tipps zur Fehlerbehebung finden Sie in der Kubernetes-Dokumentation unter Pods debuggen.
  • Verzögerung des Synchronisierungszeitraums und Latenz neuer Messwerte: Diese Latenzen sind normal. Warten Sie, bis der Synchronisierungszeitraum abgeschlossen ist oder die neue Zeitreihe für benutzerdefinierte Messwerte erstellt wurde.
  • Berechnung mehrerer Messwerte: Das ist das vorgesehene Verhalten. Wenn das Hochskalieren auf der Grundlage eines Messwerts (z. B. Anfragen pro Sekunde) erfolgt, wird die niedrigere Berechnung eines anderen Messwerts (z. B. CPU) korrekt überschrieben.

HorizontalPodAutoscaler kann nicht herunterskaliert werden

Symptome

Der HorizontalPodAutoscaler skaliert die Arbeitslast erfolgreich hoch, aber nicht wieder herunter, auch wenn Messwerte wie die CPU-Auslastung niedrig sind.

Ursache

Dieses Verhalten soll verhindern, dass schnell hoch- und herunterskaliert wird oder dass auf Grundlage unvollständiger Informationen herunterskaliert wird. Die Hauptgründe sind:

  • Mehrere Messwerte verwenden: Das horizontale Pod-Autoscaling wird basierend auf dem Messwert skaliert, für den die meisten Replikate erforderlich sind. Wenn Sie mehrere Messwerte haben, wird die Arbeitslast nur dann herunterskaliert, wenn alle Messwerte darauf hinweisen, dass weniger Replikate erforderlich sind. Wenn für einen Messwert eine hohe Replikatanzahl erforderlich ist, wird eine Verkleinerung verhindert, auch wenn die anderen niedrig sind.
  • Nicht verfügbare Messwerte: Wenn ein Messwert nicht mehr verfügbar ist (oft als <unknown> angezeigt), weigert sich der HorizontalPodAutoscaler, die Arbeitslast herunterzuskalieren. Es kann nicht festgestellt werden, ob der Messwert fehlt, weil die Nutzung tatsächlich null ist oder weil die Messwertpipeline fehlerhaft ist. Dieses Problem tritt häufig bei ratenbasierten benutzerdefinierten Messwerten auf (z. B. messages_per_second). Bei Inaktivität werden dann keine Daten mehr gemeldet. Der HorizontalPodAutoscaler betrachtet den Messwert als nicht verfügbar und stoppt die Herunterskalierungsvorgänge.
  • Verzögerung beim Herunterskalieren aus der Skalierungsrichtlinie: Mit dem Feld behavior des HorizontalPodAutoscalers können Sie Skalierungsrichtlinien konfigurieren. Die Standardrichtlinie für das Herunterskalieren enthält ein Stabilisierungsfenster von 300 Sekunden (5 Minuten). In diesem Zeitraum wird die Anzahl der Replikate durch den HorizontalPodAutoscaler nicht reduziert, auch wenn die Messwerte unter den Zielgrenzwert gefallen sind. Dieses Zeitfenster verhindert schnelle Schwankungen, kann aber dazu führen, dass das Herunterskalieren langsamer als erwartet erfolgt.

Lösung

Versuchen Sie Folgendes:

  1. Wenn Sie mehrere Messwerte haben oder Messwerte nicht verfügbar sind, müssen Sie den Messwert diagnostizieren, der Probleme verursacht:

    kubectl describe hpa HPA_NAME -n NAMESPACE_NAME

    Suchen Sie in der Ausgabe im Abschnitt Metrics nach Messwerten mit dem Status <unknown> und im Abschnitt Events nach Warnungen wie FailedGetCustomMetric oder FailedGetExternalMetric. Eine detaillierte Anleitung zum Debuggen von Pipelines finden Sie im Abschnitt Fehlerbehebung bei benutzerdefinierten und externen Messwerten.

  2. Wenn ein Messwert während eines Zeitraums mit wenig Traffic nicht verfügbar ist (was bei ratenbasierten Messwerten häufig vorkommt), versuchen Sie eine der folgenden Lösungen:

    • Verwenden Sie nach Möglichkeit messgerätebasierte Messwerte anstelle von ratenbasierten. Ein Messwert vom Typ „Gauge“, z. B. die Gesamtzahl der Nachrichten in einer Warteschlange (z. B. subscription oder num_undelivered_messages), meldet konsistent einen Wert, auch wenn dieser Wert 0 ist. So kann der HorizontalPodAutoscaler zuverlässige Skalierungsentscheidungen treffen.
    • Achten Sie darauf, dass Ihre Messwertquelle Nullwerte meldet. Wenn Sie den benutzerdefinierten Messwert steuern, konfigurieren Sie ihn so, dass er in inaktiven Zeiträumen 0 veröffentlicht, anstatt überhaupt keine Daten zu senden.

  3. Wenn das standardmäßige fünfminütige Stabilisierungsfenster für Herunterskalierungen zu lang ist, können Sie es anpassen. Sehen Sie sich den Bereich spec.behavior.scaleDown Ihres HorizontalPodAutoscaler-Manifests an. Sie können den stabilizationWindowSeconds senken, damit die Autoscaling-Funktion nach dem Sinken der Messwerte schneller skaliert. Weitere Informationen zum Konfigurieren dieser Richtlinien finden Sie in der Kubernetes-Dokumentation unter Skalierungsrichtlinien.

Fehlerbehebung bei der Skalierung von GKE-Arbeitslasten auf und von null mit HPA

In diesem Abschnitt finden Sie Informationen zur Diagnose von Problemen bei der Konfiguration von Arbeitslasten, die mit HPA auf null skaliert werden (minReplicas: 0) und von null skaliert werden können, in GKE 1.37 oder höher.

Arbeitslast wird nicht auf null skaliert

Wenn Ihre Arbeitslast bei einem oder mehreren Replikaten bleibt, obwohl die Nachfrage auf null sinkt, prüfen Sie Folgendes:

  1. minReplicas prüfen: Achten Sie darauf, dass das Feld-Wert-Paar minReplicas: 0 in Ihrem HorizontalPodAutoscaler-Manifest festgelegt ist.
  2. Messwerttypen prüfen: Der HPA kann nicht auf null skaliert werden, wenn er nur CPU- oder Arbeitsspeicher-Messwerte (Resource) verwendet. Sie müssen mindestens einen External- oder Object-Messwert konfigurieren.
  3. Mehrere Messwerte prüfen: Das HPA wird auf Grundlage des Messwerts skaliert, für den die höchste Replikatanzahl erforderlich ist. Wenn Sie mehrere Messwerte konfigurieren, wird die Arbeitslast nur dann auf null skaliert, wenn jeder überwachte Messwert null ergibt.
  4. Auf das Stabilisierungsfenster für das Herunterskalieren warten: Standardmäßig wartet die GKE fünf Minuten (scaleDown.stabilizationWindowSeconds: 300) lang, bis die Nachfrage kontinuierlich null ist, bevor sie von einem auf null Replikate herunterskaliert.
  5. Nicht verfügbare Messwerte prüfen: Wenn der Wert eines Messwerts als <unknown> angezeigt wird, pausiert der HPA die Herunterskalierungsvorgänge, um eine vorzeitige Herunterskalierung zu verhindern. Weitere Informationen finden Sie unter Fehlerbehebung beim Herunterskalieren des horizontalen Pod-Autoscalers.

Arbeitslast wird nicht ab null skaliert

Wenn Ihre Arbeitslast bei steigendem Bedarf bei null Replikaten bleibt, prüfen Sie Folgendes:

  1. HorizontalPodAutoscaler prüfen: Führen Sie den Befehl kubectl describe hpa HPA_NAME aus und prüfen Sie die folgenden Abschnitte in der Ausgabe:

    • Bereich „Messwerte“: Prüfen Sie, ob der Messwert größer als null ist und nicht als <unknown> angezeigt wird. Wenn der Messwert fehlt oder nicht aktualisiert wird, prüfen Sie, ob die externe Quelle (z. B. Pub/Sub) Ereignisse veröffentlicht und Cloud Monitoring sie empfängt.
    • Abschnitt „Bedingungen“:
      • Fehlerfreier Zustand mit null Replikaten: Prüfen Sie, ob für die Bedingungen AbleToScale: True, ScalingActive: True und ScaledToZero: True angezeigt wird (mit dem Grund ScaledToZero). In diesem Zustand skaliert GKE die Arbeitslast automatisch hoch, wenn die Nachfrage steigt.
      • Externer Override erkannt: Prüfen Sie, ob der Wert der Bedingung ScalingActive entweder False mit dem Grund ScalingDisabledExternalScaleToZero oder ScalingDisabledReplicaCountZero ist. Das weist darauf hin, dass die Arbeitslast manuell auf null skaliert wurde. Die Arbeitslast wurde beispielsweise manuell mit dem Befehl kubectl scale skaliert. Dadurch wird das Autoscaling pausiert, um Änderungskonflikte zu verhindern.

    • Lösung: Wenn Sie die automatische Skalierung fortsetzen möchten, skalieren Sie die Bereitstellung manuell auf ein oder mehrere Replikate zurück:

      kubectl scale deployment DEPLOYMENT_NAME --replicas=1

  2. Auf Kaltstartlatenz prüfen: Wenn die Arbeitslast langsam startet, kann die Knotenbereitstellung zu Verzögerungen führen. Damit die Standby-Rechenkapazität beim Skalieren von null bereit ist, sollten Sie Kapazitätsreserven verwenden.

Nächste Schritte