TP : Rolling update, canary et retour arrière sur Kubernetes

Ce que vous allez apprendre dans ce TP

• Configurer un rolling update sûr
• Faire un déploiement canary
• Revenir en arrière avec kubectl

Introduction #

Ce que vous allez apprendre dans cette section

• Configurer un rolling update sûr
• Faire un déploiement canary
• Revenir en arrière avec kubectl

Contexte. L'équipe migre vers Kubernetes et veut des déploiements progressifs. Vous validez sur un cluster local le comportement des mises à jour et des retours arrière.

Prérequis : Docker, kubectl et kind installés sur votre poste  ·  Durée estimée : 50 min

Des déploiements progressifs maîtrisés et un retour arrière en une commande.

Mise en place #

Étapes guidées, avec leur correction.

1. 1. Créer le cluster et déployer la v1

   Pourquoi ? maxUnavailable: 0 et une readiness probe garantissent qu'aucune requête n'atteint un pod non prêt.

   Créez un cluster kind et déployez 4 réplicas de hashicorp/http-echo affichant « v1 », avec une stratégie RollingUpdate prudente et une readiness probe, exposées par un Service.

2. 2. Rolling update sans interruption

   Pourquoi ? On observe le remplacement des pods un par un pendant que le trafic continue.

   Lancez une boucle de requêtes depuis le pod client, puis passez à v2 avec une annotation de cause. Suivez le déploiement et l'historique.

3. 3. Bloquer une version cassée

   Pourquoi ? Une image introuvable ou un pod qui ne devient jamais prêt arrête le rolling update : les anciens pods continuent de servir.

   Déployez une image inexistante, constatez que rollout status échoue après un délai et que le service répond toujours v2.

4. 4. Revenir en arrière

   Pourquoi ? Kubernetes conserve les ReplicaSets précédents : le retour arrière est immédiat.

   Annulez la dernière révision, vérifiez que tous les pods sont prêts, puis revenez explicitement à la révision 1.

5. 5. Déploiement canary

   Pourquoi ? Sans maillage de services, on approxime un canary en répartissant les réplicas derrière le même Service.

   Créez un Deployment web-canary (1 réplica, texte « v3-canary », label track: canary) partageant le label app: web. Mesurez la part de trafic reçue, puis promouvez ou supprimez le canary.

Niveau de difficulté : ●●●○○ (3/5)