1. 為什么PVC是K8S持久化存儲(chǔ)的核心抽象1.1 從Pod生命周期說(shuō)起為什么容器里的數(shù)據(jù)說(shuō)沒(méi)就沒(méi)剛接觸K8S那會(huì)兒我最不理解的一件事就是為什么我往容器里寫(xiě)個(gè)文件重啟一下Pod就沒(méi)了后來(lái)才想明白Pod本身就是一個(gè)“用完即棄”的東西。它的設(shè)計(jì)哲學(xué)是無(wú)狀態(tài)、可替換、隨時(shí)調(diào)度——節(jié)點(diǎn)掛了Pod被驅(qū)逐到別的節(jié)點(diǎn)重建滾動(dòng)更新舊Pod直接銷毀。容器內(nèi)的文件系統(tǒng)是跟著容器走的容器一沒(méi)寫(xiě)進(jìn)去的數(shù)據(jù)自然灰飛煙滅。這在無(wú)狀態(tài)服務(wù)里完全沒(méi)問(wèn)題比如一個(gè)純轉(zhuǎn)發(fā)請(qǐng)求的API網(wǎng)關(guān)它不需要記住任何東西。但一旦涉及數(shù)據(jù)庫(kù)、日志歸檔、文件上傳、模型文件緩存這類場(chǎng)景數(shù)據(jù)必須活過(guò)Pod的整個(gè)生命周期甚至要活過(guò)整個(gè)集群的多次重建。這時(shí)候就需要一個(gè)獨(dú)立于Pod存在的存儲(chǔ)層讓數(shù)據(jù)“掛”在集群外面Pod來(lái)了就接上Pod走了數(shù)據(jù)還在。K8S給出的答案就是Volume卷體系而PVCPersistentVolumeClaim持久卷聲明是這套體系里面向使用者的那一層抽象。你可以把它理解成一張“存儲(chǔ)申請(qǐng)單”我作為應(yīng)用開(kāi)發(fā)者不關(guān)心底層是NFS還是云盤還是本地SSD我只寫(xiě)一張單子——“我要5Gi容量讀寫(xiě)模式隨便哪個(gè)存儲(chǔ)類都行”然后K8S負(fù)責(zé)把這張單子兌現(xiàn)成一個(gè)真正可用的存儲(chǔ)卷掛到我的Pod里。1.2 PV、PVC、StorageClass三者的關(guān)系用租房打個(gè)比方很多人第一次看PVPersistentVolume和PVC會(huì)懵為什么要有兩個(gè)東西直接掛一個(gè)卷不行嗎我用租房來(lái)類比一下就清楚了。PV持久卷相當(dāng)于房東手里的房源。它是集群管理員或者存儲(chǔ)插件預(yù)先準(zhǔn)備好的一塊存儲(chǔ)比如一塊云硬盤、一個(gè)NFS目錄、一個(gè)本地磁盤路徑。PV是集群級(jí)別的資源不屬于任何命名空間。PVC持久卷聲明相當(dāng)于租客的求租需求。它描述“我要多大面積、什么戶型、預(yù)算多少”寫(xiě)在某個(gè)命名空間里屬于某個(gè)應(yīng)用團(tuán)隊(duì)。StorageClass存儲(chǔ)類相當(dāng)于中介公司。當(dāng)租客PVC提出需求但沒(méi)有現(xiàn)成房源PV匹配時(shí)StorageClass負(fù)責(zé)動(dòng)態(tài)創(chuàng)建一套新房源出來(lái)。它定義了“用哪種存儲(chǔ)后端、什么參數(shù)、什么回收策略”。這三者的綁定關(guān)系是PVC根據(jù)容量、訪問(wèn)模式、存儲(chǔ)類等條件去匹配PV匹配成功就Bound已綁定然后Pod通過(guò)volumes字段引用這個(gè)PVC最終把存儲(chǔ)掛進(jìn)容器。整個(gè)過(guò)程里應(yīng)用開(kāi)發(fā)者只需要寫(xiě)PVC完全不用碰PV的細(xì)節(jié)——這正是K8S分層抽象的價(jià)值。提示PV是集群級(jí)資源PVC是命名空間級(jí)資源。這意味著同一個(gè)PV不能被兩個(gè)不同命名空間的PVC同時(shí)綁定除非訪問(wèn)模式允許且存儲(chǔ)后端支持。排查“PVC一直Pending”時(shí)第一件事就是看有沒(méi)有可匹配的PV。1.3 訪問(wèn)模式的坑RWO、ROX、RWX、RWOP到底怎么選PVC的accessModes字段是新手最容易踩坑的地方因?yàn)樗皇谴鎯?chǔ)能力的描述而是掛載方式的約束。很多人以為寫(xiě)了RWX就能多節(jié)點(diǎn)同時(shí)讀寫(xiě)結(jié)果發(fā)現(xiàn)底層存儲(chǔ)根本不支持Pod直接起不來(lái)。訪問(wèn)模式縮寫(xiě)含義典型后端ReadWriteOnceRWO只能被單個(gè)節(jié)點(diǎn)以讀寫(xiě)方式掛載云盤、本地盤、大部分塊存儲(chǔ)ReadOnlyManyROX可被多個(gè)節(jié)點(diǎn)以只讀方式掛載NFS、部分文件存儲(chǔ)ReadWriteManyRWX可被多個(gè)節(jié)點(diǎn)以讀寫(xiě)方式掛載NFS、CephFS、部分NASReadWriteOncePodRWOP只能被單個(gè)Pod以讀寫(xiě)方式掛載較新版本支持塊存儲(chǔ)這里有個(gè)關(guān)鍵細(xì)節(jié)RWO的“Once”指的是單個(gè)節(jié)點(diǎn)不是單個(gè)Pod。也就是說(shuō)同一個(gè)節(jié)點(diǎn)上的多個(gè)Pod可以同時(shí)掛同一個(gè)RWO的PVC。如果你需要嚴(yán)格保證一個(gè)卷只被一個(gè)Pod寫(xiě)那得用RWOPK8S 1.22才穩(wěn)定支持。我踩過(guò)的坑早期用云盤做RWO以為一個(gè)PVC只能給一個(gè)Pod用結(jié)果在同一個(gè)節(jié)點(diǎn)上起了兩個(gè)Pod掛同一個(gè)PVC兩個(gè)進(jìn)程同時(shí)寫(xiě)文件直接寫(xiě)壞了。所以選訪問(wèn)模式前先問(wèn)自己三個(gè)問(wèn)題幾個(gè)節(jié)點(diǎn)要掛讀寫(xiě)還是只讀底層存儲(chǔ)支持嗎2. 從零搭建一套PVC持久化存儲(chǔ)的完整實(shí)操2.1 環(huán)境準(zhǔn)備與前置檢查清單動(dòng)手之前先確認(rèn)你的集群具備哪些條件。不同環(huán)境的存儲(chǔ)能力差異極大盲目照抄YAML大概率會(huì)卡在Pending。先跑幾條命令摸清家底# 查看集群版本決定能用哪些特性 kubectl version --short # 查看已有的StorageClass這是動(dòng)態(tài)供應(yīng)的前提 kubectl get storageclass # 查看節(jié)點(diǎn)信息確認(rèn)是否有本地存儲(chǔ)可用 kubectl get nodes -o wide # 查看默認(rèn)StorageClass名字帶default標(biāo)記的那個(gè) kubectl get sc -o jsonpath{.items[?(.metadata.annotations.storageclass\.kubernetes\.io/is-default-classtrue)].metadata.name}檢查清單如下有沒(méi)有StorageClass如果沒(méi)有要么手動(dòng)創(chuàng)建PV要么先裝一個(gè)存儲(chǔ)插件如本地路徑供應(yīng)器、NFS供應(yīng)器等。有沒(méi)有默認(rèn)StorageClassPVC不寫(xiě)storageClassName時(shí)會(huì)使用默認(rèn)存儲(chǔ)類。如果集群沒(méi)有默認(rèn)類PVC會(huì)一直Pending。節(jié)點(diǎn)上有沒(méi)有可用路徑如果用本地存儲(chǔ)確認(rèn)目標(biāo)目錄存在且權(quán)限正確。RBAC權(quán)限動(dòng)態(tài)供應(yīng)依賴Provisioner組件確認(rèn)它有創(chuàng)建PV的權(quán)限。注意生產(chǎn)環(huán)境不要用hostPath做持久化。hostPath把數(shù)據(jù)綁死在某個(gè)節(jié)點(diǎn)上Pod調(diào)度到別的節(jié)點(diǎn)就找不到數(shù)據(jù)了而且節(jié)點(diǎn)故障數(shù)據(jù)直接丟。它只適合單節(jié)點(diǎn)測(cè)試。2.2 手寫(xiě)第一個(gè)PVC字段逐個(gè)拆解先看一個(gè)最基礎(chǔ)的PVC定義我把它拆成注釋版每個(gè)字段都說(shuō)明白apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-app-data # PVC名字同命名空間內(nèi)唯一 namespace: default # 所屬命名空間 spec: accessModes: - ReadWriteOnce # 訪問(wèn)模式單節(jié)點(diǎn)讀寫(xiě) resources: requests: storage: 5Gi # 申請(qǐng)5Gi容量注意是requests不是limits storageClassName: standard # 指定存儲(chǔ)類不寫(xiě)則用默認(rèn)類 volumeMode: Filesystem # 卷模式Filesystem或Block幾個(gè)容易寫(xiě)錯(cuò)的點(diǎn)storage寫(xiě)在resources.requests下面不是limits。PVC沒(méi)有l(wèi)imits的概念申請(qǐng)多少就是多少。storageClassName如果寫(xiě)成空字符串表示不使用動(dòng)態(tài)供應(yīng)強(qiáng)制走靜態(tài)綁定只匹配沒(méi)有存儲(chǔ)類的PV。volumeMode默認(rèn)是Filesystem除非你要做裸塊設(shè)備比如給數(shù)據(jù)庫(kù)直接管理塊設(shè)備否則不用改。創(chuàng)建并觀察狀態(tài)kubectl apply -f pvc.yaml kubectl get pvc my-app-data -w正常流程是Pending→Bound。如果卡在Pending超過(guò)30秒用kubectl describe pvc my-app-data看Events通常會(huì)告訴你“no persistent volumes available”或者“storageclass not found”。2.3 把PVC掛進(jìn)Pod兩種掛載寫(xiě)法對(duì)比PVC創(chuàng)建好之后Pod通過(guò)volumes引用它。這里有兩種常見(jiàn)寫(xiě)法效果一樣但適用場(chǎng)景不同。寫(xiě)法一直接引用PVC名字apiVersion: v1 kind: Pod metadata: name: app-with-pvc spec: containers: - name: app image: nginx:1.25 volumeMounts: - name: data mountPath: /usr/share/nginx/html # 容器內(nèi)掛載點(diǎn) volumes: - name: data persistentVolumeClaim: claimName: my-app-data # 引用PVC名字寫(xiě)法二在Deployment里用同樣的方式Deployment的Pod模板里寫(xiě)法完全一致因?yàn)関olumes是Pod級(jí)別的字段。區(qū)別在于Deployment會(huì)管理多個(gè)Pod副本如果多個(gè)副本掛同一個(gè)RWO的PVC且被調(diào)度到不同節(jié)點(diǎn)就會(huì)有一個(gè)卡在ContainerCreating。apiVersion: apps/v1 kind: Deployment metadata: name: app-deploy spec: replicas: 1 # RWO場(chǎng)景下副本數(shù)建議為1 selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: containers: - name: app image: nginx:1.25 volumeMounts: - name: data mountPath: /data volumes: - name: data persistentVolumeClaim: claimName: my-app-data提示如果確實(shí)需要多副本共享存儲(chǔ)必須用RWX模式并且底層存儲(chǔ)支持。云盤類塊存儲(chǔ)基本都不支持RWX別硬上。2.4 驗(yàn)證持久化是否真的生效掛載成功不代表持久化生效必須做一次“銷毀-重建”驗(yàn)證。步驟很簡(jiǎn)單進(jìn)入Pod寫(xiě)一個(gè)文件kubectl exec -it app-with-pvc -- sh -c echo hello pvc /usr/share/nginx/html/test.txt刪掉Podkubectl delete pod app-with-pvc重新創(chuàng)建同樣的Pod再讀文件kubectl exec -it app-with-pvc -- cat /usr/share/nginx/html/test.txt如果還能看到hello pvc說(shuō)明數(shù)據(jù)確實(shí)落在了PVC上而不是容器臨時(shí)層。這一步是驗(yàn)證持久化的黃金標(biāo)準(zhǔn)任何存儲(chǔ)方案上線前都必須過(guò)這一關(guān)。3. 動(dòng)態(tài)供應(yīng)與StorageClass的進(jìn)階配置3.1 動(dòng)態(tài)供應(yīng)到底省了什么靜態(tài)綁定的痛點(diǎn)沒(méi)有動(dòng)態(tài)供應(yīng)的時(shí)候管理員得手動(dòng)創(chuàng)建PV就像手動(dòng)分配IP地址一樣低效。應(yīng)用團(tuán)隊(duì)每次要存儲(chǔ)都得提工單“我要10GiRWO”管理員再去創(chuàng)建PV然后PVC才能綁定。集群規(guī)模一大PV數(shù)量爆炸管理成本極高。動(dòng)態(tài)供應(yīng)的邏輯是PVC里指定storageClassNameK8S發(fā)現(xiàn)沒(méi)有現(xiàn)成PV匹配就調(diào)用這個(gè)StorageClass關(guān)聯(lián)的Provisioner讓它按需創(chuàng)建一個(gè)PV出來(lái)自動(dòng)綁定。應(yīng)用團(tuán)隊(duì)自助申請(qǐng)管理員只需要維護(hù)幾個(gè)StorageClass模板。一個(gè)StorageClass的典型定義apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-ssd provisioner: kubernetes.io/aws-ebs # 具體供應(yīng)器因環(huán)境而異 parameters: type: gp3 fsType: ext4 reclaimPolicy: Delete # 回收策略 allowVolumeExpansion: true # 允許擴(kuò)容 volumeBindingMode: WaitForFirstConsumer # 綁定時(shí)機(jī)3.2 reclaimPolicy刪了PVC數(shù)據(jù)到底留不留reclaimPolicy決定了PVC被刪除后底層PV和數(shù)據(jù)怎么處理。這個(gè)字段選錯(cuò)可能直接導(dǎo)致數(shù)據(jù)丟失必須搞清楚。策略行為適用場(chǎng)景Delete刪除PVC時(shí)PV和底層存儲(chǔ)一起刪除臨時(shí)數(shù)據(jù)、可重建數(shù)據(jù)Retain刪除PVC時(shí)PV保留數(shù)據(jù)保留需手動(dòng)清理生產(chǎn)數(shù)據(jù)庫(kù)、重要數(shù)據(jù)Recycle已廢棄不要用無(wú)我個(gè)人的經(jīng)驗(yàn)是生產(chǎn)環(huán)境一律用Retain。哪怕你覺(jué)得這個(gè)數(shù)據(jù)不重要多留一份總比誤刪強(qiáng)。用Delete的時(shí)候一次誤操作kubectl delete pvc云盤直接被銷毀數(shù)據(jù)找都找不回來(lái)。Retain的代價(jià)只是需要手動(dòng)清理殘留PV但換來(lái)的是數(shù)據(jù)安全。注意reclaimPolicy在StorageClass上設(shè)置的是默認(rèn)值動(dòng)態(tài)創(chuàng)建的PV會(huì)繼承它。已經(jīng)創(chuàng)建的PV可以單獨(dú)改但改之前想清楚后果。3.3 volumeBindingModeWaitForFirstConsumer解決調(diào)度死鎖volumeBindingMode有兩個(gè)值Immediate和WaitForFirstConsumer。這個(gè)字段解決的是一個(gè)很隱蔽的問(wèn)題拓?fù)涓兄{(diào)度。假設(shè)集群有三個(gè)可用區(qū)云盤只能在創(chuàng)建它的那個(gè)可用區(qū)被掛載。如果用Immediate模式PVC一創(chuàng)建就立刻分配云盤可能分到了A區(qū)。然后Pod因?yàn)橘Y源原因被調(diào)度到B區(qū)結(jié)果B區(qū)掛不上A區(qū)的盤Pod永遠(yuǎn)起不來(lái)。WaitForFirstConsumer的意思是先別急著分配存儲(chǔ)等第一個(gè)用到這個(gè)PVC的Pod被調(diào)度時(shí)再根據(jù)Pod所在節(jié)點(diǎn)/可用區(qū)來(lái)分配存儲(chǔ)。這樣存儲(chǔ)和Pod就在同一個(gè)拓?fù)溆驋燧d自然成功。volumeBindingMode: WaitForFirstConsumer用了這個(gè)模式后PVC會(huì)先處于Pending狀態(tài)直到有Pod引用它。這是正常現(xiàn)象不要以為是出錯(cuò)了。多可用區(qū)集群強(qiáng)烈建議開(kāi)啟。3.4 在線擴(kuò)容allowVolumeExpansion的正確用法業(yè)務(wù)增長(zhǎng)5Gi不夠用了能不能不刪Pod直接擴(kuò)容可以但有幾個(gè)前提StorageClass必須設(shè)置allowVolumeExpansion: true。底層存儲(chǔ)插件必須支持?jǐn)U容。只能擴(kuò)不能縮。操作步驟# 直接編輯PVC改大storage值 kubectl patch pvc my-app-data -p {spec:{resources:{requests:{storage:10Gi}}}} # 觀察狀態(tài) kubectl get pvc my-app-data -w擴(kuò)容過(guò)程中PVC會(huì)顯示FileSystemResizePending然后需要重啟Pod或者等kubelet觸發(fā)文件系統(tǒng)擴(kuò)容才能讓容器內(nèi)看到新容量。文件系統(tǒng)擴(kuò)容是最后一步塊設(shè)備擴(kuò)容完成后還得把文件系統(tǒng)撐大這一步通常由kubelet自動(dòng)完成。我踩過(guò)的坑擴(kuò)容后kubectl exec進(jìn)去df -h發(fā)現(xiàn)容量沒(méi)變以為失敗了。其實(shí)是文件系統(tǒng)還沒(méi)resize重啟Pod后就好了。所以擴(kuò)容后一定要進(jìn)容器確認(rèn)實(shí)際可用容量。4. 常見(jiàn)故障排查與避坑經(jīng)驗(yàn)實(shí)錄4.1 PVC一直Pending的六種原因速查PVC Pending是最常見(jiàn)的故障原因基本逃不出下面六種。我整理成速查表按概率從高到低排現(xiàn)象可能原因排查命令解決方向Pending無(wú)Events沒(méi)有默認(rèn)StorageClasskubectl get sc指定storageClassName或設(shè)默認(rèn)類Pending提示no volume pluginProvisioner未部署kubectl get pods -n kube-system安裝對(duì)應(yīng)存儲(chǔ)插件Pending提示waiting for first consumerWaitForFirstConsumer模式正?，F(xiàn)象創(chuàng)建引用它的PodPending容量不匹配靜態(tài)PV容量小于PVC請(qǐng)求kubectl get pv創(chuàng)建足夠大的PVPending訪問(wèn)模式不匹配PV不支持PVC要求的模式kubectl describe pv換PV或改訪問(wèn)模式Pending拓?fù)洳黄ヅ銹V在別的可用區(qū)kubectl describe pv用WaitForFirstConsumer排查順序建議先describe pvc看EventsEvents里通常直接寫(xiě)了原因。沒(méi)有Events就查StorageClass再查PV列表。4.2 Pod卡在ContainerCreating掛載失敗的排查鏈路PVC是Bound的但Pod起不來(lái)一直ContainerCreating這種問(wèn)題更隱蔽。排查鏈路是這樣的# 第一步看Pod Events通常有掛載錯(cuò)誤 kubectl describe pod app-with-pvc # 第二步看kubelet日志在Pod所在節(jié)點(diǎn)上 journalctl -u kubelet -n 100 | grep -i mount # 第三步確認(rèn)節(jié)點(diǎn)上掛載點(diǎn)狀態(tài) mount | grep my-app-data常見(jiàn)原因RWO被多節(jié)點(diǎn)掛載一個(gè)PVC被兩個(gè)不同節(jié)點(diǎn)的Pod引用第二個(gè)節(jié)點(diǎn)掛載失敗。解決方法是確保副本調(diào)度到同一節(jié)點(diǎn)或改用RWX。節(jié)點(diǎn)上沒(méi)有掛載工具比如NFS需要nfs-common包云盤需要對(duì)應(yīng)的CSI驅(qū)動(dòng)。節(jié)點(diǎn)鏡像里沒(méi)裝掛載就失敗。權(quán)限問(wèn)題掛載路徑權(quán)限不對(duì)容器內(nèi)進(jìn)程無(wú)法寫(xiě)入。可以在securityContext里設(shè)置fsGroup來(lái)調(diào)整。提示fsGroup是個(gè)很實(shí)用的字段。設(shè)置后K8S會(huì)把掛載卷的組權(quán)限改成這個(gè)GID容器內(nèi)非root進(jìn)程也能寫(xiě)。很多“Permission denied”問(wèn)題靠它解決。4.3 數(shù)據(jù)“看起來(lái)丟了”的三種假象有時(shí)候你以為數(shù)據(jù)丟了其實(shí)只是沒(méi)找對(duì)地方。我遇到過(guò)三種假象假象一掛載點(diǎn)被覆蓋。容器內(nèi)mountPath如果和鏡像里已有目錄重名掛載后原目錄內(nèi)容被隱藏。比如把PVC掛到/etc/nginx鏡像里原有的配置文件全看不見(jiàn)了。解決辦法是掛到獨(dú)立目錄或者用subPath只掛某個(gè)子路徑。假象二寫(xiě)到了容器層。應(yīng)用配置的寫(xiě)入路徑和掛載路徑不一致數(shù)據(jù)寫(xiě)到了容器臨時(shí)層Pod一重啟就沒(méi)了。驗(yàn)證方法是進(jìn)容器df -h看目標(biāo)路徑是不是掛載點(diǎn)。假象三多副本各寫(xiě)各的。RWO模式下多個(gè)Pod在不同節(jié)點(diǎn)各自掛載失敗后回退到本地寫(xiě)入看起來(lái)“有數(shù)據(jù)”但其實(shí)是各寫(xiě)各的。這種最危險(xiǎn)一定要確認(rèn)PVC狀態(tài)和掛載點(diǎn)。4.4 subPath的妙用與陷阱subPath允許你把PVC里的某個(gè)子目錄掛到容器里而不是整個(gè)卷。這在“一個(gè)PVC給多個(gè)用途”時(shí)很有用volumeMounts: - name: data mountPath: /app/config subPath: config # 只掛載卷里的config子目錄 - name: data mountPath: /app/logs subPath: logs # 同一個(gè)卷的logs子目錄好處是多個(gè)掛載點(diǎn)共享一個(gè)PVC互不干擾。但有個(gè)陷阱subPath對(duì)應(yīng)的子目錄不會(huì)自動(dòng)創(chuàng)建。如果卷里沒(méi)有config目錄掛載后容器內(nèi)/app/config是個(gè)空目錄但寫(xiě)入會(huì)失敗或者寫(xiě)到別處。所以用subPath前確保子目錄已存在或者用initContainer先創(chuàng)建。另一個(gè)坑是subPath和ConfigMap/Secret一起用時(shí)更新不會(huì)自動(dòng)同步。因?yàn)閟ubPath掛載的是文件inodeConfigMap更新后inode變了但掛載點(diǎn)還指向舊的。這個(gè)特性在需要熱更新的場(chǎng)景要特別注意。5. 生產(chǎn)環(huán)境落地的幾點(diǎn)實(shí)戰(zhàn)心得5.1 命名規(guī)范與標(biāo)簽體系后期運(yùn)維省一半力氣PVC數(shù)量一多沒(méi)有規(guī)范就是災(zāi)難。我建議的命名格式是應(yīng)用名-用途-環(huán)境比如order-db-prod、order-logs-prod。標(biāo)簽至少打三個(gè)metadata: labels: app: order component: database env: prod這樣后期用kubectl get pvc -l apporder就能快速篩選清理時(shí)也不容易誤刪。別小看這個(gè)習(xí)慣集群里幾百個(gè)PVC的時(shí)候沒(méi)有標(biāo)簽根本管不過(guò)來(lái)。5.2 備份策略PVC不等于備份很多人以為用了PVC數(shù)據(jù)就安全了這是誤解。PVC保證的是Pod重建后數(shù)據(jù)還在但不保證誤刪、勒索、存儲(chǔ)故障時(shí)的數(shù)據(jù)安全。PVC被刪、底層存儲(chǔ)損壞數(shù)據(jù)照樣丟。所以生產(chǎn)環(huán)境必須做獨(dú)立備份。常見(jiàn)做法是用備份工具定期對(duì)PVC做快照或者用應(yīng)用層導(dǎo)出比如數(shù)據(jù)庫(kù)dump。快照依賴底層存儲(chǔ)支持應(yīng)用層導(dǎo)出更通用但需要應(yīng)用配合。兩者結(jié)合最穩(wěn)妥。5.3 容量規(guī)劃別等磁盤滿了才擴(kuò)容PVC申請(qǐng)容量時(shí)建議預(yù)留30%以上余量。磁盤寫(xiě)滿會(huì)導(dǎo)致應(yīng)用直接崩潰而且擴(kuò)容需要時(shí)間擴(kuò)容期間可能已經(jīng)出事故了。監(jiān)控上要盯兩個(gè)指標(biāo)PVC使用率和底層存儲(chǔ)池剩余容量。使用率超過(guò)70%就該規(guī)劃擴(kuò)容了。另外注意storage申請(qǐng)的是上限不是預(yù)分配。也就是說(shuō)你申請(qǐng)10Gi底層可能只實(shí)際占用1Gi但存儲(chǔ)后端會(huì)按10Gi預(yù)留配額。所以申請(qǐng)?zhí)罄速M(fèi)配額申請(qǐng)?zhí)☆l繁擴(kuò)容需要平衡。5.4 版本兼容性不同K8S版本的PVC行為差異PVC相關(guān)特性在不同版本有差異升級(jí)集群時(shí)要留意RWOP1.22進(jìn)入beta1.27左右穩(wěn)定。老版本用不了。卷擴(kuò)容1.24左右GA更早版本需要開(kāi)特性門控。卷快照1.20左右GA依賴CSI驅(qū)動(dòng)支持。通用臨時(shí)卷1.23 GA適合臨時(shí)數(shù)據(jù)場(chǎng)景。升級(jí)前查一下官方文檔的特性矩陣別想當(dāng)然以為新特性在所有版本都能用。我遇到過(guò)升級(jí)后PVC行為變化導(dǎo)致Pod起不來(lái)的情況回滾才發(fā)現(xiàn)是特性門控默認(rèn)值改了。5.5 一個(gè)真實(shí)場(chǎng)景的完整配置參考最后給一套我實(shí)際用過(guò)的配置模板場(chǎng)景是“單副本W(wǎng)eb應(yīng)用持久化上傳目錄”用動(dòng)態(tài)供應(yīng)Retain策略# StorageClass apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: app-storage provisioner: kubernetes.io/aws-ebs parameters: type: gp3 fsType: ext4 reclaimPolicy: Retain allowVolumeExpansion: true volumeBindingMode: WaitForFirstConsumer --- # PVC apiVersion: v1 kind: PersistentVolumeClaim metadata: name: web-uploads-prod namespace: prod labels: app: web component: uploads env: prod spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi storageClassName: app-storage --- # Deployment片段 apiVersion: apps/v1 kind: Deployment metadata: name: web namespace: prod spec: replicas: 1 selector: matchLabels: app: web template: metadata: labels: app: web spec: securityContext: fsGroup: 1000 # 解決權(quán)限問(wèn)題 containers: - name: web image: nginx:1.25 volumeMounts: - name: uploads mountPath: /var/www/uploads volumes: - name: uploads persistentVolumeClaim: claimName: web-uploads-prod這套配置的關(guān)鍵點(diǎn)Retain保數(shù)據(jù)、WaitForFirstConsumer保調(diào)度、fsGroup保權(quán)限、標(biāo)簽保運(yùn)維。實(shí)際跑下來(lái)很穩(wěn)擴(kuò)容和遷移都沒(méi)出過(guò)問(wèn)題。我個(gè)人在實(shí)際操作中的體會(huì)是PVC這東西入門不難難的是把訪問(wèn)模式、回收策略、綁定模式這幾個(gè)字段的組合吃透。很多故障不是配置寫(xiě)錯(cuò)了而是對(duì)底層存儲(chǔ)的能力邊界不清楚。多花點(diǎn)時(shí)間搞清楚你的存儲(chǔ)后端支持什么、不支持什么比背YAML模板有用得多。