卷和持久卷有什么区别？答案

【问题标题】：What is the difference between a volume and persistent volume?卷和持久卷有什么区别？
【发布时间】：2018-07-19 10:44:22
【问题描述】：

我之前使用过这两种类型，我还阅读了以下文档：

https://kubernetes.io/docs/concepts/storage/persistent-volumes/ https://kubernetes.io/docs/concepts/storage/volumes/

但是仍然不清楚区别是什么，两者似乎都支持相同的存储类型，唯一想到的是持久卷似乎有一个“供应”方面。

有什么实际区别？两者之间是否有优点/缺点 - 或者对于哪种用例，一个比另一个更适合？

可能只是“语法糖”吗？

例如，NFS 可以挂载为卷或持久卷。两者都需要 NFS 服务器，两者都将在挂载之间“保留”其数据。在这种情况下会有什么不同？

【问题讨论】：

欢迎来到 Kubernetes 的奇异世界。等到他们添加ephemeral-volumes、temporary-volumes、non-existent-volumes 等...

标签： kubernetes

【解决方案1】：

Volume 将存储与 Container 分离。它的生命周期与 pod 耦合。它可以实现安全的容器重启并在 pod 中的容器之间共享数据。

Persistent Volume 将存储与 Pod 分离。它的生命周期是独立的。它支持安全的 pod 重启和 pod 之间的数据共享。

【讨论】：

是的 - 还是不明白
实际示例，考虑 aws az - 1a 中的 pod 和在 1a 中创建并附加到 pod 的“volume”。事情很好。现在 pod 崩溃了，需要重新安排。它可以安排到 az - 1b 但卷在 1a 中，因此不会被附加。如果我们改用持久化卷，k8s 会将 az 考虑到 pod 调度中，并且只在 1a 上调度。 kubernetes.io/docs/setup/best-practices/multiple-zones/…

【解决方案2】：

卷存在于 pod 的上下文中，也就是说，您不能单独创建卷。另一方面，持久卷是具有自己生命周期的一流对象，您可以手动管理或automatically。

【讨论】：

一个持久卷本身无论如何都不能使用，所以它可以存在于 Pod 上下文之外这一事实似乎没有好处？我能想到的唯一情况是“持久的”emptyDir - 因为数据不会绑定到 pod。
我不知道历史背景为什么认为区分它们两者的术语是一个好主意（也就是说，我同意只有术语体积会更清晰，也许我可以找到答案；）但是 PV 显然可以让您分离关注点：管理员负责 PV 本身（手动或通过存储类），开发人员通过声明使用它们。
@ChrisStryczynski Pod 可以使用持久卷。该概念在 Kubernetes 中由名为 Persistent Volume Claim (PVC) 的对象抽象出来。 Pod 可以指定一个特定的声明，该声明将负责向 Pod 提供正确的 Volume。
让我们看看乔是否还记得……twitter.com/mhausenblas/status/1019919451070849024
我的记忆——PersistentVolumes（和 PersistentVolumeClaims）后来作为一种将供应的生命周期和权限与卷的使用区分开来的方法。卷（作为 Pod 的一部分）是到各种类型的某种存储的映射。如果在带外预先分配，这最初可能是云提供商卷。随着 PV 和 PVC 的引入，您可以让 Volume 成为对绑定到 PV 的 PVC 的引用。另一种思考方式。 Pod:Node::PVC:PV -- 有一个配对/调度正在进行。

【解决方案3】：

我的理解是持久卷的概念建立在卷的概念之上，不同之处在于持久卷与使用它的 Pod 更加分离。或者如关于 Persistent Volumes 的文档页面的介绍中所述：

PV 是与 Volumes 类似的卷插件，但其生命周期独立于使用 PV 的任何单个 pod。

另一方面，Volume 的生命周期取决于使用它的 Pod 的生命周期：

Kubernetes 卷 [...] 具有明确的生命周期 - 与包含它的 Pod 相同。

NFS 在这里并不重要。 Volumes 和 Persistent Volumes 都是 Kubernetes 资源。它们提供了数据存储设施的抽象。因此，对于使用集群，抽象背后的具体操作系统资源并不重要。这在某种程度上是 Kubernetes 的重点。

请记住，Kubernetes 及其 API 仍在不断发展。 Kubernetes 开发人员有时可能会选择引入与现有概念/资源仅有细微差别的新概念/资源。我认为这样做的一个原因是为了保持向后兼容性，同时仍然能够微调基本的 API 概念。另一个例子是复制控制器和副本集，它们在概念上很大程度上重叠，因此在某种程度上是冗余的。虽然，与卷/永久卷不同的是，现在已明确弃用复制控制器。

【讨论】：

持久卷可以解决普通卷无法解决的哪些用例？或相反亦然。到目前为止，据我了解确实存在差异，但它们似乎无关紧要？

【解决方案4】：

卷 ≠ 持久卷

Volumes 和 Persistent Volumes 是相关的，但非常不同！

音量：

出现在 Pod 规范中
不作为 API 资源存在（不能做kubectl get volumes）

持久卷：

是API资源（可以做kubectl get persistentvolumes）
对应于具体的卷（例如在 SAN、EBS 等上）
不能直接与 Pod 关联（他们需要 Persistent Volume Claim）

【讨论】：

【解决方案5】：

它们是两种不同的实现，可以提供一些相似的通用功能（因此很容易混淆）。

持久卷：

支持通过StorageClass 配置的存储
不支持emptyDir卷类型(https://github.com/kubernetes/kubernetes/issues/75378)

卷：

绑定到一个 pod
定义更简单（所需的 Kubernetes 资源更少）

【讨论】：