本文匯總了使用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