最新：在Twitter和Mastodon

cert-manager 特性开关

从 v1 版本开始，cert-manager 被认为是稳定的。我们旨在遵循 Kubernetes API 兼容性策略来进行 API 更改，请参阅 API 兼容性，以避免破坏用户现有的 cert-manager 安装。这意味着，作为开发人员，我们在更改现有行为方面受到了一些限制，例如重命名或删除 API 元素或更改其行为。

尚未稳定的新功能1 仍然可以添加，但需要放在特性开关后面。

启用/禁用特性开关

特性开关可以通过 CLI 标志或配置文件启用或禁用，更多信息可以在 配置组件 中找到。

特性开关 API 字段

特性开关 API 字段使用 cert-manager 的 --feature-gates 标志实现，例如 webhook、cainjector 和 controller。

特性开关 API 字段始终对用户可见（例如，运行 kubectl explain <some-resource> 时），但只有在 webhook 和 controller 的特性标志明确启用相关特性时才起作用。

如果用户尝试应用一个带有特性开关字段设置为非空值的资源，但特性开关未启用，则资源将被 webhook 验证拒绝。这种机制不同于 Kubernetes 用于特性开关 API 字段实现的机制，在该机制中，如果特性开关被禁用，则该字段将被简单地设置为 nil。我们选择使用 webhook 验证而不是它，是为了使试图使用特性开关字段的用户更容易调试，但忘记了启用特性开关。

实现

  • 实现新字段并记录它是一个特性开关字段，要使用它，需要启用 controller 和 webhook 的特性开关。
  • 为该字段添加一个新的 webhook 特性开关
  • 更新 webhook 验证检查，以确保如果特性开关字段已设置，但 webhook 特性开关未启用，则资源将被拒绝。
  • 为该字段添加一个新的 controller 特性开关
  • 确保任何使用该特性的控制循环都检查该特性开关是否真正启用。（这是为了涵盖边缘情况，例如如果 webhook 运行的是 cert-manager 的版本，其中该特性处于 GA 状态，而 controller 运行的是旧版本，其中该特性仍处于实验状态）。
  • 确保特性开关已添加到 cert-manager 的 CI 和本地测试的安装脚本中，例如在 make 和 bash 脚本中。
  • 默认的 cert-manager e2e CI 测试运行时，所有组件的所有特性开关都已启用。还有一个可选的 e2e 测试，它在所有特性开关都禁用时运行。你可以使用 /test pull-cert-manager-e2e-feature-gates-disabled 为你的 PR 触发它，以验证所有内容在启用和禁用新特性开关的情况下都能按预期工作。

潜在问题

  • 部署 cert-manager 的人员必须记住设置两个 cert-manager 特性开关，一个在 webhook 上，一个在 controller 上，才能使该特性正常工作。忘记设置其中一个可能会导致意外行为。

  • 用户必须记住在禁用之前启用的 API 特性时，从其清单中删除 alpha 字段。否则可能会导致意外行为，例如，忘记从 Certificate 资源中删除特性开关字段可能会导致以后 cert-manager 的 controller 尝试更新 Certificate spec 时出现续订失败，因为 webhook 会由于特性开关字段已设置而拒绝更新。

参考资料

脚注

  1. 例如，将来可能会根据用户反馈而改变的功能 ↩