我一直在开发一个原型图表，它依赖于在子图表之一中定义的一些自定义资源定义。
更具体地说，我正在尝试在我的 helm 图表中创建 strimzi-kafka-operator 中定义的资源，并希望首先显式安装依赖项。我遵循 helm 文档 并将以下内容添加到我的 Chart.yaml
dependencies:
- name: strimzi-kafka-operator
version: 0.16.2
repository: https://strimzi.io/charts/
我跑了：
$ helm dep up ./prototype-chart
$ helm install ./prototype-chart
> Error: unable to build Kubernetes objects from release manifest: unable to recognize "": no matches for kind "KafkaTopic" in version "kafka.strimzi.io/v1beta1"
这表明它正在尝试在我的依赖项之前部署我的图表。首先安装依赖项然后安装父图表的正确方法是什么？
（作为参考，这是我直接在 GitHub 上与 Strimzi 提出的问题，他们告诉我他们不确定如何使用他们的 helm 作为依赖项：https://github.com/strimzi/strimzi-kafka-operator/issues/2552 )
1，这是一个功能，而不是一个错误。如果不存在，它仍然会安装它们；但它不会修改或删除现有的 CRD。以前版本的 Helm (v2) 确实可以，但是（根据经验）如果你不小心的话，可能会给你带来各种麻烦。引用您引用的链接：
目前不支持使用 Helm 升级或删除 CRD。由于存在意外数据丢失的危险，这是经过大量社区讨论后做出的明确决定。 [...] Helm 2 中使用的 crd-install 方法的一个明显缺点是，由于 API 可用性的变化而无法正确验证图表（CRD 实际上是向 Kubernetes 集群添加另一个可用的 API）。如果图表安装了 CRD，则 helm 不再有一组有效的 API 版本可供使用。 [...] 通过 CRD 安装的新 crds 方法，我们现在可以确保 Helm 拥有有关集群当前状态的完全有效的信息。这里的想法是，Helm 应该仅在
release 数据级别进行操作（添加/删除部署、存储等）；但是使用 CRD，您实际上是在修改 Kubernetes API 本身的扩展，这可能会无意中破坏使用相同定义的其他版本。考虑一下，如果您所在的团队有一个在多个图表之间共享的 CRD“库”，并且您想要卸载一个 — 以前，在 v2 中，Helm 很乐意让您随意修改甚至删除这些库，而无需检查它们是否/如何在其他版本中使用。 对 CRD 的更改是对控制平面/核心 API 的更改，并且应如此对待 — 您正在修改全局资源。
简而言之：在 v3 中，Helm 更多地将自己定位为“开发者”工具来定义、模板化和管理版本；然而，CRD 应该独立管理，例如由“集群管理员”。归根结底，这对各方来说都是双赢，因为开发人员可以随意设置/拆卸部署，并相信它不会破坏其他地方的功能……并且无论谁在值班，都不必处理警报，如果/当你不小心删除/修改 CRD 并破坏生产中的东西时:)