为什么我的应用程序因 NFS 文件存储许可权的组标识错误而失败?

排查文件存储组 ID 权限错误。

经典基础设施

创建 或 添加现有 NFS 存储到群集后，应用程序的容器部署会失败。 您将看到组标识 (GID) 错误消息。

从未指定用户和用户标识 (UID) 的映像创建容器时，缺省情况下，Dockerfile 中的所有指令都由容器内的 root 用户 (UID: 0) 运行。

但是，当您要将 NFS 文件共享安装到容器时，容器内的用户标识 0 将映射到 NFS 主机系统上的用户标识 nobody。 因此，卷安装路径由用户标识 nobody 拥有，而不是由 root 拥有。 此安全功能也称为根壁。 根壁通过安装容器来保护 NFS 中的数据，而不授予实际 NFS 主机文件系统上的用户标识 root 许可权。

使用 Kubernetes DaemonSet 来启用 NFSv4 文件共享所有工作节点上存储挂载路径的 root 权限。

要允许对卷安装路径具有 root 用户许可权，必须在工作程序节点上设置 ConfigMap。 ConfigMap 将用户标识 nobody 从 NFS 主机系统映射到容器中的 root 用户标识 0。 此过程也称为无根壁。 更新所有工作程序节点的有效方法是使用守护程序集，该守护程序集在集群中的每个工作程序节点上运行指定的 pod。 在这种情况下，由守护程序集控制的 pod 会更新每个工作程序节点，以在卷安装路径上启用 root 用户许可权。

部署配置为允许守护程序集 pod 以特权方式运行，这是访问主机文件系统所必需的。 以特权方式运行 pod 会造成安全风险，因此请谨慎使用此选项。

当守护程序集正在运行时，将自动更新添加到集群的新工作程序节点。

开始之前：

请完成以下步骤。

  1. 复制 norootsquash 守护进程设置 部署 YAML 文件。

  2. 创建 norootsquash 守护程序集部署。

    oc apply -f norootsquash.yaml

  3. 获取存储卷安装到的 pod 的名称。 这种豆荚与 norootsquash 豆荚不同。

    oc get pods

  4. 登录到该 pod。

    oc exec -it mypod /bin/bash

  5. 验证安装路径的许可权是否为 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 .

    输出结果显示，第一行中的 UID 现在归 root （而不是 nobody ）所有。

  6. 如果 UID 由 nobody 拥有，请退出 pod 并重新引导集群的工作程序节点。 等待节点重新引导。

    ibmcloud oc worker reboot --cluster MY_CLUSTER --worker MY_WORKER1,MY_WORKER2

  7. 重复步骤 4 和 5 以验证权限。