Kubernetes 存儲(chǔ)鬼故事：當(dāng) 3 個(gè) Pod 搶一塊硬盤時(shí)發(fā)生了什么？

作者：劉俊夏 2025-03-26 00:04:00

此次 PV 劫持事故暴露了云原生技術(shù)棧中“配置即代碼”的雙刃劍特性：靈活性的背后，是嚴(yán)謹(jǐn)性的絕對(duì)要求。通過本文的深度解析，希望讀者不僅能夠規(guī)避類似問題，此次 PV 劫持事故暴露了云原生技術(shù)棧中“配置即代碼”的雙刃劍特性：靈活性的背后，是嚴(yán)謹(jǐn)性的絕對(duì)要求。通過本文的深度解析，希望讀者不僅能夠規(guī)避類似問題，更能在團(tuán)隊(duì)內(nèi)建立起存儲(chǔ)配置的“免疫體系”，讓 Kubernetes 真正成為業(yè)務(wù)創(chuàng)新的堅(jiān)實(shí)底座。

引言

對(duì)于這種案例，你們的處理思路是怎么樣的呢，是否真正的處理過，如果遇到，你們應(yīng)該怎么處理。

我想大多數(shù)人都沒有遇到過。

開始

引言：云原生時(shí)代的“存儲(chǔ)鬼故事”

在 Kubernetes 集群中，存儲(chǔ)管理是許多團(tuán)隊(duì)的“暗礁區(qū)”。一個(gè)看似普通的 StatefulSet 配置錯(cuò)誤，竟導(dǎo)致分布式數(shù)據(jù)庫的多節(jié)點(diǎn)同時(shí)寫入同一塊磁盤，最終引發(fā)數(shù)據(jù)覆蓋、服務(wù)崩潰的連環(huán)災(zāi)難。本文將深入拆解這一經(jīng)典案例，揭示存儲(chǔ)配置背后的技術(shù)陷阱，并給出可復(fù)用的解決方案。

第一部分：災(zāi)難現(xiàn)場還原

1.1 現(xiàn)象：混亂的數(shù)據(jù)庫與崩潰的集群

某金融科技團(tuán)隊(duì)在 Kubernetes 上部署了一個(gè) MongoDB 分片集群（使用 StatefulSet 管理），上線后頻繁出現(xiàn)以下詭異現(xiàn)象：

? 數(shù)據(jù)“幽靈覆蓋”：用戶訂單數(shù)據(jù)隨機(jī)丟失，A 節(jié)點(diǎn)寫入的記錄被 B 節(jié)點(diǎn)覆蓋。

? Pod 自殺式重啟：日志中頻繁出現(xiàn) MongoDB failed to lock file: /data/db/mongod.lock 錯(cuò)誤，Pod 因文件鎖沖突陷入 CrashLoopBackOff。

? 存儲(chǔ)監(jiān)控告警：Prometheus 檢測到單個(gè) PVC（data-pvc-0）被 3 個(gè) Pod 同時(shí)掛載，磁盤 IOPS 飆升至 10,000 以上。

團(tuán)隊(duì)最初誤以為是“分布式系統(tǒng)的正常波動(dòng)”，直到某次數(shù)據(jù)錯(cuò)亂導(dǎo)致 10 萬級(jí)訂單金額異常，才意識(shí)到問題嚴(yán)重性。

1.2 初步排查：令人困惑的配置

基礎(chǔ)設(shè)施環(huán)境：

? Kubernetes 集群：v1.24（AWS EKS）

? 存儲(chǔ)后端：AWS EBS（gp3 卷）

? 關(guān)鍵配置：

# StatefulSet 片段
volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteMany" ]  # 錯(cuò)誤配置！
      storageClassName: "aws-ebs-ssd"
      resources:
        requests:
          storage: 100Gi

矛盾點(diǎn)分析：

1. StatefulSet 的設(shè)計(jì)邏輯：每個(gè) Pod（如 mongo-0、mongo-1）應(yīng)通過 volumeClaimTemplates 自動(dòng)創(chuàng)建獨(dú)立的 PVC/PV，為何多個(gè) Pod 共享同一個(gè) PVC？

2. AWS EBS 的物理限制：EBS 卷僅支持 ReadWriteOnce（單節(jié)點(diǎn)讀寫），為何 PVC 中聲明 ReadWriteMany 未被拒絕？

第二部分：根因深度拆解

2.1 致命錯(cuò)誤 1：StorageClass 的 `volumeBindingMode` 陷阱

問題配置：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: aws-ebs-ssd
provisioner: ebs.csi.aws.com
volumeBindingMode: Immediate  # 災(zāi)難源頭！

技術(shù)原理：

? Immediate 模式：PVC 創(chuàng)建時(shí)立即綁定 PV，無視 Pod 調(diào)度位置。

? WaitForFirstConsumer 模式（正確選擇）：延遲 PV 綁定，直到 Pod 被調(diào)度到某節(jié)點(diǎn)，確保 PV 與節(jié)點(diǎn)拓?fù)淦ヅ洹?/span>

災(zāi)難連鎖反應(yīng)：

1. StatefulSet 創(chuàng)建時(shí)，一次性生成所有 PVC（如 data-pvc-0、data-pvc-1）。

2. 由于 volumeBindingMode: Immediate，所有 PVC 立即綁定到隨機(jī) EBS 卷。

3. AWS EBS 的區(qū)域限制：若集群跨多個(gè)可用區(qū)（AZ），部分 PVC 可能因 AZ 不匹配而綁定失敗，轉(zhuǎn)而“劫持”已有 PV。

4. 最終，多個(gè) Pod 的 PVC 指向同一個(gè) EBS 卷（RWX 模式未被過濾，見下文）。

2.2 致命錯(cuò)誤 2：濫用 `ReadWriteMany` 訪問模式

開發(fā)誤區(qū)：

? 誤解聲明式 API：認(rèn)為 PVC 中聲明的 accessModes 是“需求”而非“強(qiáng)制約束”，期望 Kubernetes 自動(dòng)降級(jí)處理。

? 現(xiàn)實(shí)打臉：AWS EBS 的 CSI 驅(qū)動(dòng)不會(huì)驗(yàn)證 accessModes，即使后端存儲(chǔ)不支持 RWX，PVC 仍能成功綁定！

技術(shù)真相：

? Kubernetes 的松散耦合設(shè)計(jì)：PVC 的 accessModes 僅是用戶“期望”，存儲(chǔ)驅(qū)動(dòng)可自由決定是否遵守。

? AWS EBS 的“沉默妥協(xié)”：當(dāng) PVC 聲明 ReadWriteMany 時(shí)，EBS 驅(qū)動(dòng)會(huì)“默認(rèn)”以 ReadWriteOnce 模式掛載，但允許多個(gè) Pod 強(qiáng)制掛載同一卷。

? 后果：多個(gè) Pod 繞過 Kubernetes 調(diào)度，直接通過存儲(chǔ)后端（EBS）掛載同一塊磁盤，引發(fā)文件系統(tǒng)競態(tài)。

2.3 文件系統(tǒng)層：為什么多寫必然崩潰？

以 MongoDB 為例，其數(shù)據(jù)目錄需要獨(dú)占訪問權(quán)：

1. 鎖文件沖突：mongod.lock 文件用于保證單進(jìn)程獨(dú)占數(shù)據(jù)目錄，多 Pod 同時(shí)掛載時(shí)，鎖機(jī)制失效。

2. 日志文件撕裂：多個(gè)實(shí)例的 WiredTiger 日志（Journal）交叉寫入，導(dǎo)致數(shù)據(jù)無法恢復(fù)。

3. 磁盤結(jié)構(gòu)損壞：Ext4/XFS 等文件系統(tǒng)并非為多節(jié)點(diǎn)并發(fā)設(shè)計(jì)，元數(shù)據(jù)（inode、superblock）可能被破壞。

# 查看 EBS 卷掛載情況（SSH 到 Node）
$ lsblk
nvme1n1   259:4    0  100G  0 disk /var/lib/kubelet/pods/xxxx/volumes/kubernetes.io~csi/aws-ebs-vol1
# 發(fā)現(xiàn)同一卷被掛載到多個(gè) Pod 目錄！

第三部分：系統(tǒng)性修復(fù)方案

3.1 緊急止血：如何搶救數(shù)據(jù)？

1. 暫停 StatefulSet：

kubectl scale statefulset mongo --replicas=0

2. 備份數(shù)據(jù)卷：

? 通過 AWS 控制臺(tái)為問題 EBS 卷創(chuàng)建快照。

? 切勿直接操作在線卷，避免進(jìn)一步損壞。

3. 掛載到臨時(shí) Pod 恢復(fù)數(shù)據(jù)：

# 臨時(shí)恢復(fù) Pod
apiVersion: v1
kind: Pod
metadata:
  name: data-recovery
spec:
  containers:
  - name: recovery-tool
    image: alpine
    command: ["sleep", "infinity"]
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: data-pvc-0  # 指定問題 PVC

? 使用 fsck 檢查文件系統(tǒng)，提取未損壞數(shù)據(jù)。

3.2 配置修復(fù)：根治存儲(chǔ)劫持

3.2.1 修正 StorageClass 綁定策略

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: aws-ebs-ssd
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer  # 關(guān)鍵修復(fù)！
parameters:
  type: gp3
  encrypted: "true"

效果驗(yàn)證：

# 描述 PVC，觀察事件
kubectl describe pvc data-pvc-0

? 期望輸出：

Events:
Type    Reason                Age   From                         Message
----    ------                ----  ----                         -------
Normal  WaitForFirstConsumer  5s    persistentvolume-controller  waiting for first consumer to be created before binding

3.2.2 強(qiáng)制使用 `ReadWriteOnce`

在 StatefulSet 中修正 PVC 模板：

volumeClaimTemplates:
- metadata:
    name: data
  spec:
    accessModes: [ "ReadWriteOnce" ]  # 嚴(yán)格限制為 RWO
    storageClassName: "aws-ebs-ssd"
    resources:
      requests:
        storage: 100Gi

3.3 重建 StatefulSet：安全操作手冊(cè)

1. 徹底清理舊資源：

# 刪除 StatefulSet（保留 Pod 用于數(shù)據(jù)遷移）
kubectl delete statefulset mongo --cascade=orphan

# 刪除所有關(guān)聯(lián) PVC（謹(jǐn)慎操作！）
kubectl delete pvc data-pvc-0 data-pvc-1 data-pvc-2

# 確認(rèn) PV 狀態(tài)變?yōu)?"Released"
kubectl get pv

2. 從備份恢復(fù)數(shù)據(jù)：

? 基于快照創(chuàng)建新 EBS 卷，掛載到每個(gè) Pod 的獨(dú)立 PVC。

3. 滾動(dòng)重啟：

kubectl apply -f fixed-statefulset.yaml
kubectl rollout status statefulset mongo

第四部分：防御體系構(gòu)建 —— 從亡羊補(bǔ)牢到未雨綢繆

4.1 技術(shù)管控：代碼未動(dòng)，策略先行

? 策略 1：通過 OPA/Gatekeeper 禁止危險(xiǎn)配置

# 策略：禁止創(chuàng)建 RWX 模式的 PVC
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPVolumeTypes
metadata:
  name: deny-rwx-pvc
spec:
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["PersistentVolumeClaim"]
  parameters:
    # 允許的訪問模式列表
    allowedAccessModes: ["ReadWriteOnce", "ReadOnlyMany"]

? 策略 2：CI/CD 流水線集成檢查在 Helm/Kustomize 渲染后，添加如下檢查：

# 使用 pluto 檢測廢棄 API 和危險(xiǎn)配置
pluto detect-files --target-versions k8s=v1.25 ./manifests/

4.2 架構(gòu)優(yōu)化：存儲(chǔ)層的最佳實(shí)踐

? 方案 1：專供 StatefulSet 的 StorageClass

# 專用 StorageClass，限制為 RWO + WaitForFirstConsumer
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: statefulset-ebs
  labels:
    usage: statefulset
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: gp3

? 方案 2：Operator 自動(dòng)化管理使用類似 MongoDB Kubernetes Operator 的方案，讓 Operator 自動(dòng)處理 PVC 模板、備份、擴(kuò)縮容等復(fù)雜邏輯。

4.3 監(jiān)控告警：實(shí)時(shí)捕獲存儲(chǔ)異常

? 指標(biāo) 1：PVC 掛載沖突檢測通過 Prometheus 監(jiān)控 kubelet_volume_stats_* 系列指標(biāo)，設(shè)置如下告警規(guī)則：

- alert:MultiplePodsMountSamePVC
expr:countby(persistentvolumeclaim)(kube_pod_spec_volumes_persistentvolumeclaims_info{})>1
for:5m
labels:
    severity:critical
annotations:
    summary: "Multiple Pods mounting the same PVC {{ $labels.persistentvolumeclaim }}"

? 指標(biāo) 2：存儲(chǔ)后端健康度集成 AWS CloudWatch 的 EBS 卷 IOPS、延遲監(jiān)控，確保存儲(chǔ)性能達(dá)標(biāo)。

第五部分：從案例中提煉的云原生存儲(chǔ)哲學(xué)

5.1 Kubernetes 存儲(chǔ)的“三大紀(jì)律”

1. StatefulSet 必須配 volumeClaimTemplates：手動(dòng)管理 PVC 是萬惡之源，務(wù)必讓每個(gè) Pod 自動(dòng)獲得獨(dú)立存儲(chǔ)。

2. 假設(shè)存儲(chǔ)不支持任何高級(jí)特性：除非文檔明確聲明，否則默認(rèn)存儲(chǔ)僅支持 RWO，且不能跨節(jié)點(diǎn)掛載。

3. 永遠(yuǎn)測試存儲(chǔ)行為：在預(yù)發(fā)布環(huán)境中模擬 Pod 故障、擴(kuò)縮容場景，驗(yàn)證存儲(chǔ)的真實(shí)表現(xiàn)。

5.2 文化啟示：打破開發(fā)與運(yùn)維的認(rèn)知墻

? 開發(fā)人員須知：

理解 PVC/PV 的物理含義，accessModes 不是“愿望清單”，而是“物理約束”。

分布式系統(tǒng)的數(shù)據(jù)一致性需在應(yīng)用層設(shè)計(jì)，不能依賴存儲(chǔ)黑魔法。

? 運(yùn)維人員須知：

? 提供“安全默認(rèn)值”（Safe Defaults），例如預(yù)配置合規(guī)的 StorageClass。

? 通過策略守衛(wèi)（Policy Guardrails）防止危險(xiǎn)配置落地。

結(jié)語：讓存儲(chǔ)成為應(yīng)用的地基，而非軟肋

此次 PV 劫持事故暴露了云原生技術(shù)棧中“配置即代碼”的雙刃劍特性：靈活性的背后，是嚴(yán)謹(jǐn)性的絕對(duì)要求。通過本文的深度解析，希望讀者不僅能夠規(guī)避類似問題，更能在團(tuán)隊(duì)內(nèi)建立起存儲(chǔ)配置的“免疫體系”，讓 Kubernetes 真正成為業(yè)務(wù)創(chuàng)新的堅(jiān)實(shí)底座。