上周一封线上告警把我和一位运维负责人拉进了同一个群里：生产环境的一台数据库副本被人在云控制台手动改了参数组，Terraform 状态文件里却没有这条变更，下一次 apply 又被静默回滚，业务侧看到的是间歇性的慢查询。这件事最能说明当下基础设施"代码化"之后的尴尬——脚本写得出、状态存得住，但没人能在一分钟内说出"生产现在到底长什么样"。
Crossplane 给出的答案不是再写一份更全的 Terraform，而是换一个底座：把 AWS、阿里云、甚至你机房里的裸金属都表达成 Kubernetes 里的自定义资源（CRD），让一个常驻的控制器像管 Pod 一样持续地"看住"这些资源。期望态不是躺在 S3 里的一份 tfstate，而是写在 etcd 里、随时可被 kubectl 查到的一条对象。这套思路被称为"控制平面（control plane）"模式。
本文不打算把 Crossplane 吹成万能钥匙。它确实能解决状态漂移、多云票据各管各的痛点，但也带来 Kubernetes 运维本身的成本。我会沿着"心智模型—边界—代价—密钥—GitOps 分工—团队适配—删除保护"这条线，把真实的取舍讲清楚，顺带给出什么时候一支 Terraform 其实就够了。
Terraform 和 Pulumi 本质上是"一次性进程"：你执行 apply，世界动一下，然后直到下一次 apply 之前，没有任何东西盯着现实世界。如果有人走云控制台改了配置、某个 SRE 为了止血手动改了安全组、或者另一支工具顺手建了个资源，这些变更都会在状态文件之外悄悄发生，等到下次 plan 才被你发现——而这个"下次"可能是几周甚至几个月后。
更麻烦的是状态文件本身成了系统记录（system of record）。当平台团队和十几个应用团队都想改同一片基础设施时，状态文件的锁把所有人串行化了，这恰恰和"自助服务"的方向相反。一次 plan 要是碰上大型模块化代码，光是刷新状态就要等很久，团队于是倾向于少跑 apply，漂移窗口被越拉越大。
Crossplane 把这件事重构成一条常驻的调和循环（reconcile loop）。每个托管资源（Managed Resource，下文简称 MR）背后都有一个 Provider 控制器在定时轮询云 API，默认间隔约 10 分钟；一旦它发现现实与声明不符，就会把现实拉回声明态，或者把 Synced=false 这类条件抛出来等人处理。也就是说，漂移从"几个月后才被发现"变成"下一次调和就可见"。代价是——当运维真的需要在事故中手动改云上配置时，控制器会把它又改回去，所以 Crossplane 预留了 paused 注解作为逃生阀，这条必须写进 runbook。
这里有个容易被忽视的前提：漂移检测能力只在"控制器能读到的资源"上成立。那些用 external-name 收养（adopt）进来的存量资源能纳入调和，但 ObserveOnly 模式只看不碰，绝不会帮你纠正。控制平面不是魔法，它只能对它有凭证、有读权限的东西负责。
理解 Crossplane 只需要抓住三个层次的抽象，理解错层级是绝大多数踩坑的根源。
最底层是 Provider。它是一个被打成 OCI 包的 Kubernetes 控制器，职责是把 Crossplane 的资源定义翻译成目标 API 的调用。装了 provider-aws，你就能声明 S3、RDS；装了 provider-alibaba，你就能声明阿里云的 ECS、OSS、SLB。每个 Provider 通过 ProviderConfig 指向凭证来源（IRSA、密钥、或者注入身份）。当前主线是 v2，核心版本 v2.4 于 2026-08-20 发布，支持 Kubernetes 1.27 到 1.33；AWS 官方 Provider 家族同期已推进到 v2.8.1（2026-09-21 发布）。Provider 本身只是翻译器，没有它 Crossplane 一个资源也建不出来。
中间层是 Managed Resource（MR）：每一个 MR 和云上的一个真实对象一一对应，例如一个 RDS 实例、一个 OSS Bucket。把 MR 直接暴露给应用团队其实违背平台工程的初衷——没人希望开发同学去背 RDS 的每个参数。于是就有了上一层抽象。
再往上是组合层：CompositeResourceDefinition（XRD）定义你打算对外暴露的"平台 API"长什么样，例如一个 XDatabase；Composition 则把这份抽象扇出成底下若干个具体 MR（子网组、安全组、参数组、实例本体、连接密钥）。应用团队只声明"我要一个 medium 规格、50G 的数据库"，平台团队把子网、加密、备份窗口这些策略一次性编码进 Composition，之后所有人提交同一份小接口。
关于 Claim（XRC）要特别说明：在 v1 时代，应用团队先建一个 Claim，再由平台团队定义的 XR 去实现，中间多一层间接。v2 改了默认行为——XRD 新增 scope 字段，默认就是 Namespaced，新建的命名空间级组合资源（XR）直接由消费方在自己命名空间里 apply，不再需要 Claim 这层中转；Claim 只在用老 v1 XRD API、LegacyCluster 作用域下才保留兼容。所以如果你照着两三年前的教程写 claimNames，在新集群上要么不生效要么需要额外迁移。这对新项目意味着：先想清楚你的 API 要不要跨命名空间共享，再决定用 Namespaced 还是 Cluster 作用域的 XRD。
v2 还有一处写法变动必须提前打招呼：Composition 不再用内联的 patch-and-transform 块，而是改成一条由若干 Function 组成的管线（pipeline）。每个 Function 是一个被按顺序调用的 gRPC 服务，常见选型有 Go 模板、KCL、CUE，以及保留下来的 Patch and Transform；你要先以 Function 包的形式把它装上，再在 Composition 里引用。这里有个公认的"第一周陷阱"：每个 Function 收到上游产出的期望态后，必须把没改动的字段原样往下传，否则 Crossplane 会认为那些字段该被删掉。很多新手写出一份只设置了部分字段的 Function，结果底层资源被悄悄削掉一半配置。所以新写 Composition，先确认你用的模板/函数会 forward 全部未修改字段，再谈抽象。
把三者摆在一起看，差异不在"能不能建资源"，而在"建完之后谁盯着"。Terraform 是命令式的一次性执行，plan/apply 跑完就撤；Pulumi 用通用语言写逻辑，本质也是跑完即走；Crossplane 是常驻控制器，声明一旦落进集群就一直被调和。这个区别决定了它们各自该待在哪一层。
对大多数团队来说，收敛出来的生产栈是这样的：用 Terraform 或 OpenTofu 画云底座——VPC、子网、安全组、Kubernetes 集群本身、IAM、DNS、负载均衡；用 Helm/Kustomize 管集群内的工作负载；用 Argo CD 或 Flux 做 GitOps 交付；只有当你确实需要在集群内以云原生方式暴露"基础设施即平台 API"、并且养得起 Composition 的维护成本时，才上 Crossplane。Crossplane 不是来替掉 Terraform 的，它接手的是"应用面向的那层基础设施抽象"，而集群和底座通常还是 Terraform 画更顺手。
| 方式 | 声明形式 | 状态来源 | 漂移检测 | 多云能力 | 学习曲线 |
|---|---|---|---|---|---|
| Terraform | HCL 声明文件，期望态落在 tfstate 状态文件 | 状态文件存于对象存储或本地，加锁串行 | 下次 plan/apply 才暴露，窗口可达数周 | 各家 Provider 生态成熟，但跨云需分别编写 | 中等，模块抽象清晰但状态管理有门槛 |
| Crossplane | Kubernetes CRD（YAML），期望态存 etcd | etcd 中的对象，由常驻控制器守护 | 控制器每约十分钟调和即发现并纠正 | 单一控制平面跨云，但需各自 Provider 包 | 高，需懂 K8s、控制器与 Function 排错 |
| Pulumi | 通用语言（Python/TS/Go）写供给逻辑 | 语言状态服务端或本地文件 | 下次 up 才发现，本质仍跑完即走 | 强，复用 Terraform 生态等效资源 | 中等，会编程即可但状态问题依旧 |
| 云控制台/CLI | 点击或命令行，无版本化声明 | 无系统记录，靠人脑或文档记忆 | 基本无，手动改动难回溯 | 弱，各云相互独立难以统一 | 低，上手快但不可复现难审计 |
把这张表横着读一遍就能看清：四种方式的差异集中在"期望态存在哪"和"谁持续盯着现实"。Terraform 与 Pulumi 把期望态放在外部状态文件、靠人触发；云控制台连状态文件都没有；只有 Crossplane 把期望态放进集群自身并被常驻控制器守护。这正解释了为什么控制平面能压缩漂移窗口，也解释了它为什么要你先养得起一个 Kubernetes 控制平面。
成本侧有个现实账：每个装进集群的 Provider 服务包都会起自己的控制器 Pod、往 API Server 注册一批 CRD，内存随你管理的服务数量增长。crossplane-runtime v2.4（2026-08）针对性地把 Provider 内存在两千个 CRD 量级的集群上压掉了约八成，但"Provider 越多、控制平面越胖"这个物理事实没变。把一万网络纳入比选对象时，也要把这类底座资源的归属想清楚：
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。
换句话说，如果你的"多云"里有一块是自营机房的裸金属，它未必适合硬塞进 Crossplane 的云 Provider 抽象；更适合的做法是用 Terraform 的本地/私有 Provider 或在 Composition 里留一个指向一万网络节点交付的接口，而不是强行把所有东西都 K8s 化。
brief 里最常见的幻想是"一份 Composition 同时编排 AWS RDS 和机房里的裸金属，世界就统一了"。现实没那么便宜。能统一的前提是：机房那侧也得有一个能回答 CRUD 和读状态的 API，否则 Composition 扇出的 MR 里，云资源能被调和，裸金属却只能靠人工或脚本补位，反而制造出新的不一致。
代价一在抽象成本。一份好的 Composition 要替消费方把加密标准、网络规则、备份窗口、规格档位都定死，这本身就是平台工程的工作量，不是装个包就有的。团队小、资源种类少时，这份抽象带来的复用收益可能覆盖不了维护它的心智负担。
代价二在调试成本。传统 Terraform 报错是一条栈；Crossplane 的失败要跨 CRD、Provider 控制器、Function 执行、外部 API 四层去追。Synced=false 时标准动作是 kubectl describe 看 Events（通常直接带云厂商原始报错）、看 Provider Pod 日志（限流、鉴权失败、依赖缺失）、核对 ProviderConfig 凭证是否过期。这一套排障链路需要团队真的懂 Kubernetes，否则一次卡住的 Claim 能耗掉一整天。
代价三在版本耦合。Provider 包有版本约束，核心 Crossplane 升级不满足约束时 Provider 会拒绝安装，所以必须认真做版本钉死和升级测试。v2 把组合资源和托管资源默认改成命名空间级、Composition 改为 Function 管线（v1 的 patch-and-transform 内联写法被移除，需用 function-patch-and-transform 包替代），老教程直接搬过来会编译不过。给裸金属单独写 MR 类型更是定制工程量，没有现成社区 Provider 时要自己实现控制器，投入远超写一份 Ansible。
更具体地说，社区里能直接拿来用的 Provider 集中在主流公有云和 SaaS：AWS、Azure、GCP、阿里云都有官方家族，此外还有 DigitalOcean、Cloudflare、Snowflake、Datadog、Vault、GitHub 等社区 Provider。但"机房里的某一台特定型号裸金属"几乎不存在现成 CRD。想把裸金属编进 Composition，现实路径通常是三条：其一，机房侧若已提供 REST/API 化的供给接口，自己写一个轻量 Provider 把这个接口包成 MR；其二，没有 API 就先用 Terraform 的本地或私有 Provider 把裸金属交付出去，Crossplane 这边只声明一个指向它的引用或占位，调和职责留在 Terraform 侧；其三，干脆把裸金属排除在控制平面之外，只让云资源走 Crossplane，底层节点用传统工单/脚本交付。三条路没有高下，只有"你机房侧的自动化到哪一步"的区别。别因为想凑"同一份声明"的完美，去硬写一个半成品控制器，那会比手工运维更危险。
所以"编进同一份声明"在工程上成立，但它买来的是统一的期望态视图和一致的调和循环，不是零成本的统一。你要先确认机房侧能提供可被机器读写的供给接口，否则这份 Composition 只是半截。
多云场景里最危险的一件事，是把阿里云 AK、AWS Secret 明文写进 Git。Crossplane 的纪律是：凭证永远不进仓库，只进 Kubernetes Secret，再由 ProviderConfig 引用。更彻底的做法是用云厂商的工作负载身份——AWS 的 IRSA、GCP 的 Workload Identity、Azure 的 Managed Identity，通过 credentials.source: InjectedIdentity 让控制器拿短期令牌，根本不落地长期密钥。
但 Secret 进了集群还不够，因为 Crossplane 默认会把托管资源的连接信息（比如数据库密码）再写成一个 connection Secret 供应用消费。这个连接密钥同样不能明文落地到 Git，要靠 Sealed Secrets、External Secrets Operator、或者 Vault Agent 在 GitOps 侧注入。也就是说，密钥的收口是分两段的：云厂商凭证收口到 ProviderConfig，应用侧连接密钥收口到 GitOps 的密钥管理层，两段都不能省。
合规上还有一层：当你把国内机房和海外节点编进同一份声明时，数据驻留和跨境链路的要求要写进 Composition 的策略里，而不是靠人记得。比如某个 XDatabase 是否允许落在海外区域、备份是否要回灌到国内，这些约束应该编码成 XRD 的枚举和校验，让违规声明在提交阶段就被拒。跨境链路本身用"国际线路/跨境链路"来描述，避免把流量路径讲成需要额外审批的专用通道类型。
最后提醒一句：ObserveOnly 模式下的资源，控制器只看不碰，但它的读凭证依然要按最小权限给。很多团队给 Provider 一个管理员级 AK"图省事"，一旦控制平面被攻破， blast radius 就是整朵云。RBAC 必须与命名空间对齐，平台团队只在自己命名空间有权，应用团队只对自己的 XR 有权。
这是被问得最多、也最容易讲混的一点。先给结论：Git 是期望态的"权威源头"，Crossplane 是期望态在集群内的"执行者"和"持续守护者"，两者职责不同，不是谁替代谁。
具体分工是这样的：你把所有 Crossplane 的 XRD、Composition、以及应用团队要提交的 XR 都放进 Git 仓库；Argo CD 盯着这个仓库，把声明同步进集群，并提供 UI、多集群视图、sync wave 这些交付能力。当声明到达集群、变成 etcd 里的对象之后，真正去调云 API、把 AWS RDS 和阿里云资源建出来的，是 Crossplane 的 Provider 控制器。Argo CD 不知道也不关心 RDS 建没建好，它只保证"Git 里的 YAML 等于集群里的对象"；Crossplane 才保证"集群里的对象等于云上的现实"。
这个边界解决了传统混合模型里"两套工具打架"的问题。老的折中方案是 Terraform 管云、Argo CD 管 K8s，两者在集群边界交接；Crossplane 把云资源也变成了 K8s 对象，于是 Argo CD 可以一杆子把"云资源 + 工作负载"一起从 Git 同步下来，不再需要 Terraform 单独跑。但要注意：Argo CD 默认轮询间隔约三分钟，想要亚分钟级反应得配 webhook；而 Crossplane 的调和是异步最终一致，不保证同步事务。对需要强一致、人肉把关的变更（比如动生产数据库规格），保留一个 PR 审批闸门比全自动化更稳。
还有个容易忽略的协作点：CRD 必须先于自定义资源安装，否则 Argo CD 第一次 sync 会因 CRD 未就绪而失败。实践里要么用 ApplicationSet 把"装 CRD"和"装 XR"分成两个 wave，要么把 Crossplane 的包安装也纳入 bootstrap。跨 plane 的调试因此变成"Git 有没有同步 → 集群对象有没有 → 控制器有没有调和 → 云上有没有"四段式，定位问题要习惯这种分层。
sync wave 和 hook 是 Argo CD 侧真正好用的两个旋钮。比如说，你可以把 Crossplane 包和 XRD 放到 wave 0，把 Composition 放到 wave 1，把应用团队实际提交的 XR 放到 wave 2，这样安装顺序天然正确，不会因为"CRD 和 CR 同一次 sync"而互相踩。数据库迁移这类必须在应用启动前完成、且不适合表达成纯声明态的步骤，就交给 hook 或独立的 Argo Workflows，而不是塞进 Crossplane 的调和循环——Crossplane 擅长把云资源维持成期望态，不擅长跑一次性的多步 DAG 任务。把"持续调和"和"跑完即走"两件语义不同的事分给对的控制器，是这套组合能不能长期不吵架的关键。
说句不绕弯的话：如果你团队不到十个人、云资源种类可数、没有要对外暴露的"平台 API"、也不打算让应用同学自助申请基础设施，那 Crossplane 大概率是过度工程。一支结构清楚的 Terraform（或 OpenTofu）配合 PR 审批，已经能把状态漂移的窗口压到你可接受的范围，而且招人、排错、交接都便宜得多。
值得上 Crossplane 的信号更具体：你已经有平台工程角色、Kubernetes 是真熟练、应用团队反复提出"我要一个数据库/一个桶/一个消息队列"这类同构请求、并且你受够了每个请求都要平台同学手写一堆云细节。这时 Composition 的复用收益开始大于维护成本，控制平面的持续调和也开始值回票价。规模阈值大致在：托管资源类型跨三家以上云、或同一抽象被十个以上消费方复用。
团队成熟度阈值同样关键。Crossplane 把排错从"看一条 Terraform 栈"升级成"看控制平面"——CRD、控制器、Function、外部 API 四层。团队里如果没人能稳定地 kubectl describe + 看 Provider 日志，一次 Synced=false 就能把你打回手工运维。换句话说，控制平面省下的是"日常调和的人力"，但它预收的是"平台工程能力"这笔首付，别只看省下的那头。
折中路径也现实：先只用 Crossplane 管一家云的一个高频抽象（比如数据库），跑顺了再扩到多云；底座集群和 VPC 仍交给 Terraform。这样既吃到持续调和的红利，又不至于一上来就被 Composition 和 Function 管线淹没。
一个粗略的经验线供参考：当你的跨云托管资源类型超过二十种、或同一抽象被十个以上消费方反复复用时，控制平面才真正回本；低于这条线，Terraform 加 PR 审批通常更省心。把这句话当作启动 Crossplane 的门槛，比凭热情上项目要稳得多。
控制平面模式下，删除的破坏力被放大了，因为"删一个 K8s 对象"会顺着调和循环一路删到云上真实资源。这也是很多人第一次误删就交代了生产的原因。Crossplane 给了几道保险，但每道都要你主动开。
第一道是 deletionPolicy。默认行为通常是删除对象即删除云资源；你应当把生产资源的 deletionPolicy 设成 Orphan，这样即使 YAML 被误删，云上资源也只"失联"不"销毁"，留给你时间从 external-name 重新收养回来。第二道是 external-name 收养机制：存量资源用 external-name 指向已有 ID/ARN，Crossplane 只管理不新建，避免误删变误建。第三道是 managementPolicy: ObserveOnly，只看不碰，适合先把生产资源纳管观察一阵再决定要不要接管写权限。
回滚本身要分两层想：Git 层回滚（Argo CD 把旧声明同步回去）只解决"集群对象变回旧值"，但云上若已被删，回滚声明会让 Crossplane 重新去建——这能恢复，但重建有时间和数据风险；若数据库用了 Orphan 且底层存储没删，回滚只是重新接管。所以备份策略不能因为"上了控制平面"就松懈，RDS 的自动快照、OSS 的版本化该配还配，控制平面管的是声明，管不了你的恢复点目标。
真正能拦住"一个人删完全部云"的是 RBAC 和删除审批。把生产命名空间的删除权限收口到少数平台账号，应用团队只给 create/update；高危资源再加一层 Argo CD 的 sync 审批或 OPA 校验，让"删一个 Claim 炸多大"的答案从"全炸"变成"只炸它自己那块，且先过一道人"。下文的清单会把这些逐项列成可勾选项。
还有一层隐性成本值得在删除保护话题里一并点破：控制平面本身也要升级，而升级不是改个镜像标签那么轻。从 v1 迁到 v2 时，组合资源和托管资源改成默认命名空间级、Claim 退居兼容位、Composition 改成 Function 管线，老控制平面直接升往往要重写一批 manifest。官方提供了 crossplane beta upgrade check 去扫描现有 v1 控制平面、提前列出不兼容点，但这只告诉你"哪里要改"，改的活还是人的。所以删除保护的另一面，是给控制平面自己也留好备份与回滚通道——etcd 快照、Composition/XRD 的 Git 版本、以及升级前先拿一套非生产环境跑通。把"升级也会出事"写进预案，删除保护才算闭环。
下面把搜索意图里最高频的几个问题直接答掉，不绕概念。
Crossplane 和 Terraform 最本质的区别是什么？一句话：Terraform 跑完即走，Crossplane 常驻调和。前者是命令式一次性执行，后者把期望态放进 etcd 由控制器持续守护，漂移在下次调和即被发现而非下次 apply。选型上 Terraform 适合画底座和需要人肉把关的变更，Crossplane 适合要自助、要持续一致的应用面向抽象。
Provider 怎么装，社区版和企业版差在哪？用 pkg.crossplane.io/v1 的 Provider 对象指向 xpkg.upbound.io 上的包即可，记得钉版本。AWS/Azure/GCP/阿里云都有 Upbound 官方维护的 Provider 家族（免费、Apache-2.0、签名构建、长期维护），还有 crossplane-contrib 社区版适合学习非关键负载；企业版是在官方之上加付费支持与更早版本的钉死能力，核心代码开源免费。
Composition 适合什么团队、不适合什么？适合有平台工程角色、K8s 熟练、同构请求被反复提出的团队；不适合资源种类少、没人维护抽象、K8s 排错能力薄弱的团队，那种情况下它只是把简单事变复杂。
和 Argo CD 怎么分工、谁管期望态？Git 是期望态权威源，Argo CD 负责把 Git 同步进集群并提供交付视图，Crossplane 控制器负责把集群对象调和到云上现实。两者串行而非互斥。
跨云密钥怎么收口避免明文落地？云厂商凭证只进 ProviderConfig 引用的 Secret，优先用 IRSA/Workload Identity 注入身份；应用侧连接密钥用 Sealed Secrets/External Secrets Operator/Vault 在 GitOps 侧注入，绝不进 Git。
误删 Claim 怎么防、RBAC 怎么控？生产资源 deletionPolicy 设 Orphan、存量用 external-name 收养、高危删除收口到少数平台账号并加 sync 审批；别让一个人同时有全部云的写和删权限。
Crossplane 官方博客 blog.crossplane.io：《Cutting Provider Memory by 80%: crossplane-runtime v2.4 and Client Caching》，发布于 2026-08-20，涉及 v2.4 发布与 Provider 内存优化。
Crossplane 官网 crossplane.io：v2 主线与核心定位说明（CNCF Incubating 项目、Apache-2.0、Upbound 主导）。
FAUN.dev：《Crossplane AWS Provider review and score》，2026-09 更新，涉及 AWS 官方 Provider 家族 v2.8.1（2026-09-21 发布）、约 1000 个托管资源类型、Upbound 与社区维护状态。
Upbound Official Provider Family 文档（adhdecode.com 实务解析）：AWS/Azure/GCP 官方 Provider 家族与 Composition 跨云编排示例。
Sempervent 技术博客：《Infrastructure as Code vs GitOps: Control Planes, Drift, and the Politics of Automation》，涉及 Terraform 管云底座、GitOps 管 K8s 资源、Crossplane 模糊边界的论述。
Zaira Labs：《Argo CD vs Crossplane》对比指南，涉及两者执行模型、适用边界与限制。
KodeKloud：《Choosing the Right Engine: Operators vs Workflows vs Pipelines》，涉及 Crossplane 持续调和、Argo CD GitOps、Operator 运行时管理的分层建议。
Clanker Cloud Blog：《Modern IaC Tools and Kubernetes-Native Workflows (2026)》，涉及 2026 年生产栈收敛（Terraform + Helm/Kustomize + Argo CD/Flux + Crossplane 的分层）。
Coding Protocols：《The Terraform Kubernetes-Provider Trap》，涉及 Terraform 画底座与 GitOps 接管的边界划分、Crossplane 作为连续调和模型的定位。
本文涉及的具体云厂商机型与跨云带宽价格，以各官网实时报价为准；凡公开渠道差异较大或非标配置，一律建议询价确认，不做横向精确价格断言。
把视角落回"真要交付一套多云供给"这件事，底座资源往往不是只有云。很多客户的现实是：核心交易在阿里云、数据分析在 AWS、延迟敏感的部分放在自营机房靠近用户的节点。这时候"控制平面"要管的就不只是两家云，还有那块自营裸金属和带宽。
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。
在落地路径上，我们通常会建议客户先别追求"一份声明统管一切"的完美主义：先用 Terraform 把三家云的底座和一万网络的机柜/带宽交付钉死，再在需要自助的那层（比如应用要数据库、要桶）引入 Crossplane 的 Composition，把云资源和机房侧通过各自的 Provider 接口纳进同一套调和循环。跨境链路和国内节点的带宽接入，用一万网络的 BGP 多线资源做就近接入，比硬在云上绕路更省心。这种"云底座 + 控制平面抽象 + 自营节点"的分层，比一步到位的全 K8s 化更经得起运维现实的捶打。
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。
下单或启动项目前，建议把下面这份清单逐项勾掉，它针对的是"用控制平面管多云供给"这个具体场景，不是通用模板：
□ 是否已确认团队具备稳定的 Kubernetes 排错能力（describe + 看 Provider 日志），否则先别上 Crossplane。
□ 是否已把 Crossplane 核心版本和 Provider 版本钉死，并验证 v2 的命名空间级 XR/Function 管线写法，避免直接搬 v1 教程导致编译失败。
□ 生产托管资源的 deletionPolicy 是否设为 Orphan，存量资源是否用 external-name 完成收养而非新建。
□ 云厂商凭证是否走 IRSA/Workload Identity 注入身份，长期 AK 是否只进 ProviderConfig 引用的 Secret、绝不进 Git。
□ 应用侧连接密钥是否通过 Sealed Secrets / External Secrets Operator / Vault 在 GitOps 侧注入，而非明文落地。
□ Git 与 Crossplane 的职责是否划清：Git 是期望态权威源，Argo CD 负责同步进集群，Provider 控制器负责调和到云上。
□ 高危资源的删除权限是否收口到少数平台账号，是否加了 sync 审批或 OPA 校验，避免一人删完全部云。
□ 自营机房侧是否提供了可被机器读写的供给接口；若没有，是否接受先用 Terraform/私有 Provider 交付、再在 Composition 留接口，而非强行全部 K8s 化。
□ 数据驻留与跨境链路要求是否已编码进 XRD 的枚举与校验，海外区域与国内备份策略是否写死在 Composition 而非靠人记得。
□ 备份与恢复点目标是否独立于控制平面配置（RDS 快照、OSS 版本化照配），不因"上了控制平面"而松懈。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
