Files
omnex/deploy/longhorn/storageclass.yml
T
Xor290 ef303951a3
ci-web / test (push) Successful in 14m43s
chore: update
2026-08-08 12:20:56 +02:00

43 lines
1.9 KiB
YAML

# 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"