Pourquoi mon application échoue-t-elle avec une erreur d'ID groupe pour les droits de stockage de fichiers NFS ?
Infrastructure classique
Une fois que vous avez créé ou ajouté un stockage NFS existant à votre cluster, le déploiement de conteneur de votre application échoue. Des messages d'erreur d'ID groupe apparaissent.
Lorsque vous créez un conteneur à partir d'une image qui ne spécifie pas d'utilisateur et d'ID utilisateur (UID), toutes les instructions du fichier Dockerfile sont exécutées par l'utilisateur root (UID : 0) à l'intérieur du conteneur par défaut.
Toutefois, si vous souhaitez monter un partage de fichiers NFS sur votre conteneur, l'ID utilisateur 0
à l'intérieur du conteneur est mappé à l'ID utilisateur nobody
sur le système hôte NFS. Par conséquent, le chemin
de montage du volume est détenu par l'ID utilisateur nobody
et non par l'ID utilisateur root
. Cette fonction de sécurité est également connue sous le nom de root squash. Root squash protège les données du système NFS
en montant le conteneur sans octroyer de droits root à l'ID utilisateur sur le véritable système de fichiers hôte NFS.
Utilisez un " DaemonSet
Kubernetes pour activer les droits root sur le chemin de montage de stockage sur tous
vos nœuds de travail pour les partages de fichiers NFSv4.
Pour autoriser les droits root sur le chemin de montage du volume, vous devez configurer une mappe de configuration sur votre noeud worker. La mappe de configuration mappe l'ID utilisateur nobody
du système hôte NFS à l'ID utilisateur
root 0
dans votre conteneur. Ce processus est également appelé no root squash. Un moyen efficace de mettre à jour tous vos nœuds de travail consiste à utiliser un ensemble de démons, qui exécute une nacelle spécifiée sur chaque
noeud de travail de votre cluster. Dans ce cas, le pod contrôlé par l'ensemble de démons met à jour chacun de vos noeuds worker pour autoriser les droits root sur le chemin de montage du volume.
Le déploiement est configuré pour permettre l'exécution du pod d'ensemble de démons en mode privilégié, ce qui est nécessaire pour accéder au système de fichiers hôte. L'exécution d'un pod en mode privilégié créant un risque de sécurité, utilisez cette option avec précaution.
Lorsque l'ensemble de démons est en cours d'exécution, les nouveaux noeuds worker ajoutés au cluster sont automatiquement mis à jour.
Avant de commencer :
Etapes :
-
Copier le fichier YAML de déploiement du daemon '
norootsquash
-
Créez le déploiement de l'ensemble de démons
norootsquash
.oc apply -f norootsquash.yaml
-
Obtenez le nom du pod sur lequel votre volume de stockage est monté. Ce pod ne correspond pas aux pods
norootsquash
.oc get pods
-
Connectez-vous au pod.
oc exec -it mypod /bin/bash
-
Vérifiez que les droits d'accès au chemin de montage sont
root
.root@mypod:/# ls -al /mnt/myvol/ total 8 drwxr-xr-x 2 root root 4096 Feb 7 20:49 . drwxr-xr-x 1 root root 4096 Feb 20 18:19 .
Cette sortie montre que l'ID utilisateur de la première ligne appartient maintenant à
root
(et non plus ànobody
). -
Si l'ID utilisateur appartient à
nobody
, quittez le pod et réinitialisez les noeuds worker de votre cluster. Attendez que les noeuds soient réinitialisés.ibmcloud oc worker reboot --cluster <my_cluster> --worker <my_worker1>,<my_worker2>
-
Répétez les étapes 4 et 5 pour vérifier les droits.