Fehlerbehebung beim vertikalen Pod-Autoscaling

Wenn das vertikale Pod-Autoscaling in der Google Kubernetes Engine (GKE) nicht wie erwartet funktioniert, werden Ihre Arbeitslasten möglicherweise nicht richtig skaliert. Diese Probleme können verhindern, dass Anwendungen die Last bewältigen, was zu Leistungsproblemen oder Ausfällen führen kann. Möglicherweise werden Pods nicht mit neuen Ressourcenempfehlungen neu gestartet oder Empfehlungen stimmen nicht mit der tatsächlichen Nutzung überein.

In diesem Dokument erfahren Sie, wie Sie häufige Probleme mit der VerticalPodAutoscaler-Konfiguration oder unerwarteten Empfehlungen beheben können. Wenn Sie diese Schritte zur Fehlerbehebung ausführen, können Ihre Anwendungen effizient und zuverlässig nach Bedarf skaliert werden.

Diese Informationen sind wichtig für Anwendungsentwickler, die VerticalPodAutoscaler-Ressourcen konfigurieren und sicherstellen müssen, dass ihre Anwendungen richtig skaliert werden. Sie helfen auch Plattformadministratoren und -operatoren bei der Fehlerbehebung bei Problemen mit der Clusterkonfiguration, die sich auf automatisch skalierte Arbeitslasten auswirken. Weitere Informationen zu den häufig verwendeten Rollen und Beispielaufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Probleme mit VerticalPodAutoscaler diagnostizieren

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

VerticalPodAutoscaler beschreiben

Mit dem Befehl kubectl describe vpa können Sie Echtzeitberechnungen und aktuelle Skalierungsentscheidungen aufrufen:

kubectl describe vpa VPA_NAME -n NAMESPACE_NAME

Ersetzen Sie Folgendes:

  • VPA_NAME: der Name Ihres VerticalPodAutoscaler.
  • NAMESPACE_NAME: der Namespace Ihres VerticalPodAutoscaler.

Die Ausgabe sieht etwa so aus:

Name:         sample-deployment-vpa
Namespace:    default
API Version:  autoscaling.k8s.io/v1
Kind:         VerticalPodAutoscaler
# Multiple lines are omitted here
Spec:
  Target Ref:
    API Version:  apps/v1
    Kind:         Deployment
    Name:         sample-deployment
  Update Policy:
    Update Mode:  Auto
Status:
  Conditions:
    Last Transition Time:  2025-10-09T10:00:00Z
    Message:               VPA is fetching history in order to provide recommendation
    Reason:                FetchingHistory
    Status:                True
    Type:                  FetchingHistory
    Last Transition Time:  2025-10-09T10:05:00Z
    Message:               VPA pod metrics aren't available yet
    Reason:                NoMetrics
    Status:                True
    Type:                  LowConfidence
    Last Transition Time:  2025-10-09T10:10:00Z
    Message:               VPA is able to provide a recommendation
    Reason:                RecommendationProvided
    Status:                True
    Type:                  RecommendationProvided
  Recommendation:
    Container Recommendations:
      Container Name:  sample-container
      Lower Bound:
        Cpu:     100m
        Memory:  128Mi
      Target:
        Cpu:     200m
        Memory:  256Mi
      Upper Bound:
        Cpu:     500m
        Memory:  512Mi
Events:          <none>

Prüfen Sie in der Ausgabe die folgenden Hauptabschnitte:

  • Spec: enthält Konfigurationsdetails, einschließlich des Felds targetRef (die Zielarbeitslast) und des Felds updatePolicy (wie Aktualisierungen angewendet werden).
  • Status: enthält den Abschnitt Conditions (Betriebszustand) und den Abschnitt Recommendation (CPU- und Arbeitsspeicherressourcenwerte, die für jeden Container generiert wurden).
  • Events: listet aktuelle Aktionen oder Fehler im Zusammenhang mit dem VerticalPodAutoscaler-Objekt auf.

VerticalPodAutoscaler-Manifest ansehen

Wenn Sie die vollständige Konfiguration und den Status eines VerticalPodAutoscaler aufrufen möchten, prüfen Sie das YAML-Manifest mit kubectl oder der Google Cloud Console:

Console

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

    Zum Objektbrowser

  2. Klicken Sie auf die Liste Objektart.

  3. Entfernen Sie alle vorhandenen Auswahlen.

  4. Wählen Sie VerticalPodAutoscaler aus und klicken Sie auf OK.

  5. Wählen Sie in der gefilterten Liste die API-Gruppe autoscaling.k8s.io aus.

  6. Wählen Sie die Objektart VerticalPodAutoscaler aus.

  7. Klicken Sie auf den Namen des VerticalPodAutoscaler, den Sie prüfen möchten.

kubectl

kubectl get vpa VPA_NAME \
    -n NAMESPACE_NAME \
    -o yaml

Ersetzen Sie Folgendes:

  • VPA_NAME: der Name Ihres VerticalPodAutoscaler.
  • NAMESPACE_NAME: der Namespace Ihres VerticalPodAutoscaler.

VerticalPodAutoscaler-Status in Google Cloud derConsole prüfen

So prüfen Sie den VerticalPodAutoscaler-Status für Ihre Arbeitslasten in der Google Cloud Console:

  1. Rufen Sie die Seite Arbeitslasten auf.

    Zu Arbeitslasten

  2. Klicken Sie auf den Namen Ihrer Arbeitslast.

  3. Rufen Sie den Tab Details auf und suchen Sie den Abschnitt Autoscaler.

  4. Prüfen Sie in der Zeile Vertical Pod Autoscaler Statusmeldungen zur Messwerterfassung und zum Konfigurationszustand.

Entscheidungslogs erfassen

Wenn Sie detaillierte Informationen zu VerticalPodAutoscaler-Berechnungen und -Entscheidungen erhalten möchten, aktivieren Sie in Cloud Logging die Entscheidungslogs für vertikales Pod-Autoscaling (Vorschau).

In diesen Logs werden Ereignisse wie UPDATE_RECOMMENDATION, EVICT_POD, APPLY_RECOMMENDATION_IN_PLACE und APPLY_RECOMMENDATION_ON_EVICTION erfasst.

Informationen zum Aktivieren und Prüfen von Entscheidungslogs finden Sie unter Ereignislogs für vertikales Pod-Autoscaling erfassen.

Fehlerbehebung bei VerticalPodAutoscaler-Empfehlungen

In den folgenden Abschnitten werden Probleme behandelt, bei denen ein VerticalPodAutoscaler keine Empfehlungen erstellt oder Empfehlungen generiert, die von den Erwartungen abweichen.

Ein VerticalPodAutoscaler gibt keine Empfehlungen

Symptome:

  • Das Feld Status.Recommendation im VerticalPodAutoscaler-Manifest ist leer.
  • Die Bedingungen im VerticalPodAutoscaler-Manifest zeigen die Statusbedingungen NoPodsMatched, FetchingHistory oder LowConfidence an.

Ursache:

  • Falsches Ziel: Das Feld spec.targetRef im VerticalPodAutoscaler-Manifest verweist nicht auf eine vorhandene Arbeitslast im selben Namespace.
  • Erste Messwerterfassung: Der VerticalPodAutoscaler wurde vor Kurzem erstellt und erfasst noch Daten zur bisherigen Ressourcennutzung.
  • Probleme mit der Komponente metrics-server: Der VerticalPodAutoscaler verwendet Messwerte aus der Komponente metrics-server. Wenn die Komponente metrics-server nicht richtig funktioniert, kann der VerticalPodAutoscaler keine Nutzungsdaten abrufen.
  • Keine aktiven Pods: Die Zielarbeitslast hat keine aktiven oder bereiten Pods, die der VerticalPodAutoscaler beobachten kann.

Lösung:

  • Feld targetRef prüfen: Prüfen Sie die Werte für die Felder kind, name, und apiVersion im Abschnitt spec.targetRef. Achten Sie darauf, dass alle Werte mit der Zielarbeitslast übereinstimmen. Führen Sie den folgenden Befehl aus, um zu prüfen, ob die Arbeitslast vorhanden ist:

    kubectl get KIND WORKLOAD_NAME \
    -n NAMESPACE_NAME

    Ersetzen Sie Folgendes:

    • KIND: der Arbeitslasttyp, z. B. deployment oder statefulset.
    • WORKLOAD_NAME: der Name Ihrer Arbeitslast.
    • NAMESPACE_NAME: der Namespace Ihrer Arbeitslast.

  • Zeit für die Messwerterfassung einplanen: Bei neuen VerticalPodAutoscaler-Ressourcen dauert es einige Zeit, bis Daten erfasst werden. Prüfen Sie das Feld Status.Conditions auf einen Übergang zur Statusbedingung RecommendationProvided.

  • Komponente metrics-server prüfen:

    1. Prüfen Sie, ob der Pod für die Komponente metrics-server ausgeführt wird:

      kubectl get pods -n kube-system | grep metrics-server

    2. Wenn der Pod nicht ausgeführt wird oder eine hohe Anzahl von Neustarts aufweist, prüfen Sie die Logs:

      kubectl logs -n kube-system -l k8s-app=metrics-server

      Logeinträge mit Wörtern wie error, failed oder unable to fetch weisen auf Probleme bei der Messwerterfassung hin.

  • Prüfen, ob Pods ausgeführt werden: Prüfen Sie, ob die Zielarbeitslast mindestens einen aktiven und bereiten Pod hat.

VerticalPodAutoscaler-Empfehlungen sind unerwartet

Symptome:

  • Die CPU- oder Arbeitsspeicherwerte im Abschnitt Status.Recommendation sind höher oder niedriger als erwartet.
  • Die Empfehlungen stimmen nicht mit dem beobachteten Ressourcenverbrauch der Arbeitslast überein.

Ursache:

  • Änderungen im Arbeitslastverhalten: VerticalPodAutoscaler-Empfehlungen basieren auf der bisherigen Nutzung. Aktuelle Änderungen bei den Nutzungsmustern von Anwendungen werden möglicherweise noch nicht berücksichtigt.
  • Arbeitslasteigenschaften: Bei kurzlebigen Jobs oder Arbeitslasten mit stark schwankenden Nutzungsmustern werden möglicherweise keine optimalen Empfehlungen gegeben.
  • Konflikte bei VerticalPodAutoscaler-Ressourcen: Möglicherweise sind mehrere VerticalPodAutoscaler-Ressourcen für dieselbe Arbeitslast konfiguriert.

Lösung:

  • Zeit für die Anpassung einplanen: Geben Sie dem VerticalPodAutoscaler Zeit, neue Nutzungsmuster nach Anwendungsänderungen zu erlernen.
  • Eignung prüfen: Prüfen Sie, ob ein VerticalPodAutoscaler oder ein HorizontalPodAutoscaler besser für den Arbeitslasttyp geeignet ist.

  • Auf Konflikte bei VerticalPodAutoscaler-Ressourcen prüfen:

    1. Listen Sie alle VerticalPodAutoscaler-Ressourcen in Ihrem Cluster auf:

      kubectl get vpa --all-namespaces

    2. Prüfen Sie das Feld spec.targetRef für jede Ressource. Wenn mehrere VerticalPodAutoscaler-Ressourcen auf dieselbe Arbeitslast ausgerichtet sind, entfernen oder passen Sie die in Konflikt stehenden Ressourcen so an, dass nur ein VerticalPodAutoscaler auf eine bestimmte Arbeitslast ausgerichtet ist.

Fehlerbehebung bei Pod-Ressourcenaktualisierungen

In den folgenden Abschnitten werden Probleme behandelt, bei denen Empfehlungen vorhanden sind, aber nicht auf Ziel-Pods angewendet werden.

Pod-Ressourcenanfragen werden nicht aktualisiert

Symptome:

  • Das VerticalPodAutoscaler-Manifest enthält Empfehlungen im Abschnitt Status, aber das Feld resources.requests im Pod-Manifest wird nicht aktualisiert.
  • Pods werden nicht neu gestartet, um Empfehlungen anzuwenden, wenn der Aktualisierungsmodus Auto oder Recreate verwendet wird.

Ursache:

  • Das Feld updateMode ist Off: Wenn das Feld spec.updatePolicy.updateMode auf Off gesetzt ist, generiert der VerticalPodAutoscaler Empfehlungen, wendet sie aber nicht an.
  • Arbeitslast hat nur ein Replikat: Im Aktualisierungsmodus Auto oder Recreate vermeidet der VerticalPodAutoscaler das Entfernen von Arbeitslasten mit einem einzelnen Replikat, um Ausfallzeiten zu vermeiden.

Lösung:

  • Feld updateMode prüfen: Ändern Sie das VerticalPodAutoscaler-Manifest um das Feld spec.updatePolicy.updateMode auf Auto, Recreate oder InPlaceOrRecreate zu setzen.
  • Anzahl der Replikate erhöhen: Bei Arbeitslasten, die den Auto oder Recreate Aktualisierungsmodus verwenden, muss das Deployment oder StatefulSet mehr als ein Replikat haben.

Direkte Aktualisierungen schlagen fehl oder werden verschoben

Symptome:

  • Die direkte Größenanpassung von Containern kann nicht abgeschlossen werden oder wird verschoben.

Ursache:

  • Unzureichende Knotenkapazität: Wenn der Knoten nicht genügend Kapazität für die aktualisierten Ressourcenanfragen hat, wird die direkte Größenanpassung verschoben.

Lösung:

  • Status der verschobenen Größenanpassung und Knotenkapazität prüfen:

    Wenn die Größenanpassung länger als fünf Minuten verschoben wird, entfernt der VerticalPodAutoscaler den Pod und erstellt ihn neu, um die Empfehlung anzuwenden. So prüfen Sie den Status der verschobenen Aktualisierung:

    1. Prüfen Sie die Pod-Annotationen, um festzustellen, ob die vpaInPlaceUpdated Annotation auf "true" gesetzt ist:

      metadata:
  annotations:
    vpaInPlaceUpdated: "true"
    vpaUpdates: 'Pod resources updated by sample-deployment-vpa: container 0: cpu request, memory request'

    2. Prüfen Sie den verschobenen Status, indem Sie das Feld status.conditions auf Ereignisse zur verschobenen Größenanpassung prüfen:

      status:
  conditions:
  - type: PodResizePending
    status: "True"
    reason: Deferred
    message: "Node didn't have enough resource: ..."

    3. Prüfen Sie die Kubernetes-Ereignisse für den Pod:

      kubectl get events -n NAMESPACE_NAME --field-selector involvedObject.kind=Pod,involvedObject.name=POD_NAME

      Ersetzen Sie Folgendes:

      • NAMESPACE_NAME: der Namespace Ihres Pods.
      • POD_NAME: der Name Ihres Pods.

      Suchen Sie nach Ereignissen mit einer der folgenden Ursachen: ResizedPod (erfolgreiche direkte Aktualisierung) oder EvictedByVPA (Fallback auf Neuerstellung).

Nächste Schritte