k8s-基于nfs创建静态和动态pv,pvc
以下的操作都经过实际测试,如果遇到问题可以留言。
前置条件:
部署k8s集群(节点node-1, node-2,node-3)部署k8s集群的教程
k8s中三个node节点,node-1为master,node-2,node-3为子节点
一:nfs服务器部署
1.1 所有节点安装nfs
yum install -y nfs-utils rpcbind
1.2 所有服务器启动nfs服务
#手动加载 NFS 共享服务时,应该先启动 rpcbind,再启动 nfs
systemctl start rpcbind && systemctl enable rpcbind
systemctl start nfs && systemctl enable nfs
#查看 rpcbind 端口是否开启,rpcbind 服务默认使用 tcp 端口 111
netstat -anpt | grep rpcbind
1.3 创建共享目录,并授权
mkdir /root/data/nfs
chmod 777 /root/data/nfs
1.4 编辑 exports 文件
vim /etc/exports
/root/data/nfs 192.168.81.0/24(rw,no_root_squash,sync)
#保存退出
:wq
1.5 执行export
exportfs -rv//重新export一次
1.6 查看本机的共享目录
showmount -e
若是需要重新修改/etc/exports文件,需要执行以下命令重新运行文件即可
exportfs -rv
二. 静态 Provisioning 例子-操作演示
2.1创建PV
定义一个pv,也可以定义多个PV,本次是测试主机上是否能够成功创建pv以及绑定pvc。
注意:共享目录以及主机IP改成自己的。
2.1.1 创建PV文件
vim pv_nfs.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfspv1
spec:
capacity:
storage: 1Gi
#指定访问模式
accessModes:
#pv能以readwrite模式mount到单个节点
- ReadWriteOnce
#指定pv的回收策略,即pvc资源释放后的事件.retain(建议,使用动态供给代替)保留pvc的所有文件
persistentVolumeReclaimPolicy: Retain
#指定pv的class为nfs,相当于为pv分类,pvc将指定class申请pv
storageClassName: mynfs
#指定pv为nfs服务器上对应的目录
nfs:
path: /root/data/nfs
server: 192.168.81.140
2.1.2 创建后再查看:
kubectl apply -f pv_nfs.yaml #创建
kubectl get pv #查看
2.2: 定义pvc
定义 PVC 申请的大小为 2Gi, storageClassName指定class申请pv,进行绑定bound。
vim pvc.nfs.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: nfspvc1
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: mynfs
2.2.1 发布以及查看
kubectl apply -f pvc_nfs.yaml
kubectl get pvc
2.3:创建应用资源,使用pvc存储
2.3.1 编辑应用资源配置文件:
vim pvjob.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: pvjob
spec:
template:
spec:
containers:
- name: bbox1
image: busybox
args:
- /bin/sh
- -c
- echo "hello pv" > /mydata/hello
volumeMounts:
- mountPath: "/mydata"
name: mydata
restartPolicy: Never
volumes:
- name: mydata
persistentVolumeClaim:
claimName: nfspvc1
该job将在nfs的volume创建一个hello文件,打印”hello pv”字符串
2.3.2: 应用该Job资源
创建该job,并查看实验结果:
kubectl apply -f pvjob.yaml #创建该job资源
cat /root/data/nfs/hello #查看实验结果
2.3.3 删除job资源
删除job资源后,查看hello文件是否在共享目录中保存下来了。使用 “Retain” 时,如果用户删除 PersistentVolumeClaim,对应的 PersistentVolume 不会被删除。相反,它将变为 Released 状态,表示所有的数据可以被手动恢复。
根据上面的结果,可以知道hello文件并没有随pvc的删除,hello文件而删除掉。
三. 基于storageclass的动态 Provisioning 例子-操作演示
StorageClass概述
StorageClass 为管理员提供了描述存储 "类" 的方法,实现了存储的动态供给,简单来说,StorageClass能够根据pvc来自动创建pv,减轻了集群管理员创建pv的负担。
创建一个StorageClass需要以下几部分:
provisioner:StorageClass能够自动创建pv的前提是我们给StorageClass指定一块可以使用的存储,provisioner即定义了StorageClass使用哪块存储。
RBAC: 这里定义了StorageClass需要的权限。
StorageClass: 定义StorageClass存储类,并且说明使用哪一个provisioner
3.1 nfs服务器配置修改
3.1.1 创建共享目录
mkdir /data
3.1.2 编辑exports文件
vim /etc/exports
/data 192.168.81.4/24(rw,no_root_squash,sync) #192.168.81.0/24即可
#保存退出
:wq
/data :是共享的目录
192.168.81.4 是nfs服务器的IP地址,这个只需要在主机同一网段下面即可。可以为一个网段,一个IP,也可以是域名,域名支持通配符 如: *.qq.com
IP 网络— 允许在更大的网络中根据其 IP 地址匹配主机。例如, 192.168.0.0 / 28 允许前 16 个 IP 地址(从 192.168.0.0 到 192.168.0.15)访问导出的文件系统,但不允许访问 192.168.0.16 及更高版本。
rw/ro 权限是读写或只读 (read-only),但最终能不能读写,还是与文件系统的 rwx 及身份有关。
no_root_squash 登入 NFS 主机使用分享目录的使用者,如果是 root 的话,那么对于这个分享的目录来说,他就具有 root 的权限,单词squash是压缩压扁的意思。
sync/async: sync代表数据会同步写入到内存与硬盘中,async 则代表数据会先暂存于内存当中,而非直接写入硬盘!
3.1.3 重新加载export文件
修改了/etc/exports后,并不需要重启nfs服务,只要用exportfs重新扫描一次/etc/exports,并且重新加载即可exportfs[-aruv] 。
exportfs -rv//重新export一次
exportfs -au//全部卸载
3.2 StorageClass创建过程
3.2.1 创建RBAC的yaml文件
apiVersion: v1
kind: ServiceAccount
metadata:
name: nfs-client-provisioner
namespace: default
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: nfs-client-provisioner-runner
rules:
- apiGroups: [""]
resources: ["nodes"]
verbs: ["get", "list", "watch"]
- 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: 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
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
namespace: default
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
namespace: default
roleRef:
kind: Role
name: leader-locking-nfs-client-provisioner
apiGroup: rbac.authorization.k8s.io
执行ServiceAccount文件
kubectl apply -f rbac.yaml
3.2.2 创建provisioner的yaml文件
apiVersion: apps/v1
kind: Deployment # provisioner的类型是一个deployment
metadata:
name: nfs-client-provisioner
labels:
app: nfs-client-provisioner
namespace: default # 指定provisioner所属的namespace,改成你自己的namespace
spec:
replicas: 1
strategy:
type: Recreate
selector:
matchLabels:
app: nfs-client-provisioner
template:
metadata:
labels:
app: nfs-client-provisioner
spec:
serviceAccountName: nfs-client-provisioner # 指定provisioner使用的sa
containers:
- name: nfs-client-provisioner
image: vbouchaud/nfs-client-provisioner:latest # 指定provisioner的镜像
volumeMounts:
- name: nfs-client-root
mountPath: /persistentvolumes # 固定写法
env:
- name: PROVISIONER_NAME
value: scm-storage-class # 指定分配器的名称,创建storageclass会用到
- name: NFS_SERVER
value: 192.168.81.140 # 指定使用哪一块存储,这里用的是nfs,此处填写nfs的地址
- name: NFS_PATH
value: /data # 使用nfs哪一块盘符
volumes:
- name: nfs-client-root
nfs:
server: 192.168.81.140 # 和上面指定的nfs地址保持一致
path: /data # 和上面指定的盘符保持一致
执行文件provisioner
kubectl apply -f provisioner.yaml
查看是否部署成功
kubectl get deploy -n default
如果READY一直都是0/1,就是没有部署成功,可以通过以下命令来查看出错的信息,并根据出错的信息进行修改,修改后再次部署即可。
kubectl describe deploy nfs-client-provisioner -n ${你的namespace名称}
部署出现的问题
部署时遇到的问题:
1. 主机IP和storageclass的Name一定要改成自己的设置。
2. namespace也需要修改成自己的命名空间
3. 特别注意:共享盘符与自己创建共享目录需要一致,不然会出现无法创建的错误。
3.2.3 创建storageclass
准备storageclass.yaml文件
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: scm-storage # storageclass的名字
provisioner: scm-storage-class # 必须与provisioner.yaml中PROVISIONER_NAME的值一致
parameters:
archiveOnDelete: "true" ## 删除pv的时候,pv的内容是否要备份
allowVolumeExpansion: true #如果对PVC扩容,则其对应的"storage class"中allowVolumeExpansion字段需要设置成true:
文件创建完成后,执行创建命令
kuebctl apply -f storageclass.yaml
查看已经创建好的StorageClass:
kubectl get storageclass
3.3 创建成功后,创建一个pvc进行测试
创建scm-pvc.yaml,进行测试已经创建好的StorageClass,检查StorageClass是否创建好了pv。进行动态绑定。
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: scm-pvc
namespace: default
spec:
storageClassName: scm-storage # 需要与上面创建的storageclass的名称一致
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
执行该文件:
kubectl apply -f scm-pvc.yaml
查看pvc和pv的部署情况:
kubectl get pvc -n default
kubectl get pv -n default
我们看到已经有一个新的 PV 生成,这个 PV 其实就是根据我们提交的 PVC 以及PVC 里面指定的storageclass 动态生成的。之后k8s会将生成的 PV 以及我们提交的 PVC,就是这个 scm PVC 做绑定,之后我们就可以通过创建 pod 来使用了。
如果pvc的状态是Pending或者其他状态,执行以下命令查看异常原因:
kubectl describe pvc scm-pvc -n ${你的namespace名称}
创建pod.yaml
pod yaml 很简单,也是通过 PVC 声明,表明使用这个 PVC。然后是挂载点,下面我们可以创建看一下。
vim pod,yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-pv-demo
namespace: default
spec:
containers:
- name: scm-pod
image: ubuntu:18.04
volumeMounts:
- name: scm-pvc
mountPath: /data
command: [ "sleep" , "3600s" ]
volumes:
- name: scm-pvc
persistentVolumeClaim:
claimName: scm-pvc
可以查看一下Events,首先被调度器调度,调度完之后(使用阿里云云盘接下来会有个 attachdetach controller,它会去做 disk的attach操作,就是把我们对应的 PV 挂载到调度器调度的 node 上)然后Pod对应的容器才能启动,启动容器才能使用对应的盘。
接下来我会把 PVC 删掉,看一下PV 会不会根据我们的storageclass中的 --reclaimPolicy:回收策略,Delete(默认的)和Retain(删除pvc针对pv的处理过程) – reclaimPolicy 随之删掉呢?我们先看一下,这个时候 PVC 还是存在的,对应的 PV 也是存在的。
然后删一下 PVC,删完之后再看一下:我们的 PV 也被删了,也就是说根据 reclaimPolicy,我们在删除 PVC 的同时,PV 也会被删除掉。
部署出现的问题:
部署pvc时出现目录权限不足,而无法创建目录的问题
经过查看,可以将exports文件中rw后加上no_root_squash字段,既可以成功创建部署。
结束