如何解决为什么我应该使用 Kubernetes Persistent Volumes 而不是 Volumes
要使用 Kubernetes POD 内的存储，我可以使用 volumes 和 persistent volumes。虽然像 emptyDir 这样的卷是短暂的，但我可以使用 hostPath 和许多其他基于云的卷插件，这些插件可以在卷本身中提供持久的解决方案。
既然如此，我为什么要使用 Persistent Volume？
解决方法
了解 Volumes 和 PersistentVolumes 之间的主要区别非常重要。 Volumes 和 PersistentVolumes 都是 Kubernetes 资源，提供数据存储设施的抽象。
-
Volumes：让您的 pod 写入文件系统，只要 pod 存在，该文件系统就存在。它们还允许您在同一个 pod 中的容器之间共享数据，但是当 pod 重新启动时，该卷中的数据将被破坏。Volume将存储与容器分离。它的生命周期与 Pod 相关联。 -
PersistentVolumes：用作 Kubernetes 集群中的长期存储。它们存在于容器、Pod 和节点之外。 Pod 使用持久卷声明来获取对持久卷的读写访问权限。PersistentVolume将存储与 Pod 分离。它的生命周期是独立的。它支持安全的 pod 重启和 pod 之间的数据共享。
谈到hostPath：
hostPath 卷从主机节点的
文件系统到您的 Pod。
hostPath 有其使用场景，但由于以下几个原因，一般不推荐使用：
-
具有相同配置的 Pod（例如从
PodTemplate创建）可能会因节点上的文件不同而在不同节点上表现不同 -
在底层主机上创建的文件或目录只能由 root 用户写入。您需要在特权容器中以 root 身份运行您的进程，或者修改主机上的文件权限才能写入
hostPath卷 -
您并不总是直接控制您的 pod 将在哪个节点上运行，因此您不能保证 pod 会实际安排在具有数据量的节点上。
-
如果某个节点出现故障，您需要将 pod 安排在其他节点上，而您的本地配置卷在该节点上将不可用。
例如，如果您想将 hostPath 用于在 DaemonSet 中运行的日志收集器，那么它会很好。
我推荐 Kubernetes Volumes Guide 作为本主题的一个很好的补充。
,PersistentVoluemes 是集群范围的存储，允许您更集中地管理存储。
当您配置 volume（使用 hostPath 或任何基于云的卷插件）时，您需要在 POD 定义文件中进行此配置。为卷配置存储所需的每个配置信息都包含在 POD 定义文件中。
当您拥有一个包含大量用户和大量 POD 的大型环境时，用户每次都必须为他们部署的每个 POD 配置存储。无论使用何种存储解决方案，部署 POD 的用户都必须在他/她的所有 POD 定义文件上配置该存储。如果需要进行更改，则用户必须在他/她的所有 POD 上进行此更改。达到一定规模后，这不是管理存储的最佳方式。
相反，您希望集中管理。您希望以这样一种方式管理存储：管理员可以创建一个大型存储池，用户可以根据需要开辟该存储的一部分，而这正是您可以使用 PersistentVolumes 和 { {1}}。
当您需要设置 MongoDB、Redis、Postgres 和 MySQL 等数据库时，请使用 PersistentVolumes。因为它是长期存储，而不是与您的 Pod 深度耦合！非常适合数据库应用程序。 因为它们不会和豆荚一起死去。
在需要长期存储时避免使用 卷。 因为它们会和豆荚一起死去！
就我而言，当我必须存储一些东西时，我总是会选择持久卷！
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。