Concepts avancés des StatefulSets Kubernetes : une plongée pratique en profondeur

Découvrez comment les StatefulSets Kubernetes fonctionnent sous le capot, de l'identité et de l'ordre aux mises à jour et à la reprise après échec, avec des exemples pratiques et des étapes de vérification.

Introduction

Les StatefulSets Kubernetes sont le contrôleur de charge de travail de référence pour les applications qui nécessitent une identité stable, un stockage persistant et un déploiement et une mise à l'échelle ordonnés. Si de nombreux ingénieurs connaissent les bases, des concepts avancés comme les mécanismes d'identité, les stratégies de mise à jour, les mises à jour progressives par partition et la restauration forcée sont souvent mal compris. Cet article propose une plongée pratique dans ces concepts avancés, en expliquant comment les StatefulSets fonctionnent en interne et comment les appliquer en toute sécurité en production. À la fin, vous aurez une compréhension claire de quand ces fonctionnalités comptent et comment vérifier leur comportement avec des exemples concrets. Nous aborderons les prérequis, la configuration sûre, les techniques de vérification, les modes de défaillance, la récupération et une liste de contrôle opérationnelle.

Inventaire des versions et de l'environnement

Avant de plonger dans les concepts avancés des StatefulSets, établissez un environnement contrôlé. Les exemples de cet article supposent un cluster Kubernetes exécutant la version 1.24 ou ultérieure, car des fonctionnalités comme le drapeau --field-manager et les pilotes CSI stables sont matures. Vous avez besoin de kubectl configuré avec des autorisations de cluster-admin dans un espace de noms de développement. Une classe de stockage prenant en charge le provisionnement dynamique est requise pour les demandes de volume persistant. Pour l'expérimentation locale, des outils comme Kind ou Minikube avec un provisionneur de stockage par défaut fonctionnent bien. Le tableau ci-dessous résume les prérequis de l'environnement.

Vérifiez la version de votre cluster et votre classe de stockage avec les commandes suivantes. La sortie attendue montre la version du serveur et une classe de stockage disponible avec le marqueur (default).

$ kubectl version --short
Client Version: v1.24.0
Server Version: v1.24.0

$ kubectl get storageclass
NAME                 PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
standard (default)   rancher.io/local-path   Delete          WaitForFirstConsumer   false                10d

Chemin de configuration sûr

Les configurations avancées de StatefulSet impliquent souvent de modifier les stratégies de mise à jour et les paramètres de partition. Pour minimiser les risques, appliquez les changements de manière incrémentale et observez le comportement. Les champs avancés les plus importants sont spec.podManagementPolicy, spec.updateStrategy et spec.replicas.

podManagementPolicy peut être OrderedReady (par défaut) ou Parallel. La valeur par défaut garantit que les pods sont créés et supprimés dans l'ordre, en attendant que chacun soit prêt avant de continuer. Parallel permet des opérations simultanées sur les pods, utile pour une mise à l'échelle de type sans état d'applications stateful qui gèrent leur propre coordination.

updateStrategy contrôle la façon dont les mises à jour progressives sont effectuées. Le type rollingUpdate possède un champ partition. S'il est spécifié, seuls les pods avec un ordinal supérieur ou égal à la partition sont mis à jour. Tous les pods avec un ordinal inférieur à la partition restent à l'ancienne version. Cela permet des mises à jour de type Canary pour les applications stateful.

Voici un exemple de manifeste StatefulSet avec une mise à jour progressive basée sur une partition :

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      partition: 2
  podManagementPolicy: OrderedReady
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.24
        ports:
        - containerPort: 80
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "standard"
      resources:
        requests:
          storage: 1Gi

Appliquez ce manifeste avec kubectl apply -f statefulset.yaml. Le StatefulSet crée trois pods nommés web-0, web-1, web-2 dans l'ordre séquentiel. Comme la partition est 2, si vous changez plus tard l'image en nginx:1.25, seul web-2 sera mis à jour, tandis que web-0 et web-1 resteront sur l'ancienne version. C'est un moyen sûr de tester une mise à niveau sur un seul pod avant de la déployer sur tous.

Comprendre l'identité du pod et l'identité réseau stable

Un concept avancé central est l'identité stable fournie par les StatefulSets. Chaque pod reçoit un nom prévisible basé sur le nom du StatefulSet et un index ordinal : web-0, web-1, web-2. Ces noms sont persistants : si un pod meurt, son remplaçant obtient le même nom. Cette identité est liée aux demandes de volume persistant du pod et à l'identité réseau stable via un service headless.

Définissez un service headless pour le StatefulSet afin de permettre des entrées DNS stables :

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  clusterIP: None
  selector:
    app: nginx
  ports:
  - port: 80
    name: web

Avec ce service, chaque pod obtient un nom DNS comme web-0.nginx.default.svc.cluster.local. Cette identité réseau stable est essentielle pour les applications stateful qui doivent adresser des pairs par un nom cohérent, comme les réplicas de base de données ou les courtiers de messages en cluster.

Modèles de demandes de volume et stockage persistant

Le champ volumeClaimTemplates définit un modèle pour créer une demande de volume persistant (PVC) pour chaque pod. Lorsqu'un pod est créé, le contrôleur StatefulSet crée une PVC nommée www-web-0, www-web-1, etc. Ces PVC ne sont pas supprimées lorsqu'un pod est supprimé ; elles persistent pour préserver les données. Si un pod est replanifié sur un autre nœud, il se rattache à la même PVC, assurant la continuité des données.

Vérification et diagnostics

Après avoir appliqué les changements de configuration, vérifiez que le StatefulSet se comporte comme prévu. Utilisez kubectl get statefulset pour voir le statut, kubectl describe statefulset pour les événements, et kubectl get pods avec des étiquettes pour inspecter les pods individuellement.

Pour vérifier le comportement de mise à jour par partition, vérifiez d'abord l'image actuelle de chaque pod avec la commande suivante. La sortie montrera quels pods sont encore sur l'ancienne image et lesquels ont été mis à jour.

$ kubectl get pods -l app=nginx -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\n"}{end}'
web-0  nginx:1.24
web-1  nginx:1.24
web-2  nginx:1.25

Cela confirme que seul le pod web-2 a été mis à jour en raison de la partition. Pour observer l'ordre de création des pods après une réduction puis une augmentation d'échelle, supprimez les pods du StatefulSet et regardez-les se recréer. Par exemple, si vous supprimez web-1, le contrôleur ne le recréera qu'après que web-0 soit prêt, si podManagementPolicy est OrderedReady.

Exécutez la commande suivante pour observer les événements des pods :

kubectl get pods -l app=nginx -w

Vous verrez web-0 devenir prêt avant que web-1 ne soit créé. Ce comportement ordonné est essentiel pour les applications qui nécessitent une séquence de démarrage spécifique.

Pour la vérification du stockage, vérifiez que chaque pod possède une demande de volume persistant unique et que le volume est lié :

$ kubectl get pvc -l app=nginx
NAME        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
www-web-0   Bound    pvc-1234abcd-56ef-7890-ghij-klmnopqrstuv   1Gi        RWO            standard       5m
www-web-1   Bound    pvc-5678efgh-90ij-klmn-opqr-stuvwxyzabcd   1Gi        RWO            standard       5m
www-web-2   Bound    pvc-9012ijkl-mnop-qrst-uvwx-yzabcdefghij   1Gi        RWO            standard       5m

Cela montre que chaque pod possède son propre volume persistant, un avantage clé des StatefulSets par rapport aux Deployments.

Inspection du statut du StatefulSet

Utilisez kubectl get statefulset web -o yaml pour inspecter les champs de statut. Les champs clés comprennent :

• replicas : nombre souhaité de pods
• readyReplicas : nombre de pods prêts
• currentReplicas : nombre de pods à la version actuelle
• updatedReplicas : nombre de pods à la version mise à jour

Par exemple :

$ kubectl get statefulset web
NAME   READY   AGE
web    3/3     10m

Si vous constatez un écart entre replicas et readyReplicas, examinez les sondes de préparation des pods et les journaux.

Modes de défaillance et récupération

Les StatefulSets peuvent échouer de plusieurs façons. Les modes de défaillance courants incluent des pods bloqués en Pending en raison de problèmes de liaison de PVC, des pods qui plantent à cause d'une mauvaise configuration de l'application, ou des échecs de mise à jour nécessitant une restauration. Comme les StatefulSets maintiennent l'identité, supprimer un pod ne supprime pas sa PVC ; les données persistent. Cependant, si vous supprimez le StatefulSet lui-même, les PVC restent par défaut, ce qui peut être souhaitable pour la rétention des données mais peut causer des problèmes si vous recréez le StatefulSet avec le même nom et vous attendez à ce qu'il réutilise les anciens volumes. Le contrôleur StatefulSet n'adopte pas automatiquement les PVC existantes à moins qu'elles ne correspondent au modèle de nommage et aux étiquettes.

Pour une restauration forcée après une mise à jour échouée, vous pouvez utiliser kubectl rollout undo statefulset web. Cela revient à la révision précédente stockée dans l'historique du contrôleur. Cependant, notez que les déploiements StatefulSet ont un historique limité (10 par défaut). Pour annuler manuellement une mise à jour par partition, il suffit de réduire la partition à 0, ce qui mettra à jour tous les pods vers la version cible. Si la version cible est défectueuse, vous devez remettre l'image à la version précédente et appliquer à nouveau.

Un autre mode de défaillance survient lorsqu'un pod devient non prêt et bloque la mise à jour ordonnée. Si un pod avec un ordinal inférieur à la partition n'est pas prêt, le contrôleur ne procédera pas à la mise à jour des ordinaux supérieurs. Pour résoudre, vous devrez peut-être supprimer le pod fautif ou corriger sa préparation.

Diagnostic d'un pod bloqué

Pour récupérer d'un StatefulSet bloqué, inspectez d'abord les événements :

$ kubectl describe statefulset web
...
Events:
  Type     Reason            Age   From                    Message
  ----     ------            ----  ----                    -------
  Warning  FailedCreate      10m   statefulset-controller  create Pod web-0 in StatefulSet web failed error: pods "web-0" is forbidden: unable to validate against any pod security policy

Cet exemple montre un problème de politique de sécurité des pods. Corrigez la politique ou ajustez le contexte de sécurité du pod. Après correction, le contrôleur réessaiera automatiquement.

Pour les défaillances liées au stockage, assurez-vous que la classe de stockage est disponible et que la PVC est liée. Si une PVC est bloquée en Pending, vérifiez les événements de la classe de stockage :

kubectl describe pvc www-web-0

Recherchez les événements indiquant des échecs de provisionnement. Vous devrez peut-être supprimer et recréer la PVC ou ajuster la classe de stockage.

Intervention manuelle pour les PVC orphelines

Si vous supprimez un StatefulSet mais conservez les PVC, puis recréez le StatefulSet avec le même nom, le contrôleur n'adoptera pas automatiquement les PVC existantes car elles n'ont pas les étiquettes correctes. Vous devez les étiqueter manuellement ou les pré-provisionner. Pour adopter une PVC existante, assurez-vous que son nom correspond à www-web-<ordinal> et qu'elle possède l'étiquette app=nginx. Sinon, vous pouvez l'étiqueter :

kubectl label pvc www-web-0 app=nginx

Recréez ensuite le StatefulSet, et le contrôleur liera la PVC existante au pod.

Forcer la suppression d'un pod avec --force et --grace-period=0

Si un pod est bloqué en état Terminating, vous pouvez le supprimer de force :

kubectl delete pod web-0 --force --grace-period=0

Cela doit être utilisé en dernier recours, car cela contourne l'arrêt gracieux et peut entraîner une corruption des données si l'application ne gère pas l'arrêt brutal.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle lors de l'exploitation de StatefulSets en production pour garantir la stabilité et une récupération rapide.

De plus, examinez régulièrement les champs de statut du StatefulSet (currentReplicas, updatedReplicas, readyReplicas) pour détecter rapidement les écarts.

Exemple de flux de travail de mise à jour Canary

Voici un flux de travail concret de mise à jour Canary pour le StatefulSet web :

1. Base de référence : Tous les pods sur nginx:1.24, partition=3 (par défaut, aucune mise à jour).
2. Canary : Modifiez la partition à 2 et mettez à jour l'image à nginx:1.25. Seul web-2 est mis à jour.
3. Validation : Vérifiez les journaux, exécutez des contrôles de santé sur web-2.
4. Déploiement : Modifiez la partition à 0. web-1 et web-0 sont mis à jour dans l'ordre décroissant (car la partition 0 signifie que tous les pods avec ordinal >= 0 sont mis à jour, mais le contrôleur respecte toujours la politique ordonnée).
5. Confirmation : Tous les pods signalent nginx:1.25 et sont prêts.

Si une étape échoue, vous pouvez revenir en arrière en remettant l'image à nginx:1.24 et en ajustant la partition de manière appropriée.

Avancé : Ordre de mise à l'échelle et de suppression

Lors de la réduction d'un StatefulSet, les pods sont supprimés dans l'ordre inverse des ordinaux : l'ordinal le plus élevé est supprimé en premier. Cela garantit que le dernier pod à être supprimé est celui qui détient probablement les données les plus critiques ou qui est le primaire dans un cluster. Par exemple, passer de 3 à 2 supprime d'abord web-2, puis web-1 si on réduit davantage.

Lors de la suppression du StatefulSet, vous pouvez utiliser --cascade=orphan pour garder les pods en cours d'exécution tout en supprimant le contrôleur. Cela est utile pour la maintenance ou la migration.

kubectl delete statefulset web --cascade=orphan

Les pods restent mais ne sont plus gérés par le StatefulSet. Vous pouvez plus tard les adopter en recréant le StatefulSet avec des étiquettes correspondantes.

Conclusion

Les concepts avancés des StatefulSets, en particulier l'identité, l'ordre et les mises à jour basées sur des partitions, vous donnent un contrôle fin sur les applications stateful. En comprenant ces mécanismes internes, vous pouvez déployer et gérer en toute sécurité des bases de données, des files de messages et d'autres services stateful sur Kubernetes. Nous avons couvert les prérequis de l'environnement, la configuration sûre avec les mises à jour par partition, la vérification via des commandes détaillées, les modes de défaillance avec les étapes de récupération, et une liste de contrôle opérationnelle pratique. Commencez par appliquer ces techniques dans un cluster de développement avec un StatefulSet simple, puis passez en production avec confiance. N'oubliez pas de toujours tester les changements avec une partition et de maintenir des sauvegardes de vos manifestes StatefulSet et de vos données persistantes.