CRD 管理¶

网关 API 是用 CRD 构建的。这带来了一些显著的好处，最值得注意的是，网关 API 的每个版本都支持 Kubernetes 的 5 个最新的次要版本。这意味着你可能不需要升级 Kubernetes 集群就可以获得此 API 的最新版本。

不幸的是，这种额外的灵活性也带来了一些混淆。本指南旨在回答一些与网关 API CRD 管理相关的最常见问题。

谁应该管理 CRD？¶

最终，CRD 是一个高度特权的集群范围资源。这意味着集群管理员或集群提供商应该负责管理集群中的 CRD。

实际上，这意味着以下任何一种方法都是合理的：

集群管理员安装 CRD
集群配置工具或提供商安装和管理 CRD

一些实现也可能希望捆绑 CRD 以简化安装。只要它们从不这样做，这都是可以接受的

覆盖具有无法识别或更新版本的网关 API CRD。
覆盖具有不同发布通道的网关 API CRD。
删除网关 API CRD。

问题 #2678 探讨了实现可能用来实现这一点的一种方法。

升级到新版本¶

网关 API 在两个发布通道中发布 CRD。坚持使用标准通道 CRD 将确保 CRD 升级既简单又安全。

总体指南¶

避免倒退。新版本的 CRD 可以添加新字段和功能。回滚到这些 CRD 的先前版本可能会导致配置丢失。
升级之前阅读发行说明。在某些情况下，它们可能包含一些升级之前需要遵循的指南。
了解网关 API 版本控制策略这样你就可以知道会发生什么变化。
虽然一次升级多个网关 API 次要版本通常是安全的，但最安全且测试最广泛的路径将涉及一次升级一个次要版本。

验证 Webhook¶

早期版本的网关 API 中包含一个验证 Webhook。从 v1.0 开始，该 Webhook 已正式弃用，取而代之的是直接包含在 CRD 中的 CEL 验证。在网关 API v1.1 中，Webhook 将被完全删除。这意味着升级到更新的网关 API 版本时，验证 Webhook 不再是一个考虑因素。

API 版本移除¶

注意

这是一种高级用例，目前仅适用于在同一集群中使用网关 API v0.5.0 的用户。

网关 API 版本可能会移除像 v1alpha2 这样的 alpha API 版本，这些版本在 CRD 中具有更新或更稳定的 API 版本。在标准通道中，API 版本的移除将分布到至少四个次要版本中

一个新的 API 版本被配置为存储版本。
版本已弃用（将在发行说明中注明，并在使用弃用的 API 版本时通过弃用警告进行说明）。
版本不再提供服务，但仍包含在 CRD 中，以便在 API 版本之间自动转换。
版本不再包含在 CRD 中。

如果你使用过经历了此过程的 CRD（包括存储版本迁移），则你的一些资源可能仍然停留在旧的（已弃用）存储版本上。当 CRD 存储版本更新时，此更新仅在使用该 CRD 的单个资源再次保存时生效。

例如，如果你使用网关 API v0.5.0 CRD 创建了一个“foo”GatewayClass，则该 GatewayClass 的存储版本将是 v1alpha2。如果该“foo”GatewayClass 在你升级到网关 API v1.0.0 CRD 之前从未被修改或更新过，那么你就无法升级到网关 API v1.0.0 CRD，因为我们其中一个资源仍在使用 v1alpha2 作为存储版本，而该版本不再包含在 CRD 中（上面的步骤 4）。

为了能够升级，你需要采取一些措施来更新任何使用旧存储版本的 GatewayClass。例如，向每个 GatewayClass 发送一个空的 kubectl patch 将具有此效果。幸运的是，有一个工具可以为我们自动化这个过程 - kube-storage-version-migrator 将自动更新资源以确保它们使用最新的存储版本。

实验频道¶

顾名思义，实验通道不提供与标准通道相同的稳定性保证。在次要版本发布时，实验通道 CRD 可能出现以下任何情况：

现有 API 字段或资源的重大变更
在未经事先弃用情况下移除 API 字段或资源

实际上，这意味着升级到新的实验版本可能需要你卸载和重新安装实验 CRD。如果确实如此，将在发行说明中明确说明。