Stratégies de déploiement : progressif (rolling), bleu-vert et canari

Ce que c'est

Progressif (rolling) : la documentation Kubernetes sur les Deployments décrit la stratégie par défaut comme créant de nouveaux pods et supprimant les anciens, maxUnavailable et maxSurge (25 % chacun par défaut) fixant respectivement la limite basse de pods disponibles et la limite haute de pods supplémentaires ; les anciens pods ne sont arrêtés que lorsque suffisamment de nouveaux tournent déjà. progressDeadlineSeconds signale un déploiement qui n'avance plus, et kubectl rollout undo revient à la révision précédente. Pendant l'opération, les deux versions traitent des requêtes.

Bleu-vert : deux environnements complets existent ; le trafic bascule en une seule étape. Argo Rollouts met cela en œuvre avec un service actif et un service de prévisualisation facultatif : dès que le nouveau ReplicaSet est disponible, le contrôleur fait pointer le service actif vers lui et réduit l'ancien après scaleDownDelaySeconds — tant qu'il tourne encore, le retour arrière consiste simplement à repointer de nouveau.

Canari : la nouvelle version reçoit un petit pourcentage du trafic de production. Chez Argo Rollouts, il s'agit d'une liste d'étapes composées de setWeight (la part) et de pause (un délai d'attente ou une validation manuelle), le cas échéant sécurisée par une analyse automatique de métriques. Sans routeur de trafic, le contrôleur approche la part visée à travers le nombre de réplicas — avec dix réplicas et dix pour cent, cela donne un nouveau pod et neuf anciens.

Pourquoi c'est important

Les trois stratégies échangent de la capacité contre du risque. Le déploiement progressif ne nécessite guère de réserve, mais contraint l'application à tolérer un mélange de versions pendant plusieurs minutes. Le bleu-vert nécessite brièvement le double de la capacité, en échange d'un basculement immédiat et d'un retour arrière immédiat. Le canari limite le nombre d'utilisateurs exposés à une erreur, mais suppose une répartition du trafic et un signal de mesure qui distingue bien le bon du mauvais dans la fenêtre d'observation.

Comment l'appliquer

• D'abord les fondations : des sondes de disponibilité qui échouent tant que l'initialisation n'est pas terminée ; un arrêt propre sur SIGTERM ; des modifications de base de données selon le principe expand-contract, afin que l'ancien et le nouveau puissent coexister.
• Le déploiement progressif pour les services sans état dont les versions sont compatibles entre elles ; maxUnavailable: 0 lorsque la capacité ne doit pas diminuer.
• Le bleu-vert lorsqu'un mélange de versions est exclu (connexions de longue durée, caches incompatibles) ou qu'une répétition générale contre une infrastructure réelle est souhaitée.
• Le canari lorsqu'une erreur ne devient visible que sous trafic réel et qu'un signal mesurable existe ; fixer le seuil d'interruption avant de commencer.
• Les indicateurs de fonctionnalité (feature flags) en complément : la stratégie de déploiement décide quel binaire tourne, l'indicateur décide quel comportement est actif.

Pièges

La persistance de session, les caches côté client et les délais de propagation DNS rendent un basculement « d'un coup » plus lent que prévu. Un canari qui ne reçoit que quelques pour cent du trafic voit rarement les erreurs rares ; la fenêtre doit être assez longue. Les migrations de base de données ne reviennent pas en arrière avec le binaire. Sur un hôte unique sans orchestrateur, les trois stratégies ne peuvent être reproduites qu'à l'aide d'outils auxiliaires — une question ouverte du wiki y est consacrée.

Ce que le bleu-vert ne sépare pas

Le basculement du pointeur de service ne sépare que les processus. La base de données, les caches, les files d'attente et les clients sont communs aux deux environnements : pendant scaleDownDelaySeconds (30 secondes par défaut chez Argo Rollouts), le bleu traite encore des requêtes en cours tandis que le vert écrit déjà, et les navigateurs comme les applications mobiles conservent l'ancienne interface bien après le basculement. Le bleu-vert n'exclut donc pas le mélange de versions, il le déplace des processus serveur vers la couche de données et vers les clients. Le principe expand-contract pour les changements de schéma et des réponses d'API rétrocompatibles restent obligatoires pour les trois stratégies ; le bleu-vert se justifie lorsque l'état du processus lui-même ne tolère aucun mélange — connexions de longue durée, caches en mémoire dont le format a changé, changement de protocole entre des composants livrés uniquement ensemble. Le retour arrière immédiat ne vaut que tant que l'ancien ReplicaSet tourne encore ; après quoi le retour redevient un déploiement ordinaire.