Loading... # 0x01 <div class="tip inlineBlock success"> k8s 啥都好就是不好学 </div> k8s 是一个极其复杂的系统,所以用了很多高度抽象的概念来简化技术细节。这也导致了我这种刚学的 dd 对这些东西一脸懵逼。最近在弄 k8s 持久化存储体系方面的东西,望着 `PV (Persistent Volumes)`、`PVC (Persistent Volume Claim)`、`VC (Persistent Volume Controller)`、`SC (Storage Class)` 这堆名词一脸懵逼。接下来就来理一理这都是些什么鬼。 # PV 、PVC 和 VC - **什么是 PV 、PVC 和 VC** PV 和 PVC 的中文译名为:持久卷和持久卷声明,PV 定义的是一个持久化存储在宿主机上具体的位置,比如一个 NFS 的挂载目录。而 PVC 是描述 Pod 所希望使用的持久化存储的属性。 这有点类似面向对象的逻辑,PVC 类似面向对象里的 **接口 (Interface)** 他提供了持久化存储里的描述,而 PV 提供具体的实现。然后 VC (Persistent Volume Controller) 负责在中间搭线,一旦有了满足 PVC 条件的 PV 出现,就将其 bound。 PVC 和 PV 绑定的条件有两个条件: 1. PV 的 spec 字段内容要满足 PVC 的需求,比如存储的大小。 2. PV 和 PVC 的 storageClassName 字段必须一样。  - **为什么要有 PV 和 PVC** 如果没有 PVC 概念创建 Pod 时才会处理远程挂载等一系列操作,这无疑会拖慢整个 kubelet 的主控制循环,极大地影响 k8s 的整体调度性能。并且 Pod 运行不需要知道挂载的到底是本地磁盘还是 NFS 或是什么其他的存储实现,它只是需要一块能够进行存储的空间。 PV 就是负责处理 PVC 所需要存储空间的底层细节,标识这块持久化存储到底是本地磁盘还是 NFS 或是什么其他的存储实现。 - **PV 和 PVC 的绑定过程** 上面我们说到,当存在满足 PVC spec 和 storageClassName 的 PV 出现,Persistent Volume Controller 就会自动帮我们绑定。这里面就有一个很有趣的操作,我们可以在 PV 和 PVC 中同时命名一个独特的集群内完全不存在的 storageClassName。这样就可以保证这个拥有独特 storageClassName 的 PV 和 PVC一定会绑定到一起。 当然,我们也可以不设置 storageClassName,如果你的集群已经开启了名叫 DefaultStorageClass 的 Admission Plugin,它就会为 PVC 和 PV 自动添加一个默认的 StorageClass;否则,PVC 的 storageClassName 的值就是`""`,这也意味着它只能够跟 storageClassName 也是`""`的 PV 进行绑定。 # StorageClass 如果只有 PV 和 PVC 世界还是不够完美,我们程序员都是非常懒惰的。按照上面的逻辑,Pod 每需求一个 PVC,就需要一个对应的 PV 资源,而 PV 资源需要人工来创建。大多数情况下,我们的 PV 没有很多特殊需求,其 yaml 文件几乎都是类似的。一出现这种大量重复的手工操作,那么一定有可以优化的空间。 StorageClass 就是针对这种情况的优化。当 k8s 里配置好 StorageClass,只需要在 PVC 里指定要使用的 StorageClass 名字,StorageClass 对应的 `provisioner` 就会自动帮我们创建一个对应的 PV。  # Preference [k8s 文档 - storage classes](https://kubernetes.io/zh/docs/concepts/storage/storage-classes/) [k8s 文档 - persistent volumes](https://kubernetes.io/zh/docs/concepts/storage/persistent-volumes/) 最后修改:2021 年 10 月 12 日 10 : 24 AM © 允许规范转载 赞赏 如果觉得我的文章对你有用,请随意赞赏 赞赏作者 支付宝微信