Présentation de NFS à plusieurs projets

Question

J'ai un montage NFS contenant des éléments multimédias en lecture seule que je souhaite présenter à plusieurs projets. Créer un nouveau PV dans chaque projet avec le même chemin NFS semble trop maladroit. Que se passerait-il si d'autres PVC réclamaient mon répertoire d'actifs par accident?

À part cela, je n'ai aucune idée de comment faire cela. Comment puis-je accomplir cela?

Modifier: Pour être clair - Je veux éviter l'intervention de l'administration de cluster. Les droits d'administrateur de cluster sont requis lors de la création d'un PV.

PV CONFIG

apiVersion: v1 
kind: PersistentVolume 
metadata: 
    annotations: 
    pv.kubernetes.io/bound-by-controller: "yes" 
    creationTimestamp: null 
    labels: 
    app: my_app 
    name: my-assets 
spec: 
    accessModes: 
    - ReadWriteMany 
    capacity: 
    storage: 25Gi 
    claimRef: 
    apiVersion: v1 
    kind: PersistentVolumeClaim 
    name: my-assets 
    namespace: my_namespace 
    resourceVersion: "13480134" 
    uid: ea36d352-1a22-11e7-a443-0050568b4a96 
    nfs: 
    path: /nfs_volume 
    server: nfs_server 
    persistentVolumeReclaimPolicy: Recycle 
status: {} 

ESV à partir des espaces de noms autres que my_namespace ne peut prétendre contre cette pv. Voici une config PVC d'un espace de noms différent qui est incapable de réclamer contre le PV existant avec ReadWriteMany.

apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
    annotations: 
    openshift.io/generated-by: OpenShiftNewApp 
    creationTimestamp: null 
    name: my-assets 
spec: 
    accessModes: 
    - ReadWriteMany 
    resources: 
    requests: 
     storage: 25Gi 
    selector: 
    matchLabels: 
     app: my_app 
    volumeName: my-assets 
status: {} 

Answer 1

Je ne sais pas ce que vous entendez par le projet, mais si vous faites référence à Deployments des applications différentes, il devrait fonctionner avec une seule définition PV pour un NFS qui a le type ReadWriteMany. Cependant, je recommande de toujours inclure une définition PV et PVC par déploiement qui nécessite un accès au NFS. De cette façon, il est explicite à partir du déploiement et vous pouvez le modifier pour chaque application séparément. Imaginez que vous voulez le changer pour une application mais pas l'autre.

Voici un exemple que j'utilise pour un montage EFS NFS d'Amazon sur tous les POD de mon déploiement CockroachDB pour l'écriture de sauvegardes. Je l'ai divisé en 2 yamls mais vous pouvez aussi les réduire en un seul fichier. Notez que vous pouvez utiliser le même PersistentVolumeClaim pour tous les POD.

1 cockroachdbPV.yaml

apiVersion: v1 
kind: PersistentVolume 
metadata: 
    name: cockroachdbpv 
spec: 
    capacity: 
    storage: 100Gi 
    accessModes: 
    - ReadWriteMany 
    nfs: 
    server: {amazon path here} 
    path: "/" 
--- 
apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
    name: cockroachdbpv 
spec: 
    accessModes: 
    - "ReadWriteMany" 
    resources: 
    requests: 
     storage: 10Gi 

2 cockroachdb.yaml

apiVersion: apps/v1beta1 
kind: StatefulSet 
metadata: 
    name: cockroachdb 
spec: 
    serviceName: "cockroachdb" 
    replicas: 3 
    template: 
    metadata: 
     labels: 
     app: cockroachdb 
     annotations: 
     {...}   
    spec: 
     containers: 
     - name: cockroachdb 
     {...} 
     volumes: 
     {...} 
     - name: efsdir 
      persistentVolumeClaim: 
      claimName: cockroachdbpv 

Answer 2

Vous avez juste besoin de la liste ReadWriteMany comme access mode dans la définition PV et CVP ainsi.

Il est un exemple ici: https://github.com/kubernetes/kubernetes/tree/master/examples/volumes/nfs