Stratégies de mise à jour (RollingUpdate, Recreate)

Comment Kubernetes met à jour vos applications ?

L'un des avantages majeurs de l'utilisation d'un Deployment Kubernetes est sa capacité à gérer les mises à jour de vos applications de manière contrôlée. Lorsque vous modifiez le template de Pod dans la spécification de votre Deployment (par exemple, pour utiliser une nouvelle image de conteneur, changer une variable d'environnement, ou ajuster les requêtes de ressources), Kubernetes doit remplacer les Pods existants (basés sur l'ancien template) par de nouveaux Pods (basés sur le nouveau template).

Mais comment cette transition s'effectue-t-elle ? Kubernetes ne se contente pas de supprimer brutalement les anciens Pods et d'en créer de nouveaux. Le Deployment vous permet de choisir une stratégie de mise à jour pour définir précisément la manière dont ce remplacement va se dérouler. Le choix de la stratégie a un impact direct sur la disponibilité de votre application pendant la mise à jour et sur l'utilisation des ressources du cluster.

Kubernetes propose deux stratégies principales définies dans le champ `spec.strategy.type` du Deployment : `RollingUpdate` (la stratégie par défaut) et `Recreate`.

RollingUpdate : la mise à jour sans interruption (par défaut)

La stratégie `RollingUpdate` est la méthode privilégiée dans la plupart des cas car elle vise à effectuer la mise à jour sans interrompre la disponibilité de votre application (zero downtime). Le principe est de remplacer progressivement les Pods de l'ancienne version par ceux de la nouvelle version, en s'assurant qu'un nombre suffisant de Pods (anciens ou nouveaux) sont toujours disponibles pour traiter les requêtes pendant toute la durée de la transition.

Le processus se déroule généralement ainsi :

1. Kubernetes crée un nouveau Pod basé sur le nouveau template.
2. Il attend que ce nouveau Pod soit prêt (passe ses readiness probes) et considéré comme disponible (`minReadySeconds`).
3. Une fois le nouveau Pod prêt, Kubernetes supprime un ancien Pod.
4. Ce cycle se répète jusqu'à ce que tous les anciens Pods aient été remplacés par des nouveaux.

Vous pouvez affiner le comportement de la stratégie `RollingUpdate` à l'aide de deux paramètres clés dans `spec.strategy.rollingUpdate` :

• `maxUnavailable` : Définit le nombre maximum ou le pourcentage de Pods (par rapport au nombre total de `replicas` désiré) qui peuvent être indisponibles pendant la mise à jour. Par exemple, si `replicas: 4` et `maxUnavailable: 1` (ou `25%`), Kubernetes s'assurera qu'il y a toujours au moins 3 Pods (anciens ou nouveaux) disponibles pour servir le trafic. Une valeur plus faible ralentit la mise à jour mais garantit une meilleure disponibilité. La valeur par défaut est `25%`.
• `maxSurge` : Définit le nombre maximum ou le pourcentage de Pods qui peuvent être créés *au-dessus* du nombre désiré de `replicas` pendant la mise à jour. Par exemple, si `replicas: 4` et `maxSurge: 1` (ou `25%`), Kubernetes peut créer un nouveau Pod avant de supprimer un ancien, portant temporairement le nombre total de Pods à 5. Cela accélère la mise à jour mais consomme temporairement plus de ressources. La valeur par défaut est `25%`.

Note : `maxUnavailable` et `maxSurge` ne peuvent pas être tous les deux à 0 (ou 0%). Au moins l'un doit autoriser une certaine flexibilité.

Avantages de RollingUpdate : Zero downtime (idéalement), transition progressive, possibilité de revenir en arrière facilement (rollback).
Inconvénients : Peut être plus lente, consomme temporairement plus de ressources si `maxSurge > 0`, nécessite que l'application supporte d'avoir plusieurs versions (ancienne et nouvelle) actives simultanément pendant la transition.

Recreate : la méthode simple mais disruptive

La stratégie `Recreate` est beaucoup plus simple mais a un inconvénient majeur : elle entraîne une interruption de service pendant la mise à jour. Avec cette stratégie, le Deployment procède comme suit :

1. Il supprime tous les Pods gérés par l'ancien ReplicaSet.
2. Une fois que tous les anciens Pods sont terminés, il crée de nouveaux Pods basés sur le nouveau template, gérés par un nouveau ReplicaSet.

Pendant la période entre la suppression des anciens Pods et le moment où les nouveaux Pods sont créés et prêts, votre application sera totalement indisponible.

Pourquoi utiliser `Recreate` ?

• Simplicité : Le processus est très simple à comprendre et à suivre.
• Incompatibilité des versions : Si votre application ne peut absolument pas tolérer d'avoir l'ancienne et la nouvelle version fonctionnant en même temps (par exemple, en raison de changements majeurs dans le schéma de base de données ou des protocoles de communication internes), `Recreate` garantit une coupure nette.
• Ressources limitées : Si vous n'avez pas les ressources nécessaires pour supporter le `maxSurge` potentiel d'une `RollingUpdate`.
• Développement/Test : Peut être acceptable dans des environnements où une courte interruption n'est pas critique.

Avantages de Recreate : Simple, assure qu'une seule version est active à la fois après la coupure.
Inconvénients : Entraîne une interruption de service, pas de transition progressive.

Configurer la stratégie dans le manifeste

Vous spécifiez la stratégie de mise à jour dans la section `spec.strategy` de votre manifeste de Deployment.

Pour RollingUpdate (explicite avec paramètres) :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mon-app-deploy
spec:
  replicas: 4
  selector: # ...
  template: # ...
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # Nombre absolu
      maxSurge: 25%        # Pourcentage
  # ... autres champs

Pour Recreate :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mon-app-deploy
spec:
  replicas: 4
  selector: # ...
  template: # ...
  strategy:
    type: Recreate
  # ... autres champs

Si vous omettez complètement la section `strategy`, Kubernetes utilisera `RollingUpdate` avec les valeurs par défaut (`maxUnavailable: 25%`, `maxSurge: 25%`).

Conclusion : choisir la bonne approche pour vos mises à jour

Les stratégies de mise à jour `RollingUpdate` et `Recreate` offrent deux approches distinctes pour gérer le déploiement de nouvelles versions de vos applications via les Deployments Kubernetes.

Le choix entre les deux dépendra principalement de vos exigences en matière de disponibilité et des caractéristiques de votre application. Pour la plupart des applications web et des services modernes où la haute disponibilité est primordiale, `RollingUpdate` est la stratégie à privilégier. `Recreate` reste une option pour des cas d'usage plus spécifiques où une interruption de service est acceptable ou nécessaire.

Comprendre et configurer correctement ces stratégies est essentiel pour assurer des déploiements fluides, fiables et adaptés aux besoins de vos applications sur Kubernetes.