Kubernetes 1.35 : faut-il adopter les nœuds in-place pour réduire vos coûts ?
Kubernetes 1.35 facilite le redimensionnement in-place des pods. Bénéfices, limites et méthode pour optimiser vos serveurs.
Oui, le redimensionnement in-place des pods peut réduire vos coûts d’infrastructure si les ressources libérées vous permettent de retirer un VPS, de réduire un pool de nœuds autoscalé ou d’éviter l’ajout d’un serveur. Il ne redimensionne ni vos nœuds ni votre facture à lui seul.
Avec Kubernetes 1.35, vous pouvez ajuster les requests et limits CPU ou mémoire d’un conteneur en cours d’exécution sans recréer systématiquement son pod. Cette approche est utile lorsque les requests ont été fixées avec une marge de sécurité trop large, mais elle doit reposer sur des mesures réelles.
Ce que vous pouvez en attendre
Le gain vient de la consolidation : des requests plus proches de l’usage observé permettent au scheduler de placer davantage de pods sur les mêmes machines. Par exemple, si des requests mémoire empêchaient de regrouper les charges, leur réduction prudente peut rendre un VPS inutile ; l’économie correspond alors au VPS retiré, non au changement de manifeste.
Sur un serveur dédié fixe, le bénéfice est généralement indirect : vous pouvez absorber une nouvelle charge ou différer l’achat ou la location d’un second serveur. Dans un cloud, il devient plus direct lorsqu’un autoscaler de nœuds peut supprimer les machines devenues inutiles.
La documentation Kubernetes précise les conditions du redimensionnement des ressources de conteneurs. Selon la politique de redémarrage de la ressource, un changement peut être appliqué sans redémarrer le conteneur, exiger son redémarrage ou être différé si le nœud manque de capacité.
Vérifications avant de réduire les ressources
Examinez les pics CPU et mémoire, le throttling, les événements OOMKilled, la croissance de mémoire et la capacité réellement réservée sur les nœuds. Prometheus et Grafana peuvent servir à cette analyse ; les recommandations du Vertical Pod Autoscaler peuvent aider, sans remplacer une validation applicative.
La mémoire demande une attention particulière. Réduire une limite sous l’usage courant ne libère pas automatiquement de RAM et peut exposer l’application à un arrêt pour dépassement de mémoire.
Vérifiez aussi l’effet sur la classe QoS du pod et sur le HPA. Une métrique CPU exprimée en pourcentage de request peut augmenter après une baisse de request, à consommation identique, et déclencher plus tôt un scale-out.
Déploiement prudent
Commencez avec un service stateless, répliqué et non critique, dans un environnement de préproduction ou sur un replica canari. Évitez d’abord les bases de données, les charges à mémoire très variable et les applications sans métriques fiables.
- Relevez les pics sur un cycle représentatif de charge.
- Appliquez une faible réduction et surveillez disponibilité, latence, erreurs, throttling et événements Kubernetes.
- Contrôlez qu’aucun redimensionnement ne reste différé faute de capacité.
- Mesurez la capacité récupérée avant de modifier l’autoscaling ou de supprimer un nœud.
Conservez des manifestes versionnés, des seuils d’alerte et une procédure de retour aux anciennes requests et limits. Pour un service critique, testez aussi le comportement lors d’un redémarrage imposé, car l’absence de recréation du pod n’est pas garantie pour tous les changements.