chore: update

deploy/longhorn/storageclass.yml

@@ -0,0 +1,42 @@
+# Prérequis (à faire une seule fois, hors de ce manifeste — même logique que
+# deploy/cert-manager/, un composant partagé du cluster, pas par démo) :
+#
+#   1. Sur CHAQUE nœud du cluster (y compris les workers ARM64 Raspberry Pi —
+#      Longhorn supporte officiellement l'ARM64) :
+#        apt-get update && apt-get install -y open-iscsi nfs-common
+#        systemctl enable --now iscsid
+#
+#   2. Installer Longhorn (v1.12.0, dernière version stable au moment de
+#      l'écriture — vérifier https://github.com/longhorn/longhorn/releases
+#      avant d'appliquer une version plus récente) :
+#        kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.12.0/deploy/longhorn.yaml
+#
+#   3. Attendre que tous les pods soient Running avant de déployer une démo :
+#        kubectl -n longhorn-system get pods
+#
+#   4. Appliquer ce manifeste :
+#        kubectl apply -f deploy/longhorn/storageclass.yml
+#
+# Pourquoi : la StorageClass par défaut du cluster (local-path, fournie par
+# k3s) attache chaque volume au disque LOCAL du nœud où le pod tourne — si ce
+# nœud tombe, le volume devient inaccessible tant qu'il ne redémarre pas,
+# avec un vrai risque de perte de données. Cette StorageClass réplique
+# chaque volume sur 2 nœuds différents (numberOfReplicas) : si le nœud qui
+# héberge le pod tombe, Kubernetes reprogramme le pod ailleurs et Longhorn
+# rattache une réplique déjà à jour, sans interruption ni perte.
+#
+# Utilisée par les PVC postgres/redis/uploads des démos — voir
+# deploy/chart-gestion/{postgresql,redis,backend}/values.yaml
+# (persistence.storageClass / persistence.uploads.storageClass).
+apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  name: longhorn-replicated
+provisioner: driver.longhorn.io
+allowVolumeExpansion: true
+reclaimPolicy: Delete
+volumeBindingMode: Immediate
+parameters:
+  numberOfReplicas: "2"
+  staleReplicaTimeout: "30"
+  fsType: "ext4"