☸️ Storage Systems — Chapitre 17 : Stockage persistant pour containers et Kubernetes

• Les données survivent aux pods, pas forcément aux nœuds si local PV mal conçu.
• Un volume persistant ne remplace pas un backup.
• Une base stateful dans Kubernetes nécessite un operator ou un runbook très solide.
• La topologie multi-zone doit être pensée avant production.
• Les snapshots doivent être cohérents avec l'application, pas seulement avec le disque.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-rwo
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
reclaimPolicy: Delete
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-postgres-0
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: fast-rwo
  resources:
    requests:
      storage: 100Gi

WaitForFirstConsumer retarde la création/binding du volume jusqu'au scheduling du pod. C'est essentiel en multi-zone pour créer le volume dans la même zone que le nœud choisi.

1. Pod demande PVC.
2. Provisioner crée le volume backend.
3. Scheduler place le pod.
4. Attacher attache le volume au nœud si bloc cloud.
5. Node plugin stage le volume.
6. Kubelet mount dans le container.

kubectl get storageclass
kubectl get pvc -A
kubectl get pv
kubectl get volumeattachment
kubectl describe pvc 
kubectl describe pod 
kubectl logs -n kube-system -l app=csi-controller
kubectl logs -n kube-system -l app=csi-node

• Driver CSI absent sur un nœud.
• Permissions cloud insuffisantes.
• Volume dans mauvaise zone.
• Attach limit atteint sur instance cloud.
• Filesystem déjà monté ou dirty.
• StorageClass sans allowVolumeExpansion.

• Cloud provider : utiliser d'abord CSI natif cloud pour simplicité.
• On-prem simple : Longhorn peut être un bon point d'entrée.
• On-prem complet block/file/object : Rook-Ceph/ODF.
• Enterprise multi-cloud : Portworx selon budget/SLA.
• Performance DB maximale : local PV ou bloc cloud performant + operator DB.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres-headless
  replicas: 3
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:16
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: fast-rwo
      resources:
        requests:
          storage: 100Gi

• Supprimer le StatefulSet ne supprime pas forcément les PVC selon politique.
• Scale down conserve les PVC anciens.
• Un pod peut revenir avec ses données anciennes.
• La réplication applicative doit être cohérente avec le scheduling.

• Utiliser un operator mature pour DB critiques.
• Anti-affinity entre replicas.
• PDB pour éviter évictions simultanées.
• Backups applicatifs en plus des snapshots.
• Tests restore et failover.

Velero sauvegarde les ressources Kubernetes et peut orchestrer snapshots de volumes via plugins cloud/CSI. Il est très utile pour restaurer namespace, manifests, PVC et migrations cluster.

velero backup create app-backup --include-namespaces app
velero backup describe app-backup --details
velero restore create --from-backup app-backup
velero schedule create daily --schedule "0 2 * * *"

Les snapshots CSI capturent un volume. Ils sont rapides, mais pas toujours application-consistent. Pour bases critiques, coordonner avec l'application : freeze, flush, backup natif, WAL archiving.

kubectl get volumesnapshotclass
kubectl get volumesnapshot -A
kubectl describe volumesnapshot 

1. Restaurer CRDs/operators d'abord.
2. Restaurer secrets/configmaps.
3. Restaurer PVC/snapshots ou backups applicatifs.
4. Restaurer workloads.
5. Valider DNS, ingress, certificates, external dependencies.
6. Mesurer RTO/RPO.

Les volumes cloud zonaux ne peuvent être attachés qu'à des nœuds de la même zone. Une StorageClass sans topology correcte peut créer des PVC inutilisables pour certains pods.

• Snapshot disque seul : crash-consistent.
• Snapshot avec freeze : filesystem-consistent.
• Backup natif DB : application-consistent.
• Le restore doit être testé, pas supposé.

• DB primaire : RWO/RWOP généralement.
• Uploads partagés : RWX via NFS/CephFS/EFS/Azure Files.
• Datasets ML : ROX/RWX selon pipeline.
• Ne pas utiliser RWX pour contourner une architecture applicative mal conçue.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: zonal-fast
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
  - key: topology.kubernetes.io/zone
    values: ["eu-west-1a", "eu-west-1b"]

• Aligner replicas DB avec zones.
• Utiliser PodDisruptionBudgets.
• Tester perte zone/nœud.
• Documenter contraintes de stockage par StorageClass.

• Databases avec réplication applicative.
• Kafka brokers.
• Cassandra/ScyllaDB.
• Elasticsearch/OpenSearch.
• Edge clusters avec NVMe local.

• Operator applicatif qui sait reconstruire replica.
• Anti-affinity entre replicas.
• Monitoring disque local.
• Runbook node loss.
• Backup hors nœud.

• Uploads partagés.
• CMS médias.
• Datasets lecture partagée.
• Fichiers temporaires multi-pods.
• Mais pas toujours DB transactionnelle.

Les workloads petits fichiers et metadata intensifs saturent vite les services RWX. Surveiller ops metadata, latence, locks et nombre de clients.

• RWO rapide pour WAL/redo/logs.
• Low p99 latency.
• Topology anti-affinity.
• Snapshots coordonnés.
• Backup natif obligatoire.

• Attach limits par instance.
• Zones et topology.
• IOPS/débit selon type disque.
• Snapshots facturés.
• Expansion parfois online selon FS/driver.

Les problèmes UID/GID, fsGroup, SELinux/AppArmor sont fréquents : le volume monte, mais l'application ne peut pas écrire.

securityContext:
  runAsUser: 1000
  runAsGroup: 1000
  fsGroup: 1000
  fsGroupChangePolicy: "OnRootMismatch"

kubectl get pvc -A
kubectl get pv
kubectl describe pod 
kubectl get events -A --sort-by=.lastTimestamp
kubectl top pod -A
kubectl get volumesnapshot -A
kubectl get volumeattachment

• PVC > 80/90/95%.
• PVC Pending > 5 min.
• VolumeAttachment stuck.
• CSI pod CrashLoopBackOff.
• Snapshot failed.
• Backend storage latency high.

• RWO ou RWX ?
• Cluster cloud ou on-prem ?
• Perte nœud/zone tolérée ?
• Latence p99 requise ?
• Qui opère le backend ?
• Comment restaurer une app complète ?

1. Décrire pod et events.
2. Vérifier VolumeAttachment.
3. Vérifier node plugin CSI.
4. Vérifier permissions filesystem.
5. Vérifier backend attach/mount.

1. Confirmer usage dans pod.
2. Étendre PVC si supporté.
3. Agrandir filesystem si nécessaire.
4. Purger données validées.
5. Ajouter alertes.

1. Identifier app, namespace, PVC, point restore.
2. Restaurer dans namespace isolé.
3. Valider données et application.
4. Basculer service/DNS/Ingress.
5. Documenter RTO/RPO.

• RBAC minimal sur PVC/PV/snapshots.
• Secrets CSI protégés.
• Encryption backend.
• hostPath interdit sauf exceptions contrôlées.
• Backup credentials séparés.

• Runbook PVC Pending.
• Runbook Mount Failed.
• Runbook volume full.
• Runbook restore.
• Documentation StorageClasses et limitations.