¿Por qué falla mi app con un error de ID de grupo para los permisos de almacenamiento de archivos NFS?

Solucionar errores de permisos relacionados con el ID del grupo de almacenamiento de archivos.

Infraestructura clásica

Después de crear o añadir el almacenamiento NFS existente al clúster, el despliegue del contenedor de la app falla. Aparecen mensajes de error de ID de grupo (GID).

Cuando crea un contenedor a partir de una imagen que no especifica un usuario y un ID de usuario (UID), todas las instrucciones del archivo Dockerfile las ejecuta el usuario root (UID: 0) dentro del contenedor de forma predeterminada.

Sin embargo, cuando desea montar el uso compartido de archivos NFS en el contenedor, el ID de usuario 0 dentro del contenedor se correlaciona con el ID de usuario nobody en el sistema host NFS. Por lo tanto, la vía de acceso de montaje de volumen es propiedad del ID de usuario nobody, no de root. Esta característica de seguridad también se conoce como "root squash". Root squash protege los datos dentro del NFS montando el contenedor sin otorgar al ID de usuario root permisos sobre el sistema de archivos del host NFS real.

Utiliza un archivo Kubernetes para DaemonSet habilitar los permisos de root en la ruta de montaje del almacenamiento en todos tus nodos de trabajo para los recursos compartidos de archivos de NFSv4.

Para permitir el permiso root en la vía de acceso de montaje de volumen, debe configurar un mapa de configuración en el nodo trabajador. El mapa de configuración correlación el ID de usuario nobody del sistema host NFS con el ID de usuario root 0 en el contenedor. Este proceso también se conoce como "no root squash". Una forma eficaz de actualizar todos los nodos de trabajador es utilizar un conjunto de daemons, que ejecuta un pod especificado en cada nodo de trabajador del clúster. En este caso, el pod que está controlado por el conjunto de daemons actualiza cada uno de los nodos trabajadores para habilitar el permiso root en la vía de acceso de montaje de volumen.

El despliegue se configura de modo que permite que el conjunto de daemons se ejecute en modalidad con privilegios, lo que es necesario para acceder al sistema de archivos de host. La ejecución de un pod en modo con privilegios crea un riesgo de seguridad, por lo que debe utilizar esta opción con precaución.

Mientras se ejecuta el conjunto de daemons, los nuevos nodos trabajadores que se añaden al clúster se actualizan automáticamente.

Antes de empezar:

Realice los siguientes pasos.

Copia el archivo YAML de implementación del conjunto de daemons norootsquash.
Cree el despliegue del conjunto de daemons norootsquash.
```
oc apply -f norootsquash.yaml
```
Obtenga el nombre del pod en el que está montado el volumen de almacenamiento. Este pod no es el mismo que los pods norootsquash.
```
oc get pods
```
Inicie sesión en el pod.
```
oc exec -it mypod /bin/bash
```
Verifique que los permisos sobre la vía de acceso de montaje son 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 .
```
Este resultado muestra que el UID de la primera fila ahora pertenece a ( root en lugar de nobody).
Si el UID es propiedad de nobody, salga del pod y rearranque los nodos trabajadores del clúster. Espere que los nodos se reinicien.
```
ibmcloud oc worker reboot --cluster MY_CLUSTER --worker MY_WORKER1,MY_WORKER2
```
Repita los pasos 4 y 5 para verificar los permisos.