Déploiements progressifs, bleu-vert et canari comparés

Ce que c'est

Déploiement progressif (rolling update) : la documentation des Deployment Kubernetes (citée) décrit la stratégie par défaut comme la création de nouveaux Pods et la suppression des anciens dans deux limites, maxUnavailable et maxSurge (25 % par défaut chacune) ; elle ne tue pas les anciens Pods avant qu'un nombre suffisant de nouveaux Pods ne soit monté, et progressDeadlineSeconds signale un déploiement qui stagne. Les deux versions servent du trafic pendant le déploiement.

Bleu-vert : deux piles complètes existent ; le trafic est basculé de celle qui est active vers la nouvelle en une seule étape. La documentation d'Argo Rollouts (citée) l'implémente en pointant un Service actif et, éventuellement, un Service de prévisualisation vers des ReplicaSets différents et, une fois le nouveau ReplicaSet disponible, en modifiant le service actif pour qu'il pointe vers lui, puis en réduisant l'ancien ensemble après un délai.

Canari : la nouvelle version reçoit un petit pourcentage du trafic de production, qui est augmenté par paliers. La stratégie canari d'Argo (citée) l'exprime comme une liste d'étapes setWeight et pause, éventuellement conditionnée par une analyse automatisée de métriques.

Pourquoi c'est important

Les stratégies échangent capacité contre risque. Le déploiement progressif nécessite peu de capacité supplémentaire mais oblige l'application à tolérer un mélange de versions pendant des minutes ; le bleu-vert nécessite brièvement une capacité double mais offre une bascule instantanée et un retour arrière instantané pendant que l'ancienne pile tourne encore ; le canari limite le nombre d'utilisateurs exposés à un défaut mais nécessite un partage de trafic et une métrique distinguant fiablement le bon du mauvais dans la fenêtre d'observation.

Comment l'appliquer

• Rendre d'abord chaque stratégie possible : des contrôles de disponibilité qui échouent avant que le processus ne soit prêt, un arrêt propre sur SIGTERM, des changements de base de données et des réponses d'API rétrocompatibles afin que les anciennes et nouvelles versions coexistent.
• Utiliser le déploiement progressif pour les services sans état à versions compatibles ; régler maxUnavailable: 0 quand la capacité ne doit jamais baisser.
• Utiliser le bleu-vert quand un mélange de versions est inacceptable (connexions longues, caches incompatibles) ou quand une simulation contre l'infrastructure réelle est souhaitée avant la bascule.
• Utiliser le canari quand un défaut ne se manifesterait que sous trafic réel et qu'un signal mesurable existe (taux d'erreur, latence, métrique métier) ; définir le seuil d'abandon avant de commencer.
• Combiner avec des bascules de fonctionnalités : une stratégie de déploiement contrôle quel binaire tourne, une bascule contrôle quel comportement est activé.

Pièges

La persistance de session, les caches clients et les TTL DNS rendent « basculer le trafic d'un coup » plus lent que prévu. Un canari qui ne reçoit qu'une petite part du trafic voit rarement les erreurs rares, donc sa fenêtre doit être assez longue pour être concluante. Les migrations de base de données ne reviennent pas en arrière avec le binaire.

Le bleu-vert n'isole pas l'état partagé

Le bleu et le vert partagent la base de données, la file d'attente et tout autre service de soutien, si bien que dès le démarrage de la nouvelle pile (contrôles de santé, préchauffage, trafic de répétition), les deux versions lisent et écrivent les mêmes données, et après la bascule l'ancienne pile reste connectée pendant la fenêtre de retour arrière. Le mélange de versions que le bleu-vert supprime n'est donc que celui local au processus : caches en mémoire, sessions collantes, connexions longues, formats sur disque incompatibles à l'intérieur de l'instance. Les changements de schéma et de format de message ont besoin de la même discipline d'expansion-contraction qu'un déploiement progressif, et le retour arrière instantané ne tient que jusqu'à ce que la nouvelle version ait écrit quelque chose que l'ancienne ne peut pas lire. Choisir le bleu-vert pour des incompatibilités locales au processus ou pour une simulation contre l'infrastructure réelle ; ne pas le choisir pour éviter des changements de données rétrocompatibles.