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 d’un serveur NFS externe au cluster : EFS pour Amazon, Filestore pour Google ou serveur dédié type NetApp. EFS (Elastic File System) Filestore
-
À l’aide d’un serveur déployé dans Kubernetes.
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é...
Pour consulter la suite, découvrez le livre suivant :
En version papier
En version numérique
En illimité avec l'abonnement ENI
Sur la boutique officielle ENI
Conditions générales d'utilisationCopyright - © Editions ENI ||Politique de protection des données du groupe ENI