Kubernetes 041 – StatefulSets : principe, fonctionnement et demo

TL;DR

Un StatefulSet ressemble a un Deployment, mais il donne une identite stable a chaque pod: nom ordinal, DNS stable et PVC dedie via volumeClaimTemplates. C’est utile pour les applications avec etat, comme certaines bases de donnees ou systemes distribues.

La video de reference

Video: https://www.youtube.com/watch?v=q7qEDZYxHzg

Elle explique pourquoi un Deployment ne suffit pas toujours pour des workloads stateful.

Pourquoi StatefulSet ?

Un Deployment gere des replicas interchangeables. Si un pod disparait, un autre le remplace, sans importance pour son nom ou son stockage.

Certaines applications ont besoin d’identite: db-0, db-1, db-2, avec un ordre et un disque associe. C’est le domaine du StatefulSet.

Propriete principale

Un StatefulSet apporte:

• des noms stables avec un ordinal;
• un demarrage et un arret ordonnes par defaut;
• des identites DNS stables via un Headless Service;
• des PVC stables par replica;
• une logique adaptee aux applications avec etat.

Headless Service

Un StatefulSet s’appuie souvent sur un Service headless:

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

clusterIP: None permet d’obtenir des enregistrements DNS directs pour les pods.

Exemple de StatefulSet

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: web
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 80
              name: http
          volumeMounts:
            - name: data
              mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 1Gi

Chaque replica obtient son propre PVC, par exemple data-web-0, data-web-1, data-web-2.

Noms et DNS

Les pods auront des noms stables:

web-0
web-1
web-2

Avec le Service headless, on peut atteindre un pod par un DNS du type:

web-0.web.default.svc.cluster.local

Cette stabilite est essentielle pour certains protocoles de cluster.

Observer le comportement

kubectl apply -f service.yaml
kubectl apply -f statefulset.yaml
kubectl get pods -w
kubectl get pvc
kubectl delete pod web-1
kubectl get pods,pvc

Le pod recree garde le meme nom et retrouve son PVC.

Difference avec Deployment

Un Deployment est parfait pour des replicas stateless. Le StatefulSet ajoute de la stabilite et donc de la responsabilite. Il ne transforme pas automatiquement une application en base robuste.

Si l’application ne sait pas gerer replication, quorum ou recuperation, le StatefulSet ne l’inventera pas.

Liens utiles

• Video: https://www.youtube.com/watch?v=q7qEDZYxHzg
• Playlist Kubernetes v2: https://www.youtube.com/playlist?list=PLn6POgpklwWo6wiy2G3SjBubF6zXjksap
• Depot Xavki Kubernetes v2: https://gitlab.com/xavki/tutorials-kubernetes-v2
• StatefulSets: https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
• Headless Services: https://kubernetes.io/docs/concepts/services-networking/service/#headless-services

FAQ

Un StatefulSet est-il obligatoire pour une base de donnees ?

Pas toujours, mais il est souvent plus adapte qu’un Deployment pour conserver identite et volumes.

Les PVC sont-ils supprimes avec le StatefulSet ?

Historiquement, ils sont conserves par securite. Verifiez les options de retention selon la version Kubernetes.

Peut-on scaler un StatefulSet ?

Oui, mais l’ordre et la logique applicative doivent etre compris avant de scaler une base.

Erreurs frequentes

• Utiliser un StatefulSet pour une application stateless sans besoin reel.
• Oublier le Headless Service.
• Croire que StatefulSet signifie haute disponibilite automatique.
• Supprimer des PVC sans sauvegarde.

Pour pratiquer

Ecrivez un fichier different dans chaque pod, supprimez web-1, puis verifiez que le contenu du PVC associe revient avec le pod recree.

Notions et definitions

• Volume: point de montage rendu disponible dans un conteneur.
• PVC: demande de stockage exprimee par une application.
• PV et StorageClass: ressource de stockage et mecanisme de provisionnement associe.

Ces definitions donnent le vocabulaire minimal pour suivre l’article sans reduire Kubernetes a une simple commande. Chaque notion doit etre reliee a un objet visible avec kubectl ou a un composant du cluster.

Exemple concret

Une base de donnees dans un pod ne doit pas dependre du filesystem ephemere du conteneur; elle utilise un PVC pour retrouver ses donnees apres recreation du pod.

Cet exemple sert de fil conducteur: il montre quel probleme operationnel Kubernetes cherche a resoudre et quelle ressource permet de le formaliser.

How-to rapide

• Identifier si le besoin est ephemere, partage ou persistant.
• Creer un PVC adapte en taille et en mode d’acces.
• Monter ce PVC dans le pod ou le workload.
• Tester la persistence en supprimant puis recreant le pod.

Le how-to est volontairement court: l’idee est d’obtenir un resultat observable, puis d’utiliser les commandes de verification pour comprendre ce qui s’est passe.

Approfondir cet article

Cet episode doit surtout permettre de maitriser la difference entre stockage ephemere, volume attache au pod, volume persistant et provisionnement dynamique. L’objectif n’est pas seulement de refaire les commandes, mais de comprendre quel objet Kubernetes est cree, quel composant le prend en charge et comment verifier le resultat.

Questions a se poser

• Quel est l’etat desire exprime dans Kubernetes ?
• Quel composant observe cet etat et tente de le reconciler ?
• Quels symptomes montrent que l’objet est cree mais pas encore operationnel ?
• Quelle commande donne l’information la plus fiable pour diagnostiquer ?

Commandes de verification

• kubectl get pv,pvc,storageclass -o wide
• kubectl describe pvc <pvc> pour suivre les evenements de binding
• kubectl describe pod <pod> pour verifier les montages et les erreurs de volume

Ces commandes ne sont pas a apprendre par coeur. Elles servent a construire un reflexe: partir de l’objet Kubernetes, lire son etat, puis descendre vers les pods, les events, les logs ou le noeud uniquement si c’est necessaire.

Points de vigilance

• penser qu’un volume persistant resout automatiquement les sauvegardes
• melanger les responsabilites entre PVC, PV et StorageClass
• utiliser hostPath comme solution de production alors qu’il depend fortement du noeud

Exercice conseille

Creez un PVC, montez-le dans un pod de test, ecrivez un fichier, supprimez le pod, puis relancez-le pour verifier ce qui persiste vraiment.

Pour valider la comprehension, gardez une trace courte: manifest utilise, commandes lancees, resultat attendu, resultat observe et correction appliquee. Cette methode rend les episodes suivants beaucoup plus faciles a enchainer.

Lien interne conseille

Pour poursuivre la progression, consultez aussi Kubernetes 042 – DaemonSets : principe et demo avec node exporter.

Conclusion

Le StatefulSet est l’objet Kubernetes des identites stables. Il est puissant, mais il doit etre accompagne d’une vraie comprehension de l’application stateful que l’on deploye.