Jty*_*tan 10 kubernetes google-kubernetes-engine kubernetes-helm
我正在尝试了解 Persistent Volumes 和 Persistent Volume Claims 以及它应该如何在 Helm 中完成...
问题的TLDR版本是：如何在 helm 中创建 PVC，我可以将未来版本（无论是升级还是全新安装）附加到？
我目前的理解：
PV是一块物理存储的接口。PVC 是 pod 声称存在供自己使用的 PV 的方式。当 pod 被删除时，PVC 也被删除，但 PV 被维护 - 因此被持久化。但是，我如何再次使用它？
我知道可以动态配置 PV。以 Google Cloud 为例，如果您只创建一个 PVC，它会自动为您创建一个 PV。
现在这是我坚持的部分......
我创建了一个 helm chart，它明确地创建了 PVC，因此有一个动态创建的 PV 作为发布的一部分。然后我稍后删除发布，这也将删除 PVC。云提供商将维护PV。在后续安装相同图表的新版本中...如何重用旧 PV？有没有办法真正做到这一点？
我确实找到了这个问题的答案......但是，这意味着您需要为您需要的每个 PVC 预先创建 PV，并且副本和自动缩放的重点是所有这些应该按需生成。
用例是 - 一如既往 - 适用于我希望我的数据被持久化的测试/开发环境，但我并不总是希望服务器运行。
先感谢您！我的大脑有点痛，因为我就是想不通……>.<
确实会很头疼。
让我们从您应该如何使用 RWO 存储实现可扩展部署开始，这些存储在单个 Pod 启动时连接到它们。这就是 volumeClaimTemplates 发挥作用的地方。您可以在 Deployment 扩展时动态创建 PVC。然而，当您的 pod 需要附加到 pod 的存储，但当 pod 消失时不再真正需要时，这很适合这种情况（可以根据回收策略重新使用卷。
如果您需要在 pod 失败时重新连接这样的数据，您应该考虑至少解决该部分的 StatefulSets。
现在，如果您显式地预先创建 PVC，您就可以更好地控制发生的事情，但是动态可扩展性对于 RWO 来说会有问题。您链接的响应中的这种和手动 PV 管理实际上可以实现卷重用，这是我能想到的唯一允许它的机制。
在你碰到这样的墙之后，是时候考虑替代方案了。例如，为什么不使用 StatefulSet 来在运行的集群中为您提供存储保留，而不是删除图表，而是将其所有副本设置为 0，将非计算资源保留到位，但将其缩小到零。然后，当您放大仍然绑定的 PVC 时，应该重新连接到重新缩放的 pod。
| 归档时间： |
|
| 查看次数： |
3726 次 |
| 最近记录： |