0Pricing
DevOps Bootcamp · Leçon

Mises à jour progressives et retours en arrière

Mettez en œuvre des mises à jour d’applications sans interruption de service et revenez aux versions précédentes en cas de problème.

Mises à jour progressives et retours en arrière est une leçon DevOps Bootcamp gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage DevOps Bootcamp, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours DevOps Bootcamp comprend 4 leçons au total.

Mises à jour sans interruption : pourquoi ?

Imaginez que vous mettiez à jour une application en production. Sans planification minutieuse, les utilisateurs pourraient subir une interruption de service ou rencontrer des erreurs. C’est là que les mises à jour progressives de Kubernetes prennent tout leur sens !

Les mises à jour progressives vous permettent de mettre votre application à jour vers une nouvelle version sans interrompre le service. Les nouvelles versions sont déployées progressivement, afin que votre application reste disponible.

Comment les Deployments gèrent les mises à jour

Lorsque vous mettez à jour le modèle de pod d’un Deployment, par exemple en modifiant l’image du conteneur, Kubernetes n’arrête pas simplement tout pour redémarrer. Il utilise plutôt une stratégie RollingUpdate par défaut.

  • Il crée de nouveaux pods avec la configuration mise à jour.
  • Il supprime progressivement les anciens pods une fois que les nouveaux sont prêts.
  • Ce processus assure une transition fluide avec une interruption de service minimale, voire inexistante.

Contrôler la vitesse du déploiement

Vous pouvez ajuster précisément le comportement des mises à jour progressives à l’aide de deux paramètres clés dans la section .spec.strategy.rollingUpdate de votre Deployment :

  • maxUnavailable : le nombre maximal de pods qui peuvent être indisponibles pendant la mise à jour. Il peut s’agir d’un nombre absolu ou d’un pourcentage.
  • maxSurge : le nombre maximal de pods pouvant être créés au-delà du nombre de pods souhaité. Il peut également s’agir d’un nombre absolu ou d’un pourcentage.

Par défaut, les deux paramètres sont définis sur 25 %.

Notre Deployment initial

Commençons par un déploiement Nginx simple. Ce YAML définit notre application initiale, qui exécute 3 réplicas de nginx:1.14.2.

Nous l’utiliserons comme base pour effectuer une mise à jour progressive à l’étape suivante.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Effectuer une mise à jour progressive

Mettons maintenant à jour la version de Nginx, de 1.14.2 à 1.15.0. Il suffit de modifier l’image dans le YAML et de l’appliquer.

Kubernetes détectera la modification et lancera automatiquement une mise à jour progressive. Observez le champ image ci-dessous :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.0
        ports:
        - containerPort: 80

Surveiller l’état du déploiement

Après avoir appliqué le YAML mis à jour, vous pouvez surveiller la progression de votre mise à jour progressive à l’aide de la commande kubectl rollout status :

kubectl rollout status deployment/my-nginx

Vous verrez des messages indiquant la création de nouveaux pods et la suppression des anciens jusqu’à la fin de la mise à jour. Vous pouvez également utiliser kubectl get rs pour afficher les anciens et les nouveaux ReplicaSets.

Consulter l’historique du déploiement

Kubernetes conserve un historique des révisions de vos Deployments. Cela est extrêmement utile pour comprendre les modifications et effectuer éventuellement des restaurations.

Pour consulter l’historique, utilisez la commande :

kubectl rollout history deployment/my-nginx

Vous verrez une liste de révisions, chacune représentant un état distinct de votre Deployment. La valeur CHANGE-CAUSE reflète souvent la commande ou la modification du YAML.

Quand une restauration est nécessaire

Même avec des tests rigoureux, il arrive qu’une nouvelle version de l’application introduise des bogues ou des problèmes de performances qui n’ont pas été détectés. Dans ces situations critiques, vous devez pouvoir revenir rapidement à un état stable connu.

C’est là qu’interviennent les restaurations. Elles vous permettent d’annuler une mise à jour problématique et de restaurer votre Deployment vers une version précédente et fonctionnelle de son historique.

Effectuer une restauration

Pour restaurer la révision immédiatement précédente, utilisez :

kubectl rollout undo deployment/my-nginx

Si vous souhaitez restaurer une révision précise, par exemple la révision 1, vous pouvez la spécifier :

kubectl rollout undo deployment/my-nginx --to-revision=1

Kubernetes effectuera une nouvelle mise à jour progressive pour ramener les pods à la configuration historique spécifiée.

Vérification de la stratégie de déploiement

Lequel des paramètres suivants peut être utilisé pour contrôler le comportement de la stratégie RollingUpdate d’un Deployment Kubernetes ?

Récapitulatif : mises à jour fluides et filets de sécurité

Nous avons vu comment les Deployments Kubernetes permettent d’effectuer des mises à jour progressives sans interruption, en faisant passer progressivement vos applications à de nouvelles versions. Vous avez appris que :

  • Les Deployments utilisent RollingUpdate par défaut.
  • maxUnavailable et maxSurge contrôlent la vitesse de mise à jour.
  • kubectl rollout status surveille la progression.
  • kubectl rollout history conserve l’historique des révisions.
  • kubectl rollout undo permet d’effectuer rapidement une restauration vers des versions stables.

Ces fonctionnalités sont essentielles pour maintenir une haute disponibilité et une bonne fiabilité de vos applications !

Questions Fréquemment Posées

La leçon « Mises à jour progressives et retours en arrière » est-elle gratuite ?

Oui — le texte complet de « Mises à jour progressives et retours en arrière » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours DevOps Bootcamp, passe à CoddyKit PRO. Le cours DevOps Bootcamp comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Mises à jour progressives et retours en arrière » ?

Mettez en œuvre des mises à jour d’applications sans interruption de service et revenez aux versions précédentes en cas de problème. Tu pratiques DevOps Bootcamp avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer DevOps Bootcamp ?

Aucune expérience préalable n'est requise. DevOps Bootcamp sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.

Combien de temps prend la leçon « Mises à jour progressives et retours en arrière » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon DevOps Bootcamp ?

Oui. Chaque leçon DevOps Bootcamp inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Comprendre les Deployments
  2. Mettre les applications à l’échelle avec les ReplicaSets
  3. Mises à jour progressives et retours en arrière
  4. Stratégies de déploiement : blue-green et canary
← Retour à DevOps Bootcamp