Kubernetes 1.27挂载第二个Pod至Local-Storage PVC后首个Pod失权限

核心原因 #

这个问题的根源在于Kubernetes kubelet对本地存储卷的所有权重设逻辑，结合XFS文件系统特性触发了权限冲突：

• 第一个Pod（Pod1）挂载PVC时，kubelet会根据Pod的root安全上下文，将卷的所有权设为0:0（root:root），此时Pod1可正常读写。
• 当第二个Pod（Pod2）挂载同一PVC时，kubelet会再次执行卷所有权检查。由于XFS文件系统的属性（尤其是启用prjquota时），kubelet可能会强制重设卷的所有权或ACL，覆盖原有权限设置——Pod2作为触发重设的一方，权限保持正确，但Pod1的root用户因此失去访问权限。
• 即便两个Pod安全上下文完全一致，多Pod挂载同一本地卷时，kubelet的处理逻辑仍可能出现这类权限覆盖问题，XFS环境下更易触发。

验证步骤 #

1. 在主机节点检查卷的权限变化：

   # 替换为你的PV实际本地路径
   ls -ld /opt/local-storage/pv-3
   ls -ld /opt/local-storage/pv-3/dummy1
   

   对比挂载Pod2前后，目录的uid/gid和权限位变化。

2. 检查kubelet的fsGroupPolicy配置：

   ps aux | grep kubelet | grep fs-group-policy
   

   若设置为ReadWriteOnceWithFSType或Strict，会导致kubelet在卷重新挂载时强制重设所有权。

解决方案 #

方案1：修改PV的fsGroupPolicy #

编辑PV定义，添加fsGroupPolicy: None禁用kubelet自动重设卷所有权：

kind: PersistentVolume
apiVersion: v1
metadata:
  name: pv-3
spec:
  storageClassName: local-storage
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  local:
    path: /opt/local-storage/pv-3  # 替换为你的PV实际路径
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - your-node-name  # 替换为节点名称
  fsGroupPolicy: None  # 添加该行

应用修改后，删除并重建两个Pod，kubelet将不再自动修改卷的所有权。

方案2：手动预设置卷权限 #

在主机节点提前配置PV对应目录的权限，避免kubelet修改：

chown -R root:root /opt/local-storage/pv-3
chmod -R 775 /opt/local-storage/pv-3
chmod +t /opt/local-storage/pv-3

之后再挂载Pod，kubelet会检测到权限符合安全上下文要求，不会执行重设操作。

方案3：调整kubelet全局fsGroupPolicy #

修改kubelet配置文件（通常为/var/lib/kubelet/config.yaml）：

fsGroupPolicy: None

重启kubelet服务：

systemctl restart kubelet

关键注意事项 #

• 本地存储的ReadWriteMany仅支持同一节点上的多Pod挂载，并非分布式共享，这是权限冲突的高发场景。
• 若XFS启用了项目配额（prjquota），会影响kubelet的所有权处理逻辑，可通过以下命令检查挂载参数：

  mount | grep /opt/local-storage/pv-3
  

  临时移除prjquota参数可验证是否解决问题。

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