别再手点云控制台了：用 Crossplane，把云资源也纳入 GitOps 管理

别再手点云控制台了：用 Crossplane，把云资源也纳入 GitOps 管理

说个扎心的事实。

很多公司嘴上天天喊着：

“我们已经全面 GitOps 了！”

结果一看现实世界：

• 应用用 GitOps 管
• Kubernetes 用 GitOps 管
• 云资源？
  👉 还在控制台里点，Terraform 状态文件满天飞，谁改的都说不清

于是就出现一个非常魔幻的场景：

应用是声明式的，云资源却是“人治”的。

而 Crossplane 的出现，本质上就是来干一件事的：

把云资源，拉回到 Kubernetes + GitOps 的世界里。

一、为什么传统云资源管理，在 GitOps 时代显得这么“别扭”？

先别急着上 Crossplane，我们先把问题掰开了看。

1️⃣ 控制台运维：看似快，实则后患无穷

我见过太多这样的场景：

• 紧急上线 → 控制台手动点一个 RDS

• 谁点的？不知道

• 配置是啥？凭记忆

• 半年后环境炸了：

  “当初怎么配的来着？”

一句话总结：

控制台 = 快速满足当下，但彻底放弃长期可维护性。

2️⃣ Terraform 真的完美吗？

Terraform 当然是好东西，我也用过很多年。

但在 GitOps 体系里，它有几个绕不开的现实问题：

• 状态文件是核心资产
• 多人协作容易锁状态
• 和 Kubernetes 是“并行宇宙”
• 应用和基础设施依然是两条流水线

于是你会发现：

应用交给 Argo CD，云资源交给 Terraform Cloud，逻辑上还是割裂的。

二、Crossplane 是来干嘛的？一句话讲清楚

如果你只记住一句话，那就是这句：

Crossplane = 用 Kubernetes 的声明式方式，管理一切云资源。

在 Crossplane 眼里：

• RDS 是一个 CRD
• VPC 是一个 CRD
• S3 / OSS / COS 也是 CRD

而 GitOps 的核心是什么？

Git 是唯一真相源（Single Source of Truth）

这俩一拍即合。

三、Crossplane + GitOps，本质解决了哪 3 个运维老痛点？

痛点一：云资源和应用生命周期不同步

以前：

• 应用删了
• 云资源还在
• 账单月底一看，心在滴血

现在：

• 应用 YAML 删除
• Crossplane 自动回收资源

👉 生命周期强绑定

痛点二：环境一致性靠“人品”

以前：

• 测试环境一套参数
• 生产环境“微调过”
• 出问题只能祈祷

现在：

• 所有环境 = Git 仓库
• 差异 = diff 一眼可见

👉 环境即代码

痛点三：平台团队和业务团队扯皮

经典对话：

业务：我要一个数据库
运维：你提工单
业务：要等多久？
运维：看情况……

Crossplane 的思路是：

平台团队定义“能用什么”，业务团队只管“我要什么”。

四、Crossplane 的核心思想，其实一点都不复杂

1️⃣ Provider：对接云厂商

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-aws
spec:
  package: crossplane/provider-aws:v0.42.0

👉 就是插件，AWS / 阿里云 / Azure 都有。

2️⃣ Managed Resource：云资源原子能力

apiVersion: rds.aws.crossplane.io/v1alpha1
kind: DBInstance
spec:
  forProvider:
    dbInstanceClass: db.t3.micro
    engine: mysql
    engineVersion: "8.0"

这一步很多人会吐槽：

“这不就是把云 API 翻译成 YAML 吗？”

对，但别急，重点不在这层。

3️⃣ Composite Resource（XR）：平台真正的价值

这才是 Crossplane 最牛的地方。

平台团队可以定义一个**“业务级资源”**：

apiVersion: platform.echo.io/v1
kind: MySQL
spec:
  size: small
  env: prod

而底下真实创建的可能是：

• RDS
• 安全组
• 子网
• 参数组
• 监控告警

👉 业务不用知道这些细节。

五、Crossplane + GitOps 的标准落地姿势

我给你一套非常实用、落地过的组合拳。

架构组合

• Crossplane：资源控制面
• Argo CD / Flux：GitOps 引擎
• Git Repo：唯一真相源

工作流长这样：

1. 业务提交 YAML 到 Git
2. Argo CD 同步到集群
3. Crossplane reconcile
4. 云资源自动创建 / 变更
5. 状态回写到 CRD

一句话总结：

不登录云控制台，也能管好云资源。

六、我踩过的一些坑，提前帮你避一避

坑一：一开始就暴露太多云参数

别把所有云参数都暴露给业务。

👉 一定要做抽象分层

否则你只是把 Terraform 的复杂度，换成了 YAML 的复杂度。

坑二：Git 仓库结构混乱

建议至少分三类：

• platform-definitions
• environment-configs
• application-resources

不然半年后，没人敢动。

坑三：别一口吃成胖子

我见过有人第一步就想：

“我们要用 Crossplane 管所有云资源！”

结果直接劝退。

正确姿势是：

从数据库、缓存、对象存储这种“高频资源”开始。

七、我个人为什么越来越看好 Crossplane？

说点主观感受。

这些年我最大的感受是：

运维的价值，不是“我会点多少按钮”，而是“我能不能构建一套别人用得爽的系统”。

Crossplane 带来的，不只是一个工具，而是：

• 平台化思维
• 产品化运维
• 把“经验”沉淀成“能力”

这件事，很难，但一旦做成，壁垒极高。

八、写在最后

如果你所在的团队：

• 正在推 GitOps
• 正在做平台工程
• 正在被云资源治理折磨