一、NFS Provisioner 簡介
NFS Provisioner 是一個自動配置卷程序,它使用現有的和已配置的 NFS 服務器來支持通過持久卷聲明動態配置 Kubernetes 持久卷。
持久卷被配置爲:namespace−{pvcName}-${pvName}。
二、External NFS 驅動的工作原理
K8S 的外部 NFS 驅動,可以按照其工作方式(是作爲 NFS server 還是 NFS client)分爲兩類:
1、nfs-client
也就是我們接下來演示的這一類,它通過 K8S 的內置的NFS驅動掛載遠端的 NFS 服務器到本地目錄;然後將自身作爲 storage provider,關聯 storage class。當用戶創建對應的 PVC 來申請 PV 時,該 provider 就將 PVC 的要求與自身的屬性比較,一旦滿足就在本地掛載好的 NFS 目錄中創建 PV 所屬的子目錄,爲 Pod 提供動態的存儲服務。
2、nfs
與 nfs-client 不同,該驅動並不使用 k8s 的 NFS 驅動來掛載遠端的 NFS 到本地再分配,而是直接將本地文件映射到容器內部,然後在容器內使用ganesha.nfsd 來對外提供 NFS 服務;在每次創建 PV 的時候,直接在本地的 NFS 根目錄中創建對應文件夾,並 export 出該子目錄。利用NFS動態提供 Kubernetes 後端存儲卷
本文將介紹使用 nfs-client-provisioner 這個應用,利用 NFS Server 給 Kubernetes 作爲持久存儲的後端,並且動態提供 PV。前提條件是有已經安裝好的 NFS 服務器,並且 NFS 服務器與 Kubernetes 的 Slave 節點都能網絡連通。將 nfs-client 驅動做一個 deployment 部署到 K8S 集羣中,然後對外提供存儲服務。
nfs-client-provisioner 是一個 Kubernetes 的簡易NFS的外部 provisioner,本身不提供 NFS,需要現有的 NFS 服務器提供存儲。
三、部署服務
1、配置授權
現在的 Kubernetes 集羣大部分是基於 RBAC 的權限控制,所以創建一個一定權限的 ServiceAccount 與後面要創建的 “NFS Provisioner” 綁定,賦予一定的權限。
# 清理rbac授權
kubectl delete -f nfs-rbac.yaml -n kube-system
# 編寫yaml
cat >nfs-rbac.yaml<<-EOF
---
kind: ServiceAccount
apiVersion: v1
metadata:
name: nfs-client-provisioner
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: nfs-client-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-client-provisioner
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
namespace: kube-system
roleRef:
kind: ClusterRole
name: nfs-client-provisioner-runner
apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: leader-locking-nfs-client-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-client-provisioner
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
# replace with namespace where provisioner is deployed
namespace: kube-system
roleRef:
kind: Role
name: leader-locking-nfs-client-provisioner
apiGroup: rbac.authorization.k8s.io
EOF
# 應用授權
kubectl apply -f nfs-rbac.yaml -n kube-system
2、部署 nfs-client-provisioner
首先克隆倉庫獲取 yaml 文件
git clone https://github.com/kubernetes-incubator/external-storage.git
cp -R external-storage/nfs-client/deploy/ /root/
cd deploy
3、部署 NFS Provisioner
修改 deployment.yaml 文件,這裏修改的參數包括 NFS 服務器所在的 IP 地址(10.198.1.155),以及 NFS 服務器共享的路徑(/data/nfs/),兩處都需要修改爲你實際的 NFS 服務器和共享目錄。另外修改 nfs-client-provisioner 鏡像從七牛雲拉取。
設置 NFS Provisioner 部署文件,這裏將其部署到 “kube-system” Namespace 中。
# 清理NFS Provisioner資源
kubectl delete -f nfs-provisioner-deploy.yaml -n kube-system
export NFS_ADDRESS='10.198.1.155'
export NFS_DIR='/data/nfs'
# 編寫deployment.yaml
cat >nfs-provisioner-deploy.yaml<<-EOF
---
kind: Deployment
apiVersion: apps/v1
metadata:
name: nfs-client-provisioner
spec:
replicas: 1
selector:
matchLabels:
app: nfs-client-provisioner
strategy:
type: Recreate #---設置升級策略爲刪除再創建(默認爲滾動更新)
template:
metadata:
labels:
app: nfs-client-provisioner
spec:
serviceAccountName: nfs-client-provisioner
containers:
- name: nfs-client-provisioner
#---由於quay.io倉庫國內被牆,所以替換成七牛雲的倉庫
image: quay-mirror.qiniu.com/external_storage/nfs-client-provisioner:latest
volumeMounts:
- name: nfs-client-root
mountPath: /persistentvolumes
env:
- name: PROVISIONER_NAME
value: nfs-client #---nfs-provisioner的名稱,以後設置的storageclass要和這個保持一致
- name: NFS_SERVER
value: ${NFS_ADDRESS} #---NFS服務器地址,和 valumes 保持一致
- name: NFS_PATH
value: ${NFS_DIR} #---NFS服務器目錄,和 valumes 保持一致
volumes:
- name: nfs-client-root
nfs:
server: ${NFS_ADDRESS} #---NFS服務器地址
path: ${NFS_DIR} #---NFS服務器目錄
EOF
# 部署deployment.yaml
kubectl apply -f nfs-provisioner-deploy.yaml -n kube-system
# 查看創建的pod
kubectl get pod -o wide -n kube-system|grep nfs-client
# 查看pod日誌
kubectl logs -f `kubectl get pod -o wide -n kube-system|grep nfs-client|awk '{print $1}'` -n kube-system
4、創建 StorageClass
storage class 的定義,需要注意的是:provisioner 屬性要等於驅動所傳入的環境變量 PROVISIONER_NAME 的值。否則,驅動不知道知道如何綁定storage class。 此處可以不修改,或者修改 provisioner 的名字,需要與上面的deployment 的 PROVISIONER_NAME 名字一致。
# 清理storageclass資源
kubectl delete -f nfs-storage.yaml
# 編寫yaml
cat >nfs-storage.yaml<<-EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: nfs-storage
annotations:
storageclass.kubernetes.io/is-default-class: "true" #---設置爲默認的storageclass
provisioner: nfs-client #---動態卷分配者名稱,必須和上面創建的"PROVISIONER_NAME"變量中設置的Name一致
parameters:
archiveOnDelete: "true" #---設置爲"false"時刪除PVC不會保留數據,"true"則保留數據
mountOptions:
- hard #指定爲硬掛載方式
- nfsvers=4 #指定NFS版本,這個需要根據 NFS Server 版本號設置
EOF
#部署class.yaml
kubectl apply -f nfs-storage.yaml
#查看創建的storageclass(這裏可以看到nfs-storage已經變爲默認的storageclass了)
$ kubectl get sc
NAME PROVISIONER AGE
nfs-storage (default) nfs-client 3m38s
四、創建 PVC
01、創建一個新的 namespace,然後創建 pvc 資源
# 刪除命令空間
kubectl delete ns kube-public
# 創建命名空間
kubectl create ns kube-public
# 清理pvc
kubectl delete -f test-claim.yaml -n kube-public
# 編寫yaml
cat >test-claim.yaml<<\EOF
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: test-claim
spec:
storageClassName: nfs-storage #---需要與上面創建的storageclass的名稱一致
accessModes:
- ReadWriteMany
resources:
requests:
storage: 100Gi
EOF
#創建PVC
kubectl apply -f test-claim.yaml -n kube-public
#查看創建的PV和PVC
$ kubectl get pvc -n kube-public
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
test-claim Bound pvc-593f241f-a75f-459a-af18-a672e5090921 100Gi RWX nfs-storage 3s
kubectl get pv
#然後,我們進入到NFS的export目錄,可以看到對應該volume name的目錄已經創建出來了。其中volume的名字是namespace,PVC name以及uuid的組合:
#注意,出現pvc在pending的原因可能爲nfs-client-provisioner pod 出現了問題,刪除重建的時候會出現鏡像問題
五、創建測試 Pod
# 清理資源
kubectl delete -f test-pod.yaml -n kube-public
# 編寫yaml
cat > test-pod.yaml <<\EOF
kind: Pod
apiVersion: v1
metadata:
name: test-pod
spec:
containers:
- name: test-pod
image: busybox:latest
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-claim
EOF
#創建pod
kubectl apply -f test-pod.yaml -n kube-public
#查看創建的pod
kubectl get pod -o wide -n kube-public
01、進入 NFS Server 服務器驗證是否創建對應文件
進入 NFS Server 服務器的 NFS 掛載目錄,查看是否存在 Pod 中創建的文件:
$ cd /data/nfs/
$ ls
archived-kube-public-test-claim-pvc-2dd4740d-f2d1-4e88-a0fc-383c00e37255 kube-public-test-claim-pvc-ad304939-e75d-414f-81b5-7586ef17db6c
archived-kube-public-test-claim-pvc-593f241f-a75f-459a-af18-a672e5090921 kube-system-test1-claim-pvc-f84dc09c-b41e-4e67-a239-b14f8d342efc
archived-kube-public-test-claim-pvc-b08b209d-c448-4ce4-ab5c-1bf37cc568e6 pv001
default-test-claim-pvc-4f18ed06-27cd-465b-ac87-b2e0e9565428 pv002
# 可以看到已經生成 SUCCESS 該文件,並且可知通過 NFS Provisioner 創建的目錄命名方式爲 “namespace名稱-pvc名稱-pv名稱”,pv 名稱是隨機字符串,所以每次只要不刪除 PVC,那麼 Kubernetes 中的與存儲綁定將不會丟失,要是刪除 PVC 也就意味着刪除了綁定的文件夾,下次就算重新創建相同名稱的 PVC,生成的文件夾名稱也不會一致,因爲 PV 名是隨機生成的字符串,而文件夾命名又跟 PV 有關,所以刪除 PVC 需謹慎。
參考文檔:
https://blog.csdn.net/qq_25611295/article/details/86065053 k8s pv 與pvc 持久化存儲(靜態與動態)
https://blog.csdn.net/networken/article/details/86697018 kubernetes部署 NFS 持久存儲
https://www.jianshu.com/p/5e565a8049fc kubernetes 部署 NFS 持久存儲(靜態和動態)
作者:Lancger
github:https://dwz.cn/qcjgGS7F
K8S、Golang詳情請諮詢WeChat:17812796384