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 finden Sie Informationen zur Behebung häufiger Probleme mit der VerticalPodAutoscaler-Konfiguration oder unerwarteten Empfehlungen. Wenn Sie diese Schritte zur Fehlerbehebung befolgen, können Sie Ihre Anwendungen effizient und zuverlässig entsprechend der Nachfrage skalieren.

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

VerticalPodAutoscaler-Probleme diagnostizieren

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

VerticalPodAutoscaler beschreiben

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

kubectl describe vpa VPA_NAME -n NAMESPACE_NAME

Ersetzen Sie Folgendes:

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

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>

Sehen Sie sich in der Ausgabe die folgenden Hauptabschnitte an:

  • Spec: Hier werden Konfigurationsdetails angezeigt, einschließlich des Felds targetRef (die Zielarbeitslast) und des Felds updatePolicy (wie Updates angewendet werden).
  • Status: Zeigt den Abschnitt Conditions (Betriebszustand) und den Abschnitt Recommendation (CPU- und Arbeitsspeicherressourcenwerte, die für jeden Container generiert wurden) an.
  • Events: Listet die letzten Aktionen oder Fehler im Zusammenhang mit dem VerticalPodAutoscaler-Objekt auf.

Manifest für VerticalPodAutoscaler ansehen

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

Console

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

    Zum Objektbrowser

  2. Klicken Sie auf die Filterliste Objekttyp.

  3. Heben Sie alle vorhandenen Auswahlen auf.

  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 VerticalPodAutoscalers, 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 VerticalPodAutoscalers.

Status von VerticalPodAutoscaler in der Cloud de Confiance -Konsole prüfen

So prüfen Sie den VerticalPodAutoscaler-Status für Ihre Arbeitslasten in der Cloud de Confiance -Konsole:

  1. Zur Seite „Arbeitslasten“

    Zu Arbeitslasten

  2. Klicken Sie auf den Namen Ihrer Arbeitslast.

  3. Rufen Sie den Tab Details auf und suchen Sie den Bereich Autoscaling.

  4. In der Zeile Vertikales Pod-Autoscaling finden Sie Statusmeldungen zur Messwerterfassung und zum Konfigurationszustand.

Entscheidungsprotokolle erfassen

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

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 Ereignisprotokolle für vertikales Pod-Autoscaling erfassen.

Fehlerbehebung bei VerticalPodAutoscaler-Empfehlungen

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

Ein VerticalPodAutoscaler liefert keine Empfehlungen

Symptome:

  • Das Feld Status.Recommendation im VerticalPodAutoscaler-Manifest ist leer.
  • In den Bedingungen im VerticalPodAutoscaler-Manifest werden die Statusbedingungen NoPodsMatched, FetchingHistory oder LowConfidence angezeigt.

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 Verlaufsdaten zur Ressourcennutzung.
  • Probleme mit der metrics-server-Komponente: Der VerticalPodAutoscaler basiert auf Messwerten der metrics-server-Komponente. Wenn die metrics-server-Komponente nicht richtig funktioniert, kann der VerticalPodAutoscaler keine Nutzungsdaten abrufen.
  • Keine ausgeführten Pods: Die Zielarbeitslast hat keine ausgeführten oder bereiten Pods, die vom VerticalPodAutoscaler beobachtet werden können.

Lösung:

  • Feld targetRef prüfen: Prüfen Sie die Werte für die Felder kind, name und apiVersion im Bereich spec.targetRef. Achten Sie darauf, dass alle Werte mit der Zielarbeitslast übereinstimmen. Führen Sie 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: Namespace Ihrer Arbeitslast.

  • Zeit für die Erfassung von Messwerten einplanen: Für neue VerticalPodAutoscaler-Ressourcen ist Zeit erforderlich, um Daten zu erfassen. Behalten Sie das Feld Status.Conditions im Blick, um zu sehen, wann der Status zu RecommendationProvided wechselt.

  • metrics-server-Komponente 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, die Wörter wie error, failed oder unable to fetch enthalten, weisen auf Probleme bei der Erfassung von Messwerten hin.

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

Empfehlungen für VerticalPodAutoscaler 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 am Arbeitslastverhalten: VerticalPodAutoscaler-Empfehlungen basieren auf der bisherigen Nutzung. Aktuelle Änderungen bei den Nutzungsmustern von Anwendungen werden möglicherweise noch nicht berücksichtigt.
  • Arbeitslastmerkmale: Für kurzlebige Jobs oder Arbeitslasten mit sehr unregelmäßigen Nutzungsmustern werden möglicherweise keine optimalen Empfehlungen ausgegeben.
  • In Konflikt stehende VerticalPodAutoscaler-Ressourcen: Möglicherweise sind mehrere VerticalPodAutoscaler-Ressourcen für dieselbe Arbeitslast konfiguriert.

Lösung:

  • Anpassungszeit einplanen: Geben Sie dem VerticalPodAutoscaler Zeit, nach Anwendungsänderungen neue Nutzungsmuster zu lernen.
  • Eignung bewerten: Prüfen Sie, ob ein VerticalPodAutoscaler oder ein horizontaler Pod-Autoscaler für den Arbeitslasttyp am besten geeignet ist.

  • Nach in Konflikt stehenden VerticalPodAutoscaler-Ressourcen suchen:

    1. Alle VerticalPodAutoscaler-Ressourcen in Ihrem Cluster auflisten:

      kubectl get vpa --all-namespaces

    2. Sehen Sie sich das Feld spec.targetRef für jede Ressource an. Wenn mehrere VerticalPodAutoscaler-Ressourcen auf dieselbe Arbeitslast ausgerichtet sind, entfernen oder passen Sie die in Konflikt stehenden Ressourcen an, sodass 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 zeigt Empfehlungen im Abschnitt Status an, 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 verhindern.

Lösung:

  • updateMode-Feld prüfen: Ändern Sie das VerticalPodAutoscaler-Manifest, um das Feld spec.updatePolicy.updateMode auf Auto, Recreate oder InPlaceOrRecreate festzulegen.
  • Replikatanzahl erhöhen: Achten Sie bei Arbeitslasten, die den Aktualisierungsmodus Auto oder Recreate verwenden, darauf, dass das Deployment oder StatefulSet mehr als ein Replikat hat.

Direkte Updates schlagen fehl oder bleiben zurückgestellt

Symptome:

  • Die direkte Größenanpassung des Containers kann nicht abgeschlossen werden oder wird aufgeschoben.

Ursache:

  • Unzureichende Knotenkapazität: Wenn der Knoten nicht genügend Kapazität für die aktualisierten Ressourcenanfragen hat, wird der In-Place-Vorgang zur Größenänderung aufgeschoben.

Lösung:

  • Status der verzögerten Größenänderung und Knotenkapazität prüfen:

    Wenn die Größenänderung länger als fünf Minuten aufgeschoben wird, wird der Pod vom VerticalPodAutoscaler entfernt und neu erstellt, um die Empfehlung anzuwenden. So prüfen Sie den Status des verzögerten Updates:

    1. Prüfen Sie die Pod-Annotationen, um festzustellen, ob die Annotation vpaInPlaceUpdated 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 aufgeschobenen Status, indem Sie das Feld status.conditions nach Ereignissen für aufgeschobene Größenänderungen durchsuchen:

      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 einem der folgenden Gründe: ResizedPod (erfolgreiches In-Place-Update) oder EvictedByVPA (Fallback auf Neuerstellung).

Nächste Schritte