Gérer les déploiements (kubectl rollout, scale)

Contrôler le cycle de vie : les commandes `rollout` et `scale`

Créer un Deployment avec `kubectl apply` est la première étape, mais comment interagir avec lui une fois qu'il est lancé ? Comment suivre la progression d'une mise à jour, revenir en arrière si quelque chose se passe mal, ou simplement ajuster le nombre d'instances de votre application ? Pour ces tâches de gestion courantes, Kubernetes fournit des sous-commandes spécifiques au sein de `kubectl` : principalement `kubectl rollout` et `kubectl scale`.

Ces commandes vous permettent d'observer et de contrôler activement le cycle de vie de vos Deployments (et d'autres contrôleurs de workloads) au-delà de la simple application de manifestes YAML. Elles sont essentielles pour les opérations quotidiennes et le dépannage.

Ce chapitre détaille l'utilisation de `kubectl rollout` pour gérer l'historique et le processus de mise à jour, et de `kubectl scale` pour ajuster le nombre de réplicas.

Suivre, contrôler et annuler les mises à jour avec `kubectl rollout`

La sous-commande `kubectl rollout` est dédiée à la gestion des processus de mise à jour des contrôleurs qui les supportent, comme les Deployments et les StatefulSets.

• Vérifier l'état d'un déploiement (`rollout status`) :
  Après avoir appliqué une modification à un Deployment (par exemple, via `kubectl apply` ou `kubectl set image`), vous pouvez suivre sa progression en temps réel.

  kubectl rollout status deployment/mon-app-deployment

  Cette commande vous indiquera si le déploiement est en cours ("Waiting for rollout to finish: ..."), s'il a réussi ("deployment \"mon-app-deployment\" successfully rolled out"), ou s'il a échoué ou est bloqué. C'est très utile pour savoir quand une mise à jour est terminée et stable.
• Afficher l'historique des révisions (`rollout history`) :
  Chaque fois que le template d'un Deployment est modifié et qu'un déploiement est déclenché, Kubernetes crée une nouvelle "révision" associée au nouveau ReplicaSet. Vous pouvez lister cet historique.

  kubectl rollout history deployment/mon-app-deployment

  La sortie montre les différentes révisions avec leur numéro. La colonne `CHANGE-CAUSE` peut afficher la raison de la modification si l'annotation `kubernetes.io/change-cause` est définie lors de l'application (ou si le flag `--record` (déprécié) était utilisé).
  Pour voir les détails d'une révision spécifique (le contenu du template à ce moment-là) :

  kubectl rollout history deployment/mon-app-deployment --revision=2

• Annuler un déploiement (`rollout undo`) :
  Si vous constatez qu'une nouvelle version pose problème, vous pouvez facilement revenir en arrière. Par défaut, `undo` revient à la révision *précédente*.

  kubectl rollout undo deployment/mon-app-deployment

  Cela déclenche un nouveau déploiement (rolling update) où le template de la révision précédente est réappliqué.
  Vous pouvez aussi revenir à une révision *spécifique* de l'historique :

  kubectl rollout undo deployment/mon-app-deployment --to-revision=3

• Mettre en pause et reprendre un déploiement (`rollout pause` / `rollout resume`) :
  Vous pouvez temporairement empêcher un Deployment de déclencher de nouveaux déploiements (rollouts) même si sa configuration change.

  kubectl rollout pause deployment/mon-app-deployment

  Ceci est utile si vous voulez appliquer plusieurs modifications successives au Deployment (par exemple, changer l'image ET une variable d'env) sans déclencher un rollout intermédiaire. Une fois les modifications appliquées, vous reprenez le processus :

  kubectl rollout resume deployment/mon-app-deployment

  Si des changements ont eu lieu pendant la pause, `resume` déclenchera un nouveau déploiement.
• Redémarrer un déploiement (`rollout restart`) :
  Parfois, vous voulez simplement forcer le redémarrage de tous les Pods gérés par un Deployment, même si leur template n'a pas changé (par exemple, pour qu'ils récupèrent une nouvelle configuration d'un ConfigMap monté en volume, ou pour rafraîchir leur état).

  kubectl rollout restart deployment/mon-app-deployment

  Cette commande effectue un redémarrage progressif (rolling restart) en suivant la stratégie de mise à jour configurée (`RollingUpdate` ou `Recreate`), garantissant ainsi la disponibilité si `RollingUpdate` est utilisée.

Ajuster le nombre de réplicas avec `kubectl scale`

Le scaling (ajustement du nombre d'instances) est une opération très courante. La commande `kubectl scale` offre un moyen direct et impératif de modifier le nombre de réplicas souhaité pour un Deployment (ou un ReplicaSet, un StatefulSet, etc.).

Syntaxe :

kubectl scale deployment/[NOM_DEPLOYMENT] --replicas=[NOMBRE_DESIRE]

Exemple : Pour passer le nombre de réplicas du Deployment `mon-app-deployment` à 5 :

kubectl scale deployment mon-app-deployment --replicas=5

Que se passe-t-il ?

1. `kubectl` envoie une requête à l'API Server pour modifier le champ `spec.replicas` de l'objet Deployment spécifié.
2. Le contrôleur du Deployment détecte ce changement dans l'état désiré.
3. Il met à jour le champ `spec.replicas` du ReplicaSet actif qu'il gère.
4. Le contrôleur du ReplicaSet, via sa boucle de réconciliation, compare le nouveau nombre désiré au nombre actuel de Pods qu'il gère.
5. Il crée ou supprime des Pods pour atteindre le nouveau nombre cible.

Cette commande est très pratique pour des ajustements rapides. Cependant, il est important de noter qu'elle modifie l'état du cluster de manière impérative. Si vous gérez vos ressources de manière purement déclarative (via des fichiers YAML dans Git, par exemple), la modification apportée par `kubectl scale` pourrait être écrasée lors de la prochaine application de votre fichier YAML si celui-ci contient toujours l'ancienne valeur pour `replicas`. Une approche déclarative consisterait à modifier la valeur de `spec.replicas` directement dans votre fichier `mon-deployment.yaml` puis à exécuter `kubectl apply -f mon-deployment.yaml`. Les deux méthodes aboutissent au même résultat dans le cluster, mais `scale` est plus direct pour cette opération spécifique.

Conclusion : des outils essentiels pour la gestion dynamique

Les commandes `kubectl rollout` et `kubectl scale` sont des outils indispensables dans la boîte à outils de tout utilisateur de Kubernetes. Elles fournissent les moyens nécessaires pour interagir dynamiquement avec le cycle de vie des Deployments :

• `rollout` vous donne la visibilité et le contrôle sur le processus de mise à jour, vous permettant de suivre l'état, d'explorer l'historique, d'annuler des changements problématiques et de forcer des redémarrages.
• `scale` vous offre un moyen simple et rapide d'ajuster la capacité de votre application en modifiant le nombre de réplicas.

En maîtrisant ces commandes, vous passez d'une simple définition statique de vos applications à une gestion active et réactive de leur déploiement et de leur scalabilité sur Kubernetes.