解读kubernetes中pv和pvc的关系

2019-07-19

解读kubernetes中pv和pvc的关系

image.png

为什么会有PV 和 PVC的概念

PV和PVC使得K8s集群具备了存储的逻辑抽象能力,使得在配置Pod的逻辑里可以忽略对实际后台存储技术的配置,而把这项配置的工作交给PV的配置者,即集群的管理者(运维人员)。存储的PV和PVC的这种关系,跟计算的Node和Pod的关系是非常类似的;PV和Node是资源的提供者,根据集群的基础设施变化而变化,由K8s集群管理员配置;而PVC和Pod是资源的使用者,根据业务服务的需求变化而变化,有K8s集群的使用者即服务的管理员来配置。

在实际工作做的运用模式

k8s集群的管理者(运维人员)选择合适的存储类storageClass来创建pv,k8s的使用者(开发人员)直接通过pvc去声明选择一个合适的pv来使用,开发人员不需要了解底层的存储是如何实现的,他们只需要声明要使用卷的大小和模式,pvc会自动的选择一个合适的pv去使用它.

pv 的概念

PersistentVolume(持久卷,简称PV)是集群内,由管理员提供的网络存储的一部分。就像集群中的节点一 样,PV也是集群中的一种资源。它也像Volume一样,是一种volume插件,但是它的生命周期却是和使用它的Pod相互独立的。PV这个API对 象,捕获了诸如NFS、ISCSI、或其他云存储系统的实现细节。

pvc 的概念

PersistentVolumeClaim(持久卷声明,简称PVC)是用户的一种存储请求。它和Pod类似,Pod消耗Node资源,而PVC消耗PV资源。Pod能够请求特定的资源(如CPU和内存)。PVC能够请求指定的大小和访问的模式(可以被映射为一次读写或者多次只读)。

两种提供PV的方式

静态(static)

集群管理员创建多个PV.他们携带可供集群用户使用真实存储的详细信息.他们存在于kubernetes API 中,可用于pvc消费

动态(Dynamic)

当管理员创建的静态的pv都不能匹配pvc声明的时候,集群可能会尝试为 PVC 动态的配置卷, 此配置基于StorageClasses:PVC必须请求一个类,并且管理员必须已创建并配置该类才能进行动态配置。 要求该类的声明有效地为自己禁用动态配置

PV的几种状态

  • Available —-> 资源尚未陪pvc 使用
  • Bound —-> 资源已经被pvc绑定使用
  • Released —-> pvc已经被删除,卷处于被释放状态,但未被集群回收(pv不能被继续使用)
  • Failed —-> 卷自动回收失败

pv的几种访问模式(accessModes)

  • RWO –> ReadWriteOnly –> 仅允许单个节点挂载读写
  • ROX –> ReadOnlyMany –> 允许多个节点以只读的方式挂载
  • RWX –> ReadWriteMany –> 允许多个节点挂载读写

PV和pvc的绑定规则

1, 首先按照访问模式来匹配
2, 其次按照容量大小来选择最合适的匹配(尽量的节省资源)
3, 如访问模式和容量大小都一样,按照标签来匹配,如果没有标签随机匹配

PV 和 Pvc 的关系

PV 是集群中的资源,PVC 是对这些资源的请求,同时也是这些资源的使用者
pvpvc是一一对应关系,即一个pvc只能绑定到一个pv上,一个pv一旦被一个pvc绑定,其他的pvc就不能使用这个pv了.
你如果仔细的阅读了我上面的内容,你心中肯定充满疑问,上面这个地方说的貌似和上面有冲突,不相符合啊,别着急,下面我会以实验的方式来解决你的疑惑的

解释pv和pvc一一对应的关系

首先使用HostPath模式创建一个pv

vim pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: test-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteMany
  hostPath:
    path: /tmp/pv

创建pv

[root@rke test_pv]# kubectl create -f pv.yaml
persistentvolume/test-pv created
[root@rke test_pv]# kubectl get  pv
NAME          CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                            STORAGECLASS   REASON   AGE
test-pv       1Gi        RWX            Recycle          Available                                                            3s

可以看得出来pv的状态为Available,未绑定状态

编写pvc文件

[root@rke test_pv]# cat pvc.yml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pvc
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 300M

创建pvc

kubectl create -f pvc.yml

查看pv和pvc的绑定关系

[root@rke test_pv]# kubectl get pv
NAME          CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                            STORAGECLASS   REASON   AGE
test-pv       1Gi        RWX            Recycle          Bound    default/test-pvc                                         6m


[root@rke test_pv]# kubectl get pvc
NAME                     STATUS   VOLUME        CAPACITY   ACCESS MODES   STORAGECLASS   AGE
test-pvc                 Bound    test-pv       1Gi        RWX                           10s

我们这个时候在生命一个300M的pvc ,看看他会不会绑定到这个pv上

[root@rke test_pv]# cat pvc_2.yml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pvc-2
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 300M

创建这个pvc,并查看状态

[root@rke test_pv]#  kubectl create -f pvc_2.yml
persistentvolumeclaim/test-pvc-2 created
[root@rke test_pv]# kubectl get pvc
NAME                     STATUS    VOLUME        CAPACITY   ACCESS MODES   STORAGECLASS   AGE
test-pvc-2               Pending                                                          6s

可以看到他没有绑定到我们上面创建的那个pv上,按理说我上面的那个pv声明了 1G ,但是我第一个pvc只需要300M,但是他还是会直接选择把这个 1G 的pvc占用,别的pvc就无法占用,如果我们没有设置动态的pv,那么pvc找不到合适的他就会一直处于Pending状态,当有合适的pv起来之后,他就会自己绑定pv上

我们现在声明两个pv,一个300M,一个500M,看这个pvc会绑定到哪个pv上.

[root@rke test_pv]# cat pv_2.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: test-pv-2
spec:
  capacity:
    storage: 500M
  accessModes:
  - ReadWriteMany
  hostPath:
    path: /tmp/pv-2
  persistentVolumeReclaimPolicy: Recycle

---
apiVersion: v1
kind: dacaa
metadata:
  name: test-pv-3
spec:
  capacity:
    storage: 300M
  accessModes:
  - ReadWriteMany
  hostPath:
    path: /tmp/pv-3
  persistentVolumeReclaimPolicy: Recycle

创建pv,查看绑定关系

[root@rke test_pv]# kubectl create  -f pv_2.yaml
persistentvolume/test-pv-2 created
persistentvolume/test-pv-3 created
[root@rke test_pv]# kubectl get pvc
NAME                     STATUS    VOLUME        CAPACITY   ACCESS MODES   STORAGECLASS   AGE
test-pvc-2               Bound    test-pv-3     300M       RWX                           6m

可以看到他选择的是pv 为300M的那个,满足我上术讲的匹配条件2,也验证了pvc当有合适的pv起来只后会绑定到pv上

实验测试pv的访问模式是什么意思

PV的三种回收机制

  • Retain(保留): 当pvc和pv解除绑定关系,这个pv处于保留状态,等待下次再次声明同样的PVC时,被继续绑定使用.里面的内容不会被删除
  • Recycle(回收): 当pvc 和 pv 解除绑定关系的时候,pv会被回收,删除上一个pvc留下的数据,可以重新被其他pvc声明所使用(数据丢失)
  • delete(删除): 当pvc 和 pv 解除绑定关系的时候,pv就会被删除(数据自然也就丢失了)

只有 NFS 和 HostPath 支持 Recycle 策略,AWS EBS、GCE PD 以及 Cinder 卷支持 Delete 策略


标题:解读kubernetes中pv和pvc的关系
作者:shoufuzhang
地址:https://www.zhangshoufu.com/articles/2019/07/19/1563529191249.html
名言:The master has failed more times than the beginner has tried.
评论
发表评论