kubernetes中PV和PVC
PV 全称叫做 Persistent Volume,持久化存储卷。K8S在指定存储设备空间中逻辑划分创建的可持久化的存储资源对象。PVC 的全称是 Persistent Volume Claim,是持久化存储的请求。是对PV资源对象的请求和绑定,也是Pod能挂载使用的一种存储卷类型。PV是集群中的资源。PVC是对这些资源的请求,也是对资源的索引检查。
目录
四、 搭建 StorageClass + nfs-client-provisioner ,实现 NFS 的动态 PV 创建
3.使用 Deployment 来创建 NFS Provisioner
3.1由于 1.20 版本启用了 selfLink,所以 k8s 1.20+ 版本通过 nfs provisioner 动态生成pv会报错,解决方法如下
一、PV、PVC简介
PV 全称叫做 Persistent Volume,持久化存储卷。K8S在指定存储设备空间中逻辑划分创建的可持久化的存储资源对象。
PVC 的全称是 Persistent Volume Claim,是持久化存储的请求。是对PV资源对象的请求和绑定,也是Pod能挂载使用的一种存储卷类型。
PV是集群中的资源。 PVC是对这些资源的请求,也是对资源的索引检查。
二、PV、PVC关系
PV和PVC之间的相互作用遵循生命周期:
Provisioning(配置)---> Binding(绑定)---> Using(使用)---> Releasing(释放) ---> Recycling(回收)
- Provisioning,即 PV 的创建,可以直接创建 PV(静态方式),也可以使用 StorageClass 动态创建
- Binding,将 PV 分配给 PVC
- Using,Pod 通过 PVC 使用该 Volume,并可以通过准入控制StorageProtection(1.9及以前版本为PVCProtection) 阻止删除正在使用的 PVC
- Releasing,Pod 释放 Volume 并删除 PVC
- Reclaiming,回收 PV,可以保留 PV 以便下次使用,也可以直接从云存储中删除
根据5个阶段,PV的状态有以下4种:
- Available(可用):表示可用状态,还未被任何 PVC 绑定
- Bound(已绑定):表示 PV 已经绑定到 PVC
- Released(已释放):表示 PVC 被删掉,但是资源尚未被集群回收
- Failed(失败):表示该 PV 的自动回收失败
PV从创建到销毁的具体流程:
- 一个PV创建完后状态会变成Available,等待被PVC绑定。
- 一旦被PVC邦定,PV的状态会变成Bound,就可以被定义了相应PVC的Pod使用。
- Pod使用完后会释放PV,PV的状态变成Released。
- 变成Released的PV会根据定义的回收策略做相应的回收工作。有三种回收策略,Retain、Delete和Recycle。
PV回收策略:
- Retain(保留):当用户删除与之绑定的PVC时候,这个PV被标记为released(PVC与PV解绑但还没有执行回收策略)且之前的数据依然保存在该PV上,但是该PV不可用,需要手动来处理这些数据并删除该PV。
- Delete(删除):删除与PV相连的后端存储资源。对于动态配置的PV来说,默认回收策略为Delete。表示当用户删除对应的PVC时,动态配置的volume将被自动删除。(只有 AWS EBS, GCE PD, Azure Disk 和 Cinder 支持)
- Recycle(回收):如果用户删除PVC,则删除卷上的数据,卷不会删除。(只有 NFS 和 HostPath 支持)
三、创建静态PV
创建使用 静态PV
- 准备好存储设备和共享目录
- 手动创建PV资源,配置 存储卷类型 访问模式(RWO RWX ROX RWOP) 存储空间大小 回收策略(Retain Recycle Delete)等
- 创建PVC资源,配置请求PV资源的访问模式(必要条件,必须是PV能支持的访问模式) 存储空间大小(默认就近选择大于等于指定大小的PV)来绑定PV
- 创建Pod和Pod控制器资源挂载PVC存储卷,配置存储卷类型为 persistentVolumeClaim ,并在容器配置中定义存储卷挂载点目录
1.配置nfs存储
mkdir /data/v{1..5}
vim /etc/exports
/data/v1 192.168.88.0/24(rw,no_root_squash,sync)
/data/v2 192.168.88.0/24(rw,no_root_squash,sync)
/data/v3 192.168.88.0/24(rw,no_root_squash,sync)
/data/v4 192.168.88.0/24(rw,no_root_squash,sync)
/data/v5 192.168.88.0/24(rw,no_root_squash,sync)
exportfs -arv
showmount -e
2.定义PV
vim pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata: #由于 PV 是集群级别的资源,即 PV 可以跨 namespace 使用,所以 PV 的 metadata 中不用配置 namespace
name: pv01
labels:
name: pv01
spec:
nfs: #定义存储类型
path: /data/v1 #定义挂载卷路径
server: 192.168.88.60 #定义服务器名称或地址
accessModes: #定义访问模型
- ReadWriteOnce
- ReadWriteMany
capacity: #定义存储能力,一般用于设置存储空间
storage: 1Gi #指定大小
storageClassName: slow #自定义存储类名称,此配置用于绑定具有相同类别的PVC和PV
persistentVolumeReclaimPolicy: Retain #回收策略(Retain/Delete/Recycle)
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv02
labels:
name: pv02
spec:
nfs:
path: /data/v2
server: 192.168.88.60
accessModes:
- ReadWriteOnce
capacity:
storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv03
labels:
name: pv03
spec:
nfs:
path: /data/v3
server: 192.168.88.60
accessModes:
- ReadWriteOnce
- ReadWriteMany
capacity:
storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv04
labels:
name: pv04
spec:
nfs:
path: /data/v4
server: 192.168.88.60
accessModes:
- ReadWriteOnce
- ReadWriteMany
capacity:
storage: 4Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv05
labels:
name: pv05
spec:
nfs:
path: /data/v5
server: 192.168.88.60
accessModes:
- ReadWriteOnce
- ReadWriteMany
capacity:
storage: 5Gi
kubectl apply -f pv.yaml
3.定义PVC
定义了pvc的访问模式为多路读写,该访问模式必须在前面pv定义的访问模式之中。定义PVC申请的大小为2Gi,此时PVC会自动去匹配多路读写且大小为2Gi的PV,匹配成功获取PVC的状态即为Bound
vim pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim #定义类型为pvc
metadata:
name: mypvc-a
namespace: default
spec:
accessModes: #定义pvc的访问模式
- ReadWriteMany
resources:
requests:
storage: 2Gi #定义请求pv的大小
---
apiVersion: v1
kind: Pod
metadata:
name: pod-vol-pvc
namespace: default
spec:
containers:
- name: myapp
image: nginx:1.14
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html
volumes:
- name: html
persistentVolumeClaim: #定义挂载的pvc详细信息
claimName: mypvc-a #挂载pvc的名称
kubectl apply -f pvc.yaml
4.测试访问
在存储服务器上创建index.html,并写入数据,通过访问Pod进行查看,可以获取到相应的页面。
cd /data/v3/
echo "welcome to use pv3" > index.html
kubectl get pods -o wide
curl 10.244.1.37
welcome to use pv3
四、 搭建 StorageClass + nfs-client-provisioner ,实现 NFS 的动态 PV 创建
Kubernetes 本身支持的动态 PV 创建不包括 NFS,所以需要使用外部存储卷插件分配PV。详见:https://kubernetes.io/zh/docs/concepts/storage/storage-classes/
卷插件称为 Provisioner(存储分配器),NFS 使用的是 nfs-client,这个外部卷插件会使用已经配置好的 NFS 服务器自动创建 PV。
Provisioner:用于指定 Volume 插件的类型,包括内置插件(如 kubernetes.io/aws-ebs)和外部插件(如 external-storage 提供的 ceph.com/cephfs)。
创建使用动态PV
- 准备好存储设备和共享目录
- 如果是外置存储卷插件,需要先创建serviceaccount账户(Pod使用的账户)和做RBAC授权(创建角色授予相关资源对象的操作权限,再将账户和角色进行绑定),使serviceaccount账户具有对PV PVC StorageClass等资源的操作权限
- 创建外置存储卷插件provisioner的Pod,配置中使用serviceaccount账户作为Pod的用户,并设置相关环境变量参数
- 创建StorageClass(SC)资源,配置中引用存储卷插件的插件(PROVISIONER_NAME)
- 创建PVC资源,配置中设置 StorageClass资源名称 访问模式 存储空间大小。创建PVC资源会自动创建相关的PV资源。
- 创建Pod资源挂载PVC存储卷,配置存储卷类型为 persistentVolumeClaim ,并在容器配置中定义存储卷挂载点目录
1. 配置nfs服务
mkdir /opt/k8s
chmod 777 /data/volumes
vim /etc/exports
/data/volumes 192.168.88.0/24(rw,no_root_squash,sync)
exportfs -arv
2.创建 Service Account
Service Account:用来管理 NFS Provisioner 在 k8s 集群中运行的权限,设置 nfs-client 对 PV,PVC,StorageClass 等的规则
vim nfs-client-rbac.yaml
#创建 Service Account 账户,用来管理 NFS Provisioner 在 k8s 集群中运行的权限
apiVersion: v1
kind: ServiceAccount
metadata:
name: nfs-client-provisioner
---
#创建集群角色
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: nfs-client-provisioner-clusterrole
rules:
- apiGroups: [""]
resources: ["persistentvolumes"]
verbs: ["get", "list", "watch", "create", "delete"]
- apiGroups: [""]
resources: ["persistentvolumesclaims"]
verbs: ["get", "list", "watch", "update"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["events"]
verbs: ["list", "watch", "create", "update", "patch"]
- apiGroups: [""]
resources: ["endpoints"]
verbs: ["create", "delete", "get", "list", "watch", "patch", "update"]
---
#集群角色绑定
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: nfs-client-provisioner-clusterrolebinding
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
namespace: default
roleRef:
kind: ClusterRole
name: nfs-client-provisioner-clusterrole
apiGroup: rbac.authorization.k8s.io
verbs: ["list", "watch", "create", "update", "patch"]
- apiGroups: [""]
resources: ["endpoints"]
kubectl apply -f nfs-client-rbac.yaml
3.使用 Deployment 来创建 NFS Provisioner
NFS Provisioner(即 nfs-client),有两个功能:一个是在 NFS 共享目录下创建挂载点(volume),另一个则是将 PV 与 NFS 的挂载点建立关联。
3.1由于 1.20 版本启用了 selfLink,所以 k8s 1.20+ 版本通过 nfs provisioner 动态生成pv会报错,解决方法如下
vim /etc/kubernetes/manifests/kube-apiserver.yaml
spec:
containers:
- command:
- kube-apiserver
- --feature-gates=RemoveSelfLink=false #添加这行
- --advertise-address=192.168.88.70
kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml
kubectl delete pods kube-apiserver -n kube-system
kubectl get pods -n kube-system | grep apiserver
3.2创建 NFS Provisioner
vim nfs-client-provisioner.yaml
apiVersion: apps/v1
kind: Deployment
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
image: quay.io/external_storage/nfs-client-provisioner:latest
imagePullPolicy: IfNotPresent
volumeMounts:
- name: nfs-client-root
mountPath: /persistentvolumes
env:
- name: PROVISIONER_NAME
value: nfs-storage #配置provisioner的Name,确保该名称与StorageClass资源中的provisioner名称保持一致
- name: NFS_SERVER
value: 192.168.88.60 #配置绑定的nfs服务器
- name: NFS_PATH
value: /data/volumes #配置绑定的nfs服务器目录
volumes: #申明nfs数据卷
- name: nfs-client-root
nfs:
server: 192.168.88.60
path: /data/volumes
kubectl apply -f nfs-client-provisioner.yaml
kubectl get pod
4.创建 StorageClass
StorageClass:负责建立 PVC 并调用 NFS provisioner 进行预定的工作,并让 PV 与 PVC 建立关联
vim nfs-client-storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: nfs-client-storageclass
provisioner: nfs-storage #这里的名称要和provisioner配置文件中的环境变量PROVISIONER_NAME保持一致
parameters:
archiveOnDelete: "false" #false表示在删除PVC时不会对数据目录进行打包存档,即删除数据;为ture时就会自动对数据目录进行打包存档,存档文件以archived开头
kubectl apply -f nfs-client-storageclass.yaml
kubectl get storageclass
5.创建 PVC 和 Pod 测试
vim test-pvc-pod.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: test-nfs-pvc
#annotations: volume.beta.kubernetes.io/storage-class: "nfs-client-storageclass" #另一种SC配置方式,(annotations也可表示为注释字段)
spec:
accessModes:
- ReadWriteMany
storageClassName: nfs-client-storageclass #关联StorageClass对象
resources:
requests:
storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:
name: test-storageclass-pod
spec:
containers:
- name: busybox
image: busybox:latest
imagePullPolicy: IfNotPresent
command:
- "/bin/sh"
- "-c"
args:
- "sleep 3600"
volumeMounts:
- name: nfs-pvc
mountPath: /mnt
restartPolicy: Never
volumes:
- name: nfs-pvc
persistentVolumeClaim:
claimName: test-nfs-pvc #与PVC名称保持一致
#PVC 通过 StorageClass 自动申请到空间
kubectl get pvc
#查看 NFS 服务器上是否生成对应的目录,自动创建的 PV 会以 ${namespace}-${pvcName}-${pvName} 的目录格式放到 NFS 服务器上
ls /data/volumes
#进入 Pod 在挂载目录 /mnt 下写一个文件,然后查看 NFS 服务器上是否存在该文件
kubectl exec -it test-storageclass-pod sh
/ # cd /mnt/
/mnt # echo 'this is test file' > test.txt
#发现 NFS 服务器上存在,说明验证成功
cat /data/volumes/default-test-nfs-pvc-pvc-bff2245e-990d-4119-a846-06f898f95efb
更多推荐
所有评论(0)