Appliquer la mise à jour (`kubectl apply`) et observer le déploiement progressif

Déclencher la mise à jour avec `kubectl apply`

Maintenant que notre fichier `nginx-deployment.yaml` contient la référence à la nouvelle version de l'image Nginx (par exemple `nginx:1.27` ou `nginx:stable-alpine`), nous pouvons demander à Kubernetes d'appliquer ce changement. Comme pour la création initiale, nous utilisons la commande `kubectl apply -f`.

Retournez dans votre terminal, dans le répertoire contenant le fichier `nginx-deployment.yaml` mis à jour, et exécutez :

kubectl apply -f nginx-deployment.yaml

Cette fois-ci, comme le Déploiement `nginx-deployment` existe déjà, Kubernetes va comparer la configuration actuelle dans le cluster avec celle fournie dans le fichier. Il détectera la différence (le changement d'image) et initiera le processus de mise à jour. La sortie de la commande devrait indiquer que l'objet a été configuré :

deployment.apps/nginx-deployment configured

Le simple fait d'appliquer le nouveau manifeste suffit à déclencher une séquence d'actions intelligentes de la part de Kubernetes pour mettre à jour votre application tout en minimisant l'impact sur la disponibilité.

Comprendre la stratégie de mise à jour : Rolling Update

Par défaut, les Déploiements Kubernetes utilisent une stratégie de mise à jour appelée `RollingUpdate`. L'objectif de cette stratégie est de remplacer progressivement les anciens Pods par les nouveaux, sans interrompre complètement le service. C'est un mécanisme clé pour réaliser des mises à jour zero-downtime.

Le processus fonctionne schématiquement ainsi : Kubernetes commence par créer un nouveau Pod basé sur le template mis à jour (avec la nouvelle image). Une fois que ce nouveau Pod est prêt (`Running` et passant ses éventuelles readiness probes), Kubernetes termine (supprime) un ancien Pod. Il répète ce cycle : ajouter un nouveau, supprimer un ancien, jusqu'à ce que tous les Pods exécutent la nouvelle version de l'application.

Kubernetes gère finement ce processus pour garantir qu'un certain nombre de Pods restent toujours disponibles pour servir le trafic (configurable via `maxUnavailable`) et qu'il ne crée pas trop de Pods supplémentaires simultanément (configurable via `maxSurge`). Pour notre exercice simple, les valeurs par défaut sont suffisantes pour observer le mécanisme.

Observer le déroulement de la mise à jour

Kubernetes fournit des outils pour suivre l'état d'un déploiement en cours. La commande la plus directe est `kubectl rollout status` :

kubectl rollout status deployment/nginx-deployment

Cette commande restera active et affichera des messages indiquant la progression de la mise à jour. Vous verrez probablement des messages comme "Waiting for deployment 'nginx-deployment' rollout to finish: 1 old replicas are pending termination..." ou "deployment 'nginx-deployment' successfully rolled out". Attendez que la commande se termine avec un message de succès.

Pendant que le `rollout status` s'exécute (ou dans un autre terminal), vous pouvez également observer les Pods directement. Utilisez `kubectl get pods` avec l'option `--watch` (ou `-w`) pour voir les changements en temps réel :

kubectl get pods -l app=nginx -w

Vous verrez apparaître de nouveaux Pods (avec des noms différents) avec le statut `ContainerCreating` puis `Running`, tandis que les anciens Pods passeront en statut `Terminating`. Une fois la mise à jour terminée, seuls les nouveaux Pods (au nombre de `replicas` spécifié) seront présents en état `Running`.

Pour une vue encore plus détaillée, notamment les événements liés au déploiement, vous pouvez utiliser `kubectl describe deployment nginx-deployment`. Cela montrera les différentes étapes du scaling up du nouveau ReplicaSet et du scaling down de l'ancien.

Vérification finale de la mise à jour

Une fois que `kubectl rollout status` indique que le déploiement est terminé avec succès et que `kubectl get pods -l app=nginx` ne montre que des Pods récents en état `Running`, la mise à jour est complète. Vous pouvez vérifier que les nouveaux Pods utilisent bien la nouvelle image en décrivant l'un d'eux :

# Remplacer  par le nom d'un Pod actuel
kubectl describe pod  | grep Image:

La sortie devrait afficher la version de l'image que vous avez spécifiée dans le manifeste mis à jour (par exemple, `Image: nginx:1.27` ou `Image: nginx:stable-alpine`).

Félicitations ! Vous avez appliqué une mise à jour d'application sans interruption de service grâce à la stratégie Rolling Update de Kubernetes, en utilisant simplement une modification déclarative du manifeste et la commande `kubectl apply`.