Sommaire

Accès en lecture-écriture multiple Accès:en lecture-écriture multiple

1. Origine du besoin

Les classes de stockage définies par défaut dans un service managé sont généralement de type ReadWriteOnce : un seul pod à la fois peut écrire dans les volumes persistants. Dans la plupart des cas (base de données, middleware de messagerie), c’est un comportement attendu et souhaitable. ReadWriteOnce

En revanche, pour partager des fichiers entre plusieurs pods (pour mettre en place un espace commun comme par exemple des ressources statiques), il devient nécessaire de disposer de volumes persistants de type ReadWriteMany. ReadWriteMany

Le service Azure propose un service natif pour mettre à disposition ce type de volume. Ces caractéristiques sont présentées un peu plus loin dans le chapitre.

Par défaut, les services disque d’AWS et de Google n’offrent pas cette capacité. Heureusement, il est possible de contourner le problème de deux façons :

  • à l’aide de services managés (EFS pour Amazon et Filestore pour Google), EFS Filestore

  • en faisant appel à un serveur NFS (qu’il soit déployé dans Kubernetes ou géré en dehors du cluster). Serveur NFS

Les deux techniques seront abordées. En revanche, dans le cas du déploiement d’un serveur NFS externe à Kubernetes, sa mise en place sera à votre charge.

2. Serveur NFS déployé ...