自定义资源定义

最佳实践指南的这一部分介绍了创建和使用自定义资源定义对象。

在使用自定义资源定义 (CRD) 时，重要的是要区分两个不同的部分

• 有一个 CRD 的声明。这是具有 kind CustomResourceDefinition 的 YAML 文件
• 然后是使用 CRD 的资源。假设一个 CRD 定义了 foo.example.com/v1。任何具有 apiVersion: example.com/v1 和 kind Foo 的资源都是使用 CRD 的资源。

在使用资源之前安装 CRD 声明

Helm 经过优化，可以尽快将尽可能多的资源加载到 Kubernetes 中。从设计上讲，Kubernetes 可以接收一组完整的清单并将其全部上线（这称为协调循环）。

但 CRD 有所不同。

对于 CRD，必须在使用任何该 CRD 种类的资源之前注册声明。注册过程有时需要几秒钟。

方法 1：让 helm 为您完成

随着 Helm 3 的到来，我们删除了旧的 crd-install 钩子，改用更简单的方法。现在有一个名为 crds 的特殊目录，您可以在图表中创建该目录以存放您的 CRD。这些 CRD 不是模板化的，但会在运行图表的 helm install 时默认安装。如果 CRD 已经存在，它将被跳过并发出警告。如果您希望跳过 CRD 安装步骤，可以传递 --skip-crds 标志。

一些注意事项（和解释）

目前不支持使用 Helm 升级或删除 CRD。经过社区广泛讨论，这是由于意外数据丢失的风险而做出的明确决定。此外，目前还没有关于如何处理 CRD 及其生命周期的社区共识。随着这种情况的发展，Helm 将为这些用例添加支持。

helm install 和 helm upgrade 的 --dry-run 标志目前不支持 CRD。 “干运行”的目的是验证图表的输出在发送到服务器后是否真的有效。但 CRD 是对服务器行为的修改。Helm 无法在干运行中安装 CRD，因此发现客户端将不知道该自定义资源 (CR)，并且验证将失败。您可以选择将 CRD 移到自己的图表中，或者使用 helm template 代替。

在讨论 CRD 支持时需要考虑的另一个重要方面是如何处理模板的渲染。Helm 2 中使用的 crd-install 方法的一个明显缺点是，由于 API 可用性的变化而无法正确验证图表（CRD 实际上是在向 Kubernetes 集群添加另一个可用的 API）。如果一个图表安装了一个 CRD，helm 将不再拥有有效的 API 版本集来进行处理。这也是从 CRD 中移除模板支持的原因。使用新的 crds 方法安装 CRD，我们现在确保 helm 拥有关于集群当前状态的完全有效的信息。

方法 2：单独的图表

另一种方法是将 CRD 定义放在一个图表中，然后将使用该 CRD 的任何资源放在另一个图表中。

在这种方法中，每个图表都必须单独安装。但是，此工作流程对于具有集群管理员访问权限的集群运营商来说可能更有用