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

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

经典基础结构

创建 或 将现有 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 的名称。 此 pod 与 norootsquash pod 不同。

    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 以验证许可权。