Surveillance et alertes du Vertical Pod Autoscaler Kubernetes : guide pratique

Introduction

Le Vertical Pod Autoscaler (VPA) de Kubernetes ajuste automatiquement les demandes et limites de CPU et de mémoire des pods en fonction de l'utilisation historique et actuelle. Bien que le VPA simplifie la gestion des ressources, il nécessite une surveillance attentive pour garantir son bon fonctionnement, éviter toute instabilité et ne pas sur- ou sous-provisionner. Ce guide propose une approche pratique pour surveiller le VPA, collecter les bonnes métriques, configurer des alertes, créer des tableaux de bord et gérer les incidents.

Nous couvrirons l'ensemble du cycle de vie opérationnel : de l'inventaire initial des versions et de l'environnement, en passant par une configuration sécurisée, la vérification, les modes de défaillance, et enfin une liste de contrôle opérationnelle. Chaque section comprend des commandes concrètes, les sorties attendues et les critères de décision pour vous aider à exécuter le VPA en production avec confiance.

L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, protéger les valeurs sensibles, vérifier les résultats et documenter les chemins de récupération. Que vous soyez développeur, ingénieur DevOps ou membre d'une équipe technique de startup, ce guide vous aidera à passer d'un problème détecté à une résolution vérifiée.

Inventaire des versions et de l'environnement

Avant de surveiller le VPA, vous devez comprendre ce qui est installé et en cours d'exécution. Commencez par identifier la version du VPA, sa topologie de déploiement, les prérequis et les composants spécifiques que vous allez inspecter. Cet inventaire établit une base de référence et aide à éviter les erreurs de configuration.

Vérification de l'installation du VPA

Utilisez la commande suivante pour lister les pods VPA et leurs espaces de noms :

kubectl get pods -n kube-system | grep vpa

Sortie attendue (exemple) :

vpa-admission-controller-6f7b8c9d-abcde   1/1     Running   0          2d
vpa-recommender-7b8c9d6f5-xyz12          1/1     Running   0          2d
vpa-updater-8c9d6f5e4-pqr34             1/1     Running   0          2d

Le VPA se compose de trois composants principaux :

• Recommender : Surveille l'utilisation des ressources et génère des recommandations.
• Updater : Évince les pods s'ils doivent être recréés avec de nouvelles demandes de ressources.
• Admission Controller : Ajuste les demandes de ressources sur les nouveaux pods si configuré.

Si l'un de ces composants est manquant ou ne fonctionne pas, le VPA ne fonctionnera pas correctement. Vérifiez les journaux de chaque composant :

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

Recherchez des erreurs telles que Failed to list pods ou Unable to fetch metrics. La sortie attendue doit être une série de lignes de journal indiquant une collecte réussie des métriques.

Vérification de la version de l'API VPA

Différentes versions du VPA ont des capacités différentes. Vérifiez la version de l'API prise en charge par votre cluster :

kubectl api-versions | grep autoscaling.k8s.io

La sortie attendue inclut autoscaling.k8s.io/v1 (pour le VPA) et éventuellement autoscaling.k8s.io/v1beta2 selon votre version.

Documentez la version exacte et tous les correctifs personnalisés. Cela est essentiel lors de la consultation de la documentation ou du signalement de problèmes.

Prérequis

Assurez-vous que :

• Metrics Server est installé et en cours d'exécution (kubectl get deployment metrics-server -n kube-system).
• Les CRD VPA sont présentes : kubectl get crd | grep verticalpodautoscalers.
• Vous disposez des autorisations RBAC nécessaires pour afficher les objets VPA et les événements.

Observation vs. Intervention

À ce stade, ne faites que collecter des informations. Ne modifiez aucune ressource. Capturez l'état actuel avec des horodatages :

kubectl get vpa --all-namespaces -o yaml > vpa-inventory-$(date +%Y%m%d-%H%M%S).yaml

Ce fichier d'inventaire est votre référence de restauration.

Chemin de configuration sûr

Une fois que vous avez un inventaire, vous pouvez apporter des modifications de configuration de manière contrôlée. Le VPA est configuré via une ressource personnalisée VerticalPodAutoscaler. Un cas d'utilisation courant consiste à activer le VPA pour un déploiement spécifique en mode recommandation uniquement (également appelé mode Off), afin de pouvoir examiner les recommandations avant de les appliquer automatiquement.

Création d'un objet VPA en mode Off

Voici un manifeste VPA minimal pour un déploiement nommé my-app dans l'espace de noms default, défini en mode Off :

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-app-vpa
  namespace: default
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: my-app
  updatePolicy:
    updateMode: "Off"

Appliquez-le :

kubectl apply -f vpa-off.yaml

Sortie attendue :

verticalpodautoscaler.autoscaling.k8s.io/my-app-vpa created

Le recommender commencera alors à générer des recommandations mais ne modifiera pas les ressources des pods.

Examen des recommandations

Après un certain temps (par exemple, 24 heures pour capturer les schémas quotidiens), vérifiez les recommandations :

kubectl describe vpa my-app-vpa -n default

Recherchez la section Recommendation dans la sortie :

Recommendation:
  Container Recommendations:
    Container Name:  my-app-container
    Lower Bound:
      Cpu:     100m
      Memory:  50Mi
    Target:
      Cpu:     250m
      Memory:  128Mi
    Upper Bound:
      Cpu:     500m
      Memory:  256Mi

Ces valeurs indiquent la plage dans laquelle le VPA suggère que les demandes de votre conteneur devraient se situer. La valeur Target est celle que le VPA appliquerait s'il était en mode Auto.

Passage en mode Auto

Après avoir confiance dans les recommandations, vous pouvez passer en mode Auto en modifiant le champ updateMode. Tout d'abord, éditez le VPA :

kubectl edit vpa my-app-vpa -n default

Changez updateMode: "Off" en updateMode: "Auto" et enregistrez.

Alternativement, utilisez un patch :

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

Sortie :

verticalpodautoscaler.autoscaling.k8s.io/my-app-vpa patched

Déploiement sûr

Lors du passage en mode Auto, l'updater du VPA peut évincer des pods pour appliquer de nouvelles demandes de ressources. Pour minimiser les perturbations :

• Appliquez les modifications pendant une fenêtre de faible trafic.
• Assurez-vous que votre déploiement possède plusieurs réplicas (par exemple, au moins 3) pour maintenir la disponibilité.
• Surveillez le déploiement :

kubectl rollout status deployment/my-app -n default

Sortie attendue :

deployment "my-app" successfully rolled out

Si le déploiement échoue, vous pouvez revenir en arrière en remettant updateMode à Off et en ajustant manuellement les ressources.

Vérification et diagnostics

Cette section explique comment vérifier que le VPA fonctionne correctement et diagnostiquer les problèmes courants.

Vérification du statut du VPA

Utilisez la commande suivante pour voir le statut du VPA dans votre cluster :

kubectl get vpa --all-namespaces

Exemple de sortie :

NAMESPACE   NAME         MODE   CPU    MEM       PROVIDED   AGE
default     my-app-vpa   Auto   250m   128Mi     True       1d

La colonne PROVIDED indique si le VPA a fourni une recommandation. True signifie que le recommender a suffisamment de données pour faire une recommandation. False peut indiquer des métriques manquantes ou un historique insuffisant.

Inspection des événements

Le VPA génère des événements qui peuvent aider à diagnostiquer les problèmes :

kubectl describe vpa my-app-vpa -n default | grep -A10 Events

Les événements courants incluent :

• Cannot obtain CPU/memory metrics for pod... - Metrics Server peut être en panne ou ne pas collecter.
• Pod ... is not suitable for VPA - Le pod peut ne pas avoir les bons labels ou être contrôlé par un contrôleur non pris en charge.

Vérification des recommandations dans le temps

Vous pouvez consulter l'historique des recommandations en utilisant :

kubectl get vpa my-app-vpa -n default -o yaml | grep -A5 -B5 recommendation

Ou, si vous avez Prometheus, interrogez la métrique vpa_recommendation_target pour voir les tendances.

Validation des ressources appliquées

Si le VPA est en mode Auto, vérifiez que les pods ont été recréés avec les ressources recommandées :

kubectl get pods -n default -l app=my-app -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[0].resources}{"\n"}{end}'

Exemple de sortie :

my-app-6c7d8f9b-abcde   map[limits:map[cpu:500m memory:256Mi] requests:map[cpu:250m memory:128Mi]]

Si les ressources ne correspondent pas à la cible du VPA, vérifiez si l'admission controller est activé et si le pod a été créé après l'activation du VPA.

Modes de défaillance et récupération

Le VPA peut échouer de différentes manières. Comprendre ces modes de défaillance vous aide à réagir rapidement.

Défaillance : le recommender VPA ne fonctionne pas

Symptôme : kubectl get pods -n kube-system | grep vpa ne montre aucun pod recommender ou le pod est en CrashLoopBackOff.

Diagnostic :

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

Recherchez des erreurs telles que connection refused vers le serveur de métriques ou une configuration invalide.

Récupération :

• Vérifiez le statut de Metrics Server : kubectl get apiservice v1beta1.metrics.k8s.io -o yaml et assurez-vous qu'il est Available.
• Si le recommender est mal configuré, corrigez la configuration (par exemple, les variables d'environnement) et redémarrez le déploiement :

kubectl rollout restart deployment/vpa-recommender -n kube-system

Défaillance : l'updater VPA évince les pods de manière répétée

Symptôme : Les pods d'un déploiement sont constamment évincés et recréés, provoquant des redémarrages et des perturbations.

Diagnostic :

• Vérifiez les événements du VPA :

kubectl describe vpa my-app-vpa -n default | grep -A20 Events

• Recherchez des messages comme Evicted pod ... due to resource update.

Récupération :

• Mettez temporairement le VPA en mode Off pour arrêter les évictions :

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

• Cherchez pourquoi le VPA change continuellement de recommandations (par exemple, métriques bruitées, données insuffisantes) et envisagez d'ajuster minReplicas ou d'utiliser un recommender personnalisé.

Défaillance : le VPA n'applique pas les recommandations

Symptôme : Le VPA affiche des recommandations mais les pods ne sont pas mis à jour.

Diagnostic :

• Assurez-vous que updateMode est Auto.
• Vérifiez si le webhook de l'admission controller est enregistré :

kubectl get mutatingwebhookconfigurations | grep vpa

• Si le webhook est absent, réinstallez l'admission controller VPA.

Récupération :

• Si l'admission controller ne fonctionne pas, vous pouvez mettre à jour manuellement les ressources du déploiement pour correspondre à la cible VPA comme solution temporaire.

Récupération générale : stratégie de restauration

Ayez toujours un plan de restauration. Par exemple, si le VPA provoque une instabilité, vous pouvez :

1. Mettre le VPA en mode Off.
2. Définir manuellement les demandes de ressources à une valeur connue et bonne (par exemple, celle d'avant l'activation du VPA).
3. Supprimer l'objet VPA si nécessaire :

kubectl delete vpa my-app-vpa -n default

Puis surveillez le déploiement pour vérifier sa stabilité.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle pour les opérations VPA quotidiennes ou hebdomadaires. Remplacez les valeurs d'exemple par celles spécifiques à votre environnement.

Vérifications quotidiennes

Exemple de sortie acceptable : toutes les lignes affichent True ; tout False nécessite une enquête.

kubectl get events --all-namespaces | grep -i vpa | tail -20. Recherchez des erreurs d'éviction ou de recommandation.

• [ ] Exécutez kubectl get vpa --all-namespaces et confirmez que tous les VPA ont PROVIDED=True.
• [ ] Vérifiez les événements liés au VPA dans les espaces de noms critiques :
• [ ] Passez en revue les alertes Prometheus pour les métriques VPA (si configurées).

Vérifications hebdomadaires

• [ ] Validez que les recommandations VPA sont dans les plages attendues pour vos applications. Comparez les demandes de ressources actuelles des pods aux cibles VPA.
• [ ] Vérifiez les erreurs dans les journaux des composants VPA :

  kubectl logs -n kube-system deployment/vpa-recommender --since=24h | grep -i error | tail -20

Aucune erreur ne doit apparaître ; si des erreurs apparaissent, enquêtez rapidement.

• [ ] Sauvegardez les ressources personnalisées VPA :

  kubectl get vpa --all-namespaces -o yaml > vpa-backup-$(date +%Y%m%d).yaml

Avant toute modification

• [ ] Enregistrez l'état actuel : kubectl get vpa <name> -n <ns> -o yaml > before.yaml.
• [ ] Déterminez le changement exact à effectuer et son impact.
• [ ] Informez les membres de l'équipe concernés si le changement peut provoquer des évictions de pods.
• [ ] Ayez une commande de restauration prête (par exemple, kubectl apply -f before.yaml).

Après toute modification

• [ ] Vérifiez le changement : kubectl describe vpa <name> -n <ns>.
• [ ] Vérifiez le statut des pods : kubectl get pods -n <ns>.
• [ ] Surveillez les métriques de l'application pour détecter toute anomalie.

Conclusion

La surveillance du Vertical Pod Autoscaler Kubernetes est essentielle pour maintenir des charges de travail efficaces et stables. En suivant les pratiques de ce guide—commencer par un inventaire minutieux, configurer le VPA en toute sécurité, vérifier son comportement et savoir comment récupérer des défaillances—vous pouvez tirer parti des avantages du VPA sans les risques.

Rappelez-vous toujours des principes opérationnels : observer avant de modifier, limiter le rayon d'impact, protéger les valeurs sensibles, vérifier les résultats et documenter les étapes de récupération. Comme prochaine étape, choisissez une application à faible risque dans votre cluster, créez un VPA en mode Off et examinez ses recommandations pendant une semaine. Cette expérience pratique renforcera votre confiance et vous préparera à une adoption plus large.

Avec une surveillance et des alertes appropriées, le VPA peut devenir un composant fiable de votre stratégie de gestion des ressources Kubernetes.