Rechercher

4.9. Stockage persistant à l'aide de NFS

download PDF

Les clusters OpenShift Container Platform peuvent être dotés d'un stockage persistant à l'aide de NFS. Les volumes persistants (PV) et les réclamations de volumes persistants (PVC) constituent une méthode pratique pour partager un volume au sein d'un projet. Bien que les informations spécifiques à NFS contenues dans une définition de PV puissent également être définies directement dans une définition Pod, cela ne crée pas le volume en tant que ressource de cluster distincte, ce qui rend le volume plus susceptible d'être conflictuel.

Ressources supplémentaires

4.9.1. Provisionnement

Le stockage doit exister dans l'infrastructure sous-jacente avant de pouvoir être monté en tant que volume dans OpenShift Container Platform. Pour provisionner des volumes NFS, il suffit de disposer d'une liste de serveurs NFS et de chemins d'exportation.

Procédure

  1. Créer une définition d'objet pour le PV :

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: pv0001 1
    spec:
      capacity:
        storage: 5Gi 2
      accessModes:
      - ReadWriteOnce 3
      nfs: 4
        path: /tmp 5
        server: 172.17.0.2 6
      persistentVolumeReclaimPolicy: Retain 7
    1
    Le nom du volume. Il s'agit de l'identité du PV dans diverses commandes oc <command> pod.
    2
    La quantité de stockage allouée à ce volume.
    3
    Bien que cela semble être lié au contrôle de l'accès au volume, il est en fait utilisé de manière similaire aux étiquettes et utilisé pour faire correspondre un PVC à un PV. Actuellement, aucune règle d'accès n'est appliquée sur la base de accessModes.
    4
    Le type de volume utilisé, dans ce cas le plugin nfs.
    5
    Chemin exporté par le serveur NFS.
    6
    Le nom d'hôte ou l'adresse IP du serveur NFS.
    7
    La politique de récupération pour le PV. Elle définit ce qu'il advient d'un volume lorsqu'il est libéré.
    Note

    Chaque volume NFS doit pouvoir être monté par tous les nœuds programmables du cluster.

  2. Vérifier que le PV a été créé :

    $ oc get pv

    Exemple de sortie

    NAME     LABELS    CAPACITY     ACCESSMODES   STATUS      CLAIM  REASON    AGE
    pv0001   <none>    5Gi          RWO           Available                    31s

  3. Créez une revendication de volume persistant liée au nouveau PV :

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: nfs-claim1
    spec:
      accessModes:
        - ReadWriteOnce 1
      resources:
        requests:
          storage: 5Gi 2
      volumeName: pv0001
      storageClassName: ""
    1
    Les modes d'accès n'appliquent pas la sécurité, mais servent plutôt d'étiquettes pour faire correspondre un PV à un PVC.
    2
    Cette demande concerne les systèmes photovoltaïques offrant une capacité égale ou supérieure à 5Gi.
  4. Vérifiez que la revendication de volume persistant a été créée :

    $ oc get pvc

    Exemple de sortie

    NAME         STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    nfs-claim1   Bound    pv0001   5Gi        RWO                           2m

4.9.2. Appliquer les quotas de disque

Vous pouvez utiliser des partitions de disque pour appliquer des quotas de disque et des contraintes de taille. Chaque partition peut constituer sa propre exportation. Chaque exportation est un PV. OpenShift Container Platform impose des noms uniques pour les PV, mais l'unicité du serveur et du chemin du volume NFS est laissée à l'appréciation de l'administrateur.

L'application de quotas de cette manière permet au développeur de demander un stockage persistant d'un montant spécifique, par exemple 10Gi, et d'obtenir un volume correspondant d'une capacité égale ou supérieure.

4.9.3. Sécurité des volumes NFS

Cette section traite de la sécurité des volumes NFS, notamment des permissions correspondantes et des considérations SELinux. L'utilisateur est censé comprendre les bases des autorisations POSIX, des UID de processus, des groupes supplémentaires et de SELinux.

Les développeurs demandent un stockage NFS en référençant soit un PVC par son nom, soit le plugin de volume NFS directement dans la section volumes de leur définition Pod.

Le fichier /etc/exports du serveur NFS contient les répertoires NFS accessibles. Le répertoire NFS cible possède des identifiants POSIX de propriétaire et de groupe. Le plugin NFS d'OpenShift Container Platform monte le répertoire NFS du conteneur avec la même propriété et les mêmes autorisations POSIX que celles trouvées sur le répertoire NFS exporté. Cependant, le conteneur n'est pas exécuté avec son UID effectif égal au propriétaire du montage NFS, ce qui est le comportement souhaité.

Par exemple, si le répertoire NFS cible apparaît sur le serveur NFS sous la forme suivante :

$ ls -lZ /opt/nfs -d

Exemple de sortie

drwxrws---. nfsnobody 5555 unconfined_u:object_r:usr_t:s0   /opt/nfs

$ id nfsnobody

Exemple de sortie

uid=65534(nfsnobody) gid=65534(nfsnobody) groups=65534(nfsnobody)

Le conteneur doit alors correspondre aux étiquettes SELinux et fonctionner avec un UID de 65534, le propriétaire de nfsnobody, ou avec 5555 dans ses groupes supplémentaires pour accéder au répertoire.

Note

L'ID propriétaire de 65534 est utilisé comme exemple. Même si root_squash de NFS fait correspondre root, uid 0, à nfsnobody, uid 65534, les exportations NFS peuvent avoir des identifiants de propriétaire arbitraires. Le propriétaire 65534 n'est pas nécessaire pour les exportations NFS.

4.9.3.1. ID des groupes

La manière recommandée de gérer l'accès NFS, en supposant qu'il n'est pas possible de modifier les permissions sur l'exportation NFS, est d'utiliser des groupes supplémentaires. Les groupes supplémentaires dans OpenShift Container Platform sont utilisés pour le stockage partagé, dont NFS est un exemple. En revanche, le stockage en bloc tel que l'iSCSI utilise la stratégie SCC fsGroup et la valeur fsGroup dans le securityContext du pod.

Note

Pour accéder au stockage permanent, il est généralement préférable d'utiliser des identifiants de groupe supplémentaires plutôt que des identifiants d'utilisateur.

Comme l'ID de groupe du répertoire NFS cible de l'exemple est 5555, le module peut définir cet ID de groupe en utilisant supplementalGroups sous la définition securityContext du module. Par exemple :

spec:
  containers:
    - name:
    ...
  securityContext: 1
    supplementalGroups: [5555] 2
1
securityContext doit être définie au niveau du pod, et non pas dans le cadre d'un conteneur spécifique.
2
Un tableau de GIDs définis pour le pod. Dans ce cas, il n'y a qu'un seul élément dans le tableau. Les GID supplémentaires sont séparés par des virgules.

En supposant qu'il n'y ait pas de SCC personnalisé qui puisse satisfaire les exigences du pod, le pod correspond probablement au SCC restricted. Ce SCC a la stratégie supplementalGroups définie sur RunAsAny, ce qui signifie que tout identifiant de groupe fourni est accepté sans vérification de plage.

En conséquence, le pod ci-dessus passe les admissions et est lancé. Cependant, si le contrôle de la plage d'ID de groupe est souhaité, un SCC personnalisé est la solution préférée. Un SCC personnalisé peut être créé de manière à ce que des identifiants de groupe minimum et maximum soient définis, que le contrôle de la plage d'identifiants de groupe soit appliqué et qu'un identifiant de groupe de 5555 soit autorisé.

Note

Pour utiliser un SCC personnalisé, vous devez d'abord l'ajouter au compte de service approprié. Par exemple, utilisez le compte de service default dans le projet donné, à moins qu'un autre compte n'ait été spécifié dans la spécification Pod.

4.9.3.2. ID d'utilisateur

Les ID utilisateurs peuvent être définis dans l'image du conteneur ou dans la définition du site Pod.

Note

Il est généralement préférable d'utiliser des identifiants de groupe supplémentaires pour accéder au stockage permanent plutôt que des identifiants d'utilisateur.

Dans l'exemple de répertoire NFS cible présenté ci-dessus, le conteneur doit avoir pour UID 65534, en ignorant les ID de groupe pour le moment, ce qui permet d'ajouter ce qui suit à la définition de Pod:

spec:
  containers: 1
  - name:
  ...
    securityContext:
      runAsUser: 65534 2
1
Les pods contiennent une définition securityContext spécifique à chaque conteneur et une définition securityContext qui s'applique à tous les conteneurs définis dans le pod.
2
65534 est l'utilisateur nfsnobody.

En supposant que le projet soit default et que le CCN soit restricted, l'ID utilisateur 65534 demandé par le pod n'est pas autorisé. Par conséquent, le module échoue pour les raisons suivantes :

  • Il demande 65534 comme identifiant d'utilisateur.
  • Tous les SCC disponibles pour le pod sont examinés pour voir quel SCC autorise un ID utilisateur de 65534. Bien que toutes les politiques des SCC soient vérifiées, l'accent est mis ici sur l'ID utilisateur.
  • Étant donné que tous les CCN disponibles utilisent MustRunAsRange pour leur stratégie runAsUser, la vérification de la plage d'UID est nécessaire.
  • 65534 n'est pas inclus dans la plage d'identification de l'utilisateur du CCN ou du projet.

Il est généralement considéré comme une bonne pratique de ne pas modifier les SCC prédéfinis. Le meilleur moyen de remédier à cette situation est de créer un SCC personnalisé. Un SCC personnalisé peut être créé de manière à ce que des ID d'utilisateur minimum et maximum soient définis, que la vérification de la plage d'UID soit toujours appliquée et que l'UID de 65534 soit autorisé.

Note

Pour utiliser un SCC personnalisé, vous devez d'abord l'ajouter au compte de service approprié. Par exemple, utilisez le compte de service default dans le projet donné, à moins qu'un autre compte n'ait été spécifié dans la spécification Pod.

4.9.3.3. SELinux

Les systèmes Red Hat Enterprise Linux (RHEL) et Red Hat Enterprise Linux CoreOS (RHCOS) sont configurés par défaut pour utiliser SELinux sur les serveurs NFS distants.

Pour les systèmes non RHEL et non RHCOS, SELinux n'autorise pas l'écriture à partir d'un pod vers un serveur NFS distant. Le volume NFS se monte correctement, mais il est en lecture seule. Vous devez activer les autorisations SELinux correctes à l'aide de la procédure suivante.

Conditions préalables

  • Le paquet container-selinux doit être installé. Ce paquetage fournit le booléen SELinux virt_use_nfs.

Procédure

  • Activez le booléen virt_use_nfs à l'aide de la commande suivante. L'option -P rend ce booléen persistant à travers les redémarrages.

    # setsebool -P virt_use_nfs 1

4.9.3.4. Paramètres d'exportation

Pour permettre aux utilisateurs arbitraires du conteneur de lire et d'écrire le volume, chaque volume exporté sur le serveur NFS doit respecter les conditions suivantes :

  • Chaque exportation doit être exportée en utilisant le format suivant :

    /<example_fs> *(rw,root_squash)
  • Le pare-feu doit être configuré pour autoriser le trafic vers le point de montage.

    • Pour NFSv4, configurez le port par défaut 2049 (nfs).

      NFSv4

      # iptables -I INPUT 1 -p tcp --dport 2049 -j ACCEPT

    • Pour NFSv3, il y a trois ports à configurer : 2049 (nfs), 20048 (mountd) et 111 (portmapper).

      NFSv3

      # iptables -I INPUT 1 -p tcp --dport 2049 -j ACCEPT

      # iptables -I INPUT 1 -p tcp --dport 20048 -j ACCEPT
      # iptables -I INPUT 1 -p tcp --dport 111 -j ACCEPT
  • L'exportation et le répertoire NFS doivent être configurés de manière à être accessibles par les pods cibles. Il faut soit définir l'exportation comme appartenant à l'UID principal du conteneur, soit fournir l'accès au groupe de pods en utilisant supplementalGroups, comme indiqué dans les ID de groupe ci-dessus.

4.9.4. Récupération des ressources

NFS implémente l'interface du plugin OpenShift Container Platform Recyclable. Des processus automatiques gèrent les tâches de remise en état en fonction des politiques définies sur chaque volume persistant.

Par défaut, les PV sont réglés sur Retain.

Une fois que les droits sur un PVC sont supprimés et que le PV est libéré, l'objet PV ne doit pas être réutilisé. Au lieu de cela, un nouveau PV doit être créé avec les mêmes détails de volume de base que l'original.

Par exemple, l'administrateur crée un PV nommé nfs1:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs1
spec:
  capacity:
    storage: 1Mi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.1.1
    path: "/"

L'utilisateur crée PVC1, qui se lie à nfs1. L'utilisateur supprime ensuite PVC1, ce qui libère nfs1. Le résultat est que nfs1 est Released. Si l'administrateur souhaite rendre le même partage NFS disponible, il doit créer un nouveau PV avec les mêmes détails de serveur NFS, mais un nom de PV différent :

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs2
spec:
  capacity:
    storage: 1Mi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.1.1
    path: "/"

Il est déconseillé de supprimer le PV original et de le recréer sous le même nom. Tenter de modifier manuellement l'état d'un PV de Released à Available entraîne des erreurs et une perte potentielle de données.

4.9.5. Configuration supplémentaire et dépannage

Selon la version de NFS utilisée et la manière dont elle est configurée, des étapes de configuration supplémentaires peuvent être nécessaires pour une exportation et un mappage de sécurité corrects. En voici quelques-unes qui peuvent s'appliquer :

Le montage NFSv4 affiche incorrectement tous les fichiers dont le propriétaire est nobody:nobody

  • Cela peut être attribué aux paramètres de mappage des identifiants, qui se trouvent à l'adresse /etc/idmapd.conf sur votre NFS.
  • Voir cette solution Red Hat.

Désactivation du mappage d'identifiants sur NFSv4

  • Sur le client et le serveur NFS, exécutez :

    # echo 'Y' > /sys/module/nfsd/parameters/nfs4_disable_idmapping
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.