Installer Longhorn : Stockage Kubernetes Résilient

La perte de données se situe sur un spectre allant du léger désagrément à la catastrophe menant à la faillite. Par conséquent, il est souvent important d'utiliser les outils et les techniques appropriés pour garantir une solution de stockage de données fiable et hautement disponible. Dans le monde des homelabs et des clusters Kubernetes de taille moyenne, une solution populaire est Longhorn.

Si vous pensez que cela ne vous arrivera pas, laissez-moi vous rappeler les nombreuses façons dont vous pouvez perdre vos données, que ce soit complètement ou partiellement. Celles-ci incluent :

• Panne matérielle : C'est-à-dire que votre disque dur ou votre serveur tombe en panne ou subit un dommage physique.
• Panne logicielle : Les données peuvent être supprimées par un bug ou du code défectueux.
• Panne réseau : Vous avez perdu la connexion à votre stockage qui est maintenant inaccessible.
• Erreur humaine : Vous avez fait une erreur et supprimé votre base de données principale.
• Acteurs malveillants : Quelqu'un d'autre a réussi à supprimer votre base de données principale.
• Le soleil et les radiations cosmiques qui inversent des bits aléatoires : oui, c'est arrivé dans mon pays
• Et plus encore !

Longhorn est un système de stockage concu pour Kubernetes. S'il est utilisé correctement, Longhorn peut vous protéger de la plupart des dangers qui entraîneraient une perte de données. Les principales fonctionnalités qu'il fournit sont :

• La réplication des volumes entre les nœuds pour la haute disponibilité (HA).
• Les snapshots et les sauvegardes de volumes pour la reprise après sinistre (DR).

Dans ce tutoriel, nous allons apprendre comment Longhorn fonctionne, comment l'installer sur votre cluster, et comment l'utiliser.

Longhorn vs Ses Concurrents

Longhorn n'est ni la seule ni la principale solution de stockage disponible. La première question à laquelle vous devez répondre est : est-ce le bon outil pour vous et votre cas d'usage ? Voyons la concurrence.

La plupart des solutions de stockage déployées, en part de marché, sont des solutions propriétaires des hyperscalers comme AWS, Google ou Azure. En général, vous n'aurez pas l'occasion de les manipuler car elles se trouvent sous de nombreuses couches d'abstraction. Cependant, il est bon de mentionner que les grands acteurs ont chacun leur propre solution et que c'est ce que la plupart des gens utilisent indirectement.

Pour nous autres qui souhaitons gérer notre propre cluster de calcul, il existe quelques alternatives :

• 1. Rook-Ceph : Si vous avez la capacité

• Avantages : Le plus utilisé, de qualité professionnelle, hautement scalable et complet en fonctionnalités.

• Inconvénients : Courbe d'apprentissage abrupte, difficile à configurer et gourmand en CPU et RAM par rapport aux autres.

• Quand l'utiliser : Grands clusters puissants gérés par une équipe cloud expérimentée.

2. Portworx : Si vous avez l'argent

• Avantages : De qualité professionnelle avec un support dédié 24/7 et de nombreuses fonctionnalités avancées qui rivalisent avec Rook-Ceph, comme la migration inter-cloud.
• Inconvénients : Solution propriétaire payante et coûteuse.
• Quand l'utiliser : Environnements d'entreprise exigeant des SLA stricts, une mobilité multi-cloud et un support fournisseur.

3. OpenEBS : Si vous avez des besoins spécifiques

• Avantages : Très modulaire, c'est l'Arch Linux du stockage en cluster, ce qui le rend idéal pour les clusters de stockage hétérogènes avec des besoins très spécifiques.
• Inconvénients : Cas d'usage très spécifique nécessitant une configuration et une personnalisation manuelles importantes.
• Quand l'utiliser : Infrastructures spécialisées ou mixtes qui exigent des backends de stockage personnalisables.

4. Longhorn : Si vous avez besoin des bases

• Avantages : Très facile à configurer et à maintenir, léger en CPU et RAM, et inclut les fonctionnalités de base dont vous avez besoin pour la haute disponibilité (réplikas, snapshots, sauvegardes S3 externes, tâches automatisées).
• Inconvénients : Ne s'adapte pas bien aux grands clusters et manque de fonctionnalités plus complexes.
• Quand l'utiliser : Clusters de petite à moyenne taille à la recherche d'une solution de stockage légère et hautement disponible avec des fonctionnalités de base et une maintenance facile.

Comment fonctionne Longhorn

Lorsque vous créez un nouveau volume avec Longhorn, il apparaîtra sous forme de plusieurs réplikas (3 par défaut). Par conséquent, Longhorn triple l'espace de stockage requis pour les volumes. Ces réplikas sont ensuite distribués sur des nœuds distincts. Ainsi, si un nœud tombe en panne, vos données sont en sécurité sur un autre nœud.

En comparaison, Rook-Ceph n'utilise que 150% de l'espace de stockage nécessaire. Cependant, leur solution requiert plus de calcul. Que votre goulot d'étranglement soit le CPU ou le stockage peut influencer votre choix de solution. Néanmoins, comme nous le verrons, tout n'a pas besoin de 3 réplikas.

La lecture et l'écriture sur les volumes sont gérées par les moteurs Longhorn qui se placent devant les réplikas du volume ; chaque volume a au plus un moteur. Vos pods interagissent uniquement avec ce moteur qui accède ensuite aux réplikas. Par conséquent, écrire une fois signifie écrire trois fois (au moins deux fois sur le réseau). Cependant, les lectures sont servies par un seul réplika.

Les scénarios de type split-brain sont évités car les moteurs agissent comme des gardiens.

• Si un nœud contenant un réplika tombe en panne : Le moteur du volume voit le réplika comme indisponible et l'abandonne. Il marque ensuite le volume comme dégradé et continue de gérer les E/S sans interruption.
• Si un nœud contenant un moteur tombe en panne : Le gestionnaire Longhorn crée un nouveau moteur sur un autre nœud et y rattache la charge de travail. Les volumes restent opérationnels tant qu'au moins un réplika sain est connecté et que le moteur est disponible.

Comment installer Longhorn

D'abord, vous aurez besoin d'un cluster avec au moins deux nœuds disposant de stockage local ; Longhorn stocke les données directement sur les nœuds.

Sur chaque nœud, Longhorn requiert des dépendances hôtes spécifiques. Exécutez la commande suivante sur chacun de vos nœuds :

sudo apt-get update
sudo apt-get install -y open-iscsi nfs-common util-linux bash curl jq xfsprogs
sudo systemctl enable --now iscsid

En supposant que Helm est installé, ajoutez et mettez à jour le dépôt Longhorn :

helm repo add longhorn https://charts.longhorn.io
helm repo update

Ensuite, nous allons créer un fichier values.yaml pour configurer notre installation de Longhorn. Il est recommandé de stocker ce fichier de configuration quelque part ; j'aime les conserver dans un dépôt git séparé pour mon infrastructure.

Voici un exemple de base :

defaultSettings:
  defaultReplicaCount: 2
  storageMinimalAvailablePercentage: 10
persistence:
  defaultClassReplicaCount: 2
  defaultDataLocality: "best-effort"
ingress:
  enabled: true
  host: longhorn.home.arpa
  tls: false

Notez quelques choix :

• Nombre de réplikas = 2 : Longhorn utilise 3 réplikas par défaut. Je n'ai pas encore trois nœuds, donc je l'ai réglé à deux. Même si j'avais trois nœuds, je pourrais conserver ce paramètre pour éviter de consommer trop de stockage. Ce paramètre est défini à deux endroits :
  • defaultSettings.defaultReplicaCount : Ceci s'applique uniquement aux volumes créés manuellement via l'interface utilisateur de Longhorn.
  • persistence.defaultClassReplicaCount : Ceci s'applique aux Persistent Volume Claims (PVCs) provisionnés nativement via Kubernetes.
• Localité des données (best-effort) : Lorsque réglé sur best-effort, Longhorn essaie de conserver un réplika local du volume sur le même nœud où le pod s'exécute.
• Ajustement du stockage réservé : Par défaut, Longhorn réserve 25% de l'espace disque pour éviter la pression sur les nœuds. J'ai abaissé le pourcentage minimum d'espace disponible à 10% pour récupérer plus d'espace utilisable.
• Les champs ingress sont plus standards et utilisés pour configurer l'interface utilisateur de Longhorn.

Attention, ces choix sont les miens et vous en ferez probablement d'autres. Ne copiez pas simplement sans réfléchir à votre propre cas d'usage.

Pour plus d'informations, consultez la liste complète des paramètres ici. Je vous suggère d'utiliser quelque chose comme ceci pour l'explorer : visualiseur YAML

D'autres paramètres intéressants incluent :

• Metrics : Pour intégrer Longhorn avec Prometheus.
• preUpgradeChecker.jobEnabled : Paramètre qui permet à Longhorn d'effectuer des vérifications avant la mise à niveau.
  • Désactivez si vous installez Longhorn avec Argo CD ou des solutions similaires.

Une fois que vous êtes satisfait de votre propre fichier de valeurs, installez avec :

helm install longhorn longhorn/longhorn --namespace longhorn-system --create-namespace --values values.yaml

Si vous décidez de changer les valeurs plus tard, utilisez cette commande pour mettre à niveau :

helm upgrade longhorn longhorn/longhorn --namespace longhorn-system --values values.yaml

Une fois installé, Longhorn crée un nouveau type de classe de stockage dans votre cluster. Exécutez cette commande pour vérifier si elle est maintenant celle par défaut. Vous devriez voir une classe nommée longhorn.

kubectl get storageclass

Maintenant, vous pouvez créer un nouveau volume et vous verrez que c'est un volume Longhorn.

Ça y est, Longhorn est maintenant installé !

Si vous avez activé l'ingress, vous pouvez accéder à l'interface utilisateur via l'adresse que vous avez choisie.

Longhorn : Les Bases

Comment Migrer des Volumes vers Longhorn

Une fois installé, tout nouveau volume sera un volume Longhorn. Cependant, les anciens volumes ne changeront pas et devront être migrés.

Voici une procédure pour effectuer cette migration correctement :

N'oubliez jamais de faire cela d'abord en production ou sur des volumes importants. Ce n'est qu'une fois la méthode validée que vous pourrez l'appliquer sur des données de production réelles si vous avez besoin de migrer.

flowchart TD
 
    %% Main Flow Subgraphs & Nodes Definition
 
    Start([Start Migration]) --> S1["1. Disable GitOps (e.g., ArgoCD) if it is responsible for that volume"]
 
    subgraph SG2 ["2. Scale Down"]
 
        direction LR
 
        S2_exp["Scale down deployments <br>to prevent volume changes"] --> S2_cmd>"`kubectl scale deployment/my-app --replicas=0 -n namespace`"]
 
    end
 
    subgraph SG3 ["3. Create PVC"]
 
        direction LR
 
        S3_exp["Create new PVC <br>using Longhorn storage class"] --> S3_cmd>"`kubectl apply -f new-pvc.yaml -n namespace`"]
 
    end
 
    subgraph SG4 ["4. Verify PVC is a longhorn PVC"]
 
        direction LR
 
        S4_exp["Verify new PVC creation"] --> S4_cmd>"`kubectl get pvc -n namespace`"]
 
    end
 
    subgraph SG5 ["5. Copy Data"]
 
        direction LR
 
        S5_exp["Copy data to new volume using <a href="https://github.com/utkuozdemir/pv-migrate">pv-migrate</a>"] --> S5_cmd>"`pv-migrate --source old-pvc --dest new-pvc`"]
 
    end
 
    S6["6. Test by deploying a test instance of the app"]
 
    S7a["8a. Delete the old PVC"]
 
    S7b["8a. Clone new PVC to old name via Longhorn UI"]
 
    subgraph SG8 ["9. Scale Up"]
 
        direction LR
 
        S8_exp["Scale up deployment <br>by re-applying manifest or manually"] --> S8_cmd>"`kubectl scale deployment/my-app --replicas=1 -n namespace`"]
 
    end
 
    Finish([Migration Complete])
 
 
 
    %% Subgraph-to-Subgraph Main Connections
 
    S1 --> SG2
 
    SG2 --> SG3
 
    SG3 --> SG4
 
    SG4 --> SG5
 
    SG5 --> S6
 
    %% Decision Path Connections
 
    S6 -- "All Good? All of the data is there?" --> S7a
 
    S7a --> S7b
 
    S7b --> SG8
 
    SG8 --> Finish
 
 
 
    %% Styling Definitions
 
    classDef action fill:#d4e6f1,stroke:#2874a6,stroke-width:2px,color:#000
 
    classDef command fill:#273746,stroke:#85929e,stroke-width:2px,color:#fff
 
    classDef decision fill:#fcf3cf,stroke:#f1c40f,stroke-width:2px,color:#000
 
    classDef terminal fill:#abebc6,stroke:#27ae60,stroke-width:2px,color:#000
 
 
 
    %% Apply Classes Safely
 
    class S1,S2_exp,S3_exp,S4_exp,S5_exp,S6,S7a,S7b,S7c_exp,S8_exp action
 
    class S2_cmd,S3_cmd,S4_cmd,S5_cmd,S7c_cmd,S8_cmd command
 
    class D1 decision
 
    class Start,Finish terminal

Si vous êtes fou comme moi, vous pouvez aussi utiliser la stratégie de copie double de korb. Elle effectue le clonage, la suppression, puis le clonage inverse en une seule commande, et saute l'étape de test. Je ne saurais trop insister sur le fait que c'est une très mauvaise idée pour des données de production réelles. (N'oubliez pas de réduire puis d'augmenter le nombre de réplikas) :

korb my-pvc --source-namespace=<namespace> --new-pvc-storage-class=longhorn --strategy=copy-twice-name

Créer Plusieurs Classes de Stockage

Tout n'a pas besoin du même niveau de haute disponibilité (HA). Certaines applications n'en ont pas du tout besoin ; d'autres nécessitent encore plus de résilience. Si c'est votre cas, vous voudrez peut-être créer plusieurs classes de stockage distinctes pour divers besoins.

Par exemple, vous pouvez créer des classes de stockage avec

• 1 réplika pour les applications qui n'ont pas besoin de HA
• 2-3 réplikas pour les applications qui ont besoin d'un certain niveau de HA
• Des réplikas sensibles aux zones (zone-aware), généralement si vous avez besoin de haute disponibilité entre les zones.

Attention, la création de classes avec trop de réplikas entraînera des pics de latence en écriture. Au-delà de 3, ce n'est pas recommandé dans la plupart des configurations.

Les zones sont des clusters physiquement isolés. Longhorn est compatible avec une topologie basée sur les zones et répartira les réplikas entre les zones si nous le lui demandons.

Par exemple, voici une nouvelle classe de stockage sensible aux zones :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-zone-aware
provisioner: driver.longhorn.io
parameters:
  # Crée 3 copies des données, bon pour un cluster à 3 zones
  numberOfReplicas: "3"
 
  # L'Anti-Affinité souple (Soft Anti-Affinity) contrôle ce qui se passe si une zone tombe en panne :
  # "enabled" : Longhorn préfère des zones différentes, mais autorise le repli sur une zone existante si l'une d'elles échoue.
  # "disabled" : Longhorn force STRICTEMENT les réplikas dans des zones différentes (le provisionnement échoue si moins de 3 zones existent).
  replicaZoneSoftAntiAffinity: "enabled"
 
  # Préfère conserver 1 réplika sur le nœud où s'exécute la charge de travail/Pod consommateur pour des lectures à faible latence
  dataLocality: "best-effort"

Ensuite, lors de la création d'un nouveau volume HA sensible aux zones, vous devez spécifier explicitement cette classe de stockage comme suit :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: zone-aware-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn-zone-aware
  resources:
    requests:
      storage: 10Gi

Longhorn : Résilience des Données et Reprise après Sinistre

Parfois, les réplikas ne suffisent pas. Ils ne peuvent pas vous sauver si tout votre cluster tombe en panne, si votre volume est corrompu ou si vous commettez des erreurs. Heureusement, Longhorn fournit quelques fonctionnalités pour nous aider dans ces moments-là, à condition que nous les ayons configurées correctement. Celles-ci sont :

Snapshots : Similaires aux commits Git mais pour les volumes, les snapshots nous permettent de restaurer un volume à un état antérieur. C'est utile pour récupérer après une corruption de données ou une erreur humaine. Ils sont stockés aux côtés des réplikas et sont donc également répliqués. Ils constituent le moyen le plus rapide de récupération si le volume concerné est encore sain.

Sauvegardes (Backups) : C'est votre dernière ligne de défense. Les sauvegardes vous permettent de récupérer des volumes complètement perdus. Elles sont utilisées pour les données de valeur, tout n'a pas besoin d'être sauvegardé. D'autant plus que la sauvegarde nécessite plus de stockage, une maintenance et des tests constants.

Les sauvegardes doivent être stockées à l'extérieur, dans un emplacement distinct de votre cluster. Vous ne voulez pas perdre vos sauvegardes au moment où vous en avez le plus besoin. Heureusement, Longhorn vous permet de vous connecter à des services comme des buckets S3 ou un serveur NFS pour stocker vos sauvegardes.

Volumes de reprise après sinistre (DR) : Ils offrent un moyen d'automatiser le processus de basculement vers un cluster de secours secondaire. Fondamentalement, vous déployez un volume DR en attente dans un cluster secondaire et il se synchronise en continu avec une sauvegarde. En cas d'incident, vous pouvez transformer ce volume DR en un volume Longhorn normal et l'utiliser immédiatement. L'objectif est de réduire le temps de récupération, aussi appelé RTO.

Sauvegarde système : Longhorn dispose également d'une fonctionnalité pour sauvegarder sa configuration et la restaurer si nécessaire. Cependant, je vous conseillerais de ne faire aucune configuration via l'interface utilisateur, mais uniquement via des manifestes Kubernetes stockés dans un dépôt Git. Dans ce cas, la sauvegarde système n'est pas très utile.

Comment Configurer les Snapshots

Les snapshots peuvent être créés manuellement, mais la meilleure approche est d'utiliser les tâches récurrentes de Longhorn (Recurring Jobs).

Au fur et à mesure que vous accumulez des snapshots, Longhorn supprimera automatiquement les plus anciens. Vous pouvez configurer cela dans la définition de la tâche et dans le values.yaml utilisé pour installer Longhorn. Cherchez simplement "snapshot" ici.

Par exemple, voici une tâche de snapshot récurrente :

apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
  name: test-job
  namespace: longhorn-system
spec:
  task: snapshot
  cron: "*/5 * * * *"
  retain: 5 # Nombre de snapshots à conserver
  concurrency: 1
 
  # Affectations de groupes (les volumes doivent être étiquetés pour correspondre à ce groupe)
  groups:
    - snapped-volumes

Après l'avoir appliqué, vous devriez le trouver dans l'interface utilisateur, dans l'onglet des tâches récurrentes :

Pour lier les volumes à ces tâches, vous pouvez ajouter des étiquettes à la définition de votre PVC directement dans le manifeste. Je recommanderais cette approche pour vous assurer que cette information est encodée et commitée.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
  namespace: default
  labels:
    # 1. Active la synchronisation entre le PVC et le volume Longhorn
    recurring-job.longhorn.io/source: "enabled"
 
    # 2. Assigne ce PVC au groupe "snapped-volumes"
    recurring-job-group.longhorn.io/snapped-volumes: "enabled"
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 20Gi

Ou si nécessaire, vous pouvez étiqueter manuellement un PVC existant comme ceci :

kubectl label pvc my-pvc -n <namespace> recurring-job.longhorn.io/source=enabled
kubectl label pvc my-pvc -n <namespace> recurring-job-group.longhorn.io/snapped-volumes=enabled

Comment Configurer les Sauvegardes

Les sauvegardes sont définies lors de l'installation dans le fichier values.yaml, en utilisant le paramètre defaultBackupStore comme ceci :

defaultSettings:
  defaultReplicaCount: 2
persistence:
  defaultClassReplicaCount: 2
  defaultDataLocality: "best-effort"
ingress:
  enabled: true
  host: longhorn.home.arpa
  tls: false
defaultBackupStore:
  backupTarget: s3://longhorn-backups@garage/
  backupTargetCredentialSecret: longhorn-backup-store

Vous devez également définir un secret pour spécifier les clés d'accès et le point de terminaison comme ceci :

apiVersion: v1
kind: Secret
metadata:
  name: longhorn-backups-secret
  namespace: longhorn-system
type: Opaque
stringData:
  AWS_ACCESS_KEY_ID: "xxx"
  AWS_SECRET_ACCESS_KEY: "xxx"
  AWS_ENDPOINTS: "https://<Some https endpoint>"

Vous pouvez ensuite mettre à niveau votre installation Longhorn et la redémarrer pour que les changements s'appliquent.

helm upgrade longhorn longhorn/longhorn --namespace longhorn-system --values values.yaml
kubectl rollout restart daemonset longhorn-manager -n longhorn-system
kubectl rollout status daemonset longhorn-manager -n longhorn-system

Vous devriez alors voir la sauvegarde configurée dans l'interface utilisateur :

De manière similaire aux snapshots, vous pouvez créer une tâche de sauvegarde comme ceci, puis étiqueter les volumes qui doivent être sauvegardés :

apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
  name: daily-backup-job
  namespace: longhorn-system
spec:
  name: daily-backup-job
  task: "backup"
  cron: "0 0 * * *"
  retain: 3
  concurrency: 1
  groups:
    - backed-volumes

Si vous avez besoin d'utiliser une sauvegarde :

1. Allez dans l'interface utilisateur de Longhorn
2. Sélectionnez un volume
3. Sélectionnez 'Restaurer la dernière sauvegarde'
   

Vous pouvez décider de conserver le nom précédent, ce qui écrasera le volume existant. Ne le faites que si vous êtes sûr que vos sauvegardes sont saines ou si le volume existant est déjà perdu. Pour le reste, cela dépend, vous devriez correspondre autant que possible au volume existant, sauf si vous avez une raison.

Les tests de sauvegarde doivent être effectués fréquemment. Une sauvegarde qui n'est utilisée qu'en temps de crise est susceptible d'échouer. Des tests réguliers garantissent que vous avez confiance en vos sauvegardes et que vous connaissez le processus de restauration. Cela peut être automatisé dans une certaine mesure. Cependant, pour les données importantes, il est important de rester impliqué.

Comment Longhorn se Comporte à la Panne d'un Nœud

Lorsqu'un nœud plante brutalement, une condition de concurrence se produit entre la replanification des pods par Kubernetes et le cycle de vie des réplikas Longhorn, ce qui peut bloquer les pods à l'état ContainerCreating. Laissez-moi vous expliquer.

Par défaut, Kubernetes attend 5 minutes avant de tenter d'expulser le pod du nœud défaillant. De plus, Kubernetes ne supprime jamais automatiquement les pods de StatefulSet sur les nœuds en panne. Ils restent indéfiniment à l'état Terminating à moins d'être supprimés manuellement.

Ce délai est un choix de conception délibéré dicté par le théorème CAP. Comme Kubernetes ne peut pas faire la distinction entre un nœud mort et un nœud isolé par une partition réseau (qui pourrait encore écrire des données non synchronisées sur le disque), Longhorn refuse de libérer le verrou du volume prématurément. Il choisit l'Intégrité des Données pour empêcher complètement la corruption des données de type split-brain.

Vous pouvez accélérer ce processus en

1. Définissant tolerationSeconds: 30 sur vos charges de travail. Cela signifie un temps de réaction plus rapide mais aussi plus de risques que K8s réagisse trop vite à une fausse alerte.
2. Activant la politique node-down-pod-deletion-policy de Longhorn Ou en supprimant manuellement le pod bloqué avec

kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0

Ceci est sûr si remettre votre application en ligne rapidement est plus important pour vous que le risque de perdre quelques secondes de données récentes. Ou si le nœud est vraiment mort et non pas simplement isolé par le réseau.

Autres Fonctionnalités de Longhorn

Le Moteur et Pourquoi Vous ne Devriez Pas le Changer

Par défaut, Longhorn utilise la version 1 pour tous les moteurs de volume qu'il déploie. Cependant, une version 2 est disponible. Elle est plus rapide mais aussi plus lourde et encore expérimentale au moment de la rédaction de cet article. Vous pouvez en lire plus à ce sujet ici.

D'après les discussions des utilisateurs, la conclusion est que vous devriez probablement éviter la V2, du moins en production. La V1 est suffisante pour la plupart des cas d'usage.

Volumes Attachés vs Détachés

Un concept important de Longhorn est de savoir si les volumes sont attachés (attached) ou détachés (detached).

Un volume est attaché à un nœud lorsqu'il est en cours d'utilisation. Cela signifie qu'un moteur a été créé sur ce nœud et que les pods sont autorisés à l'utiliser. Lorsqu'un volume est détaché, il n'est pas supprimé mais mis dans un état désactivé. Le moteur est arrêté et les réplikas passent en état de repos.

En général, Kubernetes gère l'attachement/détachement, mais vous pouvez attacher ou détacher manuellement des volumes pour de multiples raisons. Par exemple, il est préférable de cloner des volumes détachés pour éviter les écritures actives pendant le processus. D'autres cas d'usage incluent la réparation de volumes bloqués ou le débogage.

Anti-Affinité et Localité des Réplikas

Nous avons déjà mentionné le concept d'Anti-Affinité au niveau de la zone, et Longhorn ne s'arrête pas là. Vous pouvez définir une Anti-Affinité de zone, de nœud et de disque. Par exemple, vous pourriez autoriser plusieurs réplikas sur le même nœud mais pas sur le même disque de ce nœud. Elle est toujours configurée soit en mode souple (soft/best-effort) soit en mode strict (hard).

Un concept similaire est la localité des données (data locality), qui est un autre paramètre de Longhorn. Lorsqu'elle est activée, Longhorn essaiera de conserver au moins un réplika sur le même nœud que les pods attachés. Par défaut, elle est désactivée mais peut être réglée sur best-effort ou strict-local. Notez que le mode strict-local n'est pris en charge que pour les volumes avec un seul réplika.

Image de Base (Backing Image)

L'image de base (Backing Image) fournit une image disque pré-remplie ; c'est comme une image de base Docker. C'est idéal pour démarrer rapidement des machines virtuelles, des données de pré-production ou des jeux de données de ML. De plus, chaque volume n'a besoin de stocker que ses propres modifications. Cela permet d'économiser de la bande passante et de la capacité de stockage.

Observabilité et Alertes

Longhorn peut être connecté à Prometheus pour produire diverses métriques, vous aidant à gérer votre stockage et à créer des alertes.