Fehlerbehebung beim horizontalen Pod-Autoscaling

Wenn horizontales Pod-Autoscaling in Google Kubernetes Engine (GKE) nicht wie erwartet funktioniert, werden Ihre Arbeitslasten möglicherweise nicht richtig skaliert. Dieses Problem kann verhindern, dass Anwendungen Lasten bewältigen, 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 Messwerte in Ihrem HorizontalPodAutoscaler-Status als <unknown> angezeigt werden oder dass Skalierungsvorgänge überhaupt nicht stattfinden.

Auf dieser Seite finden Sie Informationen zur Diagnose und Behebung häufiger Probleme mit dem horizontalen Pod-Autoscaling, von anfänglichen Fehlkonfigurationen in Ihren HorizontalPodAutoscaler-Objekten bis hin zu komplexeren Fehlern in der Messwertpipeline. Wenn Sie diese Schritte zur Fehlerbehebung ausführen, können Sie dafür sorgen, dass Ihre Anwendungen effizient und zuverlässig auf Grundlage der Nachfrage skaliert werden und die Ressource „Horizontales Pod-Autoscaling“ 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.

Wenn Sie bereits Symptome bemerkt oder eine Fehlermeldung gesehen haben, finden Sie in der folgenden Tabelle die richtigen Anleitungen:

Symptom Mögliche Lösung
Keine Skalierung, aber HorizontalPodAutoscaler-Bedingungen sind True Fehlerbehebung bei einem fehlerfreien, aber nicht reagierenden HorizontalPodAutoscaler
In den HorizontalPodAutoscaler-Ereignissen wird eine bestimmte Fehlermeldung angezeigt. Häufige Fehler beim horizontalen Pod-Autoscaling beheben
Messwert <unknown> Fehlerbehebung bei benutzerdefinierten und externen Messwerten
Wird nicht herunterskaliert Fehlerbehebung, wenn das horizontale Pod-Autoscaling nicht herunterskaliert

Hinweise

  • Achten Sie darauf, dass Sie HorizontalPodAutoscaler-Objekte mit skalierbaren Arbeitslasten wie Deployments und StatefulSets verwenden. 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:

    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 .

Status und Konfiguration des horizontalen Pod-Autoscalers prüfen

Beginnen Sie mit der Fehlerbehebung, indem Sie den Zustand und die Konfiguration des HorizontalPodAutoscaler-Objekts untersuchen. Mit dieser ersten Prüfung können Sie grundlegende Fehlkonfigurationen erkennen und beheben, die häufig die Ursache von Skalierungsproblemen sind.

HorizontalPodAutoscaler beschreiben

Verwenden Sie den Befehl kubectl describe hpa, um die Echtzeitberechnungen und die letzten Skalierungsentscheidungen des HorizontalPodAutoscaler aufzurufen. Dieser Befehl gibt eine Zusammenfassung des HorizontalPodAutoscaler-Objekts und ein Events-Log aus, das bei der Diagnose von Problemen hilfreich ist:

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
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: In diesem Abschnitt werden die aktuellen Messwerte im Vergleich zu ihren Zielvorhaben angezeigt. Prüfen Sie hier, ob der HorizontalPodAutoscaler Daten empfängt. Ein Messwert von <unknown> gibt an, dass der HorizontalPodAutoscaler den Messwert nicht abgerufen hat oder dass die Messwertpipeline unterbrochen ist.
  • Conditions: Diese allgemeine Systemdiagnose zeigt, ob der HorizontalPodAutoscaler Messwerte (AbleToScale) abrufen und Skalierungsberechnungen (ScalingActive) durchführen kann. Der Status False in einer dieser Bedingungen weist auf einen Fehler hin.
  • Events: In diesem Abschnitt werden die letzten Skalierungsaktionen, Warnungen und Fehler des HorizontalPodAutoscaler-Controllers protokolliert. Dort finden Sie oft bestimmte Fehlermeldungen oder Gründe wie FailedGetScale oder FailedGetResourceMetric, die Ihnen helfen, die Ursache des Problems zu ermitteln.

Status des HorizontalPodAutoscaler in Deployments prüfen

So prüfen Sie den Status der HorizontalPodAutoscaler-Objekte, die mit Ihren Deployments verwendet werden: Google Cloud

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

    Zu Arbeitslasten

  2. Klicken Sie auf den Namen Ihres Deployments.

  3. Rufen Sie den Tab Details auf und suchen Sie nach dem Abschnitt Autoscaling.

  4. Prüfen Sie den Wert in der Zeile Status:

    • Ein grünes Häkchen bedeutet, dass der HorizontalPodAutoscaler konfiguriert ist und seine Messwerte lesen kann.
    • Ein gelbes Dreieck bedeutet, dass der HorizontalPodAutoscaler konfiguriert ist, aber Probleme beim Lesen der Messwerte hat. Das ist ein häufiges Problem bei benutzerdefinierten oder externen Messwerten. Um dieses Problem zu beheben, müssen Sie herausfinden, warum die Messwerte nicht verfügbar sind. Weitere Informationen finden Sie im Abschnitt Fehlerbehebung bei benutzerdefinierten und externen Messwerten.

Bei anderen Arbeitslasttypen wie StatefulSets oder für weitere Details sehen Sie sich das Manifest des HorizontalPodAutoscaler-Objekts an.

Manifest des HorizontalPodAutoscalers prüfen

Im YAML-Manifest Ihres HorizontalPodAutoscaler-Objekts können Sie Informationen zu seiner Konfiguration und seinem 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 Aufklapppfeil 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 diesen wichtigen Abschnitten:

  • spec (Ihre Konfiguration):
    • scaleTargetRef: die Arbeitslast (z. B. ein Deployment), die vom HorizontalPodAutoscaler skaliert werden soll.
    • minReplicas und maxReplicas: die Einstellungen für die Mindest- und Höchstanzahl von Replikaten.
    • metrics: Die Messwerte, die Sie für die Skalierung konfiguriert haben, 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 von Pods und die Anzahl, auf die das horizontale Pod-Autoscaling skaliert werden soll.
    • conditions: Der wichtigste Abschnitt für die Fehlerbehebung. In diesem Abschnitt wird der Zustand des HorizontalPodAutoscaler angezeigt:
      • 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 minReplicas- oder maxReplicas-Einstellungen begrenzt wird.

Erweiterte Protokollierungsfunktionen verwenden

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

  • Ereignisse für horizontales Pod-Autoscaling in Cloud Logging ansehen: Verwenden Sie einen Logfilter, um alle Ereignisse für horizontales Pod-Autoscaling 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, für Menschen lesbare Logs, in denen erläutert wird, wie der HorizontalPodAutoscaler eine Empfehlung berechnet. Sie bieten detaillierte Einblicke in den Entscheidungsprozess.

Fehlerbehebung bei einem fehlerfreien, aber nicht reagierenden HorizontalPodAutoscaler

In diesem Abschnitt erfahren Sie, warum Ihr HorizontalPodAutoscaler möglicherweise keine Skalierungsaktionen auslöst, obwohl er anscheinend fehlerfrei ist und in seinem Status oder seinen Ereignissen keine Fehler gemeldet werden.

Symptome:

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

Ursache:

Dafür kann es mehrere Gründe geben:

  • Replikatlimits: Die aktuelle Anzahl der Replikate hat bereits den Grenzwert erreicht, der im Feld minReplicas oder maxReplicas in der HorizontalPodAutoscaler-Konfiguration festgelegt ist.
  • Toleranzbereich: Kubernetes verwendet einen standardmäßigen Toleranzbereich von 10 %, um Skalierungen 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 und die aktuelle Nutzung 93 % beträgt, ist das Verhältnis ungefähr 1,094 (93/85 ≈ 1,094). Da dieser Wert kleiner als 1,1 ist, wird der Horizontal Pod Autoscaler nicht hochskaliert.
  • Nicht bereite Pods: Das horizontale Pod-Autoscaling berücksichtigt nur Pods mit dem Status Ready in seinen Skalierungsberechnungen. Pods, die im Status Pending verbleiben oder nicht den Status Ready erreichen (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 einen Messwert und dem Beginn einer Skalierungsaktion ist normal.
  • Latenz für neue Messwerte: 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 Überwachungssystem (z. B. Cloud Monitoring) die neue Zeitachse erstellen muss, wenn der erste Datenpunkt geschrieben wird.
  • Berechnung mit mehreren Messwerten: Wenn Sie mehrere Messwerte konfigurieren, berechnet das horizontale Pod-Autoscaling die erforderliche Replikatanzahl für jeden Messwert unabhängig voneinander 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 dem höchsten Bedarf entspricht. Wenn beispielsweise CPU-Messwerte einen Bedarf von 9 Replikaten ergeben, ein Messwert für Anfragen pro Sekunde jedoch einen Bedarf von 15, skaliert das horizontale Pod-Autoscaling das Deployment auf 15 Replikate.

Lösung:

Probieren Sie die folgenden Lösungen aus:

  • Replica-Limits: 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 sich der Messwert außerhalb des Bereichs von 0,9 bis 1,1 befindet.
  • 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 für neue 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 die Aufskalierung auf einem Messwert (z. B. Anfragen pro Sekunde) basiert, wird die niedrigere Berechnung eines anderen Messwerts (z. B. CPU) korrekt überschrieben.

Häufige Fehler beim horizontalen Pod-Autoscaling beheben

In den folgenden Abschnitten finden Sie Lösungen für bestimmte Fehlermeldungen und Ereignisgründe, die beim Prüfen des Status Ihres HorizontalPodAutoscaler auftreten können. Normalerweise finden Sie diese Meldungen im Abschnitt Events der Ausgabe des Befehls kubectl describe hpa.

Fehler bei der Konfiguration des horizontalen Pod-Autoscalers beheben

Eine Fehlkonfiguration im HorizontalPodAutoscaler-Manifest, z. B. ein falsch geschriebenes Feld oder widersprüchliche Konfigurationen, verursacht die Fehler in diesem Abschnitt.

Fehler: Ungültige Messwerte

Dieser Fehler kann auftreten, wenn die Konfiguration für einen Messwert in einem HorizontalPodAutoscaler syntaktisch falsch oder inkonsistent ist.

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 nicht mit dem target übereinstimmt, den Sie in Ihrem HorizontalPodAutoscaler-Manifest definiert haben. Sie haben beispielsweise einen type von Utilization angegeben, aber einen Zielwert von averageValue anstelle von averageUtilization bereitgestellt.

Lösung:

Korrigieren Sie das HorizontalPodAutoscaler-Manifest so, dass 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.

Fehler: Mehrere Dienste wählen dasselbe Ziel aus

Dieser Fehler kann auftreten, wenn Sie das traffic-basierte Autoscaling mit einer falschen Dienstkonfiguration für Ihren HorizontalPodAutoscaler verwenden.

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 Eins-zu-eins-Beziehung zwischen dem Dienst und der automatisch skalierten Arbeitslast.

Lösung:

Achten Sie zur Behebung dieses Problems darauf, dass der Label-Selektor nur eines Dienstes mit den Pods Ihrer Arbeitslast übereinstimmt:

  1. So finden 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 der Bereitstellung.

    Die Ausgabe sieht etwa so aus:

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

  2. Suchen Sie nach allen Diensten, 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 würden sowohl {"app": "my-app"} als auch {"app": "my-app", "env": "prod"} mit den Beispiel-Pod-Labels übereinstimmen.

  3. Wählen Sie eine der folgenden Optionen aus, um den Konflikt zu beheben:

    • Machen Sie die Auswahl des gewünschten Dienstes eindeutig, indem Sie dem Feld spec.template.metadata.labels Ihres Deployments ein neues, eindeutiges Label hinzufügen. Aktualisieren Sie dann das Feld spec.selector des einen vorgesehenen Dienstes, um dieses neue Label einzufügen.
    • Machen Sie andere Dienstselektoren restriktiver, indem Sie das Feld spec.selector aller anderen in Konflikt stehenden Dienste 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 Bereitstellungsmanifest enthält.

Fehler: Label 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 lässt diesen Schlüssel für den Messwert nicht zu.

Lösung:

So beheben Sie das Problem:

  1. Ermitteln Sie den unzulässigen Labelnamen aus 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.

Problem: Mehrere HorizontalPodAutoscaler sind auf dieselbe Arbeitslast ausgerichtet

Wenn Sie mehrere HorizontalPodAutoscaler-Objekte zum Verwalten derselben Arbeitslast konfigurieren, führt dies zu widersprüchlichem und unvorhersehbarem Skalierungsverhalten.

Symptome:

Es gibt keinen bestimmten Condition oder Reason im Status eines HorizontalPodAutoscalers, der diesen Konflikt direkt angibt. Stattdessen treten möglicherweise die folgenden Symptome auf:

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

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 die Anzahl der Replikate unabhängig und versucht, die Arbeitslast basierend auf den eigenen Messwerten und Zielen zu skalieren. Kubernetes blockiert diese Konfiguration nicht, sie führt jedoch zu unregelmäßigen Skalierungsanpassungen, da die HorizontalPodAutoscaler miteinander konkurrieren.

Lösung:

Um Konflikte zu vermeiden, definieren Sie alle Skalierungsmesswerte in einem einzigen HorizontalPodAutoscaler-Objekt. Jeder HorizontalPodAutoscaler berechnet die Skalierungsanforderungen aus seinem eigenen spec.metrics-Feld. Durch das Zusammenführen kann das ausgewählte HorizontalPodAutoscaler-Objekt alle Faktoren wie CPU und Anfragen pro Sekunde berücksichtigen:

  1. Um herauszufinden, welche HorizontalPodAutoscaler auf dieselbe Arbeitslast ausgerichtet sind, rufen Sie das YAML-Manifest für jedes HorizontalPodAutoscaler-Objekt ab. 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, in denen verschiedene HorizontalPodAutoscaler-Ressourcen dieselben Werte für apiVersion, kind und name im Feld scaleTargetRef haben.

  2. Messwerte in einem einzigen HorizontalPodAutoscaler-Objekt zusammenfassen:

    1. Wählen Sie ein HorizontalPodAutoscaler-Objekt aus, das beibehalten werden soll. Diesen HorizontalPodAutoscaler werden Sie ändern.
    2. Sehen Sie sich den Abschnitt spec.metrics im Manifest der anderen HorizontalPodAutoscaler-Objekte an, die auf dieselbe Arbeitslast 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 behalten 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.

Fehler bei Arbeitslast und Ziel beheben

Die Fehler in diesem Abschnitt werden durch die Skalierung des Deployments, StatefulSets oder der Pods verursacht, nicht durch das HorizontalPodAutoscaler-Objekt selbst.

Fehler: Aktuelle Skalierung des Ziels kann nicht abgerufen werden

Dieser Fehler kann auftreten, wenn der HorizontalPodAutoscaler die Arbeitslast, die er skalieren soll, nicht finden oder darauf zugreifen kann.

Symptome:

Der Abschnitt Events hat die Bedingung FailedGetScale mit einer Meldung, die der folgenden ähnelt:

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 wird durch ein Problem im Feld scaleTargetRef im Manifest des HorizontalPodAutoscaler verursacht. Die angegebene Ressource ist möglicherweise nicht vorhanden, wurde gelöscht oder enthält einen Rechtschreibfehler.

Lösung:

Probieren Sie die folgenden Lösungen aus:

  1. Manifest des HorizontalPodAutoscaler-Objekts prüfen: Achten Sie darauf, dass die Werte von name, kind und apiVersion im Feld scaleTargetRef genau mit den entsprechenden Metadaten Ihrer Zielarbeitslast übereinstimmen.scaleTargetRef Wenn der Arbeitslastname falsch ist, aktualisieren Sie das Feld scaleTargetRef des HorizontalPodAutoscaler, damit es auf den richtigen Namen verweist.
  2. Prüfen, ob die Arbeitslast vorhanden ist: Die Zielarbeitslast muss sich im selben Namespace wie der HorizontalPodAutoscaler befinden. 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 befindet, Ihre Arbeitslast jedoch in einem anderen Namespace oder umgekehrt. Prüfen Sie den Namespace für beide Objekte und achten Sie darauf, 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.

Fehler: Anzahl der Replikate konnte nicht berechnet werden

Dieser Fehler kann auftreten, wenn der HorizontalPodAutoscaler die Skalierung basierend auf der Ressourcenauslastung berechnen muss, aber die erforderlichen Baseline-Informationen aus den Pods fehlen.

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:

Das horizontale Pod-Autoscaling 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, auf der der HorizontalPodAutoscaler für alle Container im Pod skaliert werden soll. Beispiel:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
...
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"

Fehler: Pod-Messwerte für Pod konnten nicht abgerufen werden

Dieser Fehler kann auftreten, wenn es ein Problem beim Abrufen der Messwerte gibt, die für einen HorizontalPodAutoscaler erforderlich sind, um Skalierungsentscheidungen zu treffen. Sie hängen oft mit Pod-Ressourcendefinitionen zusammen.

Symptome:

Es wird eine Meldung ähnlich der folgenden angezeigt:

unable to fetch pod metrics for pod

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

Ursache:

Wenn Sie die Skalierung auf der Grundlage des prozentualen Anteils der Ressourcenauslastung (z. B. cpu oder memory) vornehmen 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.

Fehler bei der Metrics API und der Datenverfügbarkeit beheben

In den folgenden Abschnitten erfahren Sie, wie Sie Fehler beheben, die auftreten, wenn der HorizontalPodAutoscaler versucht, Daten aus einer Messwert-API abzurufen. Diese Probleme können von internen Kommunikationsfehlern im Cluster, bei denen die Metrics API nicht verfügbar ist, bis hin zu ungültigen Anfragen reichen, die vom Metrics-Anbieter abgelehnt werden (oft als HTTP-Fehler auf 400-Ebene).

Fehler: Keine bekannten verfügbaren Messwertversionen gefunden

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 sind:

  • Der Kubernetes API-Server ist vorübergehend nicht verfügbar, z. B. während eines Clusterupgrades oder einer Reparatur der Steuerungsebene.
  • Die Pods des Messwerteadapters (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. Integrität der Kubernetes-Steuerungsebene prüfen:

    1. Sehen Sie sich in der Google Cloud Console den Zustand und Status Ihres Clusters an.

      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 dieser Zeit möglicherweise kurzzeitig nicht verfügbar.

    2. Prüfen Sie Cloud-Audit-Logs auf Fehler im Zusammenhang mit Steuerungsebenenkomponenten. Informationen zum Ansehen dieser Logs finden Sie unter Informationen zum GKE-Audit-Logging.

  2. Status und Logs der Pods des Messwerteadapters prüfen: Die Pods des Messwerteadapters müssen den Status Running haben und dürfen nicht kürzlich neu gestartet worden sein:

    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 aufweist, untersuchen Sie den Pod, um die Ursache zu ermitteln. Tipps zur Fehlerbehebung finden Sie in der Kubernetes-Dokumentation unter Pods debuggen.

  3. Prüfen, ob die Metrics 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.

Fehler: Bei der Abfrage 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. Das ist etwas anderes, als wenn ein Messwert mit dem Wert 0 gefunden wird. 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:

Probieren Sie die folgenden Lösungen aus:

  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 Anwendung, die für den Messwert verantwortlich ist, in Betrieb war und versucht hat, während des Zeitraums, in dem die HPA-Warnungen (Horizontal Pod Autoscaler) aufgetreten sind, Daten an Cloud Monitoring zu senden.
  4. Fehler untersuchen:Prüfen Sie die Logs der Anwendung aus demselben Zeitraum auf explizite Fehler im Zusammenhang mit der Messwerterfassung, z. B. Verbindungsfehler, ungültige Anmeldedaten oder Formatierungsprobleme.

Fehlerbehebung bei benutzerdefinierten und externen Messwerten

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

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

In diesem Abschnitt wird beschrieben, wie Sie diese Pipeline vom Messwertadapter bis zur Messwertquelle debuggen.

Symptome:

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

  • Der Messwert wird als <unknown> angezeigt.
  • In den 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:

Führen Sie die folgenden Schritte aus, um Fehler in der Pipeline zu beheben:

  1. Prüfen, ob der Messwerteadapter registriert und verfügbar ist: Der Messwerteadapter muss sich beim Haupt-Kubernetes-API-Server registrieren, um Messwerte bereitzustellen. So können Sie am einfachsten 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, Netzwerkverbindung zur Messwertquelle oder Meldungen, die darauf hinweisen, dass der Messwert nicht gefunden werden konnte.

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

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

    der Befehle entfernen, um die unverarbeitete JSON-Antwort aufzurufen.

    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_secondoder queue_depth.

  3. Befehlsausgabe analysieren: Das Ergebnis der vorherigen Befehle gibt Aufschluss darüber, 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 den Messwertnamen auf Rechtschreibfehler oder falsche matchLabels.

    • 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. Identifizieren Sie den Messwerteadapterdienst. Normalerweise befindet sich die Datei im Namespace custom-metrics oder kube-system:

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

      2. Ermitteln Sie den Port, den der Adapter überwacht:

        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 ermittelt 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. So finden 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, den der Messwertadapter überwacht.

      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 zugelassen 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 Abrufen von Messwerten. So sehen Sie sich die Logs an:

        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.

Fehlerbehebung, wenn das horizontale Pod-Autoscaling nicht herunterskaliert wird

In diesem Abschnitt erfahren Sie, warum ein HorizontalPodAutoscaler Ihre Arbeitslast möglicherweise nicht wie erwartet herunterskaliert.

Symptome:

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

Ursache:

Dieses Verhalten soll verhindern, dass schnell hoch- und herunterskaliert wird oder dass die Herunterskalierung auf unvollständigen Informationen basiert. Dafür gibt es zwei Hauptgründe:

  • Mehrere Messwerte verwenden: Das horizontale Pod-Autoscaling wird anhand des Messwerts 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 Herunterskalierung 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 das horizontale Pod-Autoscaling, die Arbeitslast herunterzuskalieren. Es kann nicht ermittelt werden, ob der Messwert fehlt, weil die Nutzung tatsächlich null ist oder weil die Messwertpipeline unterbrochen ist. Dieses Problem tritt häufig bei ratenbasierten benutzerdefinierten Messwerten auf (z. B. messages_per_second). Diese können die Meldung von Daten einstellen, wenn keine Aktivität vorhanden ist. Dadurch sieht das horizontale Pod-Autoscaling den Messwert als nicht verfügbar an und stoppt die Herunterskalierungsvorgänge.
  • Verzögerung beim Herunterskalieren aus der Skalierungsrichtlinie: Mit dem Feld behavior des HorizontalPodAutoscaler können Sie Skalierungsrichtlinien konfigurieren. Die Standardrichtlinie für das Herunterskalieren enthält ein Stabilisierungsfenster von 300 Sekunden (5 Minuten). In diesem Zeitraum verringert HorizontalPodAutoscaler die Anzahl der Replikate nicht, auch wenn die Messwerte unter den Zielschwellenwert gefallen sind. Dieses Zeitfenster verhindert schnelle Schwankungen, kann aber das Herunterskalieren verlangsamen.

Lösung:

Probieren Sie die folgenden Lösungen aus:

  1. Wenn mehrere Messwerte oder nicht verfügbare Messwerte Probleme verursachen, gehen Sie so vor:

    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 geringem Traffic nicht mehr 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 Messwerten. Ein Messwert vom Typ „Gauge“, z. B. die Gesamtzahl der Nachrichten in einer Warteschlange (z. B. subscription oder num_undelivered_messages), gibt immer einen Wert zurück, auch wenn dieser Wert 0 ist. So kann das horizontale Pod-Autoscaling zuverlässige Skalierungsentscheidungen treffen.
    • Achten Sie darauf, dass in der Messwertquelle Nullwerte gemeldet werden. Wenn Sie die benutzerdefinierte Messwertquelle kontrollieren, konfigurieren Sie sie so, dass in inaktiven Zeiträumen ein 0 veröffentlicht wird, anstatt überhaupt keine Daten zu senden.

  3. Wenn die standardmäßige Stabilisierungszeit von fünf Minuten für das Herunterskalieren zu lang ist, können Sie sie anpassen. Sehen Sie sich den Abschnitt spec.behavior.scaleDown Ihres HorizontalPodAutoscaler-Manifests an. Sie können den stabilizationWindowSeconds senken, damit die Autoscaling-Funktion nach dem Sinken der Messwerte schneller herunterskaliert. Weitere Informationen zum Konfigurieren dieser Richtlinien finden Sie in der Kubernetes-Dokumentation unter Skalierungsrichtlinien.

Nächste Schritte

  • Wenn Sie in der Dokumentation keine Lösung für Ihr Problem finden, lesen Sie den Abschnitt Support erhalten. Dort finden Sie weitere Hilfe, z. B. zu den folgenden Themen: