Kubernetes Vertical Pod Autoscale : erreurs courantes et correctifs avec exemples pratiques

Introduction

Kubernetes Vertical Pod Autoscaler (VPA) ajuste dynamiquement les demandes et limites de CPU et de mémoire des pods en fonction de l'utilisation réelle. Bien que puissant, VPA peut introduire des problèmes subtils : pods bloqués en attente, évictions inattendues, recommandations incorrectes et conflits de configuration. Ce guide couvre les erreurs VPA les plus courantes que vous rencontrerez en production, comment les diagnostiquer avec des commandes pratiques et comment appliquer des correctifs en toute sécurité.

Nous nous concentrons sur les développeurs, les ingénieurs DevOps et les équipes techniques de startups qui exécutent Kubernetes en production. Chaque section comprend des scénarios du monde réel, des commandes kubectl, les sorties attendues et des extraits YAML concrets. Nous mettons l'accent sur la sécurité opérationnelle : observer d'abord, changer une chose à la fois et vérifier le résultat avant de continuer.

À la fin de cet article, vous serez en mesure de :

• Identifier si VPA est installé et sain dans votre cluster
• Diagnostiquer les erreurs VPA courantes à l'aide de kubectl et des journaux
• Appliquer des correctifs ciblés pour les contraintes de ressources, les mauvaises configurations et les conflits
• Utiliser VPA en toute confiance avec Horizontal Pod Autoscaler (HPA)

Inventaire de la version et de l'environnement

Avant de dépanner VPA, vous devez savoir exactement ce qui est installé et comment c'est configuré. Commencez par vérifier la version de VPA et l'état du déploiement.

Vérifier si VPA est installé

kubectl get pods -n kube-system | grep vpa

Sortie attendue si VPA est en cours d'exécution :

vpa-admission-controller-6c7f8b9d4-abcde   1/1     Running   0          2d
vpa-recommender-5f9c8b7d6-ghijk            1/1     Running   0          2d
vpa-updater-7d8e9f0a1-lmnop                1/1     Running   0          2d

Si vous ne voyez aucun pod, VPA n'est pas installé. Installez-le en suivant la documentation officielle pour votre version de Kubernetes.

Vérifier la version de l'API VPA

VPA utilise une définition de ressource personnalisée (CRD). Vérifiez les versions d'API disponibles :

kubectl api-versions | grep autoscaling.k8s.io

Sortie attendue (pour un cluster récent) :

autoscaling.k8s.io/v1

Si vous ne voyez que v1beta2, votre version de VPA peut être plus ancienne et avoir des comportements différents. Alignez vos étapes de dépannage avec la version de l'API.

Vérifier la source de métriques VPA

VPA s'appuie sur metrics-server ou Prometheus. Assurez-vous que metrics-server est en cours d'exécution :

kubectl get deployment metrics-server -n kube-system

Si metrics-server est manquant ou défaillant, les recommandations VPA seront vides ou retardées. Installez ou corrigez d'abord metrics-server.

Liste de contrôle clé pour l'inventaire de l'environnement :

• Les composants VPA s'exécutent dans l'espace de noms kube-system
• La version de l'API prend en charge votre cas d'utilisation
• La source de métriques est accessible
• Le cluster a une capacité suffisante pour les pods gérés par VPA

Chemin de configuration sûr

Une erreur courante consiste à créer un objet VPA qui entre en conflit avec les paramètres de ressources de pod existants ou qui a des paramètres invalides. Suivez ce chemin de configuration sûr pour éviter les mauvaises configurations.

Étape 1 : Comprendre les modes VPA

VPA prend en charge quatre modes de mise à jour :

• Off : fournit uniquement des recommandations, aucun changement
• Initial : définit les demandes de ressources uniquement à la création du pod
• Recreate : évince et recrée les pods pour appliquer de nouvelles demandes/limites (à utiliser avec précaution)
• Auto : met à jour dynamiquement les demandes de ressources sans éviction, mais les limites ne sont pas modifiées

L'erreur la plus courante est d'utiliser le mode Auto et de s'attendre à ce que les limites soient ajustées, ce qui n'arrive pas. VPA ne met à jour que les demandes (et les limites si minAllowed et maxAllowed sont définis et que le mode est Auto avec controlledResources incluant Limits). Soyez clair sur ce que VPA peut et ne peut pas faire.

Étape 2 : Valider votre YAML VPA

Voici une définition VPA minimale :

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-app-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: my-app
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
    - containerName: '*'
      minAllowed:
        cpu: 100m
        memory: 50Mi
      maxAllowed:
        cpu: 1
        memory: 500Mi
      controlledResources: ["cpu", "memory"]

Erreurs courantes :

• targetRef.name ne correspond pas à un déploiement existant
• containerName ne correspond pas au conteneur dans la spécification du pod
• minAllowed ou maxAllowed manquant, ce qui provoque des recommandations non bornées
• controlledResources omet une ressource que vous vous attendez à gérer

Étape 3 : Appliquer progressivement

N'appliquez jamais VPA à un grand déploiement sans test. Commencez avec une seule réplique et le mode Off pour observer les recommandations avant d'activer les mises à jour.

kubectl apply -f vpa.yaml
kubectl get vpa my-app-vpa -o yaml

Recherchez status.recommendation pour voir ce que VPA suggère.

Étape 4 : Surveiller les événements

Après avoir appliqué VPA, vérifiez les événements pour détecter des anomalies :

kubectl describe vpa my-app-vpa

La sortie attendue comprend des événements comme :

Events:
  Type    Reason             Age   From                Message
  ----    ------             ----  ----                -------
  Normal  Updated            10m   vpa-updater         Updated pod specs for my-app-1234

Si vous voyez des avertissements concernant des mises à jour échouées, examinez les journaux de vpa-updater.

Vérification et diagnostics

Une fois VPA configuré, vous devez vérifier qu'il fonctionne correctement et diagnostiquer toute erreur. Cette section couvre les commandes de diagnostic courantes et l'interprétation des résultats.

Vérifier le statut et les recommandations VPA

kubectl get vpa my-app-vpa -o jsonpath='{.status.recommendation.containerRecommendations[0].target}' && echo

Exemple de sortie attendue :

map[cpu:200m memory:100Mi]

Si la sortie est vide, VPA ne génère pas de recommandations. Cela indique souvent que metrics-server ne fournit pas de données ou que le pod n'a pas de demandes de ressources initiales.

Inspecter les événements VPA

kubectl describe vpa my-app-vpa | tail -20

Recherchez des événements d'erreur tels que :

Warning  FailedGetResourceMetric  5m  vpa-recommender  unable to get metrics for resource cpu: no metrics returned from resource metrics API

Cette erreur indique un problème de collecte de métriques.

Vérifier les journaux de vpa-recommender

kubectl logs -n kube-system deployment/vpa-recommender --tail=50

Recherchez les lignes contenant ERROR ou WARN. Erreurs courantes :

• failed to get metrics
• could not retrieve pod list
• inconsistent labels

Chaque ligne de journal comprend un nom de pod et une raison, ce qui vous donne une piste précise.

Vérifier les demandes et limites de ressources du pod

Après que VPA a mis à jour un pod, vérifiez les nouvelles demandes :

kubectl get pod my-app-1234 -o jsonpath='{.spec.containers[0].resources}' && echo

Sortie attendue :

map[limits:map[cpu:1 memory:500Mi] requests:map[cpu:200m memory:100Mi]]

Si les demandes sont inchangées, VPA peut ne pas mettre à jour en raison du mode Off ou d'une contrainte de politique.

Flux de dépannage

1. Confirmer que les composants VPA sont en cours d'exécution.
2. Confirmer que metrics-server est disponible.
3. Confirmer que l'objet VPA est correctement ciblé.
4. Confirmer que le mode de mise à jour n'est pas Off.
5. Confirmer qu'il n'y a pas de conflit avec HPA (expliqué plus loin).

Modes de défaillance et récupération

VPA peut causer ou être impliqué dans plusieurs modes de défaillance. Cette section détaille les erreurs les plus courantes, leurs symptômes, causes profondes et étapes de récupération.

Erreur 1 : Pods bloqués en état Pending

Symptôme : Les pods gérés par VPA restent en Pending avec des événements comme :

Warning  FailedScheduling  10m  default-scheduler  0/3 nodes are available: 3 Insufficient cpu.

Cause profonde : VPA a augmenté les demandes de ressources au-delà de la capacité de tout nœud, ou maxAllowed est défini trop haut.

Diagnostic :

kubectl describe pod my-app-1234 | grep -A5 Events

Vérifiez le CPU/mémoire demandé et la capacité des nœuds : kubectl get nodes -o custom-columns='NAME:.metadata.name,CPU:.status.allocatable.cpu,MEMORY:.status.allocatable.memory'

Récupération : Ajustez maxAllowed pour qu'il corresponde à votre cluster ou ajoutez plus de nœuds. Vous pouvez aussi temporairement définir updateMode: "Off" et réduire manuellement les demandes pour ramener le pod.

kubectl patch vpa my-app-vpa --type='json' -p='[{"op": "replace", "path": "/spec/updatePolicy/updateMode", "value": "Off"}]'

Ensuite, modifiez le déploiement pour réduire les demandes manuellement.

Erreur 2 : VPA évince les pods trop fréquemment

Symptôme : Les pods sont constamment évincés et recréés en raison du mode Recreate ou Auto de VPA avec des mises à jour agressives.

Cause profonde : La recommandation VPA change souvent en raison de l'utilisation fluctuante, et le mode de mise à jour déclenche des évictions à chaque changement.

Diagnostic :

kubectl get events --field-selector reason=Evicted -n my-namespace

Vérifiez les journaux de vpa-updater pour les décisions d'éviction.

Récupération : Passez en mode Auto si ce n'est pas déjà fait, et envisagez d'augmenter le minReplicas ou d'utiliser le mode Off pendant les pics de variabilité. Vous pouvez aussi ajuster l'intervalle du recommender (1 minute par défaut) en modifiant les drapeaux du déploiement du recommender.

Erreur 3 : Conflit entre HPA et VPA

Symptôme : HPA met à l'échelle les pods en fonction du CPU, et VPA ajuste également les demandes de CPU, ce qui provoque des oscillations ou un comportement de mise à l'échelle inattendu.

Cause profonde : HPA et VPA gèrent tous deux la même métrique de ressource. C'est un anti-modèle connu.

Diagnostic : Vérifiez si les deux ont targetRef vers le même déploiement : kubectl get hpa,vpa -n my-namespace

Récupération : N'utilisez pas HPA sur le CPU/la mémoire lorsque VPA est actif sur ces ressources. Si vous devez utiliser les deux, définissez VPA en mode Off ou limitez HPA aux métriques personnalisées uniquement. Alternativement, utilisez HPA sur des métriques externes et VPA sur les demandes de ressources.

Erreur 4 : Les recommandations VPA sont obsolètes ou vides

Symptôme : kubectl get vpa ne montre aucune recommandation ou des recommandations qui ne changent jamais.

Cause profonde : Metrics-server ne fonctionne pas, autorisations RBAC manquantes, ou targetRef VPA pointe vers une charge de travail inexistante.

Diagnostic :

• Vérifiez metrics-server : kubectl top pods -n kube-system
• Vérifiez la CRD VPA et les pods du contrôleur : kubectl logs -n kube-system deployment/vpa-recommender --tail=20
• Vérifiez RBAC : kubectl auth can-i get pods.metrics.k8s.io -n kube-system --as system:serviceaccount:kube-system:vpa-recommender

Récupération : Corrigez metrics-server ou RBAC, ou corrigez le targetRef. Après correction, attendez quelques minutes pour de nouvelles recommandations.

Erreur 5 : VPA ne met pas à jour les limites

Symptôme : Les demandes de pod sont mises à jour mais les limites restent inchangées, provoquant des tueries OOM.

Cause profonde : Par défaut, VPA ne met à jour que les demandes. Pour mettre à jour les limites, vous devez explicitement définir controlledResources pour inclure Limits et fournir minAllowed et maxAllowed pour les limites.

Diagnostic : Inspectez la configuration VPA et les limites du pod.

Récupération : Mettez à jour la politique de ressources VPA comme suit :

resourcePolicy:
  containerPolicies:
  - containerName: '*'
    controlledResources: ["cpu", "memory", "limits.cpu", "limits.memory"]
    minAllowed:
      cpu: 100m
      memory: 50Mi
      limits.cpu: 200m
      limits.memory: 100Mi
    maxAllowed:
      cpu: 1
      memory: 500Mi
      limits.cpu: 2
      limits.memory: 1Gi

Ensuite, appliquez et vérifiez.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle avant et après tout changement VPA pour garantir un fonctionnement sûr.

Avant d'activer VPA sur une charge de travail :

• [ ] Confirmer que les composants VPA sont sains : kubectl get pods -n kube-system | grep vpa
• [ ] Confirmer que metrics-server est disponible : kubectl top pods -n my-namespace
• [ ] Vérifier l'existence d'un HPA sur le même déploiement : kubectl get hpa -n my-namespace
• [ ] Définir d'abord le updateMode VPA sur Off pour observer les recommandations sans changement
• [ ] Définir minAllowed et maxAllowed pour éviter des demandes hors limites
• [ ] Tester sur un déploiement à faible impact avec une seule réplique

Après que VPA est actif :

• [ ] Surveiller les redémarrages de pods : kubectl get pods -w
• [ ] Vérifier les évictions : kubectl get events --field-selector reason=Evicted -n my-namespace
• [ ] Vérifier l'utilisation réelle des ressources : kubectl top pods -n my-namespace
• [ ] Examiner les recommandations VPA : kubectl get vpa -o yaml
• [ ] S'assurer qu'il n'y a pas d'épuisement des nœuds : kubectl describe nodes | grep -A5 'Allocated resources'

Plan de retour en arrière :

• Supprimer l'objet VPA : kubectl delete vpa my-app-vpa
• Définir manuellement les demandes et limites de ressources dans la spécification du déploiement
• Redéployer et vérifier que les pods fonctionnent

Conclusion

Kubernetes Vertical Pod Autoscaler peut améliorer considérablement l'utilisation des ressources et la stabilité des applications, mais il doit être configuré et surveillé avec soin. Ce guide a couvert les erreurs courantes telles que les pods bloqués en attente, les évictions fréquentes, les conflits HPA, les recommandations vides et les limites inchangées. Pour chacune, nous avons fourni des commandes pratiques, des exemples YAML et des étapes de récupération.

Rappelez-vous les principes opérationnels fondamentaux :

• Observer avant de changer : toujours vérifier l'état actuel et les journaux VPA
• Limiter le rayon d'impact : tester avec le mode Off et de petites charges de travail
• Vérifier après les changements : confirmer les recommandations, les ressources des pods et la capacité du cluster
• Avoir un plan de retour en arrière : savoir comment désactiver VPA et définir manuellement les ressources

Comme prochaine étape, exécutez la liste de contrôle opérationnelle sur l'un de vos déploiements. Commencez par le mode Off, observez les recommandations pendant une journée, puis passez progressivement au mode Auto avec des bornes min/max appropriées. Documentez vos résultats et partagez-les avec votre équipe.

Avec une mise en œuvre soignée, VPA vous aidera à exécuter un cluster Kubernetes plus efficace et résilient.