如何控制Kubernetes中节点非挂载文件系统的权限？

核心原因 #

非挂载的容器内文件系统（比如镜像自带、部署时解压的目录）的权限，本质由镜像构建阶段决定，或是容器启动脚本修改的。你猜的没错，fsGroup确实只对挂载的卷生效——Kubelet只会给挂载卷应用权限调整逻辑，不会改动镜像本身的文件权限。

两台集群权限不同，大概率是镜像构建/解压过程有差异，或是节点容器运行时（containerd、Docker这类）的配置细节不一样，但最常见的还是镜像层面的问题。

具体解决方法 #

1. 修改镜像构建逻辑（最彻底） #

直接在构建镜像时把/opt/app的权限设为777：

• 在Dockerfile里加这行：

  RUN chmod 777 /opt/app
  

  要是解压文件后生成的目录，就把权限调整命令跟在解压命令后面：

  RUN tar -xzf app.tar.gz -C /opt/app && chmod 777 /opt/app
  

2. 在Pod启动时临时调整权限（不用改镜像） #

如果没法修改镜像，就在Pod启动命令里先调权限再启动应用：

• 在Pod YAML的command字段里加权限修改步骤：

  spec:
    containers:
    - name: your-app
      image: your-image:tag
      command: ["/bin/sh", "-c"]
      args: ["chmod 777 /opt/app && exec your-app-start-command"]
  

  这里用exec是为了让应用进程成为容器的PID 1，保证信号能正常传递给应用。

3. 统一容器运行时的umask配置 #

如果两台节点的容器运行时umask不一样，也可能导致解压后的权限有差异：

• 对于containerd，检查/etc/containerd/config.toml里的default_runtime_options是否有umask配置；
• 对于Docker，查看/etc/docker/daemon.json或者启动脚本里的umask设置。
  可以把两台节点的容器运行时umask统一设为000，不过这种方式会影响所有容器，得谨慎操作。

验证 #

修改后重新部署Pod，进入容器执行ls -ld /opt/app，确认权限显示为drwxrwxrwx就搞定了。

内容的提问来源于stack exchange，提问作者Blaisem