kubernetes工作空间中的持久卷和声明

Question

我已经在k8的工作区中工作了大约6个月，总是想知道为什么我们需要一个持久体积（PV）和持久体积声明（PVC）？有人可以向我阐明这个概念吗？

Answer 1

PV和PVC的分离实现了Kubernetes集群管理和资源管理中的职责划分。

PV是集群管理员将创建的对象，它们将底层存储资源抽象化以向用户公开统一视图（即，这是您可以在这么大的空间中使用的“卷”）。他们只关心将存储资源公开给集群，而不关心将使用谁或如何使用它。引用文档：

  

PersistentVolume（PV）是群集中具有以下内容的一块存储   由管理员提供。它是集群中的资源   就像节点是集群资源一样。 PV是体积插件，例如   卷，但生命周期独立于   使用PV。这个API物件会撷取   存储的实施，可以是NFS，iSCSI或   特定于云提供商的存储系统。

另一方面，集群用户（即那些正在部署和维护应用程序的用户）可以使用PVC动态请求和释放存储块，而不必担心基础架构。他们不必一定在乎存储来自何处或实际对其进行管理。引用文档

  

PersistentVolumeClaim（PVC）是用户存储请求。它   类似于豆荚。 Pod消耗节点资源，PVC消耗PV   资源。 Pod可以请求特定级别的资源（CPU和   记忆）。声明可以要求特定的大小和访问方式（例如   一次读/写或多次只读都可以安装。

在动态预配置的部署中，Kubernetes充当PV管理的角色。用户只需请求一个PVC，Kubernetes便会配置PV并将PVC绑定到PV，从而使存储配置过程对集群用户透明。

希望这会有所帮助！

Answer 2

这些信息来自Kubernetes In Action书。

将Pod与基础存储技术脱钩

理想情况下，在Kubernetes上部署其应用程序的开发人员永远不必知道底层使用了哪种存储技术，就像他们不必知道正在使用哪种类型的物理服务器来运行其pod一样。 / p>

当开发人员需要为应用程序提供一定数量的持久性存储时，他们可以从Kubernetes请求它，就像创建Pod时可以请求CPU，内存和其他资源一样。系统管理员可以配置群集，以便为应用程序提供他们所需的内容。

介绍持久卷和PersistentVolume声明

为了使应用程序能够在Kubernetes集群中请求存储而不必处理基础架构的特定要求，引入了两个新资源。它们是 PersistentVolumes 和 PersistentVolumeClaims 。

由集群管理员设置基础存储，然后通过Kubernetes API服务器创建 PersistentVolume 资源在Kubernetes中注册，而不是由开发人员在其pod中添加特定于技术的卷。 。创建 PersistentVolume 时，管理员会指定其大小和它支持的访问模式。

This image is from Kubernetes In Action book, too.

当集群用户需要在其中一个Pod中使用永久性存储时，他们首先创建一个 PersistentVolumeClaim 清单，指定所需的最小大小和访问模式。然后，用户将 PersistentVolumeClaim 清单提交给Kubernetes API服务器，然后Kubernetes找到合适的PersistentVolume并将该卷绑定到声明。

PersistentVolumeClaim 然后可以用作pod内的一个卷。其他用户不能使用相同的 PersistentVolume ，直到通过删除绑定的< strong> PersistentVolumeClaim 。