克罗斯普莱恩 v2（于 2025 年末发布）引入了更简洁、基于命名空间的资源模型，并移除了大量围绕声明和集群范围组合资源的 v1 版本繁琐流程。将控制平面升级到 v2 通常是无痛苦的——如果您没有使用那些发生变化的 v1 功能，得益于向后兼容性，您现有的声明将继续正常工作。
困难的部分在于下一步：将现有的 v1 风格工作负载迁移到 v2 风格的命名空间资源上。目前这里仍然缺乏一个连贯的、端到端的解决方案——这也是我花费大部分精力，将整个生产环境的弹性容器服务集群舰队彻底完成迁移的地方。
这篇文章是我希望当时能拥有的现场指南：原地采用方法、如何在接触任何内容之前进行验证，以及会在生产环境中给您带来麻烦的三种故障模式。
这里的任何操作都不会销毁或重建云基础设施。其核心目的是保持每个现有的亚马逊网络服务资源原封不动，仅更改哪个克罗斯普莱恩资源拥有它。
设置（通用术语）
- 一个运行克罗斯普莱恩的控制平面，端到端地管理亚马逊弹性容器服务集群。
- 每个集群由一个克罗斯普莱恩组合资源表示，该组合资源进而拥有约 90–100 个托管资源：身份和访问管理角色/策略、弹性容器服务集群、弹性容器服务插件、托管节点组、启动模板、安全组及规则、开放身份连接提供商，以及一堆通过
provider-kubernetes管理的Object对象。 - 几种不同的集群架构类型，每种类型都由其自身的组合定义支持（例如：通用工作负载集群、入口/网关集群和有状态集群）。迁移机制相同，但资源集略有不同。
- 由吉特奥普斯驱动：吉特仓库作为单一事实来源，由吉特奥普斯控制器进行协调。
塑造所有决策的限制条件：不重建资源、不轮换节点、零停机时间。
为何“删除并重建”不可行
naive 的迁移方式是：删除 v1 组合资源，创建 v2 组合资源，让提供商重建所有内容。在生产环境中，这是不可行的：
- 您不能在流量运行时销毁虚拟私有云、弹性容器服务控制平面或活跃的节点组并重新构建它们。
- 即使是克罗斯普莱恩的
Observe（观察）/导入流程，也会留下一个资源短暂处于未管理状态或被重建的时间窗口。 - 任何重建节点组的操作都会触发节点轮换——集群上的每个 Pod 都会被驱逐并重新调度。这是一个客户可见的事件，您不希望它作为内部重构的副作用出现。
因此，目标不是“创建 v2 资源”。而是“让 v2 组合资源采用 v1 组合资源已经拥有的确切资源，且没有任何可观察到的变化”。
克罗斯普莱恩如何决定创建还是采用
两个事实使得原地采用成为可能：
外部名称是真实云资源的事实来源。克罗斯普莱恩根据其
crossplane.io/external-name注解标识的实际亚马逊网络服务对象，对托管资源进行协调。如果由 v2 拥有的托管资源具有与实时亚马逊网络服务资源相同的外部名称，克罗斯普莱恩会观察它，而不是创建一个新的资源。-
所有权通过标签 + 所有者引用来表达。组合后的托管资源通过以下方式指向其拥有的组合资源：
crossplane.io/composite标签，以及- 指向拥有组合资源（名称 + UID）的库伯内蒂斯
ownerReference。
在组合定义中，每个托管资源由“组合资源名称”键控——即
crossplane.io/composition-resource-n免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
