本文汇总了使用CSI存储组件挂载和使用存储卷的常见问题。
典型问题
挂载和使用存储卷时，如有Pod状态异常，存储卷挂载失败的问题，可参考存储异常问题排查进行排查。
以下是一些典型的常见问题：
云盘存储卷
类型 | 问题 |
创建 | |
挂载 | |
使用 | |
扩容 | |
卸载 | |
其他 |
NAS存储卷
类型 | 问题 |
挂载 | |
使用 | |
卸载 |
OSS存储卷
ossfs 1.0
类型 | 问题 |
挂载 | |
使用 | |
扩容 | |
卸载 |
ossfs 2.0
类型 | 问题 |
挂载 | |
扩容 | |
使用 |
存储组件
类型 | 问题 |
组件异常问题 | |
组件升级失败 |
CNFS
ACK集群升级后，出现IPAddress ... for Service ... has a wrong reference事件告警
问题现象
集群升级后，通过kubectl get events -A观察到有持续的Warning类型的事件，内容如下：
IPAddress: <IP_ADDRESS> for Service kube-system/cnfs-cache-ds-service has a wrong reference; cleaning up此问题通常发生在：
集群storage-operator 组件版本低于 v1.33.1。
集群从 1.32 及以下版本升级至 1.33 及以上版本。
问题原因
低于 v1.33.1 版本的 storage-operator 存在一个已知问题：会不断尝试创建已存在的 Service。在 Kubernetes 1.33 及以上版本中，由于 MultiCIDRServiceAllocator 特性被默认启用，这一重复行为会触发该特性，导致系统陷入快速创建并删除临时 IPAddress 资源的循环。
解决方案
为什么手动删除kube-system/cnfs-cache-ds-service后又被自动重建了？
问题现象
尝试手动删除kube-system命名空间下的cnfs-cache-ds-service后，操作显示已删除，但再次检查该Service时，又重新出现。
问题原因
此问题由storage-operator组件引起，其工作逻辑如下：
期望状态：
storage-operator的ConfigMap中定义了cnfs-cache-ds-service的安装状态为true。持续监控：该组件会持续检查集群，确保上述Service存在。
自动修复：手动删除Service时，控制器发现Service与期望状态不符，将立即重新创建以进行“纠正”。
解决方案
方式一：升级storage-operator组件（推荐）
方式二：修改storage-operator配置（临时方案）
此方法通过直接修改storage-operator的配置文件，以告知不再需要cnfs-cache-ds。
找到并编辑
kube-system命名空间下的storage-operatorConfigMap。kubectl edit configmap storage-operator -n kube-system定位
data字段下的cnfs-cache-ds，将其install值从true修改为false。cnfs-cache-ds: install: "false" # ...其他配置...保存并退出编辑器。
storage-operator会加载新配置。再次执行删除Service的命令。
kubectl delete service cnfs-cache-ds-service -n kube-system