Opérations de production avec Kubernetes Vertical Pod Autoscale : une liste de contrôle pratique

Introduction

Les opérations de production avec Kubernetes Vertical Pod Autoscale (VPA, Vertical Pod Autoscaler) doivent faire passer les opérateurs d’un problème observé à un résultat vérifié. Cet article fournit une liste de contrôle pratique destinée aux développeurs, consultants DevOps et équipes techniques de startups qui exécutent VPA en production. Il relie les opérations VPA, les éléments de la liste de contrôle, les bonnes pratiques et la maintenance à des commandes concrètes, des sorties attendues, des signes de défaillance et des décisions de récupération.

L’objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d’impact, utiliser des espaces réservés plutôt que des secrets, vérifier les résultats et documenter les étapes de récupération avant qu’un incident ne survienne.

VPA ajuste automatiquement les demandes et limites de ressources des pods en fonction de l’utilisation historique et actuelle. Il se distingue de l’autoscaler horizontal de pods (HPA, Horizontal Pod Autoscaler), qui fait varier le nombre de réplicas. VPA est utile pour les charges de travail dont les besoins en ressources sont variables, comme les traitements par lots, les services avec état ou les applications difficiles à calibrer manuellement. Toutefois, VPA en production exige une planification minutieuse, car il peut redémarrer des pods, évincer des charges de travail et interagir avec HPA et l’autoscaler de cluster.

Cette liste de contrôle couvre les principaux domaines opérationnels :

1. Inventaire des versions et de l’environnement – savoir ce qui est installé et ses prérequis.
2. Chemin de configuration sécurisé – déployer et ajuster VPA en toute sécurité.
3. Vérification et diagnostic – confirmer que VPA fonctionne et résoudre les problèmes.
4. Modes de défaillance et récupération – comprendre ce qui peut mal se passer et comment récupérer.
5. Liste de contrôle des opérations – une liste consolidée pour les opérations courantes et les incidents.

Chaque section comprend des commandes, des sorties attendues et des points de décision.

Inventaire des versions et de l’environnement

Avant toute action sur VPA, identifiez la version installée, la topologie de déploiement, les prérequis et le composant exact inspecté. VPA est composé de trois composants :

• Recommender (système de recommandation) : surveille l’utilisation des ressources et recommande des demandes et limites cibles.
• Updater (système de mise à jour) : évince les pods qui nécessitent de nouvelles valeurs de ressources et applique les mises à jour.
• Admission Controller (contrôleur d’admission) : intercepte la création des pods et réécrit les demandes de ressources.

Vérifiez si VPA est installé dans votre cluster :

kubectl get pods -n kube-system | grep vpa

Sortie attendue :

vpa-admission-controller-xxxxx   1/1     Running   0          2d
vpa-recommender-xxxxx            1/1     Running   0          2d
vpa-updater-xxxxx                1/1     Running   0          2d

Si le pod du contrôleur d’admission est absent, VPA ne peut pas modifier les pods en cours d’exécution ; il ne peut que recommander des valeurs. C’est essentiel : le UpdateMode d’un objet VPA détermine si VPA peut réellement modifier les ressources ou seulement fournir des recommandations.

Vérifiez la version de VPA en examinant l’image du conteneur :

kubectl get deployment vpa-recommender -n kube-system -o jsonpath='{.spec.template.spec.containers[0].image}'

Exemple de sortie :

registry.k8s.io/autoscaling/vpa-recommender:0.14.0

Prérequis :

• Kubernetes 1.12+ (nécessaire pour VPA, mais les versions plus récentes offrent une meilleure intégration).
• Metrics Server doit être installé et opérationnel pour que VPA collecte les métriques de ressources.
• Si vous utilisez HPA conjointement avec VPA, soyez conscient des conflits (abordés plus loin).
• Le cluster doit disposer d’une capacité suffisante pour les évictions de pods et le réordonnancement.

Commandes d’observation en lecture seule :

kubectl get vpa --all-namespaces
kubectl describe vpa <nom-vpa> -n <namespace>

Vérifiez que Metrics Server est sain :

kubectl get apiservice v1beta1.metrics.k8s.io -o yaml

État attendu : Available: True.

Enregistrez l’état actuel avec des horodatages avant toute modification :

date -u +"%Y-%m-%dT%H:%M:%SZ"
kubectl get deployment -n kube-system | grep vpa
kubectl get pods -n kube-system | grep vpa

Conservez un journal de ces sorties pour l’audit et la restauration.

Important : VPA nécessite que le contrôleur d’admission soit enregistré en tant que webhook de mutation (MutatingAdmissionWebhook). Vérifiez :

kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations | grep vpa

Si le webhook n’est pas enregistré, VPA n’appliquera pas les recommandations aux nouveaux pods.

Chemin de configuration sécurisé

Une fois l’environnement compris, suivez un chemin sécurisé pour configurer VPA. La ressource clé est la ressource personnalisée VerticalPodAutoscaler.

Une définition VPA minimale :

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: "Auto"

UpdateMode peut être :

• Off : VPA recommande uniquement, ne modifie jamais les pods.
• Initial : VPA applique les demandes de ressources uniquement à la création du pod ; n’évince pas les pods en cours d’exécution.
• Recreate : VPA peut évincer et recréer des pods pour appliquer de nouvelles recommandations.
• Auto : VPA utilise Recreate pour les pods pouvant être évincés en toute sécurité (en respectant le budget de perturbation des pods, PodDisruptionBudget) et Initial sinon.

Pour la production, commencez par Off ou Initial afin d’observer les recommandations avant d’autoriser les modifications.

Appliquez l’objet VPA :

kubectl apply -f vpa.yaml

Vérifiez sa création :

kubectl get vpa my-app-vpa

Sortie attendue :

NAME          MODE   CPU   MEM   PROVIDED   AGE
my-app-vpa    Off    100m  256Mi  true       10s

Consultez les recommandations détaillées :

kubectl describe vpa my-app-vpa

Extrait d’exemple :

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

Cela vous indique la plage recommandée et les valeurs cibles. Avant d’activer Auto, assurez-vous que :

• Votre application peut tolérer les redémarrages (si Recreate).
• Les budgets de perturbation des pods (PDB, PodDisruptionBudget) sont configurés afin que les évictions ne provoquent pas d’interruption de service.
• HPA n’est pas configuré sur la même ressource (CPU/mémoire) pour éviter les conflits.

Si vous devez utiliser à la fois HPA et VPA, utilisez VPA pour la mémoire et HPA pour le CPU, ou définissez VPA en mode Off pour la métrique contrôlée par HPA. Sinon, VPA risque d’écraser les décisions de dimensionnement de HPA.

Exemple de configuration sécurisée avec PDB :

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

Appliquez le PDB avant d’activer Auto.

Pour passer le mode de mise à jour de Off à Auto, modifiez l’objet VPA :

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

Effectuez toujours une petite modification, vérifiez, puis continuez.

Vérification et diagnostic

La vérification garantit que VPA fonctionne comme prévu et aide à diagnostiquer les problèmes.

Vérifier l’état de VPA :

kubectl get vpa my-app-vpa -o yaml

Recherchez status.conditions :

conditions:
- lastTransitionTime: "2024-03-15T10:00:00Z"
  status: "True"
  type: RecommendationProvided

Si le statut est False, examinez les journaux du recommender :

kubectl logs -n kube-system deployment/vpa-recommender | tail -20

Problème fréquent : aucune métrique disponible. Vérifiez Metrics Server :

kubectl top pods

Si cette commande échoue, Metrics Server n’est peut-être pas installé ou ne collecte pas de métriques.

Vérifier si VPA met à jour les pods :

Lorsque le mode de mise à jour est Auto ou Recreate, l’Updater de VPA peut évincer des pods. Consultez les événements :

kubectl get events -n default --field-selector involvedObject.name=my-app-vpa

Recherchez des événements d’éviction :

5m         Warning   EvictedByVPA   pod/my-app-1234   Pod was evicted by VPA Updater to apply resource recommendations.

Vérifiez si le pod a redémarré avec de nouvelles ressources :

kubectl get pod my-app-1234 -o yaml | grep -A4 resources

Si les ressources ne sont pas mises à jour, assurez-vous que le contrôleur d’admission fonctionne. Consultez ses journaux :

kubectl logs -n kube-system deployment/vpa-admission-controller | tail -20

Vérifier que les recommandations sont appliquées aux nouveaux pods :

Créez un déploiement de test et inspectez les demandes de ressources du pod après sa création :

kubectl run test-pod --image=nginx --restart=Never
kubectl get pod test-pod -o jsonpath='{.spec.containers[0].resources}'

Si VPA est configuré pour ce déploiement, les ressources doivent être modifiées.

Commandes de diagnostic :

• Vérifier l’endpoint de métriques du recommender VPA :

kubectl port-forward -n kube-system svc/vpa-recommender 8942:8942
curl http://localhost:8942/metrics | grep vpa_recommender

• Vérifier les métriques de l’updater :

kubectl port-forward -n kube-system svc/vpa-updater 8943:8943
curl http://localhost:8943/metrics

Des métriques telles que vpa_recommender_recommendation_latest indiquent une activité.

Modes de défaillance et récupération

VPA peut échouer de plusieurs manières. Les comprendre facilite une récupération rapide.

1. VPA évince des pods critiques

Symptôme : redémarrages de pods inattendus, baisse de la disponibilité de l’application.

Cause : UpdateMode défini sur Auto ou Recreate sans PDB appropriés.

Récupération :

• Définissez immédiatement VPA sur Off :

kubectl patch vpa my-app-vpa --type='merge' -p '{"spec":{"updatePolicy":{"updateMode":"Off"}}}'

• Recréez le pod avec les ressources d’origine si nécessaire.

• Ajoutez des PDB et envisagez le mode Initial.

2. Le recommender VPA ne fournit pas de recommandations

Symptôme : kubectl describe vpa ne montre aucune recommandation, status.conditions de type RecommendationProvided est False.

Cause : Metrics Server indisponible ou le recommender ne parvient pas à récupérer les métriques.

Diagnostic :

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

Recherchez des erreurs telles que failed to get metrics.

Récupération :

• Réparez Metrics Server :

kubectl get deployment metrics-server -n kube-system
kubectl rollout restart deployment metrics-server -n kube-system

• Si les métriques sont absentes pendant une longue période, VPA peut désactiver les recommandations. Après correction, attendez quelques minutes.

3. Le contrôleur d’admission VPA ne modifie pas les pods

Symptôme : les nouveaux pods sont créés avec les demandes de ressources d’origine alors que VPA est en mode Auto.

Cause : webhook non enregistré, contrôleur d’admission non exécuté ou non-concordance du targetRef de VPA.

Diagnostic :

kubectl get mutatingwebhookconfigurations vpa-webhook-config -o yaml

Vérifiez qu’il existe et possède le bon bundle CA.

Consultez les journaux du contrôleur d’admission :

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

Récupération :

• Recréez la configuration du webhook si elle est corrompue.
• Assurez-vous que le contrôleur d’admission est en cours d’exécution.
• Vérifiez que le targetRef de l’objet VPA correspond au déploiement.

4. Conflit entre VPA et l’autoscaler horizontal de pods

Symptôme : HPA tente de faire varier le nombre de réplicas en fonction du CPU, mais VPA ajuste également les demandes de CPU, provoquant une oscillation.

Cause : VPA et HPA gèrent tous deux le CPU.

Récupération :

• Configurez VPA pour gérer uniquement la mémoire, et HPA pour le CPU. Cela nécessite de personnaliser les politiques de conteneur de VPA :

spec:
  resourcePolicy:
    containerPolicies:
    - containerName: "*"
      controlledResources: ["memory"]

• Ou désactivez HPA et comptez sur VPA pour les deux.

5. VPA provoque une pénurie de ressources sur le nœud

Symptôme : pods évincés en raison de la pression sur le nœud, VPA recommande des valeurs élevées.

Cause : VPA surestime en raison de pics ou de voisins bruyants.

Récupération :

• Définissez des bornes supérieures à l’aide de minAllowed et maxAllowed :

spec:
  resourcePolicy:
    containerPolicies:
    - containerName: "*"
      minAllowed:
        cpu: "50m"
        memory: "100Mi"
      maxAllowed:
        cpu: "500m"
        memory: "1Gi"

• Ajustez les paramètres du recommender VPA (par exemple, --recommendation-margin-fraction=0.15).

• Examinez l’utilisation réelle avec kubectl top pods.

Vérification de la récupération

Après toute action de récupération, vérifiez :

• L’état de VPA redevient normal.
• Les pods s’exécutent avec les ressources attendues.
• Les métriques de l’application sont stables.
• Aucune éviction inutile ne se produit.

Documentez chaque incident avec l’horodatage, le symptôme, la cause, l’action et le résultat.

Liste de contrôle des opérations

Utilisez cette liste concise pour les opérations courantes et les interventions sur incident.

Pré-déploiement

• [ ] Confirmer que les composants VPA s’exécutent dans kube-system.
• [ ] Confirmer que Metrics Server est sain.
• [ ] Confirmer que le webhook VPA est enregistré.
• [ ] Identifier la charge de travail et ses demandes/limites de ressources actuelles.
• [ ] Vérifier si HPA est déjà configuré sur la charge de travail.
• [ ] Définir le mode de mise à jour VPA en fonction de la tolérance de la charge aux redémarrages.
• [ ] Définir minAllowed et maxAllowed pour éviter un sur- ou sous-dimensionnement.
• [ ] Créer ou vérifier le budget de perturbation des pods (PDB, PodDisruptionBudget) si vous utilisez Auto ou Recreate.

Déploiement

• [ ] Appliquer le manifeste VPA et vérifier sa création.
• [ ] Vérifier les recommandations avec kubectl describe vpa.
• [ ] En mode Off, examiner manuellement les recommandations.
• [ ] En cas d’activation de Auto, le faire pendant une période de faible trafic et surveiller.

Vérification

• [ ] kubectl get vpa -o yaml montre RecommendationProvided=True.
• [ ] Les nouveaux pods reçoivent des ressources mises à jour (vérifier avec kubectl describe pod).
• [ ] Aucune éviction inattendue dans les événements.
• [ ] Les métriques de performance de l’application restent dans une plage acceptable.

Réponse aux incidents

• [ ] Si les pods sont évincés de manière excessive, définir immédiatement VPA sur Off.
• [ ] Vérifier les journaux du recommender et de l’updater pour détecter les erreurs.
• [ ] Vérifier Metrics Server et le webhook.
• [ ] Vérifier les conflits avec HPA.
• [ ] Ajuster les politiques de ressources si nécessaire.
• [ ] Documenter l’incident et la récupération.

Maintenance

• [ ] Examiner périodiquement les recommandations VPA par rapport à l’utilisation réelle.
• [ ] Surveiller les versions des composants VPA et effectuer les mises à niveau avec précaution.
• [ ] Tester le comportement de VPA en environnement de préproduction avant de l’appliquer en production.
• [ ] Maintenir à jour les PDB et les politiques de ressources.
• [ ] Garantir la fiabilité de la collecte des métriques.

Conclusion

Les opérations de production avec Kubernetes Vertical Pod Autoscale exigent une approche disciplinée, observable et réversible. Cette liste de contrôle fournit les commandes essentielles, les signes de défaillance et les décisions de récupération pour une exploitation sûre de VPA. Commencez par un inventaire en lecture seule, comprenez les composants et les modes de mise à jour de VPA, puis activez progressivement l’automatisation avec des garde-fous.

Comme prochaine étape, choisissez une vérification à faible risque : créez un VPA en mode Off pour un déploiement non critique, observez les recommandations pendant une journée, comparez-les avec l’utilisation réelle, puis décidez de passer ou non en mode Auto avec des bornes de ressources et des PDB appropriés.

Un flux de travail VPA fiable rend les défaillances visibles, protège les valeurs sensibles, limite les modifications aux ressources prévues et définit la vérification de la récupération avant qu’un incident ne force la décision.