Home PV, PVC, Volumes NFS, même ça c'est compliqué
Post
Cancel

PV, PVC, Volumes NFS, même ça c'est compliqué

Oyé les gens

Je travaille beaucoup autour de K3S et Rancher RKE en ce moment (j’aime beaucoup l’approche de Rancher d’ailleurs) et mon voyage Kube vient de me conduire vers les affaires de gestion du stockage, PersistentVolumes, PVC et consort.

Pour le coup, je voulais vous partager une découverte, ou plutôt une nouvelle “compréhension” autour du provisionnent du stockage via NFS en particulier. J’était bloqué depuis quelques jours sur le fonctionnement du stockage à travers Kube. Depuis le début je pensais que les PersistentVolumes de type NFS étaient gérés comme les stockages passant par des CSI qu’on trouve chez beaucoup de cloud providers : Tu définie un PersistentVolume et tu utilises une StorageClass particulière associée, et enfin tu “consomme” via des PersistentStorageClaim 10 Go, 50 Go ou 20Go en fonction de tes besoins lorsque tu veux déployer tes applications.

Euréka

Ce que je viens de comprendre c’est d’abord qu’on peut préparer un PersistentVolume via NFS sans avoir à indiquer de StorageClass, mais qu’en plus, quand on définit un PersistentVolume de type NFS, le premier Pod ou Deployment qui fait un « Claim » sur ce volume le réserve directement pour son usage exclusif !! J’était auparavant persuadé qu’on pouvait faire plusieurs « Claim » sur un seul PersistentVolume NFS, tant que le « montant du stockage » réservé n’était pas atteint.

Certains vont me prendre pour un noob, évidemment, mais il n’empêche que c’est tout sauf trivial. Sur NFS, si vous faites un PersistentVolumeClaim sur un volume de type NFS, c’est terminé, impossible de le consommer de nouveau, même en respectant les contraintes de volume…

Attention à NFS, il ne fonctionne pas comme les CSI cloud

Découvrir cela à vraiment débloqué quelque chose chez moi car je ne comprenais pas pourquoi mes divers Deployments tombaient en pending et mes pods en erreur dès le deuxième « Claim ». Evidemment, il y avait toujours pas mal de conséquences notamment avec certains Operators ou certaines applications complexes …

Au final, ce n’est pas forcément le comportement “naturel” qu’on peut attendre d’un share NFS mis à dispo de plusieurs applications/pods, si on se réfère au comportement historique des volumes file dans les productions classique.

Donc, si vous êtes confrontés, comme moi à ce genre de comportement : pensez à créer un PersistentVolume UNIQUE par application, voire par Claim, quand vous utilisez le NFS ^^

Prosper

This post is licensed under CC BY 4.0 by the author.