Optimiser le stockage Kubernetes on-premise : de NFS à iSCSI sur SAN TrueNAS

Sous le capot du cloud #5

Dans les épisodes précédents, nous avons posé les bases : pourquoi Kubernetes est devenu notre socle d’hébergement, comment nous concevons la HA on-prem, sur quelle couche d’hyperviseur nous industrialisons, et comment nous observons plusieurs clusters sans que l’observabilité devienne elle-même un risque.

Logiquement, l’étape suivante c’est le stockage : parce qu’en production, ce n’est pas “juste un PV”, c’est la différence entre un cluster qui tient ses SLA… et un cluster qui se met à “ramer” au pire moment.

I. Le point de départ : “on fait simple” (NFS)

On a tous connu ce réflexe : un export NFS, une StorageClass (ou un provisionneur), et on avance. En lab, ça fonctionne. En démo, ça passe. Et pour des workloads stateless… ça suffit souvent.

Sauf que notre réalité a vite rattrapé cette simplicité : dès qu’on met une base de données sous pression, le stockage devient un composant actif de la performance applicative.

Symptôme : sur certaines lectures, on observait des latences délirantes, avec des requêtes qui pouvaient prendre 30–40 secondes via NFS, là où le même chemin de lecture descendait sous la seconde après migration iSCSI (à architecture applicative équivalente).

NFS (Network File System) est un mécanisme de stockage de fichiers sur un réseau. Il s’agit d’un système de fichiers distribué qui permet aux utilisateurs d’accéder aux fichiers et répertoires situés sur des ordinateurs distants et de traiter ces fichiers et répertoires comme s’ils étaient locaux — IBM

II. Ce que l’on attend vraiment du stockage Kubernetes

Quand on exploite Kubernetes, on finit par vouloir retrouver une propriété des cloud providers :

• un volume qui s’attache au bon endroit,
• qui survit à la perte d’un nœud,
• et qui permet de segmenter les usages (base de données ≠ logs ≠ fichiers partagés).

Kubernetes formalise très bien ce contrat via PV/PVC et StorageClass. Mais Kubernetes ne “crée” pas de performance : il orchestre une implémentation de stockage.

Schéma illustrant simplement le role d’un PV/PVC

Donc la vraie question est devenue : quel backend on-prem nous permet de servir des workloads stateful (DB) sans exploser la latence, tout en restant opérable ?

III. Le constat : NFS et base de données, le mariage compliqué

Sans rentrer dans une guerre de religion, notre retour d’expérience est simple :

• NFS est très pratique pour partager des fichiers,
• mais sur des IO patterns de base de données (petites lectures/écritures, latence perçue, fsync, etc.), la latence devient vite un mur, et ce mur n’est pas “corrigeable” uniquement côté Kubernetes.

On ne va pas théoriser plus que nécessaire : on a surtout retenu une règle d’exploitation :

Quand le stockage devient le bottleneck, on change la nature du stockage (bloc vs fichier), avant d’empiler des contournements.

IV. Notre cible : SAN TrueNAS (iSCSI) + Longhorn

4.1 — La brique “SAN” : TrueNAS SCALE + iSCSI

Nous sommes sur TrueNAS SCALE, avec un pool classique (pas d’optimisation extrême type finance/HFT). Le SAN expose des volumes bloc en iSCSI, et surtout : le trafic iSCSI passe sur un VLAN dédié en 10Gb (câble SFP+ pour ceux qui se posent la question).

Côté TrueNAS, la logique iSCSI est structurée autour des éléments “portals / initiators / targets / extents” (via le wizard de l’UI).

Schéma de la doc officielle de TrueNas expliquant simplement le protocol iSCSI

4.2 — La brique “Kubernetes” : Longhorn comme plan de contrôle des volumes

Nous voulions conserver l’expérience Kubernetes (PVC, StorageClass), mais gagner :

• l’attachement/détachement propre,
• la réplication,
• les snapshots,
• et une stratégie de sauvegarde.

Longhorn fait exactement ce travail : il crée un contrôleur (engine) par volume et réplique de manière synchrone vers plusieurs réplicas répartis sur les nœuds. Il gère aussi les sauvegardes vers un stockage secondaire NFS ou S3-compatible.

Read/write Data Flow between the Volume, Longhorn Engine, Replica Instances, and Disks — Doc officielle de Longhorn

V. Deux StorageClass : “standard” et “rapide”

5.1 — Standard : réplication 3

Pour les PVC “classiques”, nous utilisons une réplication 3.

Pourquoi : c’est un bon compromis disponibilité/résilience/opérations. Si un nœud disparaît, Longhorn reconstruit et la plateforme reste cohérente (c’est exactement le genre de mécanisme qu’on recherche dans une architecture HA).

5.2 — Rapide (BDD) : 1 replica local au Pod (best-effort)

Pour les PVC qui doivent lire très vite (typiquement BDD), nous cherchons à maintenir un replica sur le même nœud que le Pod, afin d’éviter une lecture “à travers le réseau” quand c’est possible.

C’est précisément l’objet de la data locality. En mode best-effort, Longhorn tente de conserver un replica local, sans bloquer le volume si la contrainte ne peut pas être respectée.

Note : il existe aussi strict-local, plus radical, avec des contraintes (notamment incompatibilités selon les modes/volumes).

VI. Format de fichiers et détail “sans sur-ingénierie”

• Filesystem : ext4 (de mémoire, côté nœuds/volumes).
• Anti-affinity : activée quand plusieurs replicas — et dans beaucoup de setups, c’est “par défaut” dans le sens où la plateforme pousse naturellement à répartir pour survivre à la perte d’un nœud (et sinon, il faut le forcer).

On garde volontairement cette partie sobre : notre enjeu n’était pas de faire une thèse sur le tuning, mais de rendre la plateforme prévisible et exploitable.

VII. Sauvegarde & reprise : Longhorn → S3 + socle TrueNAS

Nous avons :

• des backups Longhorn vers un S3 (stockage secondaire), ce qui donne un plan de reprise “cluster down” (on restaure ailleurs).
• et côté TrueNAS, une protection par RAID sur les disques du pool (protection matérielle du socle).

RPO

Avec notre réseau (VLAN/10Gb) et notre organisation, nous avons un RPO < 5 minutes si un PVC doit être remonté (selon le scénario).

IX. Conclusion & suite

Passer d’un stockage NFS “simple” en lab à une chaîne SAN TrueNAS (iSCSI) + Longhorn nous a permis de franchir un cap très concret : retrouver un stockage prédictible pour nos workloads stateful, sans perdre l’expérience Kubernetes (PVC/StorageClass).

Concrètement, ce changement nous a apporté :

• un gain massif de latence perçue sur les charges sensibles (notamment base de données) ;
• une séparation claire des rôles : TrueNAS comme socle SAN iSCSI, Longhorn comme plan de contrôle “cloud-like” (réplication synchrone, orchestration des volumes).
• deux classes de stockage orientées usages : une classe “standard” répliquée, et une classe “rapide” où Longhorn tente de garder une réplique au plus près du pod via la data locality best-effort.
• une reprise mieux maîtrisée grâce aux backups Longhorn vers S3 (en complément des mécanismes de protection côté SAN).

Comme pour le reste de notre cloud interne, l’objectif n’était pas d’empiler des briques “à la mode”, mais de construire une plateforme opérable : stable, restaurable, et lisible.

Et ensuite ?

Dans la suite de Sous le capot du Cloud, on change de couche : Sécuriser nos clusters Kubernetes on-premise : best practices RBAC et accès d’administration, segmentation réseau, durcissement des workloads, et sécurité de la supply chain. On garde le cap, et on continue d’ouvrir le capot…