4.9. Stockage persistant à l'aide de NFS
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
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é.
NoteChaque volume NFS doit pouvoir être monté par tous les nœuds programmables du cluster.
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
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: ""
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.
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.
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
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é.
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
.
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
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égierunAsUser
, 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é.
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 SELinuxvirt_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) et111
(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 |
|
Désactivation du mappage d'identifiants sur NFSv4 |
|