Optimisation des déploiements continus avec Kubernetes
Introduction
Le deploiement continu sur Kubernetes, je le pratique quotidiennement depuis 2018. Du cluster OVH chez Metronome au GKE Autopilot chez Okeiro, en passant par EKS Fargate chez F2R2, chaque contexte m'a enseigne des lecons differentes. La difference entre un CD qui "fonctionne" et un CD sur lequel l'equipe peut compter tient souvent a une poignee d'optimisations que je vais detailler ici.
Strategies de deploiement : le choix qui change tout
Kubernetes propose plusieurs strategies de mise a jour, et le choix de la bonne strategie depend directement de votre contexte metier.
Rolling Update : c'est le defaut, et il convient a 90% des cas. Les pods sont remplaces progressivement, avec zero downtime si les probes sont bien configurees. Chez Coopengo, en environnement HDS, on l'utilisait avec maxSurge: 1 et maxUnavailable: 0. Cette combinaison garantit qu'aucun pod n'est supprime avant qu'un nouveau soit pret a recevoir du trafic. Le cout : un pod supplementaire pendant la transition, ce qui necessite de la capacite disponible sur les noeuds.
Canary deployment : pour les cas critiques ou un bug peut avoir des consequences importantes. Chez KNDS, dans le secteur Defense, j'ai mis en place des canary deployments via ArgoCD Rollouts. Le principe : 10% du trafic est dirige vers la nouvelle version pendant 15 minutes. Prometheus collecte les metriques (taux d'erreurs, latence p99), et ArgoCD Rollouts promeut automatiquement si les seuils sont respectes. En 6 mois, cette approche a detecte 3 regressions de performance qui auraient impacte 100% des utilisateurs avec un rolling update classique.
Blue-green : chez Earny SA, pendant la migration GCP vers AWS, j'ai utilise une variante blue-green au niveau DNS. Les deux clusters (ancien GCP, nouveau AWS) tournaient en parallele. Le basculement se faisait via un changement de record DNS avec un TTL de 60 secondes. Le rollback consistait a pointer le DNS vers l'ancien cluster. Simple, fiable, et adapte au contexte de migration.
Helm Charts : la cle de l'industrialisation
Helm est mon outil de templating de reference. Chez Bloomflow, un Helm Chart "maison" parametrable servait de base a une trentaine de microservices. Chaque service declarait ses specificites dans un values-<service>.yaml : nombre de replicas, ressources, probes, routes d'ingress, variables d'environnement. Les avantages etaient concrets : uniformite des deploiements (un seul template a maintenir), gestion centralisee des versions, et rollback en une commande helm rollback.
Chez Okeiro, j'ai developpe un Helm Chart specifique pour le serveur FHIR (standard e-sante). La particularite : le chart integrait le Workload Identity GCP pour l'authentification native sans credentials statiques. Chaque pod recevait une identite GCP via un service account Kubernetes annote, eliminant les cles de service stockees en secret.
La migration de Helm v2 a v3 chez Coopengo a ete un chantier de 3 semaines. Le changement majeur : la suppression de Tiller (le composant serveur de Helm v2 qui avait des privileges excessifs). Le resultat en termes de securite et de maintenabilite a justifie chaque heure investie.
Reduire le temps de deploiement de 8 a 2 minutes
Chez Cardiologs, le temps de rollout initial etait de 8 minutes. Inacceptable pour une equipe qui deployait 3 fois par jour. Voici les optimisations qui l'ont fait passer a 2 minutes :
Images legeres : passage d'Ubuntu (800 Mo) a Alpine (120 Mo). Le pull d'image seul est passe de 45 secondes a 8 secondes. Sur WizOps, les images multi-stage reduisent l'image finale de 1.2 Go a 180 Mo.
Probes bien calibrees : des readiness probes trop conservatrices (initialDelaySeconds de 60 secondes "par securite") retardent chaque pod de 60 secondes. Mon calibrage type : initialDelaySeconds de 5 secondes, periodSeconds de 5, failureThreshold de 3. Le pod est marque "ready" des qu'il repond, pas 60 secondes apres.
preStop hook pour un drainage propre : un sleep 15 dans le preStop hook laisse le temps aux connexions en cours de se terminer avant la suppression du pod. Sans ca, les requetes en cours recoivent un connection reset. Chez Bloomflow, ce hook etait critique pour les connexions websocket des utilisateurs connectes en temps reel.
Autoscaling en production : les metriques qui comptent
Le HPA (Horizontal Pod Autoscaler) est indispensable, mais il faut choisir les bonnes metriques. Le CPU seul est rarement suffisant. Chez Bloomflow, j'avais configure des HPA bases sur des metriques custom Prometheus : nombre de requetes par seconde, longueur de la queue de messages, et temps de reponse p95. Le HPA reagissait aux pics de charge reels, pas aux pics de CPU causes par un garbage collector.
L'astuce souvent negligee : les requests doivent etre realistes, car le HPA calcule le ratio d'utilisation par rapport aux requests. Des requests surestimees (512m de CPU quand le pod en consomme 50m en moyenne) empechent le HPA de scaler car le ratio reste bas.
Le VPA (Vertical Pod Autoscaler) en mode recommendation est un excellent complement. Il analyse l'utilisation reelle sur 7 jours et suggere des requests optimales. Chez F2R2 sur EKS Fargate, le VPA m'a permis de reduire les requests de 40% en moyenne, liberant de la capacite pour d'autres workloads.
Observabilite du deploiement : le dashboard indispensable
Sur chaque projet, je configure un dashboard Grafana dedie au deploiement qui affiche en temps reel : pods ready vs desired, temps de rollout, restart counts, et taux d'erreurs applicatives post-deploiement. Chez Metronome, des alertes Prometheus se declenchaient si un deploiement prenait plus de 5 minutes ou si le nombre de CrashLoopBackOff depassait 2 sur 10 minutes. Cette boucle de feedback rapide est la difference entre un CD reactif et un CD proactif.
Conclusion
L'optimisation du deploiement continu sur Kubernetes est un travail d'artisan. Chaque cluster a ses specificites, mais les fondamentaux restent les memes : strategie de deploiement adaptee au contexte, Helm Charts bien structures, images legeres, probes calibrees, autoscaling intelligent et observabilite continue. Chaque minute gagnee sur un deploiement est multipliee par le nombre de deploiements quotidiens et par la taille de l'equipe. L'investissement en vaut toujours la peine.