Helm Chart：如何首先安装依赖项？

Question

我一直在开发一个原型图表，该图表依赖于在其中一个子图表中定义的一些自定义资源定义。

更具体地说，我试图在我的 helm 图表中创建strimzi-kafka-operator中定义的资源，并希望首先显式安装依赖项。我遵循helm 文档并将以下内容添加到我的 Chart.yaml 中

dependencies:
- name: strimzi-kafka-operator
  version: 0.16.2
  repository: https://strimzi.io/charts/

我跑：

dependencies:
- name: strimzi-kafka-operator
  version: 0.16.2
  repository: https://strimzi.io/charts/

这表明它正在尝试在我的依赖项之前部署我的图表。首先安装依赖项然后再安装父图表的正确方法是什么？

（作为参考，这是我直接在 GitHub 上与 Strimzi 一起打开的问题，他们告诉我他们不确定如何使用他们的 helm 作为依赖项： https ://github.com/strimzi/strimzi-kafka-operator/issues /2552 )

Answer 1

关于 CRD：事实上，Helm 默认情况下不会管理这些¹，这是一个功能，而不是一个错误。如果不存在，它仍然会安装它们；但它不会修改或删除现有的 CRD。以前版本的 Helm (v2)确实可以，但是（根据经验）如果您不小心，可能会给您带来各种麻烦。引用您引用的链接：

\n\n

\n

目前不支持使用 Helm 升级或删除 CRD。由于存在意外数据丢失的危险，这是经过大量社区讨论后做出的明确决定。[...] Helm 2 中使用的 crd-install 方法的明显缺点之一是，由于 API 可用性的变化而无法正确验证图表（CRD 实际上是向 Kubernetes 集群添加另一个可用的 API）。如果图表安装了 CRD，则 helm 不再有一组有效的 API 版本可供使用。[...] 通过 CRD 安装的新 crds 方法，我们现在可以确保 Helm 拥有有关集群当前状态的完全有效的信息。

\n

\n\n

这里的想法是，Helm 应该仅在发布数据级别进行操作（添加/删除部署、存储等）；但对于 CRD，您实际上是在修改 Kubernetes API 本身的扩展，这可能会无意中破坏使用相同定义的其他版本。考虑一下，如果您所在的团队有一个在多个图表之间共享的 CRD“库”，并且您想卸载以前的一个 \xe2\x80\x94，对于 v2，Helm 会很乐意让您修改甚至删除这些内容会，不会检查它们是否/如何在其他版本中使用。对 CRD 的更改是对控制平面/核心 API 的更改，应将其视为您正在修改全局资源的 \xe2\x80\x94 。

\n\n

简而言之：在 v3 中，Helm 将自己更多地定位为“开发人员”工具来定义、模板化和管理版本；然而，CRD 旨在由“集群管理员”等独立管理。归根结底，这对各方来说都是胜利，因为开发人员可以随意设置/拆卸部署，并确信它不会破坏其他地方的功能……无论谁待命，谁都会赢如果/当您意外删除/修改 CRD 并破坏生产中的内容时，不必处理警报:)

\n\n\n\n

另请参阅此处的广泛讨论，了解此决定背后的更多背景。

\n\n

希望这可以帮助！

\n