web-dev-qa-db-fra.com

Partage des revendications de volume persistant entre les conteneurs de Kubernetes/OpenShift

C'est peut-être une question idiote, mais je n'ai pas trouvé grand chose en ligne et je veux clarifier ceci. 

Étant donné deux déploiements A et B, tous deux avec différents images de conteneur:

  • Ils sont déployés dans deux pods différents (différents rc, svc, etc.) dans un cluster K8/OpenShift.
  • Ils doivent tous les deux accéder au même volume pour lire les fichiers (restons verrouillés pour l'instant) ou au moins à la même structure de répertoires dans ce volume.
  • Montage de ce volume à l'aide d'un PVC (réclamation de volume persistant) soutenu par un PV (volume persistant) configuré sur un partage NFS.

Puis-je confirmer que ce qui précède serait réellement possible? C'est à dire. deux différents pods connectés au même volume avec le même PVC. Ils lisent donc tous les deux dans le même volume.

J'espère que ça a du sens ...

openshiftkubernetes
12
Donovan Muller

TL; DR Vous pouvez partager des PV et des PVC dans le même projet/espace de noms pour des volumes partagés (nfs, gluster, etc.), vous pouvez également accéder à votre volume partagé à partir de plusieurs projets/espaces de noms, mais cela nécessitera un projet dédié. PV et PVC, en tant que PV est lié à un seul projet/espace de noms et que PVC est une étendue projet/nom.

Ci-dessous, j'ai essayé d'illustrer le comportement actuel et la manière dont les PV et les PVC sont définis dans OpenShift. Ce sont des exemples simples utilisant NFS comme couche de stockage persistant.

les modes d'accès à ce stade ne sont que des étiquettes, ils n'ont aucune fonctionnalité réelle en termes de contrôle d'accès à la PV. Ci-dessous quelques exemples pour montrer ceci

le PV est global en ce sens qu'il peut être vu/accédé par n'importe quel projet/espace de noms, TOUJOURS une fois qu'il est lié à un projet, il ne peut être accédé que par des conteneurs du même projet/espace de noms.

le PVC est spécifique au projet/à l'espace de noms (donc, si vous avez plusieurs projets, vous aurez besoin d'un nouveau PV et d'un nouveau PVC pour que chaque projet se connecte au volume NFS partagé - vous ne pouvez pas réutiliser le PV du premier projet).

Exemple 1:
J'ai 2 pods distincts fonctionnant dans le projet/espace de nom "par défaut", les deux accédant au même partage exporté PV et NFS. Les deux montent et courent bien.

[root@k8dev nfs_error]# oc get pv
NAME      LABELS    CAPACITY   ACCESSMODES   STATUS    CLAIM  REASON    AGE
pv-nfs    <none>    1Gi        RWO           Bound default/nfs-claim             3m


[root@k8dev nfs_error]# oc get pods    <--- running from DEFAULT project, no issues connecting to PV
NAME              READY     STATUS    RESTARTS   AGE
nfs-bb-pod2-pvc   1/1       Running   0          11m
nfs-bb-pod3-pvc   1/1       Running   0          10m

Exemple 2:
J'ai deux pods distincts s'exécutant dans un projet/espace de nom "par défaut" et j'essaie de créer un autre pod utilisant le même PV, mais à partir d'un nouveau projet appelé testproject pour accéder au même export NFS. Le troisième module de la nouvelle testproject ne pourra pas se lier au PV car il est déjà lié par le projet default.

[root@k8dev nfs_error]# oc get pv
NAME      LABELS    CAPACITY   ACCESSMODES   STATUS    CLAIM  REASON    AGE
pv-nfs    <none>    1Gi        RWO           Bound default/nfs-claim             3m


[root@k8dev nfs_error]# oc get pods    <--- running from DEFAULT project, no issues connecting to PV
NAME              READY     STATUS    RESTARTS   AGE
nfs-bb-pod2-pvc   1/1       Running   0          11m
nfs-bb-pod3-pvc   1/1       Running   0          10m

** Créez une nouvelle revendication contre le PV existant d'un autre projet (testproject) et le PVC échouera.

[root@k8dev nfs_error]# oc get pvc 
NAME        LABELS    STATUS    VOLUME    CAPACITY   ACCESSMODES   AGE
nfs-claim   <none>    Pending                                      2s

** nfs-claim ne sera jamais lié au PV pv-nfs car il ne peut pas le voir depuis la portée actuelle du projet

Exemple 3:

J'ai 2 pods distincts en cours d'exécution dans le projet "par défaut", puis je crée un autre PV et PVC et un pod à partir de testproject. Les deux projets pourront accéder au même partage NFS exporté mais j'ai besoin d'un PV et d'un PVC dans chacun des projets. 

[root@k8dev nfs_error]# oc get pv
NAME      LABELS    CAPACITY   ACCESSMODES   STATUS     CLAIM                    REASON    AGE
pv-nfs    <none>    1Gi        RWX           Bound     default/nfs-claim                  14m
pv-nfs2   <none>    1Gi        RWX           Bound     testproject/nfs-claim2             9m



[root@k8dev nfs_error]# oc get pods --all-namespaces
NAMESPACE     NAME              READY     STATUS    RESTARTS   AGE
default       nfs-bb-pod2-pvc   1/1       Running   0          11m
default       nfs-bb-pod3-pvc   1/1       Running   0          11m
testproject   nfs-bb-pod4-pvc   1/1       Running   0          15s

** remarque, j'ai maintenant trois pods fonctionnant sur le même volume partagé NFS sur deux projets, mais j'avais besoin de deux PV car ils sont liés à un seul projet et de 2 PVC, un pour chaque projet et le PV NFS que j'essaie d'utiliser. accès

Exemple 4:

Si je contourne PV et PVC, je peux me connecter directement aux volumes NFS partagés à partir de n’importe quel projet à l’aide du plugin nfs.

volumes:
- name: nfsvol
  nfs:
    path: /opt/data5
    server: nfs1.rhs

Maintenant, la sécurité des volumes est une autre couche au-dessus de cela. En utilisant supplementalGroups (pour le stockage partagé, par exemple, nfs, gluster, etc.), les administrateurs et les développeurs doivent également être en mesure de gérer et de contrôler l’accès au système NFS partagé.

J'espère que cela pourra aider

16
screeley

Autant que je sache, la liaison d'un PV plusieurs fois n'est pas prise en charge. Vous pouvez utiliser la source de volume (NFS dans votre cas) directement pour votre cas d'utilisation.

0
Huamin