L'un des avantages majeurs de Kubernetes réside dans sa capacité à mettre à jour des applications sans interruption de service. Ce processus, appelé Rolling Update, permet de remplacer progressivement les anciennes instances d'une application (Pods) par de nouvelles versions, garantissant ainsi une disponibilité continue pour les utilisateurs finaux.
Mécanisme du Rolling Update
Lorsqu'une mise à jour est déclenchée sur un objet Deployment, Kubernetes orchestre le remplacement des unités d'exécution. Le processus suit généralement cette logique :
- Le plan de contrôle (Control Plane) sélectionne un nœud pour instancier un nouveau Pod basé sur la nouvelle image spécifiée.
- Une fois que le nouveau Pod est prêt et passe les tests de santé (readiness probes), Kubernetes commence à drainer le trafic d'un ancien Pod.
- L'ancien Pod est progressivement terminé tandis que de nouveaux Pods sont créés jusqu'à ce que l'état désiré soit atteint.
- Le service Kubernetes (Service) ajuste dynamiquement l'équilibrage de charge pour n'envoyer le trafic que vers les Pods opérationnels.
Cette approche permet non seulement de déployer de nouvelles fonctionnalités de manière fluide, mais offre également la possibilité de revenir rapidement à une version antérieure en cas d'instabilité détectée.
Mise en œuvre pratique : Mise à jour d'un déploeiment Web
Imaginons un scénario où nous gérons un serveur web. Nous allons passer d'une version spécifique de Nginx à une version plus récente en modifiant le manifeste YAML.
1. Configuration initiale du déploiement
Voici le fichier de configuration web-server-deploy.yaml définissant un état initial avec trois répliques :
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-server-frontend
labels:
tier: frontend
spec:
replicas: 3
selector:
matchLabels:
app: web-app
template:
metadata:
labels:
app: web-app
spec:
containers:
- name: nginx-host
image: nginx:1.14.2 # Version initiale
ports:
- containerPort: 80
2. Application de la mise à jour
Pour mettre à jour l'image vers la version 1.16.1, modifiez la valeur du champ image dans le fichier YAML, puis exécutez la commande suivante :
kubectl apply -f web-server-deploy.yaml
Alternativement, vous pouvez modifier l'image directement via la ligne de commande :
kubectl set image deployment/web-server-frontend nginx-host=nginx:1.16.1
3. Surveillance du déploiement
Il est crucial d'observer comment Kubernetes gère la transition. Utilisez la commande get pods avec l'option watch pour voir les Pods changer d'état en temps réel :
kubectl get pods -l app=web-app -w
Au cours de l'exécution, vous observerez une sortie similaire à celle-ci, montrant la création de nouveaux Pods et l'arrêt des anciens :
NAME READY STATUS RESTARTS AGE
web-server-frontend-578f554444-abcde 1/1 Running 0 5m
web-server-frontend-578f554444-fghij 1/1 Running 0 5m
web-server-frontend-6b9d698b98-klmno 0/1 ContainerCreating 0 2s
web-server-frontend-6b9d698b98-pqrst 0/1 ContainerCreating 0 2s
Une fois le processus terminé, tous les anciens identifiants de réplica auront disparu, laissant place aux nouveaux Pods configurés avec la version cible. Vous pouvez vérifier l'historique des révisions avec :
kubectl rollout history deployment/web-server-frontend