Optimisation du Déploiement Continu avec Kubernetes
Introduction
Optimiser le déploiement continu sur Kubernetes ne se résume pas à configurer ArgoCD et espérer que tout fonctionne. C'est un travail de fine-tuning permanent qui touche les stratégies de rolling update, la gestion des ressources, les health checks et le scaling. Après avoir géré des clusters Kubernetes en production sur plus de 8 missions, voici les optimisations qui font la différence.
Les readiness et liveness probes : bien les configurer change tout
La première optimisation, souvent bâclée, concerne les probes Kubernetes. Chez Bloomflow, un incident récurrent était des 502 lors des déploiements : les pods recevaient du trafic avant que l'application soit prête. La solution : une readiness probe configurée sur le healthcheck applicatif (pas juste un TCP check), avec un initialDelaySeconds adapté au temps de démarrage réel. Pour une application Spring Boot qui démarre en 25 secondes, mettre initialDelaySeconds: 5 est une erreur classique. J'utilise aussi systématiquement des startup probes pour les applications au démarrage lent, ce qui permet de configurer des liveness probes agressives sans risquer de tuer un pod en phase de boot. Chez Coopengo, cette correction a éliminé 100% des erreurs 502 lors des rolling updates.
Le resource management : requests vs limits
La gestion des ressources CPU et mémoire est un art. Chez F2R2, avec EKS Fargate, chaque pod doit déclarer ses requests pour que Fargate provisionne le bon profil. J'ai mis en place un processus systématique : observer les métriques réelles de consommation pendant 2 semaines, puis configurer les requests à la médiane et les limits à 2 fois les requests. Chez Metronome sur OVH Kubernetes, j'avais installé le Vertical Pod Autoscaler en mode recommandation pour ajuster les resources automatiquement. Un piège courant : ne pas mettre de limits mémoire. Sans limits, un memory leak peut consommer toute la mémoire du node et provoquer un OOMKill en cascade sur tous les pods du node. J'ai vu ce scénario chez Cardiologs, où un pod de traitement ECG sans limit mémoire a crashé le node entier.
Le PodDisruptionBudget pour des déploiements sans interruption
Le PodDisruptionBudget (PDB) est souvent oublié mais essentiel en production. Il garantit qu'un nombre minimum de pods reste disponible pendant les mises à jour ou les maintenances de nodes. Chez KNDS, chaque deployment critique avait un PDB avec minAvailable: 2 ou maxUnavailable: 1. Lors d'un upgrade du cluster OVH Kubernetes, les nodes étaient drainés un par un, et le PDB empêchait Kubernetes de supprimer trop de pods d'un même service simultanément. Sans PDB, un drain de node peut supprimer tous les pods d'un service d'un coup, causant une interruption visible par les utilisateurs. C'est une protection simple à mettre en place et qui sauve des situations critiques.
L'Horizontal Pod Autoscaler avancé
L'autoscaling basique sur CPU est rarement suffisant. Chez TEKYN, le e-commerce avait des patterns de charge prévisibles (pics le soir et le week-end) mais aussi des pics imprévisibles (ventes flash). J'ai configuré le HPA avec des métriques custom Prometheus : le nombre de requêtes par seconde et la taille de la file d'attente RabbitMQ. Le scaling se déclenchait sur la métrique la plus critique, pas uniquement le CPU. J'ai aussi utilisé le KEDA (Kubernetes Event-Driven Autoscaling) pour scaler les workers de traitement de commandes en fonction du nombre de messages dans la queue. Résultat : scaling en 30 secondes au lieu de 3 minutes avec le HPA standard.
Les stratégies de déploiement avancées
Au-delà du rolling update par défaut, Kubernetes offre des possibilités avancées via des outils comme Argo Rollouts. Chez Earny SA, lors de la migration GCP vers AWS, j'ai utilisé des canary deployments avec Argo Rollouts : 5% du trafic sur la nouvelle version pendant 10 minutes, analyse automatique des métriques Prometheus (taux d'erreur, latence P95), puis progression automatique à 25%, 50%, 100% si les métriques étaient saines. En cas d'anomalie, le rollback était automatique. Cette approche a détecté une incompatibilité de driver PostgreSQL qui n'apparaissait que sous charge, invisible en staging. Le canary a rollbacké automatiquement après avoir détecté une augmentation de 15% de la latence P95 sur les 5% de trafic test.
Conclusion
L'optimisation du déploiement continu sur Kubernetes est un processus itératif. Les fondamentaux (probes, resources, PDB) doivent être en place dès le premier déploiement. Les optimisations avancées (HPA custom, canary, KEDA) viennent ensuite, guidées par les métriques de production. Chaque cluster que j'ai optimisé a gagné en fiabilité et en efficacité, souvent avec des gains mesurables : zéro interruption lors des déploiements, scaling 4 fois plus rapide, coûts d'infrastructure réduits de 20 à 30%.