Introduction aux StatefulSets : Identifiants réseau et stockage stables

La réponse de Kubernetes aux besoins Stateful : le StatefulSet

Face aux défis uniques posés par les applications stateful – besoin d'identité réseau stable, de stockage persistant stable lié à chaque instance, et de déploiements ordonnés – Kubernetes propose un contrôleur de workload spécifiquement conçu pour y répondre : le StatefulSet.

Contrairement aux Deployments qui traitent les Pods comme des entités anonymes et interchangeables, les StatefulSets gèrent leurs Pods en leur attribuant et en maintenant une identité persistante unique. Cette identité est composée d'un identifiant ordinal, d'un nom réseau stable et d'un stockage stable spécifique à chaque instance.

Le StatefulSet est donc l'outil de choix pour déployer des applications comme des bases de données en cluster, des systèmes de messagerie, ou d'autres applications distribuées où chaque membre a un état unique et a besoin de communiquer de manière fiable avec ses pairs. Ce chapitre introduit les mécanismes fondamentaux par lesquels les StatefulSets fournissent ces garanties d'identité et de stockage.

Identité Réseau Stable et Prévisible

C'est l'une des caractéristiques les plus distinctives des StatefulSets. Chaque Pod géré par un StatefulSet obtient une identité stable et prévisible qui persiste même si le Pod est redémarré ou replanifié sur un autre noeud.

Cette identité se manifeste de plusieurs manières :

• Index Ordinal : Chaque Pod se voit attribuer un index entier non négatif unique (0, 1, 2, ... N-1, où N est le nombre de réplicas). Cet index est stable.
• Nom de Pod Prévisible : Le nom de chaque Pod suit un format fixe : `-`. Par exemple, si votre StatefulSet s'appelle `web`, les Pods s'appelleront `web-0`, `web-1`, `web-2`, etc.
• Nom d'Hôte DNS Stable : Pour que ces noms soient résolubles et utilisables pour la communication, un StatefulSet est presque toujours utilisé en conjonction avec un Service Headless (dont le nom est spécifié dans `spec.serviceName` du StatefulSet). Ce Service Headless, comme nous l'avons vu, ne crée pas de ClusterIP mais configure le DNS pour retourner les IPs des Pods. Plus important encore, il crée des enregistrements DNS pour chaque Pod individuel du StatefulSet, suivant le format : `...svc.`.
  Par exemple, `web-0.nginx.default.svc.cluster.local` résoudra toujours l'adresse IP actuelle du Pod `web-0`, même s'il redémarre.

Grâce à ces noms DNS stables, les Pods d'un StatefulSet peuvent se découvrir et communiquer entre eux de manière fiable, ce qui est essentiel pour la formation de clusters.

Stockage Persistant Stable et Unique par Instance

L'autre garantie fondamentale fournie par les StatefulSets est que chaque Pod obtient son propre volume de stockage persistant unique, et qu'il retrouvera toujours ce *même* volume, même après un redémarrage ou une replanification.

Ceci est réalisé grâce au champ `spec.volumeClaimTemplates` dans la définition du StatefulSet. Ce champ contient une liste de spécifications de PersistentVolumeClaims (PVCs).

• Création automatique de PVCs : Pour chaque Pod créé par le StatefulSet (avec l'index ordinal `i`), une PVC correspondante est automatiquement créée à partir de chaque template défini dans `volumeClaimTemplates`.
• Nommage prévisible des PVCs : Le nom de la PVC créée suit également un format stable : `--`. Par exemple, si `volumeClaimTemplates` définit une demande nommée `data`, le Pod `web-0` obtiendra une PVC nommée `data-web-0`, le Pod `web-1` obtiendra `data-web-1`, etc.
• Liaison persistante : Kubernetes garantit que le Pod `-i` montera toujours le volume (PV) associé à la PVC `--i`. Même si le Pod `web-0` est supprimé et recréé sur un autre noeud, il sera automatiquement rattaché au volume persistant lié à la PVC `data-web-0`.

Pour que cela fonctionne, vous devez disposer d'une StorageClass supportant le provisionnement dynamique, ou avoir pré-provisionné manuellement des PVs qui peuvent satisfaire les PVCs générées.

Cette association stable entre un Pod spécifique et son stockage dédié est exactement ce dont les bases de données et autres applications stateful ont besoin pour maintenir leur état individuel.

Exemple partiel de manifeste StatefulSet illustrant l'identité et le stockage

Voici un aperçu de la structure YAML montrant les champs clés pour l'identité et le stockage :

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web # Nom du StatefulSet
spec:
  serviceName: "nginx" # Nom du Service Headless associé (obligatoire)
  replicas: 3
  selector:
    matchLabels:
      app: nginx # Doit correspondre aux labels du template
  template:
    metadata:
      labels:
        app: nginx
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: data-volume # Doit correspondre au nom dans volumeClaimTemplates
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates: # Section clé pour le stockage stable
  - metadata:
      name: data-volume # Nom du template de volume
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "standard-ssd" # Demande une StorageClass spécifique
      resources:
        requests:
          storage: 1Gi # Taille demandée pour chaque PVC

Dans cet exemple :

• Les Pods s'appelleront `web-0`, `web-1`, `web-2`.
• Ils auront des noms DNS stables comme `web-0.nginx.default...`, `web-1.nginx.default...` (en supposant que le StatefulSet est dans le namespace `default` et qu'un Service Headless nommé `nginx` existe).
• Chaque Pod (`web-0`, `web-1`, `web-2`) obtiendra automatiquement sa propre PVC nommée `data-volume-web-0`, `data-volume-web-1`, `data-volume-web-2`, chacune demandant 1Gi de stockage via la StorageClass `standard-ssd`.
• Le Pod `web-i` montera toujours le volume associé à `data-volume-web-i` dans `/usr/share/nginx/html`.

Conclusion : les piliers de la gestion Stateful

Les identifiants réseau stables (via l'index ordinal, les noms de Pods prévisibles et les enregistrements DNS générés par un Service Headless associé) et le stockage persistant stable (via les `volumeClaimTemplates` qui génèrent des PVCs uniques et liées à chaque Pod) sont les deux piliers fondamentaux sur lesquels repose le StatefulSet.

Ces mécanismes résolvent directement les principaux défis posés par les applications stateful dans un environnement d'orchestration comme Kubernetes, en fournissant les garanties d'identité et de persistance dont ces applications ont besoin.

Cependant, le StatefulSet offre une autre garantie importante que nous allons explorer ensuite : le contrôle ordonné des opérations.