Netapp 存储卷无法挂载pod

文章目录

- [1. 现象](#1. 现象)
- [2. 修复宿主机服务状态 (必须执行)](#2. 修复宿主机服务状态 (必须执行))
- [3. 修正 SELinux 策略 (OCP 特有)](#3. 修正 SELinux 策略 (OCP 特有))
- [4. 手动模拟挂载测试 (定位真因)](#4. 手动模拟挂载测试 (定位真因))
- - [结论：这就是 NetApp 存储端的权限问题](#结论：这就是 NetApp 存储端的权限问题)
  - 你需要如何修复？（联系存储管理员或自查）
- [5. 优化 StorageClass 参数 (针对 Trident)](#5. 优化 StorageClass 参数 (针对 Trident))
- [6. 总结](#6. 总结)

1. 现象

bash 复制代码

Warning  FailedScheduling        6m10s (x5 over 6m15s)  default-scheduler        0/6 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/6 nodes are available: 6 Preemption is not helpful for scheduling.
Normal   Scheduled               6m10s                  default-scheduler        Successfully assigned prometheus/alertmanager-prometheus-kube-prometheus-alertmanager-0 to worker02.ocp.bsgchina.com
Normal   SuccessfulAttachVolume  6m5s                   attachdetach-controller  AttachVolume.Attach succeeded for volume "pvc-fa6e5c19-b8ec-4b83-ad76-6a860667aded"
Warning  FailedMount             115s (x10 over 6m5s)   kubelet                  MountVolume.SetUp failed for volume "pvc-fa6e5c19-b8ec-4b83-ad76-6a860667aded" : rpc error: code = Internal desc = error mounting NFS volume 192.168.22.196:/trident_pvc_fa6e5c19_b8ec_4b83_ad76_6a860667aded on mountpoint /var/lib/kubelet/pods/fa4afba4-ab1b-49c4-8119-b75c1b64df2a/volumes/kubernetes.io~csi/pvc-fa6e5c19-b8ec-4b83-ad76-6a860667aded/mount: exit status 32

在 OpenShift (OCP) 环境下，rpcinfo 测试通过说明网络连通性（111, 2049 端口）没问题，但 exit status 32 依然存在，且 mountOptions 已经包含了 nfsvers=3。

这通常意味着 Worker 节点宿主机上的 NFS 客户端服务未完全就绪 ，或者是 SELinux 策略拦截。

请按照以下步骤在 worker02（或报错节点）上执行深度修复：

2. 修复宿主机服务状态 (必须执行)

虽然 mount.nfs 二进制文件存在，但 RHCOS 上的 NFS 相关服务（如 rpcbind 和 nfs-client.target）可能没有激活，导致内核无法处理挂载请求。

请再次进入调试模式：

Bash 复制代码

oc debug node/worker02.ocp.bsgchina.com

进入后执行以下命令：

Bash 复制代码

# 进入宿主机根目录
chroot /host

# 启动并启用 rpcbind
systemctl enable rpcbind --now

# 启动 NFS 客户端目标 (这是 RHCOS 处理挂载的关键)
systemctl enable nfs-client.target --now

# 检查服务状态
systemctl status rpcbind nfs-client.target

3. 修正 SELinux 策略 (OCP 特有)

OpenShift 默认的 SELinux 策略有时会阻止容器进程通过内核挂载 NFS 卷。

在上述 chroot /host 环境下执行：

Bash 复制代码

# 允许虚拟化/容器使用 NFS
setsebool -P virt_use_nfs 1

4. 手动模拟挂载测试 (定位真因)

在 chroot /host 环境下，手动尝试挂载报错信息中的路径，观察最原始的错误输出（这比 K8s 的 Event 更准确）：

Bash 复制代码

sh-5.1# chroot /host
sh-5.1# mkdir -p /tmp/manual_test
sh-5.1#  mount -t nfs -o nfsvers=3,nolock 192.168.22.196:/test_root /tmp/manual_test
mount.nfs: access denied by server while mounting 192.168.22.196:/test_root
sh-5.1# which mount.nfs
/usr/sbin/mount.nfs
sh-5.1#

如果提示 Permission denied ：说明 NetApp 端的 Export Policy (导出策略) 没有允许 Worker 节点的 IP。你需要联系存储管理员，在 NetApp 上把所有 Worker 节点的 IP 加到对应 Volume 的只读/读写权限中。
如果提示 Protocol not supported ：尝试改用 nfsvers=4.1。

真相大白了！报错 mount.nfs: access denied by server 是最直接的证据。

结论：这就是 NetApp 存储端的权限问题

你的 OCP 节点工具是全的，网络也是通的，但 NetApp 存储拒绝了这台机器的挂载请求。

这是因为在 NetApp 存储上，每个 NFS 卷（Volume）都关联了一个 Export Policy（导出策略） 。如果发起挂载的机器 IP（192.168.22.51/52/53 等）不在该策略的白名单内，存储就会报 access denied。

你需要如何修复？（联系存储管理员或自查）

如果你或你的同事负责管理 NetApp，请确保执行以下操作：

找到对应的 Export Policy ：在 NetApp 管理界面或命令行中，找到分配给 ontap-nas-test 这个后端使用的 Export Policy。
添加规则（Rule） ：为该策略添加一条新规则，包含以下内容：
1. Client Specification（客户端匹配） : 192.168.22.0/24 (或者列出所有 Worker 节点的具体 IP)。
2. Access Protocols : nfs3 (或者 nfs)。
3. Read-Only Access : any 或 sys。
4. Read-Write Access : any 或 sys。
5. Superuser Security : 必须设为 any 或 sys（这非常重要！因为 K8s 挂载是以 root 身份执行的，如果 Superuser 不允许，就会报 Access Denied）。
Trident 自动化的处理（长久之计） ：如果你希望 Trident 以后自动创建的卷都能正常挂载，你需要检查 Trident 的后端配置文件（backend.json）。
1. 确保 exportPolicy 字段指向了一个已经配置好上述权限的策略。
2. 或者在 backend.json 中配置 defaults: { "exportPolicy": "your_policy_name" }。

登陆 ONTAP System Manager 添加读写权限。

5. 优化 StorageClass 参数 (针对 Trident)

Trident 在 ONTAP NAS 模式下，有时需要显式指定协议为 TCP。请尝试更新 SC：

Bash 复制代码

oc patch sc ontap-nas-test -p '{"mountOptions": ["nfsvers=3", "proto=tcp", "nolock"]}'

6. 总结

你现在的现象是 "工具在，服务没开" 或者 "权限被 SELinux 拦了"。

先去执行 systemctl enable nfs-client.target --now。
再执行 setsebool -P virt_use_nfs 1。
如果还是 32 报错，那 100% 是 NetApp 存储端的 Export Policy 拦截了这几台新机器的 IP。