K8s存储排障：PV已挂载但内容不可见？

Kubernetes存储排障：PV已挂载但内容不可见？九招直击病灶！

当你的Pod已经成功挂载PV，但死活读不到数据时，就像拿到了保险箱钥匙却打不开！ 本文将结合生产环境实战经验，手把手教你从基础排查到高阶诊断，彻底解决这个存储领域的高频难题！

---

一、第一现场：PV/PVC绑定状态确认（青铜段位）

口诀：先看婚姻状态再查婚后生活

# 快速诊断三件套
kubectl get pv | grep -E "NAME|${pv-name}"  # 查看PV状态
kubectl get pvc -n ${namespace} | grep -E "NAME|${pvc-name}"  # 查看PVC绑定
kubectl describe pod ${pod-name} | grep -A10 "Mounts"  # 确认挂载路径

经典翻车现场：

• PV/PVC显示Bound但数据不可见 → 跨命名空间挂载（PV是集群级资源）
• Access Modes不匹配 → ReadWriteOnce Pod被调度到多节点

---

二、文件权限修罗场（白银段位）

Linux文件权限三大致命伤：

1. UID/GID不匹配

   # 解决方案：在Pod中指定运行用户
   securityContext:
     runAsUser: 1000
     fsGroup: 2000
   

2. 挂载传播配置

   # 查看PV的mountOptions
   kubectl get pv ${pv-name} -o jsonpath='{.spec.mountOptions}'
   
   # 典型配置（NFS示例）
   mountOptions:
     - hard
     - nfsvers=4.1
     - rsize=1048576
   

3. 权限掩码问题

   # 进入容器验证权限
   kubectl exec -it ${pod-name} -- ls -l /mnt/data
   # 期望结果：至少显示drwxrws---（2770）
   

---

三、安全策略暗箭（黄金段位）

SELinux/AppArmor排查指南：

1. SELinux权限检测

   # 查看AVC拒绝日志
   ausearch -m avc -ts recent
   
   # 临时解决方案（仅测试环境！）
   setenforce 0
   

2. AppArmor配置文件

   # 查看Pod所在节点的AppArmor配置
   cat /sys/module/apparmor/parameters/enabled
   
   # 查看当前加载的配置
   aa-status
   

3. 生产环境正确姿势

   # 生成SELinux策略模块
   audit2allow -a -M mypolicy
   semodule -i mypolicy.pp
   

---

四、存储系统验尸报告（铂金段位）

不同存储类型专杀工具：

存储类型	必检命令	典型故障
NFS	rpcinfo -p ${nfs-server}	NFS服务未启动v4支持
CephFS	ceph fs ls	MDS服务宕机
AWS EFS	aws efs describe-mount-targets	安全组未开放2049端口

云厂商特别检查项：

• AWS EBS：检查卷是否处于in-use状态
• Azure Disk：验证LUN号是否冲突
• GCP PD：确认是否启用自动扩容

---

五、CSI驱动暗战（钻石段位）

CSI组件深度检查：

1. 查看CSI插件日志

   # Controller插件日志
   kubectl logs -n kube-system ${csi-controller-pod} -c csi-provisioner
   
   # Node插件日志（在Pod所在节点）
   journalctl -u kubelet | grep -i volume
   

2. 版本兼容性矩阵

   CSI驱动类型	最低K8s版本	关键特性
   AWS EBS	v1.17	卷扩展/快照
   Azure Disk	v1.21	CSI迁移

---

六、节点级深度探秘（大师段位）

节点挂载点取证分析：

1. SSH登录目标节点

   # 查找Pod对应的挂载点
   findmnt | grep ${pvc-id}
   
   # 检查文件系统类型
   blkid /dev/nvme1n1
   

2. 手动挂载测试

   # 模拟K8s挂载流程（以NFS为例）
   mount -t nfs4 ${nfs-server}:/path /mnt/test
   

3. 内核日志排查

   dmesg | grep -i error
   journalctl -k --since "5 minutes ago"
   

---

七、高级疑难杂症（宗师段位）

1. Subpath陷阱

   # 错误示例：subPath指向不存在的目录
   volumeMounts:
     - name: data
       mountPath: /app/config
       subPath: config  # 要求PV中必须存在该目录！
   

2. ReadOnlyRootFilesystem冲突

   # 解决方案：明确声明可写目录
   securityContext:
     readOnlyRootFilesystem: true
   volumeMounts:
     - name: data
       mountPath: /data
       readOnly: false
   

3. FlexVolume残留问题

   # 检查旧版插件残留
   ls /usr/libexec/kubernetes/kubelet-plugins/volume/exec/
   

---

八、终极排障流程图

Pod无法访问PV内容 → kubectl describe pod查Events
                ↓
事件分析：
  [PermissionDenied] → 检查文件权限/安全策略
  [InvalidArgument] → 检查mountOptions
                ↓
节点挂载验证：
  SSH到节点 → 手动访问挂载点
                ↓
存储系统检查：
  NFS：showmount -e
  云存储：控制台验证卷状态
                ↓
CSI驱动诊断：
  查看控制器/节点插件日志
                ↓
终极验证：
  创建测试Pod挂载同PV → 是否可读？

---

九、防患未然：生产环境存储规范

1. 统一文件系统：集群内统一使用xfs/ext4
2. 权限标准化：通过SecurityContext统一uid/gid
3. 挂载检测Sidecar：

   - name: volume-check
     image: busybox
     command: ["/bin/sh", "-c", "test -d /data && echo OK || exit 1"]
   

4. 混沌测试：定期模拟存储中断场景

记住：存储问题无小事！ 按照这个排查路线，下次遇到PV内容不可见的问题时，你一定能像老中医一样快速把脉开方，保障业务数据万无一失！