L’article sur le VPA explique que son mode Auto redémarre systématiquement un pod pour appliquer une nouvelle recommandation de requests. Ce comportement, vrai historiquement, change avec le redimensionnement de pod sur place : une fonctionnalité qui permet de modifier les requests et limits d’un conteneur déjà en cours d’exécution, sans jamais le recréer.

Ce que le redimensionnement in-place change réellement

Avant cette fonctionnalité, modifier les requests ou limits d’un pod exigeait sa recréation complète : Kubernetes ne permettait tout simplement pas de changer ces champs sur un pod déjà planifié et en cours d’exécution. Le redimensionnement in-place introduit un sous-ressource resize qui accepte ce changement directement, sans passer par la suppression et la recréation du pod.

# Modifie les requests/limits d'un conteneur en cours
# d'exécution, sans jamais recréer le pod
kubectl patch pod my-app --subresource resize --patch \
  '{"spec":{"containers":[{"name":"app","resources":{"requests":{"cpu":"200m"}}}]}}'

Ce qui peut se redimensionner sans interruption, et ce qui ne peut pas

Une augmentation ou diminution de CPU s’applique généralement sans redémarrage du conteneur, le CPU étant une ressource compressible que le kernel peut réajuster à la volée via les cgroups. La mémoire est plus contrainte : une augmentation fonctionne souvent sans redémarrage, mais une diminution peut exiger un redémarrage du conteneur selon la politique de redimensionnement définie, puisque la mémoire déjà allouée ne peut pas être reprise de force sans risquer de tuer le processus.

# La politique de redimensionnement décide, ressource
# par ressource, si un redémarrage est nécessaire ou non
resizePolicy:
  - resourceName: cpu
    restartPolicy: NotRequired
  - resourceName: memory
    restartPolicy: RestartContainer

Ce que ça change pour le VPA

Le VPA peut désormais exploiter cette capacité via un mode InPlaceOrRecreate (en plus de Off, Initial, Auto déjà couverts), qui tente d’abord un redimensionnement sur place et ne recrée le pod que si la politique de redimensionnement l’exige (typiquement une réduction de mémoire) ou si le nœud ne peut techniquement pas accueillir le changement en place.

spec:
  updatePolicy:
    updateMode: "InPlaceOrRecreate"

Ce mode réduit significativement les interruptions par rapport au mode Auto classique, sans les éliminer complètement : il reste une catégorie de changements (réduction de mémoire notamment) qui déclenchent toujours un redémarrage, selon la politique définie.

Ce que ça ne change pas

Le redimensionnement in-place ne modifie jamais l’image du conteneur, ni aucun autre champ du pod en dehors des ressources CPU/mémoire : un changement de code applicatif exige toujours un déploiement classique avec recréation de pod, via un rolling update normal. Cette fonctionnalité reste strictement limitée à l’ajustement de dimensionnement, pas à la mise à jour de version.

À retenir

Le redimensionnement de pod sur place permet de modifier les requests et limits d’un conteneur déjà en cours d’exécution, sans jamais le recréer, une évolution qui corrige la limitation historique du mode Auto du VPA (redémarrage systématique). L’augmentation de CPU s’applique généralement sans interruption, une réduction de mémoire peut encore nécessiter un redémarrage selon la politique de redimensionnement définie par ressource. Le mode InPlaceOrRecreate du VPA exploite cette capacité pour réduire les interruptions, sans les éliminer entièrement, une évolution récente à connaître avant de dimensionner une stratégie d’autoscaling vertical pour une migration Kubernetes récente.