IBM Cloud Docs
Pourquoi mon application échoue-t-elle avec une erreur d'ID groupe pour les droits de stockage de fichiers NFS ?

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 :

  1. Copier le fichier YAML de déploiement du daemon 'norootsquash

  2. Créez le déploiement de l'ensemble de démons norootsquash.

    oc apply -f norootsquash.yaml
    
  3. Obtenez le nom du pod sur lequel votre volume de stockage est monté. Ce pod ne correspond pas aux pods norootsquash.

    oc get pods
    
  4. Connectez-vous au pod.

    oc exec -it mypod /bin/bash
    
  5. 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).

  6. 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>
    
  7. Répétez les étapes 4 et 5 pour vérifier les droits.