Maximiser l'Efficacité du Déploiement Continu avec Kubernetes
Déploiement continu sur Kubernetes : les stratégies qui fonctionnent en production
Déployer une application sur Kubernetes, c'est facile. Déployer en continu, sans downtime, avec un rollback automatique en cas de problème, c'est un autre niveau. En 8 ans de pratique K8s en production, j'ai expérimenté toutes les stratégies de déploiement et j'ai des opinions tranchées sur ce qui fonctionne.
Rolling Updates : le défaut qui suffit souvent
La stratégie par défaut de Kubernetes, le Rolling Update, convient à 90% des cas. Le principe est simple : K8s remplace progressivement les anciens pods par les nouveaux. Tant que votre application supporte d'avoir deux versions en parallèle pendant quelques secondes, c'est la solution la plus simple et la plus fiable.
Chez Bloomflow, nous déployions 2 à 3 fois par jour avec des Rolling Updates sur nos clusters multi-providers (AWS, Scaleway, Outscale). La configuration clé : maxSurge: 1 et maxUnavailable: 0. Cela garantit qu'aucun pod n'est supprimé avant que le nouveau soit prêt. Combiné avec des readiness probes bien calibrées, nous n'avons jamais eu de downtime en déploiement.
Blue-Green et Canary : quand les Rolling Updates ne suffisent plus
Chez Earny SA, lors de la migration GCP vers AWS, nous avions besoin de valider chaque déploiement sur un sous-ensemble de trafic avant de basculer totalement. Nous avons mis en place des déploiements Canary avec Argo Rollouts : 10% du trafic dirigé vers la nouvelle version pendant 15 minutes, analyse automatique des métriques Prometheus (taux d'erreurs, latence P99), puis promotion automatique ou rollback.
Cette approche a un coût en complexité, et je ne la recommande que si vous avez déjà une stack d'observabilité solide. Sans métriques fiables pour évaluer la santé du canary, vous êtes en aveugle.
ArgoCD : le game changer du déploiement continu sur K8s
Si je ne devais recommander qu'un seul outil pour le déploiement continu sur Kubernetes, ce serait ArgoCD. Je l'ai déployé et opéré chez KNDS, F2R2, Bloomflow, Padam Mobility et Earny SA. Le principe est simple : ArgoCD surveille un repository Git contenant vos manifestes Kubernetes (ou vos Helm Charts) et synchronise automatiquement le cluster avec l'état déclaré dans Git.
Chez Padam Mobility, nous avions mis en place un workflow GitOps complet : le développeur merge sa PR, la CI build et push l'image Docker, un bot met à jour le tag de l'image dans le repo GitOps, ArgoCD détecte le changement et déploie. Tout est tracé dans Git, tout est auditable, et un rollback se fait en revertant un commit.
Les pièges du déploiement continu sur K8s
Le piège numéro un : les migrations de base de données. Kubernetes gère très bien le déploiement des containers, mais il ne sait rien de votre schéma de base de données. Chez Coopengo (HDS sur AWS), nous avions adopté le pattern des migrations découpées en deux phases. La phase 1 ajoute les nouvelles colonnes/tables sans supprimer les anciennes (compatible avec l'ancienne et la nouvelle version du code). La phase 2, lors du déploiement suivant, nettoie les éléments obsolètes. Ce pattern garantit des rollbacks sans perte de données.
Le piège numéro deux : les PersistentVolumes. Sur EKS chez F2R2 avec Fargate, les volumes EBS ne suivent pas les pods entre les zones de disponibilité. Nous avons résolu le problème en utilisant EFS pour les volumes partagés, mais avec un impact sur les performances I/O. La leçon : préférez les services managés (RDS, S3, ElastiCache) aux volumes persistants quand c'est possible.
Mesurer la maturité de votre déploiement continu
Les quatre métriques DORA (Deployment Frequency, Lead Time for Changes, Change Failure Rate, Time to Restore Service) sont un excellent indicateur de maturité. Chez Bloomflow, après avoir mis en place ArgoCD et un pipeline CI optimisé, nous mesurions : déploiements quotidiens, lead time de 30 minutes du commit au déploiement, taux d'échec inférieur à 5%, et temps de restauration sous les 10 minutes grâce aux rollbacks Git.