K8S 之 PV、PVC
- PersistentVolume(PV) 是集群中由管理员配置的一段网络存储。集群中的资源就像一个节点是一个集群资源,可以从远程的 NFS 或分布式对象存储系统中创建得来(PV 存储空间大小、访问方式)。- PV 是诸如卷之类的卷插件,但是只有独立于使用 PV 的任何单个 pod 的生命周期。- 该 API 对象捕获存储的实现细节,即 NFS,ISCSI 或云提供商特定的存储系统。- PV 就
文章目录
一、PV 和 PVC
1. PV 概念
- PersistentVolume(PV) 是集群中由管理员配置的一段网络存储。集群中的资源就像一个节点是一个集群资源,可以从远程的 NFS 或分布式对象存储系统中创建得来(PV 存储空间大小、访问方式)。
- PV 是诸如卷之类的卷插件,但是只有独立于使用 PV 的任何单个 pod 的生命周期。
- 该 API 对象捕获存储的实现细节,即 NFS,ISCSI 或云提供商特定的存储系统。
- PV 就是从存储设备中的空间创建出一个存储资源。
2. PVC 概念
- PersistentVolumeClaim(PVC) 是用户存储的请求。PVC 的使用逻辑:在 pod 中定义一个存储卷(该存储卷类型为 PVC),定义的时候直按指定大小,PVC 必须与对应的 PV 建立关系,PVC 会根据定义去 PV 申请,而 PV 是由存储空间创建出来的。PV 和 PVC 是 kubernetes 抽象出来的一种存储资源。
- 虽然 PersistentVolumeClaims 允许用户使用抽象存储资源,但是常见的需求是,用户需要根据不同的需求去创建 PV,用于不同的场景。而此时需要集群管理员提供不同需求的 PV,而不仅仅是 PV 的大小和访问模式,但又不需要用户了解这些卷的实现细节。
- 对于这样的需求,此时可以采用 storageclass 资源。
3. PV 与 PVC 之间的关系
PV 是集群中的资源,PVC 是对这些资源的请求,也是对资源的索引检查。PV 和 PVC 之间的相互作用遵循这个生命周期:Provisioning(配置) ---> Binding(绑定) ---> Using(使用) ---> Releasing(释放) ---> Recycling(回收)
4. 两种 PV 的提供方式
这里有两种 PV 的提供方式:静态或者动态
- 静态 —》直接固定存储空间
集群管理员创建一些 PV。它们携带可供集群用户使用的真实存储的详细信息。它们存在于 Kubernetes API 中,可用于消费。 - 动态 —》通过存储类进行动态创建存储空间
当管理员创建的静态 PV 都不匹配用户的 PVC 时,集群可能会尝试动态地为 PVC 配置卷。此配置基于 StorageClasses:PVC 必须请求存储类,并且管理员必须已创建并配置该类才能进行动态配置。要求该类的声明有效地为自己禁用动态配置。
二、基于 nfs 创建静态 PV 资源和 PVC 资源
1. 实验环境
nfs-server | k8s-master(192.168.10.100) |
---|---|
nfs-client | k8s-node1(192.168.10.101),k8s-node2(192.168.10.102) |
2. 所有节点安装 nfs
yum install -y nfs-utils rpcbind
3. 在 master 节点创建共享目录
mkdir /nfsdata1
mkdir /nfsdata2
mkdir /nfsdata3
4. master 授权共享目录
chmod 777 /nfsdata1
chmod 777 /nfsdata2
chmod 777 /nfsdata3
5. master 编辑 exports 文件
vim /etc/exports
/nfsdata1 192.168.10.0/24(rw,no_root_squash,sync)
/nfsdata2 192.168.10.0/24(rw,no_root_squash,sync)
/nfsdata3 192.168.10.0/24(rw,no_root_squash,sync)
exportfs -rv
6. master 启动 rpc 和 nfs(注意顺序)
#手动加载 NFS 共享服务时,应该先启动 rpcbind,再启动 nfs
systemctl start rpcbind && systemctl enable rpcbind
systemctl start nfs && systemctl enable nfs
#查看 rpcbind 端口是否开启,rpcbind 服务默认使用 tcp 端口 111
netstat -anpt | grep rpcbind
查看本机发布的共享目录
showmount -e
7. master 创建访问页面供测试用
echo '11111' > /nfsdata1/index.html
echo '22222' > /nfsdata2/index.html
echo '33333' > /nfsdata3/index.html
8. master 创建 PV
这里定义 3 个 PV,并且定义挂载的路径以及访问模式,还有 PV 划分的大小。
vim pv-demo.yaml #注意自己的共享目录和主机名
————————————————————————————————————————————
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv001
labels:
name: pv001
spec:
nfs:
path: /nfsdata1
server: master
accessModes: ["ReadWriteMany","ReadWriteOnce"]
capacity:
storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv002
labels:
name: pv002
spec:
nfs:
path: /nfsdata2
server: master
accessModes: ["ReadWriteOnce"]
capacity:
storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv003
labels:
name: pv003
spec:
nfs:
path: /nfsdata3
server: master
accessModes: ["ReadWriteMany","ReadWriteOnce"]
capacity:
storage: 2Gi
创建并查看
kubectl apply -f pv-demo.yaml
kubectl get pv
----------------------------------------
[root@master ~]# kubectl apply -f pv-demo.yaml
persistentvolume/pv001 created
persistentvolume/pv002 created
persistentvolume/pv003 created
[root@master ~]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv001 1Gi RWO,RWX Retain Available 6s
pv002 2Gi RWO Retain Available 6s
pv003 2Gi RWO,RWX Retain Available 6s
9. 定义 PVC
这里定义了 PVC 的访问模式为多路读写,该访问模式必须在前面 PV 定义的访问模式之中。定义 PVC 申请的大小为 2Gi,此时 PVC 会自动去匹配多路读写且大小为 2Gi 的 PV ,匹配成功获取 PVC 的状态即为 Bound。
vim pvc-demo.yaml
---------------------------------------
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mypvc
spec:
accessModes: ["ReadWriteMany"]
resources:
requests:
storage: 2Gi
---
apiVersion: v1
kind: Pod
metadata:
name: pv-pvc
spec:
containers:
- name: myapp
image: nginx
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html
volumes:
- name: html
persistentVolumeClaim:
claimName: mypvc
发布并查看
kubectl apply -f pvc-demo.yaml
kubectl get pv
------------------------------------
[root@master ~]# kubectl apply -f pvc-demo.yaml
persistentvolumeclaim/mypvc created
pod/pv-pvc created
[root@master ~]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv001 1Gi RWO,RWX Retain Available 4m51s
pv002 2Gi RWO Retain Available 4m51s
pv003 2Gi RWO,RWX Retain Bound default/mypvc 4m51s
可以看到 pv003 设定的 pvc 请求存储卷是 2Gi 并且多路可读可写。
访问 pv003
[root@master ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pv-pvc 1/1 Running 0 58s 10.244.1.3 node01 <none> <none>
[root@master ~]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv001 1Gi RWO,RWX Retain Available 84s
pv002 2Gi RWO Retain Available 84s
pv003 2Gi RWO,RWX Retain Bound default/mypvc 84s
[root@master ~]# curl 10.244.1.3
33333
pod 创建不成功检查下网络怎么样,delete pv/pvc.yaml 重试。
10. 测试多路读写
1. 我们通过相同的存储卷,只修改 pod 的名称
cp pvc-demo.yaml 1.yaml
cp pvc-demo.yaml 2.yaml
2. 修改 pod 的名称后,apply 执行创建
kubectl apply -f 1.yaml
kubectl apply -f 2.yaml
3. 查看 ip
kubectl get pod -o wide
4. curl 进行测试,查看是否共享存储卷,多路读写
三、基于动态 storageclass 创建 PV 与 PVC
1. storageclass 定义
前面的例子中,我们提前创建了 PV,然后通过 PVC 申请 PV 并在 Pod 中使用,这种方式叫做静态供给(Static Provision)。
与之对应的是动态供给(Dynamical Provision),即如果没有满足 PVC 条件的 PV,会动态创建 PV。相比静态供给,动态供给有明显的优势:不需要提前创建 PV,减少了管理员的工作量,效率高。
2. storageclass 用途
在 PV 和 PVC 使用过程中存在的问题,在 PVC 申请存储空间时,未必就有现成的 PV 符合 PVC 申请的需求,上面 nfs 在做 PVC 可以成功的因素是因为我们做了指定的需求处理。当 PVC 申请的存储空间不一定有满足 PVC 要求的 PV 时,Kubernetes 为管理员提供了描述存储 “class(类)” 的方法(StorageClass)。举个例子,在存储系统中划分一个 1TB 的存储空间提供给 Kubernetes 使用,当用户需要一个 10G 的 PVC 时,会立即通过 restful 发送请求,从而让存储空间创建一个 10G 的 image,之后在我们的集群中定义成 10G 的 PV 供给给当前的 PVC 作为挂载使用。在此之前我们的存储系统必须支持 restful 接口,比如 ceph 分布式存储,而 glusterfs 则需要借助第三方接口完成这样的请求。
3. storageclass 的 yaml 格式
kubectl explain storageclass #storageclass 也是 k8s 上的资源
KIND: Storageclass
VERSION: storage.k8s.io/vl
FIELDS:
allowVolumeExpansion <boolean>
allowedTopologies<[]Object>apiversion<string>
kind <string>
metadata <object>
mountOptions <[]string>挂载选项
parameters <map[string]string #参数,取决于分配器,可以接受不同的参数。例如参数 type 的值 io1 和参数 iopsPerGB 特定于 EBS PV。当参数被省略时,会使用默认值。
provisioner <string-requred- #存储分配器,用来决定使用哪个卷插件分配 PV。该字段必须指定。
reclaimPolicy <string> #回收策略,可以是 Delete 或者 Retain。如果 StorageClass 对象被创建时没有指定 reclaimPolicy,它将默认为 Delete。
volumeBindingMode<string> #卷的绑定模式
StorageClass 中包含 provisioner、parameters 和 reclaimPolicy 字段,当 class 需要动态分配 PersistentVolume 时会使用到。由于 storageclass 需要一个独立的存储系统,此处就不再演示。从其他资料查看定义 storageclass 的方式如下:
==========================================================
kind: storageClass
apiversion: storage.k8s.io/v1432
metadata :
name : standard
provisioner: kubernetes.iol aws-ebs435 parameters:
type: gp2
reclaimPolicy: Retain
mountoptions:
- debug
示例:
StorageClass standard:
StorageClass slow:
这两个 StorageClass 都会动态创建 AWS EBS,不同在于 standard 创建的是 gp2 类型的 EBS,而 slow 创建的是 io1 类型的 EBS。不同类型的 EBS 支持的参数可参考 AWS 官方文档。StorageClass 支持 Delete 和 Retain 两种 reclaimPolicy,默认是 Delete。
与之前一样,PVC 在申请 PV 时,只需要指定 StorageClass 和容量以及访问模式,比如:
除了 AWS EBS,Kubernetes 支持其他多种动态供给 PV 的 Provisioner,完整列表请参考:https://kubernetes.io/docs/concepts/storage/storage-classes/#provisioner
四、PV、PVC 应用在 mysql 的持久化存储
下面演示如何为 MySQL 数据库提供持久化存储,步骤为:
- 创建 PV 和 PVC。
- 部署 MySQL。
- 向 MySQL 添加数据。
- 模拟节点宕机故障,Kubernetes 将 MySQL 自动迁移到其他节点。
- 验证数据一致性。
1. 创建 MySQL PV 和 PVC
mysql-pv.yml
vim mysql-pv.yml
---------------------------------------
apiVersion: v1
kind: PersistentVolume
metadata:
name: mysql-pv
spec:
accessModes:
- ReadWriteOnce
capacity:
storage: 1Gi
persistentVolumeReclaimPolicy: Retain
storageClassName: nfs
nfs:
path: /nfsdata1/mysql-pv
server: master
mysql-pvc.yml
vim mysql-pvc.yml
-----------------------------------
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: nfs
创建 mysql-pv 和 mysql-pvc
[root@master ~]# kubectl apply -f mysql-pv.yml
persistentvolume/mysql-pv created
[root@master ~]# kubectl apply -f mysql-pvc.yml
persistentvolumeclaim/mysql-pvc created
[root@master ~]# kubectl get pv,pvc
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
persistentvolume/mysql-pv 1Gi RWO Retain Bound default/mysql-pvc nfs 24s
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/mysql-pvc Bound mysql-pv 1Gi RWO nfs 20s
#将先前实验的配置清除,方便检查
2. 部署 MySQL
mysql.yml
vim mysql.yml
------------------------------------
apiVersion: v1
kind: Service
metadata:
name: mysql
spec:
ports:
- port: 3306
selector:
app: mysql
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql
spec:
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- image: mysql:5.6
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: password
ports:
- containerPort: 3306
name: mysql
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pvc
PVC mysql-pvc Bound 的 PV mysql-pv 将被 mount 到 MySQL 的数据目录 /var/lib/mysql。
kubectl apply -f mysql.yml
kubectl get pod -o wide
以下参考:https://www.cnblogs.com/benjamin77/p/9944268.html
参考文档:
K8S 持久化存储 PV/PVC
https://www.cnblogs.com/dingcong1201/p/15538413.html
https://www.cnblogs.com/benjamin77/p/9944268.html
更多推荐
所有评论(0)