Résoudre les problèmes liés à l'autoscaling vertical des pods

Lorsque l'autoscaling vertical des pods ne fonctionne pas comme prévu dans Google Kubernetes Engine (GKE), il est possible que vos charges de travail ne soient pas mises à l'échelle correctement. Ces problèmes peuvent empêcher les applications de gérer la charge, ce qui peut entraîner des problèmes de performances ou des pannes. Il est possible que les pods ne redémarrent pas avec de nouvelles recommandations de ressources ou que les recommandations ne correspondent pas à l'utilisation réelle.

Consultez ce document pour résoudre les problèmes courants liés à la configuration de VerticalPodAutoscaler ou aux recommandations inattendues. En suivant ces étapes de dépannage, vous pouvez aider vos applications à évoluer de manière efficace et fiable en fonction de la demande.

Ces informations sont importantes pour les développeurs d'applications qui configurent des ressources VerticalPodAutoscaler et doivent s'assurer que leurs applications sont mises à l'échelle correctement. Elles aident également les administrateurs et opérateurs de plate-forme à résoudre les problèmes liés à la configuration du cluster qui affectent les charges de travail mises à l'échelle automatiquement. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le Cloud de Confiance by S3NS contenu, consultez Rôles utilisateur et tâches courantes de GKE.

Diagnostiquer les problèmes liés à VerticalPodAutoscaler

Pour diagnostiquer les problèmes liés à un VerticalPodAutoscaler, inspectez l'état et la configuration à l'aide de kubectl ou de la Cloud de Confiance console.

Décrire le VerticalPodAutoscaler

Pour afficher les calculs en temps réel et les décisions de scaling récentes, utilisez la commande kubectl describe vpa :

kubectl describe vpa VPA_NAME -n NAMESPACE_NAME

Remplacez les éléments suivants :

  • VPA_NAME : nom de votre VerticalPodAutoscaler.
  • NAMESPACE_NAME : espace de noms de votre VerticalPodAutoscaler.

Le résultat ressemble à ce qui suit :

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>

Dans le résultat, examinez les sections principales suivantes :

  • Spec: affiche les détails de configuration, y compris le champ targetRef (charge de travail cible) et le champ updatePolicy (mode d'application des mises à jour).
  • Status: affiche la section Conditions (état opérationnel) et la section Recommendation (valeurs de ressources mémoire et de processeur générées pour chaque conteneur).
  • Events: répertorie les actions ou erreurs récentes liées à l'objet VerticalPodAutoscaler.

Afficher le fichier manifeste VerticalPodAutoscaler

Pour afficher la configuration et l'état complets d'un VerticalPodAutoscaler, inspectez son fichier manifeste YAML à l'aide de kubectl ou de la Cloud de Confiance console :

Console

  1. Dans la Cloud de Confiance console, accédez à la page Navigateur d'objets.

    Accéder au navigateur d'objets

  2. Cliquez sur la liste des filtres Type d'objet.

  3. Supprimez toutes les sélections existantes.

  4. Sélectionnez VerticalPodAutoscaler , puis cliquez sur OK.

  5. Dans la liste filtrée, sélectionnez le groupe d'API autoscaling.k8s.io.

  6. Sélectionnez le type d'objet VerticalPodAutoscaler.

  7. Cliquez sur le nom du VerticalPodAutoscaler que vous souhaitez inspecter.

kubectl

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

Remplacez les éléments suivants :

  • VPA_NAME : nom de votre VerticalPodAutoscaler.
  • NAMESPACE_NAME : espace de noms de votre VerticalPodAutoscaler.

Vérifier l'état de VerticalPodAutoscaler dans la Cloud de Confiance console

Pour inspecter l'état de VerticalPodAutoscaler pour vos charges de travail dans la Cloud de Confiance console :

  1. Accédez à la page Charges de travail.

    Accéder à la page Charges de travail

  2. Cliquez sur le nom de votre charge de travail.

  3. Accédez à l'onglet Détails , puis recherchez la section Autoscaler.

  4. Examinez la ligne Autoscaler vertical des pods pour obtenir des messages d'état concernant la collecte de métriques et l'état de la configuration.

Collecter les journaux de décision

Pour obtenir des insights détaillés sur les calculs et les décisions de VerticalPodAutoscaler, activez les journaux de décision de l'autoscaler vertical des pods (aperçu) dans Cloud Logging.

Ces journaux capturent des événements tels que UPDATE_RECOMMENDATION, EVICT_POD, APPLY_RECOMMENDATION_IN_PLACE et APPLY_RECOMMENDATION_ON_EVICTION.

Pour activer et inspecter les journaux de décision, consultez Collecter les journaux d'événements de l'autoscaler vertical des pods.

Résoudre les problèmes liés aux recommandations de VerticalPodAutoscaler

Les sections suivantes traitent des problèmes liés à un VerticalPodAutoscaler qui ne génère pas de recommandations ou qui génère des recommandations différentes de celles attendues.

Un VerticalPodAutoscaler ne fournit pas de recommandations

Symptômes :

  • Le champ Status.Recommendation du fichier manifeste VerticalPodAutoscaler est vide.
  • Les conditions du fichier manifeste VerticalPodAutoscaler affichent les conditions d'état NoPodsMatched, FetchingHistory ou LowConfidence.

Cause:

  • Cible incorrecte : le champ spec.targetRef du fichier manifeste VerticalPodAutoscaler ne pointe pas vers une charge de travail existante dans le même espace de noms.
  • Collecte initiale de métriques : le VerticalPodAutoscaler a été créé récemment et collecte toujours des données d'utilisation des ressources historiques.
  • Problèmes liés au composant metrics-server : le VerticalPodAutoscaler s'appuie sur les métriques du composant metrics-server. Si le composant metrics-server ne fonctionne pas correctement, le VerticalPodAutoscaler ne peut pas récupérer les données d'utilisation.
  • Aucun pod en cours d'exécution : la charge de travail cible ne comporte aucun pod en cours d'exécution ou prêt à être observé par le VerticalPodAutoscaler.

Solution:

  • Vérifiez le champ targetRef : vérifiez les valeurs des champs kind, name, et apiVersion dans la section spec.targetRef. Assurez-vous que toutes les valeurs correspondent à la charge de travail cible. Pour vérifier que la charge de travail existe, exécutez la commande suivante :

    kubectl get KIND WORKLOAD_NAME \
    -n NAMESPACE_NAME

    Remplacez les éléments suivants :

    • KIND : type de charge de travail, par exemple deployment ou statefulset.
    • WORKLOAD_NAME : nom de votre charge de travail.
    • NAMESPACE_NAME : espace de noms de votre charge de travail.

  • Laissez le temps à la collecte de métriques : les nouvelles ressources VerticalPodAutoscaler ont besoin de temps pour collecter des données. Surveillez le champ Status.Conditions pour une transition vers la condition d'état RecommendationProvided.

  • Vérifiez le composant metrics-server :

    1. Vérifiez que le pod du composant metrics-server est en cours d'exécution :

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

    2. Si le pod n'est pas en cours d'exécution ou s'il a un nombre élevé de redémarrages, vérifiez ses journaux :

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

      Les entrées de journal contenant des mots tels que error, failed ou unable to fetch indiquent des problèmes liés à la collecte de métriques.

  • Assurez-vous que les pods sont en cours d'exécution : vérifiez que la charge de travail cible comporte au moins un pod en cours d'exécution et prêt.

Les recommandations de VerticalPodAutoscaler sont inattendues

Symptômes :

  • Les valeurs de processeur ou de mémoire de la section Status.Recommendation sont supérieures ou inférieures à celles attendues.
  • Les recommandations ne correspondent pas à la consommation de ressources observée pour la charge de travail.

Cause:

  • Modifications du comportement de la charge de travail : les recommandations de VerticalPodAutoscaler sont basées sur l'historique d'utilisation. Il est possible que les changements récents dans les modèles de consommation des applications ne soient pas encore pris en compte.
  • Caractéristiques de la charge de travail : les tâches de courte durée ou les charges de travail avec des modèles d'utilisation très irréguliers peuvent ne pas recevoir de recommandations optimales.
  • Ressources VerticalPodAutoscaler en conflit : plusieurs ressources VerticalPodAutoscaler peuvent être configurées pour cibler la même charge de travail.

Solution:

  • Laissez un temps d'adaptation : laissez le temps à VerticalPodAutoscaler d'apprendre de nouveaux modèles d'utilisation après les modifications apportées à l'application.
  • Évaluez l'adéquation : déterminez si un VerticalPodAutoscaler ou un Autoscaler horizontal de pods est le mieux adapté au type de charge de travail.

  • Recherchez les ressources VerticalPodAutoscaler en conflit :

    1. Répertoriez toutes les ressources VerticalPodAutoscaler de votre cluster :

      kubectl get vpa --all-namespaces

    2. Examinez le champ spec.targetRef pour chaque ressource. Si plusieurs ressources VerticalPodAutoscaler ciblent la même charge de travail, supprimez ou ajustez les ressources en conflit afin qu'un seul VerticalPodAutoscaler cible une charge de travail donnée.

Résoudre les problèmes liés aux mises à jour des ressources des pods

Les sections suivantes traitent des problèmes liés à l'existence de recommandations qui ne sont pas appliquées aux pods cibles.

Les demandes de ressources des pods ne sont pas mises à jour

Symptômes :

  • Le fichier manifeste VerticalPodAutoscaler affiche des recommandations dans la section Status, mais le champ resources.requests du fichier manifeste du pod n'est pas mis à jour.
  • Les pods ne redémarrent pas pour appliquer les recommandations lorsque vous utilisez le mode de mise à jour Auto ou Recreate.

Cause:

  • Le champ updateMode est défini sur Off : lorsque le champ spec.updatePolicy.updateMode est défini sur Off, le VerticalPodAutoscaler génère des recommandations, mais ne les applique pas.
  • La charge de travail ne comporte qu'une seule instance répliquée : en mode de mise à jour Auto ou Recreate, le VerticalPodAutoscaler évite d'expulser les charges de travail à instance répliquée unique pour éviter les temps d'arrêt.

Solution:

  • Vérifiez le champ updateMode : modifiez le fichier manifeste VerticalPodAutoscaler pour définir le champ spec.updatePolicy.updateMode sur Auto, Recreate ou InPlaceOrRecreate.
  • Augmentez le nombre d'instances répliquées : pour les charges de travail utilisant le mode de mise à jour Auto ou Recreate, assurez-vous que le déploiement ou le StatefulSet comporte plus d'une instance répliquée.

Les mises à jour sur place échouent ou restent différées

Symptômes :

  • Le redimensionnement sur place du conteneur échoue ou reste différé.

Cause:

  • Capacité de nœud insuffisante : si le nœud ne dispose pas de la capacité nécessaire pour les demandes de ressources mises à jour, l'opération de redimensionnement sur place est différée.

Solution:

  • Vérifiez l'état du redimensionnement différé et la capacité du nœud :

    Si le redimensionnement reste différé pendant plus de cinq minutes, le VerticalPodAutoscaler revient à l'expulsion et à la recréation du pod pour appliquer la recommandation. Pour vérifier l'état de la mise à jour différée, procédez comme suit :

    1. Inspectez les annotations du pod pour vérifier si l'annotation vpaInPlaceUpdated est définie sur "true" :

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

    2. Vérifiez l'état différé en inspectant le champ status.conditions pour les événements de redimensionnement différé :

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

    3. Inspectez les événements Kubernetes pour le pod :

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

      Remplacez les éléments suivants :

      • NAMESPACE_NAME: espace de noms de votre pod.
      • POD_NAME : nom de votre pod.

      Recherchez les événements avec l'une des raisons suivantes : ResizedPod (mise à jour sur place réussie) ou EvictedByVPA (retour à la recréation).

Étape suivante