初探Kubernetes動態卷存儲(NFS)

前言：K8S是一個成熟的容器業務集群管理方案，但是目前來講，在存儲方面顯得過于復雜和繁瑣，更不要說中間穿插著資源訪問權限和認證的管理，盡管google在開源它之前有很多年的實戰經驗，但是從目前官方的發布文檔來看，依然顯得學習成本略高，我們來看看這個學習流程：

1，最初，學習k8s發現它羅列了一系列存儲方案，無非就是對一系列本地和云存儲的廣泛支持：

看到這么多的存儲卷類型的確很唬人，但是沒有辦法，在目前存儲界沒有達到統一（也不可能統一）之前，為了保持自己的強大的生態兼容性，K8S作出了無奈之舉。

2，好在我們不需要學習每一種存儲類型，只要要針對需要的存儲卷類型進行了解和學習，接著，為了讓Pod和存儲資源管理解耦，K8S又引入了PV和PVC的概念，于是集群管理員和研發人員各司其職，但是帶來了額外的PV和PVC的創建，刪除以及存儲卷的綁定和回收以及讀寫控制等資源管理工作。

3，當集群規模增長后，發現PV和PVC的管理開銷驚人的時候，K8S又引入StorageClass的動態卷以及基于storageClass 的CSI的概念，這是目前K8S存儲靈活分配的終極方案。

4，就在我們還沒有完全理解StorageClass和CSI的時候，我們在官網又看到相關的Clone和Snapshot已經出來了。

?????? 說明一個問題，業務需求場景不斷升級，業務需求量不斷變大，解決方案也不斷更新和變更，僅僅一個存儲就前后涉及諸多概念，實在讓人有點無所適從，弱水三千，取一瓢飲，今天這個實驗是針對NFS的共享存儲展開的。

?????? 為什么圍繞NFS展開實驗呢？因為從企業來講，NFS共享在企業私有云內部非常容易取得，并且成本較低，一臺普通的四盤位的企業級NAS服務器出廠即攜帶穩定可靠的NFS服務，無需自己部署，和企業的文件共享服務器集成，無需另外的硬件和部署成本。

首先，我們驗證NAS服務器的NFS服務是否就位：

1，啟動NFS客戶端：

掛載前，請確保系統中已經安裝了nfs-utils或nfs-common，安裝方法如下：
CentOS：

yum?install?nfs-utils?-y

注意：這一步是必須的，道理很簡單，即便是K8S也沒有什么神通，底層依然是通過nfs驅動去掛載文件系統，如果連nfs套件都不安裝，哪怕K8S所有配置都正確無誤，在創建接口pod的時候，會提示報錯說NFS服務路徑無法連接，為了體驗這個錯誤，建議先不安裝，假設你的nfs服務正常，后面再安裝，就可以看到錯誤消失。

Ubuntu 或 Debian：

apt-get?install?nfs-common

創建掛載路徑：

mkdir??/nfs

確認遠端NAS服務器上面存在的NFS服務和共享路徑：

掛載NFS共享路徑：

mount?-t?nfs??NAS服務器的IP:/NAS-NFS

我們可以進入掛載路徑嘗試創建文件夾，看是否掛載成功并且讀寫正常；

容易出問題的是，掛載成功但是無法創建文件夾，提示文件系統只讀，但是ls命令顯示777，這是因為NAS服務器的NFS服務權限沒有開放匿名訪問的讀寫權限：

不同的NAS設備可能配置不太一樣，請根據自己的NFS服務器的配置開啟讀寫。

以上全部成功后進一步測試NFS共享存儲在PV，PVC中是否工作正常：

2，創建測試的靜態PV和PVC

pv.yml

apiVersion:?v1
kind:?PersistentVolume
metadata:
??name:?mypv1
spec:
??capacity:
????storage:?4Gi
??accessModes:
????-?ReadWriteOnce
??persistentVolumeReclaimPolicy:?Recycle
??nfs:
????path:?/NAS-NFS
????server:?[NAS服務器IP或域名]

pvc.yml

kind:?PersistentVolumeClaim
apiVersion:?v1
metadata:
??name:?mypvc1
spec:
??accessModes:
????-?ReadWriteOnce
??resources:
????requests:
??????storage:?100Mi

開始創建資源對象（為了簡化實驗，所有資源對象都是默認的命名空間default展開）：

其實動態存儲的命名空間是任何一個都無所謂，因為動態創建的PV是集群級別的，可以被任何一個命名空間的pvc請求并綁定。

并且dashboard里面顯示，綁定成功：

以上實驗充分證明nfs系統工作正常，刪除以上測試的內容，進行下一步。

注意：

如果不刪除PVC來解除資源的占用，是無法直接刪除PV并釋放資源，違反K8S的持久化原則：

具體操作表現在三個方面:

1，kubectl delete pv 命令一直停留在執行狀態不顯示結果；

2，Dashboard資源對象一直正常顯示存在，無視刪除操作；

3，命令行強制退出刪除命令，但是并不代表撤銷刪除操作，而是掛起，一直等待PVC手工清除，系統隨即立即釋放PV.

想要動態生成PV，需要運行一個NFS-Provisioner服務，將已配置好的NFS系統相關參數錄入，向用戶提供創建PV的服務。

官方推薦使用Deployment運行一個副本集來實現，當然也可以使用Daemonset等其他方式，這些都在官方文檔中提供了。

創建持久卷的服務訪問角色，角色綁定，權限分配供Provisioner角色后臺調用：

apiVersion:?v1
kind:?ServiceAccount
metadata:
??name:?nfs-provisioner
---
kind:?ClusterRole
apiVersion:?rbac.authorization.k8s.io/v1
metadata:
??name:?nfs-provisioner-runner
rules:
??-?apiGroups:?[""]
????resources:?["persistentvolumes"]
????verbs:?["get",?"list",?"watch",?"create",?"delete"]
??-?apiGroups:?[""]
????resources:?["persistentvolumeclaims"]
????verbs:?["get",?"list",?"watch",?"update"]
??-?apiGroups:?["storage.k8s.io"]
????resources:?["storageclasses"]
????verbs:?["get",?"list",?"watch"]
??-?apiGroups:?[""]
????resources:?["events"]
????verbs:?["create",?"update",?"patch"]
---
kind:?ClusterRoleBinding
apiVersion:?rbac.authorization.k8s.io/v1
metadata:
??name:?run-nfs-provisioner
subjects:
??-?kind:?ServiceAccount
????name:?nfs-provisioner
????namespace:?default
roleRef:
??kind:?ClusterRole
??name:?nfs-provisioner-runner
??apiGroup:?rbac.authorization.k8s.io
---
kind:?Role
apiVersion:?rbac.authorization.k8s.io/v1
metadata:
??name:?leader-locking-nfs-provisioner
rules:
??-?apiGroups:?[""]
????resources:?["endpoints"]
????verbs:?["get",?"list",?"watch",?"create",?"update",?"patch"]
---
kind:?RoleBinding
apiVersion:?rbac.authorization.k8s.io/v1
metadata:
??name:?leader-locking-nfs-provisioner
subjects:
??-?kind:?ServiceAccount
????name:?nfs-provisioner
????#?replace?with?namespace?where?provisioner?is?deployed
????namespace:?default
roleRef:
??kind:?Role
??name:?leader-locking-nfs-provisioner
??apiGroup:?rbac.authorization.k8s.io

創建NFS服務的provisioner角色，部署結果是得到一個Pod來響應各種cliet提交的存儲資源請求：

編寫deployment.yaml文件如下：

kind:?Deployment
apiVersion:?extensions/v1beta1
metadata:
??name:?nfs-provisioner
spec:
??replicas:?1
??strategy:
????type:?Recreate
??template:
????metadata:
??????labels:
????????app:?nfs-provisioner
????spec:
??????serviceAccount:?nfs-provisioner
??????containers:
????????-?name:?nfs-provisioner
??????????image:?registry.cn-hangzhou.aliyuncs.com/open-ali/nfs-client-provisioner
???????????#官方鏡像：quay.io/external_storage/nfs-client-provisioner:latest?無法下載，使用上面阿里云鏡像代替
??????????volumeMounts:
????????????-?name:?nfs-client-root
??????????????mountPath:?/persistentvolumes
??????????env:
????????????-?name:?PROVISIONER_NAME
??????????????value:?example.com/nfs
????????????-?name:?NFS_SERVER
??????????????value:?[NAS服務器的IP地址]
????????????-?name:?NFS_PATH
??????????????value:?/NAS-NFS???#NFS系統的掛載路徑
??????volumes:
????????-?name:?nfs-client-root
??????????nfs:
????????????server:?[NAS服務器的IP地址]
????????????path:?/NAS-NFS???#NFS系統的掛載路徑

將以上文件通過kubectl命令創建完畢后，我們查看K8S部署結果：

我們得到一個副本集和這個副本集啟動一個Pod，來充當nfs-client-provisioner角色，這個角色用來響應各種存儲資源請求，但是并不能直接使用，需要用StorageClass去觸發。

創建存儲類StorageClass

編寫并創建storageclass.yaml如下：

kind:?StorageClass
apiVersion:?storage.k8s.io/v1
metadata:
??name:?nfs
provisioner:?example.com/nfs

接下來要創建測試的PVC，以檢測StorageClass能否正常工作：

編寫并創建test-claim.yaml如下，注意storageClassName應確保與上面創建的StorageClass名稱一致。

kind:?PersistentVolumeClaim
apiVersion:?v1
metadata:
??name:?test-claim1
spec:
??accessModes:
????-?ReadWriteMany
??resources:
????requests:
??????storage:?1Mi
??storageClassName:?nfs???#這里和創建的SC名稱保持一致

創建后，用kubectl get pvc查看，觀察新創建的PVC能夠自動綁定PV。

創建一個測試的Pod使用這個PVC，編寫test-pod.yaml文件如下：

kind:?Pod
apiVersion:?v1
metadata:
??name:?test-pod
spec:
??containers:
??-?name:?test-pod
????image:?busybox
????command:
??????-?"/bin/sh"
????args:
??????-?"-c"
??????-?"touch?/mnt/SUCCESS?&&?exit?0?||?exit?1"
????volumeMounts:
??????-?name:?nfs-pvc
????????mountPath:?"/mnt"
??restartPolicy:?"Never"
??volumes:
????-?name:?nfs-pvc
??????persistentVolumeClaim:
????????claimName:?test-claim1

查看Pod狀態是否變為Completed。如果是，則應該能在NFS系統的共享路徑中看到一個SUCCESS文件。

這樣，StorageClass動態創建PV的功能就成功實現了。

普通的pod是在編排文件里面通過聲明預先手工創建PVC去請求storageclass來自動獲取動態卷，實際上這種自動由于PVC的存在也屬于半自動，還是不夠靈活，所以，官方推薦使用statefulset；

編寫statefulset.yaml文件如下：

apiVersion:?apps/v1beta1
kind:?StatefulSet
metadata:
??name:?web
spec:
??serviceName:?"nginx1"
??replicas:?2
??volumeClaimTemplates:
??-?metadata:
??????name:?test
??????annotations:
????????volume.beta.kubernetes.io/storage-class:?"nfs"???#?nfs和前面定義的storageclass的名稱保持一致
????spec:
??????accessModes:?[?"ReadWriteOnce"?]
??????resources:
????????requests:
??????????storage:?1Gi
??template:
????metadata:
??????labels:
????????app:?nginx1
????spec:
??????serviceAccount:?nfs-provisioner?????#和前面創建的資源訪問角色保持一致
??????containers:
??????-?name:?nginx1
????????image:?nginx
????????imagePullPolicy:?IfNotPresent
????????volumeMounts:
????????-?mountPath:?"/my_dir"??#此掛載路徑可以任意指定
??????????name:?test

查看執行結果：

查看存儲資源創建結果：

打開nfs的文件系統目錄，發現和PV對應的資源文件夾自動生成：

文件夾的自動命名規則為pod的各種資源名稱的集合。

進一步的，可以用kubectl exec -it 進入其中一個Pod中驗證,可以看到K8S也不是神仙，也是通過mount的方式將NFS路徑下生成一個臨時路徑掛載到容器內的指定的編排路徑：

至此，實驗基本完成。

github有官方上傳的現成源碼，和上面基本一致，此教程只是將過程詳細證明出來：

https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client