1. 為什么要在K8S里折騰NFS動態(tài)供給很多團隊在K8S里跑有狀態(tài)服務(wù)時第一個繞不開的問題就是存儲。容器本身是無狀態(tài)的Pod一重啟寫在容器里的數(shù)據(jù)就沒了。早期大家最常用的辦法是hostPath或者emptyDir簡單粗暴但問題也很明顯Pod漂移到別的節(jié)點數(shù)據(jù)就找不到了多個副本想共享同一份數(shù)據(jù)更是無從談起。再往后一點有人開始用PVPersistentVolume加PVCPersistentVolumeClaim的靜態(tài)綁定方式。管理員提前創(chuàng)建好一堆PV用戶寫PVC去申請。這個方案在小規(guī)模場景下能用但一旦集群里跑了幾十個需要存儲的服務(wù)管理員就得手動創(chuàng)建幾十個PV還得盯著哪個被用了、哪個空著維護成本高得離譜。更麻煩的是用戶提交PVC時如果容量、訪問模式跟現(xiàn)有PV對不上PVC就會一直卡在Pending狀態(tài)排查起來也費勁。NFS動態(tài)供給就是為了解決這個痛點出現(xiàn)的。它的核心思路是集群里部署一個Provisioner供給器用戶只需要提交PVCProvisioner會自動在NFS服務(wù)器上創(chuàng)建對應(yīng)的目錄并生成匹配的PV然后自動跟PVC綁定。整個過程不需要管理員介入PVC提交后幾秒鐘就能變成Bound狀態(tài)Pod直接掛載使用。這套方案特別適合以下幾類場景中小規(guī)模集群里跑有狀態(tài)應(yīng)用比如數(shù)據(jù)庫、日志收集、文件共享服務(wù)團隊內(nèi)部測試環(huán)境需要快速給不同項目分配獨立存儲空間以及那些對存儲性能要求不是極致、但需要數(shù)據(jù)持久化和多副本共享的場景。NFS本身是網(wǎng)絡(luò)文件系統(tǒng)天然支持多節(jié)點同時掛載讀寫權(quán)限控制也相對成熟配合K8S的動態(tài)供給機制能省掉大量手工運維工作。不過我得先說清楚NFS動態(tài)供給不是銀彈。它的性能受網(wǎng)絡(luò)和NFS服務(wù)器磁盤IO限制高并發(fā)寫入場景下可能成為瓶頸另外NFS本身是單點服務(wù)器掛了所有掛載它的Pod都會受影響。所以生產(chǎn)環(huán)境用這套方案NFS服務(wù)端的高可用和備份策略必須提前規(guī)劃好。這篇文章我會從零開始把NFS服務(wù)端配置、Provisioner部署、StorageClass定義、PVC動態(tài)掛載、常見坑排查整個鏈路講透代碼和配置都可以直接抄作業(yè)。2. NFS服務(wù)端的搭建與導(dǎo)出目錄規(guī)劃2.1 選一臺合適的機器做NFS ServerNFS服務(wù)端不一定非要獨立物理機用一臺配置還行的虛擬機或者閑置服務(wù)器都行。我的經(jīng)驗是磁盤IO盡量好一點因為所有Pod的讀寫最終都落到這臺機器的磁盤上。如果預(yù)算有限至少保證數(shù)據(jù)盤是SSD系統(tǒng)盤用機械盤無所謂。內(nèi)存和CPU要求不高2核4G就能跑得很穩(wěn)但如果掛載的Pod數(shù)量多、并發(fā)讀寫頻繁建議4核8G起步。操作系統(tǒng)層面主流的Linux發(fā)行版都自帶NFS服務(wù)端軟件包。我習(xí)慣用較新的穩(wěn)定版系統(tǒng)內(nèi)核里NFS模塊支持比較完善。安裝之前先確認一下系統(tǒng)是否已經(jīng)裝了nfs-utils或者nfs-kernel-server不同發(fā)行版包名不一樣。用rpm -qa | grep nfs或者dpkg -l | grep nfs查一下有的話就不用重復(fù)裝。網(wǎng)絡(luò)方面NFS服務(wù)端和K8S集群節(jié)點最好在同一個內(nèi)網(wǎng)網(wǎng)段延遲低、帶寬足。如果跨網(wǎng)段記得防火墻要放行NFS相關(guān)端口。NFS默認用2049端口做數(shù)據(jù)傳輸?shù)o助服務(wù)mountd、rpcbind會隨機用一些端口所以生產(chǎn)環(huán)境建議在配置文件里把端口固定下來方便防火墻規(guī)則管理。2.2 安裝NFS服務(wù)端并配置導(dǎo)出目錄以常見的Linux發(fā)行版為例安裝命令大概是這樣的# Debian/Ubuntu系 apt-get update apt-get install -y nfs-kernel-server # RHEL/CentOS系 yum install -y nfs-utils裝完之后創(chuàng)建專門用于K8S存儲的目錄。我一般會單獨掛一塊數(shù)據(jù)盤掛載到/data/nfs這樣的路徑下然后在這個目錄里再分門別類。比如mkdir -p /data/nfs/k8s chmod 777 /data/nfs/k8s這里權(quán)限給777是為了省事讓Provisioner能直接創(chuàng)建子目錄。但生產(chǎn)環(huán)境更穩(wěn)妥的做法是創(chuàng)建一個專用用戶把目錄屬主改掉然后在NFS導(dǎo)出配置里做用戶映射。不過K8S的NFS Provisioner默認以root身份操作如果服務(wù)端做了root_squash創(chuàng)建目錄時可能會權(quán)限不足。所以測試環(huán)境我通常先關(guān)掉root_squash生產(chǎn)環(huán)境再根據(jù)安全要求調(diào)整。接下來編輯/etc/exports文件配置導(dǎo)出規(guī)則/data/nfs/k8s *(rw,sync,no_subtree_check,no_root_squash)這行配置的意思是把/data/nfs/k8s目錄導(dǎo)出給所有網(wǎng)段讀寫權(quán)限同步寫入不檢查子目錄并且不壓縮root用戶權(quán)限。sync選項保證數(shù)據(jù)寫入磁盤后才返回成功雖然性能比async差一點但數(shù)據(jù)安全性高很多。no_root_squash讓客戶端的root用戶在服務(wù)端也保持root權(quán)限這樣Provisioner創(chuàng)建目錄時不會因為權(quán)限問題失敗。配置改完后讓導(dǎo)出規(guī)則生效exportfs -arv然后重啟NFS服務(wù)systemctl restart nfs-kernel-server systemctl enable nfs-kernel-server在K8S節(jié)點上驗證一下能不能掛載showmount -e NFS_SERVER_IP mount -t nfs NFS_SERVER_IP:/data/nfs/k8s /mnt能掛上并且能讀寫文件說明服務(wù)端配置沒問題。這一步很關(guān)鍵很多后續(xù)問題都是因為服務(wù)端導(dǎo)出配置不對導(dǎo)致的所以務(wù)必先手工驗證通過再往下走。2.3 固定NFS輔助服務(wù)端口前面提到NFS除了2049端口還會用到mountd和rpcbind的隨機端口。如果K8S節(jié)點和NFS服務(wù)端之間有防火墻隨機端口會被攔掉導(dǎo)致掛載超時。解決辦法是在NFS服務(wù)端配置文件里把端口固定。編輯/etc/nfs.conf或者/etc/sysconfig/nfs不同發(fā)行版路徑不同設(shè)置[lockd] port32803 udp-port32769 [mountd] port20048 [statd] port32765 outgoing-port32766改完后重啟服務(wù)然后用rpcinfo -p確認端口都固定了。防火墻放行2049、20048、32803、32765這些端口。這一步做完跨網(wǎng)段掛載基本就不會因為端口問題卡住了。3. 部署NFS Subdir External Provisioner3.1 Provisioner的工作原理與選型K8S官方并沒有內(nèi)置NFS動態(tài)供給器社區(qū)里用得最多的是nfs-subdir-external-provisioner這個項目。它的工作邏輯很清晰監(jiān)聽集群里新創(chuàng)建的PVC一旦發(fā)現(xiàn)PVC的StorageClass匹配自己就在NFS服務(wù)端的導(dǎo)出目錄下創(chuàng)建一個以${namespace}-${pvcName}-${pvName}命名的子目錄然后生成對應(yīng)的PV對象最后把PV和PVC綁定。這個Provisioner以Deployment形式跑在集群里通常單副本就夠了。它內(nèi)部用了一個小的控制器循環(huán)通過K8S的API監(jiān)聽PVC事件。因為NFS本身不支持配額管理所以PVC里申請的容量大小實際上只是個標簽并不會真正限制目錄使用空間。這一點要特別注意別以為申請了10G就只能用10G實際能寫多少取決于NFS服務(wù)端磁盤剩余空間。選型方面社區(qū)還有基于CSI的NFS驅(qū)動功能更豐富支持快照、擴容等高級特性。但如果只是基礎(chǔ)的文件共享和持久化需求nfs-subdir-external-provisioner足夠用部署簡單維護成本低。我下面就以這個方案為例來展開。3.2 用Helm快速部署Provisioner手工寫一堆YAML比較繁瑣推薦用Helm Chart來部署。先添加倉庫helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/ helm repo update然后創(chuàng)建一個values文件把NFS服務(wù)端地址和導(dǎo)出路徑填進去nfs: server: NFS_SERVER_IP path: /data/nfs/k8s storageClass: name: nfs-client defaultClass: false reclaimPolicy: Delete archiveOnDelete: true這里幾個參數(shù)值得說明一下。reclaimPolicy: Delete表示PVC刪除后對應(yīng)的PV和NFS目錄也會被清理掉。archiveOnDelete: true是個很實用的選項它不會直接刪目錄而是把目錄重命名成archived-xxx相當(dāng)于留了個后悔藥。萬一誤刪了PVC數(shù)據(jù)還在NFS服務(wù)端能找到。生產(chǎn)環(huán)境我強烈建議開啟這個選項。執(zhí)行安裝helm install nfs-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \ -f values.yaml \ -n kube-system裝完后檢查Pod狀態(tài)kubectl get pods -n kube-system | grep nfs看到Running就說明Provisioner起來了。再看一下StorageClasskubectl get sc應(yīng)該能看到名為nfs-client的StorageClass。如果沒看到多半是RBAC權(quán)限或者鏡像拉取有問題用kubectl logs看Provisioner的日志排查。3.3 手工部署方式與關(guān)鍵配置解讀有些環(huán)境不方便用Helm那就手工部署。核心資源包括ServiceAccount、ClusterRole、ClusterRoleBinding、Deployment、StorageClass。我重點說Deployment里的幾個關(guān)鍵配置。Provisioner容器啟動參數(shù)里--provisioner指定供給器名稱必須和StorageClass里的provisioner字段一致否則PVC不會觸發(fā)動態(tài)供給。--nfs-server和--nfs-path指定NFS服務(wù)端信息。環(huán)境變量POD_NAMESPACE用fieldRef注入讓Provisioner知道自己跑在哪個命名空間。Deployment的volume部分要掛載一個NFS卷指向服務(wù)端的導(dǎo)出目錄。這樣Provisioner容器內(nèi)部才能在該目錄下創(chuàng)建子目錄。掛載配置大概長這樣volumes: - name: nfs-client-root nfs: server: NFS_SERVER_IP path: /data/nfs/k8s容器里的掛載點通常是/persistentvolumesProvisioner就在這個路徑下創(chuàng)建子目錄。StorageClass的YAML里provisioner字段填k8s-sigs.io/nfs-subdir-external-provisionerreclaimPolicy按需選Delete或RetainvolumeBindingMode用Immediate就行NFS不涉及拓撲感知調(diào)度。手工部署的好處是每個字段都看得見出問題容易定位。Helm部署省事但排查時得先helm get manifest把渲染后的YAML導(dǎo)出來看。兩種方式我都用過建議新手先手工部署一遍理解每個組件的作用之后再上Helm提效。4. PVC動態(tài)掛載的完整實操鏈路4.1 創(chuàng)建一個測試PVC并觀察綁定過程StorageClass就緒后創(chuàng)建一個PVC試試apiVersion: v1 kind: PersistentVolumeClaim metadata: name: test-pvc namespace: default spec: accessModes: - ReadWriteMany storageClassName: nfs-client resources: requests: storage: 1Gi注意accessModes這里寫的是ReadWriteMany因為NFS天然支持多節(jié)點讀寫。如果寫ReadWriteOnce雖然也能綁定但語義上不太匹配NFS的能力。storageClassName必須和前面創(chuàng)建的StorageClass名字一致。提交之后用kubectl get pvc -w盯著看。正常流程是PVC先變成PendingProvisioner監(jiān)聽到事件在NFS目錄下創(chuàng)建子目錄生成PV然后PVC變成Bound。整個過程通常幾秒鐘。如果超過一分鐘還是Pending就要查Provisioner日志了。綁定成功后kubectl get pv能看到自動生成的PV名字一般是pvc-uuid格式。PV的claimRef指向剛才的PVCnfs字段里的path就是Provisioner創(chuàng)建的子目錄路徑。到NFS服務(wù)端上ls /data/nfs/k8s應(yīng)該能看到一個類似default-test-pvc-pvc-xxxx的目錄。4.2 用Deployment掛載PVC驗證讀寫光綁定成功還不夠得實際掛載進Pod驗證讀寫。寫一個簡單的DeploymentapiVersion: apps/v1 kind: Deployment metadata: name: nfs-test-app spec: replicas: 2 selector: matchLabels: app: nfs-test template: metadata: labels: app: nfs-test spec: containers: - name: app image: busybox command: [/bin/sh, -c, while true; do echo $(date) /data/out.txt; sleep 5; done] volumeMounts: - name: nfs-vol mountPath: /data volumes: - name: nfs-vol persistentVolumeClaim: claimName: test-pvc這個Deployment跑兩個副本每個副本每5秒往/data/out.txt追加一行時間戳。因為兩個副本掛的是同一個NFS目錄所以它們會往同一個文件里寫。等一會兒進Pod里看kubectl exec -it pod-name -- cat /data/out.txt應(yīng)該能看到時間戳在不斷增加而且兩個副本寫入的內(nèi)容混在一起。這就驗證了NFS的ReadWriteMany能力。如果只有一個副本能寫、另一個報權(quán)限錯誤那多半是NFS服務(wù)端導(dǎo)出配置里root_squash沒關(guān)或者目錄權(quán)限不對。4.3 刪除PVC時數(shù)據(jù)到底去哪了這是很多人容易踩坑的地方。前面StorageClass里配了reclaimPolicy: Delete和archiveOnDelete: true。當(dāng)你刪除PVC時PV會被刪除但NFS目錄不會被真刪而是被重命名為archived-原目錄名。你可以到NFS服務(wù)端確認ls /data/nfs/k8s/ # 會看到 archived-default-test-pvc-pvc-xxxx 這樣的目錄如果archiveOnDelete設(shè)為false那目錄就直接被刪了數(shù)據(jù)找不回來。所以生產(chǎn)環(huán)境務(wù)必開啟歸檔。另外如果reclaimPolicy設(shè)為RetainPV會變成Released狀態(tài)目錄保留原名但PV不能被新PVC復(fù)用需要管理員手工清理。三種組合的行為差異挺大建議在測試環(huán)境都試一遍心里有數(shù)。還有一個細節(jié)刪除PVC時如果還有Pod在掛載使用PVC會卡在Terminating狀態(tài)直到Pod被刪掉。這是K8S的保護機制防止數(shù)據(jù)正在寫入時被強制卸載。所以下線服務(wù)時先刪Pod再刪PVC順序別搞反。5. 那些讓我熬夜排查的坑與應(yīng)對方案5.1 PVC一直Pending的幾種典型原因PVC卡在Pending是最常見的故障。排查思路要按順序來先看StorageClass名字對不對kubectl get pvc name -o yaml看storageClassName字段如果為空或者拼錯Provisioner根本不會理它。再看Provisioner Pod是否正常運行kubectl logs看有沒有報錯。常見錯誤包括連不上NFS服務(wù)端、創(chuàng)建目錄權(quán)限不足、RBAC權(quán)限不夠。連不上NFS服務(wù)端的情況日志里會顯示mount failed或者connection timed out。這時候先在Provisioner Pod里手動掛載測試kubectl exec進去mount -t nfs server:/path /mnt看報什么錯。如果是端口不通檢查防火墻和端口固定配置如果是權(quán)限拒絕檢查/etc/exports里的客戶端網(wǎng)段限制。權(quán)限不足的報錯通常是mkdir permission denied。這是因為NFS服務(wù)端做了root_squash而Provisioner以root身份創(chuàng)建目錄被映射成了nobody。解決辦法是在exports里加no_root_squash或者把導(dǎo)出目錄權(quán)限放開。我一般測試環(huán)境直接chmod 777加no_root_squash生產(chǎn)環(huán)境再收緊。5.2 掛載成功但寫入報Read-only file system這個坑我踩過好幾次。Pod掛載PVC成功但一寫文件就報只讀。原因通常是NFS服務(wù)端導(dǎo)出目錄的權(quán)限問題或者exports配置里寫成了ro。檢查/etc/exports確認是rw不是ro。另外如果NFS服務(wù)端磁盤滿了或者文件系統(tǒng)變成只讀比如磁盤故障也會導(dǎo)致客戶端寫入失敗。用df -h和mount命令確認服務(wù)端磁盤狀態(tài)。還有一種情況是SELinux在搗亂。某些發(fā)行版默認開啟SELinux會阻止NFS客戶端寫入。臨時用setenforce 0測試如果好了就說明是SELinux策略問題需要配置相應(yīng)的布爾值或者策略規(guī)則。生產(chǎn)環(huán)境不建議直接關(guān)SELinux而是加規(guī)則放行。5.3 Provisioner Pod反復(fù)重啟的排查Provisioner Pod如果一直CrashLoopBackOff先看日志。常見原因是鏡像拉取失敗國內(nèi)環(huán)境拉registry.k8s.io的鏡像可能超時需要提前把鏡像同步到私有倉庫或者用鏡像加速。另一個原因是RBAC配置不全Provisioner沒有權(quán)限監(jiān)聽PVC和創(chuàng)建PV日志里會報forbidden。檢查ClusterRole里是否包含了persistentvolumes的create、delete、list、watch權(quán)限以及persistentvolumeclaims的get、list、watch、update權(quán)限。還有一個隱蔽的問題Provisioner的Deployment里掛載NFS卷時如果NFS服務(wù)端地址寫錯或者網(wǎng)絡(luò)不通Pod會一直卡在ContainerCreating。用kubectl describe pod看Events會顯示FailedMount。這時候回到NFS服務(wù)端確認服務(wù)是否正常網(wǎng)絡(luò)是否可達。5.4 多副本并發(fā)寫入的數(shù)據(jù)一致性問題NFS本身提供的是最終一致性不是強一致性。多個Pod同時往同一個文件追加內(nèi)容在低并發(fā)下一般沒問題但高并發(fā)時可能出現(xiàn)內(nèi)容交錯或者部分丟失。如果業(yè)務(wù)對數(shù)據(jù)一致性要求高建議每個Pod寫自己的獨立文件而不是共享同一個文件。比如用Pod名字或者IP作為文件名后綴避免寫沖突。另外NFS的鎖機制在某些場景下不太可靠尤其是跨多個NFS客戶端做文件鎖時。如果應(yīng)用依賴文件鎖做互斥最好換成基于數(shù)據(jù)庫或者Redis的分布式鎖別依賴NFS鎖。這個坑在跑一些老式應(yīng)用時特別容易遇到表現(xiàn)是偶爾出現(xiàn)兩個進程同時寫同一份數(shù)據(jù)導(dǎo)致文件損壞。6. 生產(chǎn)環(huán)境落地時的容量與性能考量6.1 NFS服務(wù)端磁盤容量規(guī)劃與監(jiān)控因為NFS動態(tài)供給不限制單個PVC的實際使用量所以服務(wù)端磁盤很容易被某個失控的應(yīng)用寫滿。一旦磁盤滿所有掛載該NFS的Pod都會寫入失敗影響面很大。我的做法是給NFS數(shù)據(jù)盤單獨分區(qū)并且設(shè)置監(jiān)控告警使用率超過80%就通知。監(jiān)控可以用Node Exporter采集磁盤指標配合Prometheus和Alertmanager做告警規(guī)則。容量規(guī)劃上先估算所有有狀態(tài)服務(wù)的總存儲需求然后留至少30%的余量。比如預(yù)計總共需要500G那就準備至少700G的磁盤。如果增長快可以考慮用LVM做動態(tài)擴容或者直接上分布式存儲方案替代NFS。但分布式存儲運維復(fù)雜度高小團隊用NFS加監(jiān)控就夠了。6.2 提升NFS讀寫性能的幾個實用參數(shù)NFS掛載參數(shù)對性能影響很大。K8S的NFS Volume默認掛載參數(shù)比較保守可以在StorageClass的mountOptions里調(diào)整mountOptions: - nfsvers4.1 - rsize1048576 - wsize1048576 - hard - timeo600 - retrans2 - noresvportrsize和wsize設(shè)成1M可以提升大文件傳輸吞吐。nfsvers4.1比3版本在并發(fā)和安全性上更好。hard表示掛載操作會一直重試而不是報錯返回避免網(wǎng)絡(luò)抖動導(dǎo)致應(yīng)用看到IO錯誤。noresvport讓客戶端使用非保留端口某些NFS服務(wù)端配置下必須加這個才能掛載成功。不過這些參數(shù)不是萬能的得根據(jù)實際網(wǎng)絡(luò)和負載調(diào)。我一般先用默認參數(shù)跑一輪基準測試記錄IOPS和吞吐然后逐項調(diào)整對比。用fio或者dd做簡單測試就行別搞太復(fù)雜。6.3 NFS服務(wù)端高可用與數(shù)據(jù)備份思路NFS服務(wù)端是單點掛了整個存儲層就不可用。提升可用性有兩個方向一是用DRBD加Keepalived做雙機熱備主備切換時VIP漂移客戶端重新掛載二是直接用云廠商的NAS服務(wù)底層做了高可用省心但成本高。小團隊如果預(yù)算有限雙機熱備方案比較現(xiàn)實但切換過程中會有短暫中斷應(yīng)用要能容忍。數(shù)據(jù)備份方面NFS服務(wù)端上的數(shù)據(jù)目錄要定期備份到另一臺機器或者對象存儲。可以用rsync做增量同步或者用restic、borg這類工具做去重加密備份。備份策略根據(jù)數(shù)據(jù)重要程度定核心數(shù)據(jù)每天全備加每小時增量非核心數(shù)據(jù)每天一次就行。備份完一定要做恢復(fù)演練不然真出事的時候發(fā)現(xiàn)備份不能用就尷尬了。7. 從靜態(tài)PV到動態(tài)供給的遷移經(jīng)驗7.1 存量靜態(tài)PV如何平滑過渡如果集群里已經(jīng)有一批靜態(tài)PV在用想遷移到動態(tài)供給不能直接刪了重建得考慮數(shù)據(jù)遷移。我的做法是先部署好Provisioner和StorageClass新業(yè)務(wù)一律用動態(tài)PVC。存量靜態(tài)PV繼續(xù)保留等對應(yīng)服務(wù)下次發(fā)版或者維護窗口時再逐步遷移。遷移單個服務(wù)時先把老PV里的數(shù)據(jù)用rsync或者cp拷到新創(chuàng)建的動態(tài)PVC掛載目錄里然后改Deployment的PVC引用重啟Pod驗證數(shù)據(jù)完整。確認沒問題后再刪掉老PVC和PV。整個過程可以在線做但最好選業(yè)務(wù)低峰期避免數(shù)據(jù)拷貝影響性能。7.2 多命名空間下的存儲隔離動態(tài)供給默認所有命名空間共用一個StorageClassPVC名字在不同命名空間可以重復(fù)Provisioner創(chuàng)建的目錄會帶上命名空間前綴所以不會沖突。但如果想給不同團隊分配不同的NFS導(dǎo)出目錄可以創(chuàng)建多個StorageClass每個指向不同的NFS路徑。比如給開發(fā)團隊用/data/nfs/dev給測試團隊用/data/nfs/test通過StorageClass名字區(qū)分。RBAC層面也可以做限制讓某個命名空間只能使用特定的StorageClass。不過這需要額外配置K8S原生不直接支持StorageClass級別的命名空間隔離得靠準入控制器或者策略引擎來實現(xiàn)。小規(guī)模場景下靠命名規(guī)范和人工約定就夠了不必過度設(shè)計。7.3 日常運維中值得固化的幾個檢查項跑了一段時間后我總結(jié)了幾條日常檢查清單每周花幾分鐘過一遍能避免大部分突發(fā)故障。第一確認Provisioner Pod狀態(tài)正常沒有重啟記錄。第二檢查NFS服務(wù)端磁盤使用率超過閾值就清理歸檔目錄。第三看有沒有長期處于Pending或者Terminating狀態(tài)的PVC及時處理。第四驗證備份任務(wù)是否按時完成備份文件大小是否正常。這些檢查項可以寫成腳本定時跑輸出結(jié)果發(fā)到運維群或者郵件。自動化程度不用太高關(guān)鍵是形成習(xí)慣。存儲這東西平時不出事一出事就是大事提前花點時間巡檢比事后救火劃算得多。8. 寫在最后的一點個人體會這套NFS動態(tài)供給方案我在好幾個集群里用過從測試環(huán)境到中小規(guī)模生產(chǎn)環(huán)境都跑得挺穩(wěn)。它最大的價值是把存儲分配這件事從手工操作變成了自助服務(wù)開發(fā)同學(xué)提交PVC就能用運維不用再當(dāng)人肉PV工廠。但前提是NFS服務(wù)端要配好、監(jiān)控要到位、備份要可靠這三樣缺一個都可能埋雷。另外提醒一句NFS終究是網(wǎng)絡(luò)存儲延遲比本地盤高一個數(shù)量級。對IO延遲敏感的應(yīng)用比如高頻交易或者實時數(shù)據(jù)庫還是老老實實用本地SSD或者專業(yè)塊存儲。NFS適合的是那些對延遲不敏感、但需要共享和持久化的場景。選型的時候想清楚業(yè)務(wù)需求別為了圖省事把不合適的負載硬塞進來后面性能問題會讓你更頭疼。