CRD 管理
原文：https://gateway-api.sigs.k8s.io/guides/getting-started/crd-management/
Gateway API 基于 CRD 构建。这带来了多个重要的好处：其中最值得注意的是，Gateway API 的每一次发布都支持 Kubernetes 的近 5 个次要版本。这意味着你通常不需要为获得最新 API 版本而升级 Kubernetes 集群。
但这种灵活性也带来了一些容易混淆的余地。本指南旨在回答与 Gateway API CRD 管理相关的最常见问题。
CRD 应由谁管理？
归根结底，CRD 是一类权限很高的集群级资源。这意味着应该由集群管理员或集群提供方来负责管理集群中的 CRD。
从实践角度来说，下述任何一种方式都是合理的：
- 集群管理员安装 CRD。
- 集群供应工具或提供方安装并管理 CRD。
部分实现也可能希望把 CRD 打包进自己的安装包里以简化安装流程。这种做法是可以接受的，只要它们永远不会：
- 覆盖那些无法识别或版本更新的 Gateway API CRD。
- 覆盖那些发布通道不同的 Gateway API CRD。
- 删除 Gateway API CRD。
Issue #2678 探讨了一种可行的实现方案。
升级到新版本
Gateway API 通过两个发布通道来发布 CRD。坚持使用标准通道的 CRD，可以既让 CRD 升级更简单，也让升级更安全。
总体准则
- 避免回退（rollback）。新版本 CRD 可能新增字段和特性。回退到 CRD 的旧版本可能导致这些配置丢失。
- 升级前阅读发布说明。某些情况下，发布说明中可能包含你升级前必须遵守的指导。
- 了解 Gateway API 的版本策略，知道哪些内容可能发生变化。
- 虽然通常情况下一次跨多个 Gateway API 次要版本升级是安全的，但最安全、最经实战检验的路径还是一个次要版本一个次要版本地升。
校验 Webhook
早期版本的 Gateway API 带有一个校验 webhook。从 v1.0 开始，该 webhook 已正式被弃用，改用直接嵌入 CRD 内部的 CEL 校验。在 Gateway API v1.1 中，该 webhook 将被完全移除。这意味着：升级到较新版本的 Gateway API 时，校验 webhook 已不再需要单独考虑。
API 版本移除
Gateway API 的某个发布可能会移除一个 alpha API 版本（如 v1alpha2）——前提是该 CRD 已有更新或更稳定的 API 版本。在标准通道中，移除一个 API 版本会被拆分到至少 4 个次要发布：
- 较新版本被设置为存储版本（storage version）。
- 该版本被弃用（会在发布说明中说明，并在使用该弃用版本时给出弃用警告）。
- 该版本不再被 served，但依然被保留在 CRD 中以支持 API 版本之间的自动转换。
- 该版本不再包含在 CRD 中。
如果你正在使用的某个 CRD 走完了这个过程（包括存储版本迁移），可能会有部分资源仍然停留在旧的（被弃用的）存储版本上。当某个 CRD 的存储版本被更新时，该更新只会在该资源被重新保存时才会对该资源本身生效。
例如，如果你在 Gateway API v0.5.0 的 CRD 下创建了一个名为 foo 的 GatewayClass，那么该 GatewayClass 的存储版本会是 v1alpha2。如果这个 foo GatewayClass 自那以后从未被修改或更新过，那么你将无法直接升级到 Gateway API v1.0.0 的 CRD——因为我们的某个资源仍然在使用 v1alpha2 作为存储版本，而 v1alpha2 已经不再包含在 CRD 中（上面的步骤 4）。
要能够升级，你需要采取某种动作，把仍在使用旧存储版本的 GatewayClass 更新一下。例如，对每个 GatewayClass 发出一个空 kubectl patch 就可以起到这种效果。幸运的是有工具可以把这个过程自动化——kube-storage-version-migrator 会自动更新资源，保证它们使用最新的存储版本。
实验通道
顾名思义，实验通道并不提供与标准通道同样的稳定性保证。对一个次要发布来说，下面任何一种情况对实验通道 CRD 都是可能的：
- 对现有 API 字段或资源做破坏性变更。
- 不经过弃用就直接移除 API 字段或资源。
实践中这意味着：升级到新的实验版本时，可能需要你先卸载再重装实验 CRD。如果出现这种情况，发布说明中会做明确说明。