浅析kubernates的pv和pvc网站首页 技术交流

浅析kubernates的pv和pvc

@WAT 2024-09-01 00:01:04

简介浅析kubernates的pv和pvc

文章目录

概要

最近，在看许多Kubenates的相关文章的时候，了解到了一个概念，是我之前不清楚的。–PV&PVC 。那么今天就总结下这几天的收获。

在总结之前我先解释下PV和PVC是什么意思。

PV：Persistent Volume
PVC：Persistent Volume Claim

【通俗字面理解】

从英文的解释上看，大致可以理解为PV就是一个持久化的卷；PVC就是PV的声明

【docker层面理解】

谈到卷，相信学习过docker的小伙伴并不陌生。Volume用于持久化数据的一种机制。那么就可以把PV看做成docker里的卷，那么PVC又怎么理解呢？就是用于统一调用管理PV的。

【官方解释】

PV :持久化卷的意思，是对底层的共享存储的一种抽象
PVC（Persistent Volume Claim）：是持久卷请求于存储需求的一种声明(PVC其实就是用户向kubernetes系统发出的一种资源需求申请。)

在这里插入图片描述
这里还需要明确几个职责：

存储：存储工程师维护
PV： kubernetes管理员维护
PVC：kubernetes用户维护

所以kubernates引入了pvc的概念后，用户就很好的能够使资源的利用率达到最高

名词解释

上面在简单的了解了什么是PV和PVC之后，接下来根据上图所示，介绍几个概念。

概述：

什么是Pod
什么是StorageClass
静态PV和动态PV
PV和PVC的生命周期

什么是Pod

Pod是kubernetes中最小的资源管理组件，Pod也是最小化运行容器化应用的资源对象。
大家都知道，docker是利用生成镜像在容器里运行的工具。
kubernates则是通过Pod承载容器进行运行的工具。
在k8s里一个Pod可以运行一个容器，也可以运行多个容器。不过最常用的是单个容器。

什么是StorgeClass

在上图种，我们可以看到Pod与我们的PVC进行绑定，换言之，Pod消耗的是PVC。然后PVC请求PV资源，而PV资源必须要是管理员事先创建好的。
这样一来就会存在一个问题，当我们的Pod请求的资源没有相应的PV去与PVC匹配的时候，这个时候就必须要管理员手动创建PV。二者之间必然会存在一定的误差，这个时候就引入了StorgeClass

可用于将存储资源定义为具有显着特性的类别（Class）而不是具体的PV，用户通过PVC直接向意向的类别发出申请，匹配由管理员事先创建的PV，或者由其按需为用户动态创建PV，这样做甚至免去了需要事先创建PV的过程。

静态PV和动态PV

在了解了StorgeClass机制后，我们就很好的理解什么是静态PV和动态PV

【静态】：
需要我们自己去手动创建，业务少的情况下可以用手动创建。

【动态】：
根据 yaml 文件里面的参数自动创建合适的 pv，业务量大或者静态 pv 无法满足需求的时候需要动态创建 pv。

PV和PVC的生命周期

其实不论是PV还是PVC，他们之间的关联关系都遵循着一个统一的生命周期：
资源创建–>资源绑定–>资源使用–>资源释放–>资源回收。这么一个生命周期。

【资源创建】
由管理员静态创建PV，或者由PVC动态创建PV。
【资源绑定】
由PVC根据Pod所需要的资源大小以及读取模式绑定PV。PV一旦被绑定，就被该Pod独占。
【资源使用】
PV一旦被PVC绑定，那么Pod就可以像使用Volume一样根据PVC的定义消耗PVC，进而PVC消耗PV
【资源释放】
用户删除PVC来释放PV
当存储资源使用完毕后，用户可以删除PVC，与该PVC绑定的PV将会被标记为“已释放”，但还不能立刻与其他的PVC进行绑定，通过之前PVC写入的数据可能还被留在存储设备上，只有在清除之后该PV才能再次使用
【资源回收】
Kubernetes根据PV设置的回收策略进行资源的回收
对于PV，管理员可以设定回收策略，用于设置与之绑定的PVC释放资源之后如何处理遗留数据的问题，只有PV的存储空间完成回收，才能供新的PVC绑定和使用

PVC ， PV和 StorageClass的关系

PVC 描述的** 是 Pod 想要使用的持久化存储的属性** 。比如存储的大小、读写权限等。
PV 描述的则是一个具体的 Volume 的属性，比如 Volume 的类型、挂载目录、远程存储服务器地址等。
而 StorageClass 的作用，则是充当 PV 的模板。并且，只有同属于一个 StorageClass 的 PV 和 PVC，才可以绑定在一起。