Garanties des StatefulSets (ordre de déploiement/suppression)

Au-delà de l'identité et du stockage : l'importance de l'ordre

Nous avons vu comment les StatefulSets fournissent des identités réseau et un stockage persistants et stables pour chaque instance de Pod. Ces garanties sont essentielles, mais elles ne suffisent pas toujours pour gérer correctement certaines applications stateful distribuées. Souvent, l'ordre dans lequel les instances sont démarrées, mises à jour ou arrêtées est tout aussi critique.

Pensez à un cluster de base de données : vous ne voulez probablement pas démarrer tous les noeuds simultanément, mais plutôt attendre que le noeud primaire (ou leader) soit pleinement opérationnel avant de lancer les réplicas. De même, lors d'une mise à l'échelle ou d'une suppression, il peut être nécessaire d'arrêter les instances dans un ordre inverse pour permettre un transfert de responsabilités en douceur.

Contrairement aux Deployments qui traitent les Pods comme un ensemble non ordonné, les StatefulSets offrent des garanties fortes et uniques concernant l'ordre et la séquentialité des opérations sur les Pods qu'ils gèrent. Ces garanties sont une autre raison majeure pour laquelle ils sont adaptés aux charges de travail stateful complexes.

Déploiement et mise à l'échelle ordonnés et séquentiels

Lors de la création initiale d'un StatefulSet avec `N` réplicas, ou lors d'une opération de mise à l'échelle (scaling up) pour augmenter le nombre de réplicas, les Pods sont créés dans un ordre strict et séquentiel, basé sur leur index ordinal.

• Le Pod avec l'index 0 (`-0`) est créé en premier.
• Le StatefulSet attend que le Pod 0 soit en cours d'exécution (`Running`) et prêt (`Ready`, c'est-à-dire qu'il passe ses readiness probes) avant de continuer.
• Ensuite, le Pod avec l'index 1 (`-1`) est créé.
• Le StatefulSet attend que le Pod 1 soit `Running` et `Ready`.
• Ce processus continue séquentiellement, un Pod à la fois, jusqu'à ce que tous les Pods jusqu'à l'index `N-1` soient créés et prêts.

Cette approche ordonnée garantit que les instances démarrent les unes après les autres, ce qui est souvent nécessaire pour que les membres d'un cluster puissent se découvrir et établir correctement leur quorum ou leurs relations (par exemple, un réplica ne démarre que lorsque le maître est prêt).

Mise à jour ordonnée et séquentielle (Rolling Update)

Les StatefulSets supportent également une stratégie de mise à jour de type `RollingUpdate` (c'est la stratégie par défaut, l'autre option étant `OnDelete`). Cependant, contrairement aux Deployments, la mise à jour progressive d'un StatefulSet se fait également de manière ordonnée et séquentielle, en ordre inverse des index ordinaux.

• La mise à jour commence par le Pod ayant l'index le plus élevé (`N-1`).
• Ce Pod est terminé (en respectant sa `terminationGracePeriodSeconds`).
• Un nouveau Pod (`N-1`) est créé avec la nouvelle configuration (basée sur le `updateStrategy` ou le template mis à jour).
• Le StatefulSet attend que ce nouveau Pod `N-1` soit `Running` et `Ready`.
• Ensuite seulement, il passe au Pod avec l'index précédent (`N-2`) et répète le processus.
• La mise à jour continue en descendant les index jusqu'à atteindre le Pod 0.

Cet ordre inverse est souvent choisi car il permet de mettre à jour les instances "secondaires" ou "suiveuses" avant de toucher à l'instance potentiellement "primaire" ou "leader" (qui est souvent le Pod avec l'index 0 ou le plus bas). Cela minimise l'impact sur la disponibilité du service pendant la mise à jour.

Partitions (`partition` dans `updateStrategy.rollingUpdate`) : Vous pouvez contrôler finement le processus de mise à jour en utilisant le champ `partition`. Si vous définissez `partition: k`, le StatefulSet ne mettra à jour que les Pods dont l'index est supérieur ou égal à `k`. Les Pods avec un index inférieur à `k` ne seront pas touchés et conserveront leur version précédente. C'est utile pour effectuer des déploiements canaris ou des mises à jour progressives contrôlées manuellement.

Suppression et mise à l'échelle (Scaling Down) ordonnées

De manière symétrique au déploiement, la suppression d'un StatefulSet ou la réduction de son nombre de réplicas (scaling down) se fait également de manière ordonnée et séquentielle, en ordre inverse des index ordinaux.

• Si vous réduisez le nombre de `replicas` de N à M (où M < N), le StatefulSet commencera par terminer le Pod avec l'index le plus élevé (`N-1`).
• Il attendra que ce Pod soit complètement arrêté.
• Ensuite, il terminera le Pod `N-2`.
• Ce processus continue en descendant les index jusqu'à atteindre le Pod avec l'index `M`.

Cet arrêt ordonné et gracieux permet aux applications stateful de gérer proprement le départ d'un membre du cluster (par exemple, transférer des données, notifier les autres membres) avant que le Pod ne soit effectivement supprimé.

Important : Par défaut, lorsque vous supprimez un StatefulSet (`kubectl delete statefulset ...`), les Pods sont supprimés selon cet ordre inverse, mais les PersistentVolumeClaims (PVCs) associées ne sont pas supprimées automatiquement. Cela permet de conserver les données. Si vous souhaitez également supprimer les PVCs, vous devez le faire manuellement après la suppression du StatefulSet (ou utiliser des mécanismes de nettoyage plus avancés).

Stratégie `OnDelete`

En plus de `RollingUpdate`, les StatefulSets supportent une stratégie `updateStrategy.type: OnDelete`. Avec cette stratégie, si vous mettez à jour le template du StatefulSet, le contrôleur ne fera rien automatiquement. Les Pods existants ne seront pas mis à jour tant qu'ils ne seront pas supprimés manuellement. Lorsque vous supprimez manuellement un Pod géré par un StatefulSet `OnDelete`, le contrôleur le recréera en utilisant le template mis à jour. Cela vous donne un contrôle total sur le moment et la manière dont chaque instance est mise à jour.

Conclusion : prévisibilité et contrôle pour le Stateful

Les garanties d'ordre fournies par les StatefulSets lors du déploiement, de la mise à l'échelle et des mises à jour sont une caractéristique clé qui les distingue des Deployments. Cette approche ordonnée et séquentielle (basée sur les index ordinaux stables) est souvent indispensable pour assurer le bon fonctionnement et la cohérence des applications stateful distribuées.

En combinant ces garanties d'ordre avec l'identité réseau stable et le stockage persistant stable, le StatefulSet offre une solution complète et robuste pour gérer le cycle de vie complexe des applications avec état sur Kubernetes. Il permet d'orchestrer ces applications exigeantes avec un niveau de prévisibilité et de contrôle que les autres contrôleurs ne peuvent pas offrir.