Stratégies de mise à jour progressive (Rolling Update) avec Kubernetes

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

Étiquettes: kubernetes devops deployment RollingUpdate ContainerOrchestration

Publié le 20 juillet à 10h31