Kubernetes 中部署 NFS Provisioner 为 NFS 提供动态分配卷
文章目录
!版权声明:本博客内容均为原创,每篇博文作为知识积累,写博不易,转载请注明出处。
注意: 该项目已经过期,请转移至部署 Kubernetes 中部署 NFS Provisioner 为 NFS 提供动态分配卷文章
环境说明:
- NFS Provisioner Github 地址:https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client
- NFS 示例部署文件 Github 地址:https://github.com/my-dlq/blog-example/tree/master/kubernetes/nfs-provisioner-deploy
一、NFS Provisioner 简介
NFS Provisioner 是一个自动配置卷程序,它使用现有的和已配置的 NFS 服务器来支持通过持久卷声明动态配置 Kubernetes 持久卷。
- 持久卷被配置为:${namespace}-${pvcName}-${pvName}。
二、创建 NFS Server 端
本篇幅是具体介绍如何部署 NFS 动态卷分配应用 "NFS Provisioner",所以部署前请确认已经存在 NFS Server 端,关于如何部署 NFS Server 请看之前写过的博文 “CentOS7 搭建 NFS 服务器”,如果非 Centos 系统,请先自行查找 NFS Server 安装方法。
这里 NFS Server 环境为:
- IP地址:192.168.2.11
- 存储目录:/nfs/data
三、创建 ServiceAccount
现在的 Kubernetes 集群大部分是基于 RBAC 的权限控制,所以创建一个一定权限的 ServiceAccount 与后面要创建的 "NFS Provisioner" 绑定,赋予一定的权限。
提前修改里面的 Namespace 值设置为要部署 "NFS Provisioner" 的 Namespace 名
nfs-rbac.yaml
1kind: ServiceAccount
2apiVersion: v1
3metadata:
4 name: nfs-client-provisioner
5---
6kind: ClusterRole
7apiVersion: rbac.authorization.k8s.io/v1
8metadata:
9 name: nfs-client-provisioner-runner
10rules:
11 - apiGroups: [""]
12 resources: ["persistentvolumes"]
13 verbs: ["get", "list", "watch", "create", "delete"]
14 - apiGroups: [""]
15 resources: ["persistentvolumeclaims"]
16 verbs: ["get", "list", "watch", "update"]
17 - apiGroups: ["storage.k8s.io"]
18 resources: ["storageclasses"]
19 verbs: ["get", "list", "watch"]
20 - apiGroups: [""]
21 resources: ["events"]
22 verbs: ["create", "update", "patch"]
23---
24kind: ClusterRoleBinding
25apiVersion: rbac.authorization.k8s.io/v1
26metadata:
27 name: run-nfs-client-provisioner
28subjects:
29 - kind: ServiceAccount
30 name: nfs-client-provisioner
31 namespace: kube-system #替换成你要部署NFS Provisioner的 Namespace
32roleRef:
33 kind: ClusterRole
34 name: nfs-client-provisioner-runner
35 apiGroup: rbac.authorization.k8s.io
36---
37kind: Role
38apiVersion: rbac.authorization.k8s.io/v1
39metadata:
40 name: leader-locking-nfs-client-provisioner
41rules:
42 - apiGroups: [""]
43 resources: ["endpoints"]
44 verbs: ["get", "list", "watch", "create", "update", "patch"]
45---
46kind: RoleBinding
47apiVersion: rbac.authorization.k8s.io/v1
48metadata:
49 name: leader-locking-nfs-client-provisioner
50subjects:
51 - kind: ServiceAccount
52 name: nfs-client-provisioner
53 namespace: kube-system #替换成你要部署NFS Provisioner的 Namespace
54roleRef:
55 kind: Role
56 name: leader-locking-nfs-client-provisioner
57 apiGroup: rbac.authorization.k8s.io
创建 RBAC
- -n: 指定应用部署的 Namespace
1$ kubectl apply -f nfs-rbac.yaml -n kube-system
四、部署 NFS Provisioner
设置 NFS Provisioner 部署文件,这里将其部署到 "kube-system" Namespace 中。
nfs-provisioner-deploy.yaml
1kind: Deployment
2apiVersion: apps/v1
3metadata:
4 name: nfs-client-provisioner
5 labels:
6 app: nfs-client-provisioner
7spec:
8 replicas: 1
9 strategy:
10 type: Recreate #---设置升级策略为删除再创建(默认为滚动更新)
11 selector:
12 matchLabels:
13 app: nfs-client-provisioner
14 template:
15 metadata:
16 labels:
17 app: nfs-client-provisioner
18 spec:
19 serviceAccountName: nfs-client-provisioner
20 containers:
21 - name: nfs-client-provisioner
22 image: quay.io/external_storage/nfs-client-provisioner:v3.1.0-k8s1.11
23 volumeMounts:
24 - name: nfs-client-root
25 mountPath: /persistentvolumes
26 env:
27 - name: PROVISIONER_NAME
28 value: nfs-client #--- nfs-provisioner的名称,以后设置的storageclass要和这个保持一致
29 - name: NFS_SERVER
30 value: 192.168.2.11 #---NFS服务器地址,和 valumes 保持一致
31 - name: NFS_PATH
32 value: /nfs/data #---NFS服务器目录,和 valumes 保持一致
33 volumes:
34 - name: nfs-client-root
35 nfs:
36 server: 192.168.2.11 #---NFS服务器地址
37 path: /nfs/data #---NFS服务器目录
注意: 在 Kubernetes 1.20+ 版本中移除了 SelfLink,由于该镜像也好久不更新,在新版本中将出现不能正常使用问题,可以在 kube-apiserver.yaml 中添加
- --feature-gates=RemoveSelfLink=false
参数来解决此问题,详情请参考 https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner/issues/25
创建 NFS Provisioner
- -n: 指定应用部署的 Namespace
1$ kubectl apply -f nfs-provisioner-deploy.yaml -n kube-system
五、创建 NFS SotageClass
创建一个 StoageClass,声明 NFS 动态卷提供者名称为 “nfs-storage”。
nfs-storage.yaml
1apiVersion: storage.k8s.io/v1
2kind: StorageClass
3metadata:
4 name: nfs-storage
5 annotations:
6 storageclass.kubernetes.io/is-default-class: "true" #---设置为默认的storageclass
7provisioner: nfs-client #---动态卷分配者名称,必须和上面创建的"provisioner"变量中设置的Name一致
8parameters:
9 archiveOnDelete: "true" #---设置为"false"时删除PVC不会保留数据,"true"则保留数据
10mountOptions:
11 - hard #指定为硬挂载方式
12 - nfsvers=4 #指定NFS版本,这个需要根据 NFS Server 版本号设置
创建 StorageClass
1$ kubectl apply -f nfs-storage.yaml
六、创建 PVC 和 Pod 进行测试
1、创建测试 PVC
在 “kube-public” Namespace 下创建一个测试用的 PVC 并观察是否自动创建是 PV 与其绑定。
test-pvc.yaml
1kind: PersistentVolumeClaim
2apiVersion: v1
3metadata:
4 name: test-pvc
5spec:
6 storageClassName: nfs-storage #---需要与上面创建的storageclass的名称一致
7 accessModes:
8 - ReadWriteOnce
9 resources:
10 requests:
11 storage: 1Mi
创建 PVC
- -n:指定创建 PVC 的 Namespace
1$ kubectl apply -f test-pvc.yaml -n kube-public
查看 PVC 状态是否与 PV 绑定
利用 Kubectl 命令获取 pvc 资源,查看 STATUS 状态是否为 “Bound”。
1$ kubectl get pvc test-pvc -n kube-public
2
3NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS
4test-pvc Bound pvc-be0808c2-9957-11e9 1Mi RWO nfs-storage
2、创建测试 Pod 并绑定 PVC
创建一个测试用的 Pod,指定存储为上面创建的 PVC,然后创建一个文件在挂载的 PVC 目录中,然后进入 NFS 服务器下查看该文件是否存入其中。
test-pod.yaml
1kind: Pod
2apiVersion: v1
3metadata:
4 name: test-pod
5spec:
6 containers:
7 - name: test-pod
8 image: busybox:latest
9 command:
10 - "/bin/sh"
11 args:
12 - "-c"
13 - "touch /mnt/SUCCESS && exit 0 || exit 1" #创建一个名称为"SUCCESS"的文件
14 volumeMounts:
15 - name: nfs-pvc
16 mountPath: "/mnt"
17 restartPolicy: "Never"
18 volumes:
19 - name: nfs-pvc
20 persistentVolumeClaim:
21 claimName: test-pvc
创建 Pod
- -n:指定创建 Pod 的 Namespace
1$ kubectl apply -f test-pod.yaml -n kube-public
3、进入 NFS Server 服务器验证是否创建对应文件
进入 NFS Server 服务器的 NFS 挂载目录,查看是否存在 Pod 中创建的文件:
1$ cd /nfs/data
2$ ls -l
3
4-rw-r--r-- kube-public-test-pvc-pvc-3dc54156-b81d-11e9-a8b8-000c29d98697
5
6$ cd /kube-public-test-pvc-pvc-3dc54156-b81d-11e9-a8b8-000c29d98697
7$ ls -l
8
9-rw-r--r-- 1 root root 0 Jun 28 12:44 SUCCESS
可以看到已经生成 SUCCESS 该文件,并且可知通过 NFS Provisioner 创建的目录命名方式为 “namespace名称
-pvc名称
-pv名称
”,pv 名称是随机字符串,所以每次只要不删除 PVC,那么 Kubernetes 中的与存储绑定将不会丢失,要是删除 PVC 也就意味着删除了绑定的文件夹,下次就算重新创建相同名称的 PVC,生成的文件夹名称也不会一致,因为 PV 名是随机生成的字符串,而文件夹命名又跟 PV 有关,所以删除 PVC 需谨慎。
---END---
!版权声明:本博客内容均为原创,每篇博文作为知识积累,写博不易,转载请注明出处。