k8s 使用StorageClass+NFS动态创建pv
k8s 使用StorageClass+NFS动态创建pv
参考
https://www.cnblogs.com/panwenbin-logs/p/12196286.html
1. 创建NFS共享服务
安装nfs-utils和rpcbind
nfs客户端和服务端都安装nfs-utils包
yum install nfs-utils rpcbind
创建共享目录
mkdir -p /nfsdata
chmod 777 /nfsdata
编辑/etc/exports文件添加如下内容
vi /etc/exports
/nfsdata *(rw,sync,no_root_squash)
nfs权限说明
- ro 只读
- rw 可读写
- sync 同步写数据，保证数据不丢失
- async 异步写数据，在写入持久化存储之前进行请求响应，如果服务器重启可能会导致文件丢失或者损坏
- root_squash 将root用户（uid/gid 0）的请求映射为匿名用户（anonymous uid/gid）
- no_root_squash 禁用root_squash规则
- all_squash 将所有用户都映射为匿名用户
- no_all_squash 禁用all_squash规则，默认选项
- anonuid 指定要映射为匿名用户的uid，例如：anonuid=150
- anongid 指定要映射为匿名用户的gid，例如：anongid=100
启动服务
# systemctl start rpcbind.service
# systemctl enable rpcbind.service
# systemctl start nfs.service
# systemctl enable nfs.service
启动顺序一定是rpcbind->nfs，否则有可能出现错误
2. 创建StorageClass
因为StorageClass可以实现自动配置，所以使用StorageClass之前，我们需要先安装存储驱动的自动配置程序，而这个配置程序必须拥有一定的权限去访问我们的kubernetes集群(类似dashboard一样，必须有权限访问各种api，才能实现管理)。
创建rbac(Role-Based Access Control:基于角色的访问控制)
apiVersion: v1
kind: ServiceAccount
metadata:
name: nfs-client-provisioner
namespace: default #根据实际环境设定namespace,下面类同
---
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
# replace with namespace where provisioner is deployed
namespace: default
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
# replace with namespace where provisioner is deployed
namespace: default
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: default
roleRef:
kind: Role
name: leader-locking-nfs-client-provisioner
apiGroup: rbac.authorization.k8s.io
创建StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: master-nfs-storage
provisioner: master-nfs-storage #这里的名称要和下面的provisioner配置文件中的环境变量PROVISIONER_NAME保持一致
parameters:
archiveOnDelete: "false"
创建自动配置程序 - NFS客户端
apiVersion: apps/v1
kind: Deployment
metadata:
name: nfs-client-provisioner
labels:
app: nfs-client-provisioner
# replace with namespace where provisioner is deployed
namespace: default #与RBAC文件中的namespace保持一致
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
image: quay.io/external_storage/nfs-client-provisioner:latest
volumeMounts:
- name: nfs-client-root
mountPath: /persistentvolumes
env:
- name: PROVISIONER_NAME
value: master-nfs-storage #provisioner名称,请确保该名称与StorageClass的provisioner名称保持一致
- name: NFS_SERVER
value: 192.168.2.5 #NFS Server IP地址
- name: NFS_PATH
value: /nfsdata #NFS挂载卷
volumes:
- name: nfs-client-root
nfs:
server: 192.168.2.5 #NFS Server IP地址
path: /nfsdata #NFS 挂载卷
3. 创建测试pod,检查是否部署成功
创建PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: test-service-pvc
annotations:
volume.beta.kubernetes.io/storage-provisioner: master-nfs-storage #与nfs-StorageClass.yaml metadata.name保持一致
spec:
accessModes:
- ReadWriteOnce #表示该volume只能被单个节点以读写的方式映射
resources:
requests:
storage: 1Gi
storageClassName: master-nfs-storage #指定storageclass 与StorageClass中的provisioner一致
accessModes访问模式说明
ReadWriteOnce -- 该volume只能被单个节点以读写的方式映射
ReadOnlyMany -- 该volume可以被多个节点以只读方式映射
ReadWriteMany -- 该volume可以被多个节点以读写的方式映射
查看pvc状态是否为Bound
gg@gg-linux:/> sudo kubectl get pvc --all-namespaces
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
test-service-pvc Bound pvc-aae2b7fa-377b-11ea-87ad-525400512eca 1Gi RWX master-nfs-storage 2m48s
创建测试pod,查看是否可以正常挂载
kind: Pod
apiVersion: v1
metadata:
name: test-pod
namespace: default
spec:
containers:
- name: test-pod
image: busybox:1.24
command:
- "/bin/sh"
args:
- "-c"
- "touch /mnt/SUCCESS && exit 0 || exit 1" #创建一个SUCCESS文件后退出
volumeMounts:
- name: nfs-pvc
mountPath: "/mnt"
restartPolicy: "Never"
volumes:
- name: test-pod-nfs-pvc
persistentVolumeClaim:
claimName: test-service-pvc #与PVC名称保持一致
此时在nfs文件夹/nfsdata下应以多出一个名字为default-test-service-pvc-pvc-aae2b7fa-377b-11ea-87ad-525400512eca的文件夹
4. 关于StorageClass回收策略对数据的影响
1.第一种配置
archiveOnDelete: "false"
reclaimPolicy: Delete #默认没有配置,默认值为Delete
测试结果:
1.pod删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
2.sc删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
3.删除PVC后,PV被删除且NFS Server对应数据被删除
2.第二种配置
archiveOnDelete: "false"
reclaimPolicy: Retain
测试结果:
1.pod删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
2.sc删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
3.删除PVC后,PV不会别删除,且状态由Bound变为Released,NFS Server对应数据被保留
4.重建sc后,新建PVC会绑定新的pv,旧数据可以通过拷贝到新的PV中
3.第三种配置
archiveOnDelete: "ture"
reclaimPolicy: Retain
结果:
1.pod删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
2.sc删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
3.删除PVC后,PV不会别删除,且状态由Bound变为Released,NFS Server对应数据被保留
4.重建sc后,新建PVC会绑定新的pv,旧数据可以通过拷贝到新的PV中
4.第四种配置
archiveOnDelete: "ture"
reclaimPolicy: Delete
结果:
1.pod删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
2.sc删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
3.删除PVC后,PV不会别删除,且状态由Bound变为Released,NFS Server对应数据被保留
4.重建sc后,新建PVC会绑定新的pv,旧数据可以通过拷贝到新的PV中
