当你在多个云厂商之间反复粘贴 Terraform 脚本、为开通一个数据库工单等上三天时，Crossplane 提供了一种更贴近云原生团队习惯的思路：用 Kubernetes 声明式 API 来管理底层 云基础设施。它把 AWS、GCP、阿里云的资源抽象成 CRD，让“开通一个 RDS”和“创建一个 Pod”走同一套 GitOps 流程。本文从概念到落地，带你跑通一条可复用的基础设施自助开通链路。
一、Crossplane 是什么
Crossplane 是一个运行在 Kubernetes 里的开源控制平面，核心使命是“用 K8s 的方式管云”。它本身不替代云厂商控制台，而是在集群内安装一个个 Provider（供应商控制器），由这些控制器把你在 YAML 里声明的资源，翻译成对应云厂商的 API 调用。最终效果：基础设施和应用都变成集群里的“一等公民”，统一由 kubectl、Argo CD、Helm 来管理。
和传统的 IaC 工具相比，Crossplane 最大的差异是“状态自愈”——它持续 reconcile，云上资源被误删或漂移，控制器会自动把状态拉回你声明的样子，这一点在 Terraform 的 apply-once 模型里很难天然获得。
设想一个典型痛点：运维在控制台手动改了一个安全组规则，三个月后没人记得这处“漂移”，直到一次故障才暴露。Crossplane 把资源定义固化在 Git 里，任何偏离声明的变更都会被控制器持续纠正，相当于给云资源装上了“期望状态守护进程”。对已经用 Kubernetes 管理应用的团队来说，这几乎零额外认知成本。
二、Crossplane vs Terraform：不是替代，是补充
很多团队担心“又要学一个工具”。其实二者定位不同：Terraform 擅长一次性、过程式的资源编排；Crossplane 擅长把资源长期托管在集群里、并向上层提供自助服务。实践中两者常共存——用 Terraform 把 Crossplane 的托管集群先铺好，再让业务团队在集群内用 Crossplane 自助开通。下面这张对照表能帮你快速判断该用哪个：
| 维度 | Terraform | Crossplane |
|---|---|---|
| 执行模型 | 命令式 apply（一次性） | 声明式 reconcile（持续生效） |
| 状态存放 | 本地/远端 state 文件 | etcd 内 CR 状态 |
| 自助服务 | 需封装模块+CI | 原生 CRD + Composition |
| 漂移修复 | 靠 plan 人工发现 | 控制器自动拉回 |
| 学习曲线 | HCL 语法独立 | 复用 K8s YAML 习惯 |
三、核心概念速览
动手前先记住四个关键词：Provider（云厂商适配器）、Managed Resource（MR）（云资源映射，如一个 S3 Bucket）、Composition（把多个 MR 组合成一个“套餐”）、Claim（业务方提交的自助申请）。Provider 决定“能管什么云”，Composition 决定“给业务方多简单的入口”，Claim 则是业务方唯一需要关心的 YAML。
四、动手：从零装好 Crossplane
Crossplane 官方提供 Helm Chart，三行命令即可在现有 K8s 集群里跑起来。若你还没有可用的集群，可以先参考 Kubernetes Pod/Deployment/Service 入门 把基础环境搭好。
# 添加官方仓库
helm repo add crossplane-stable https://charts.crossplane.io/stable
helm repo update
# 安装 Crossplane 到独立命名空间
helm install crossplane \
crossplane-stable/crossplane \
--namespace crossplane-system \
--create-namespace
# 确认控制器就绪
kubectl get pods -n crossplane-system
五、配置云厂商凭证与 Provider
以 AWS 为例，先把访问密钥写进 Secret，再用 ProviderConfig 绑定给 Provider。Provider 安装后会在集群里注册一批新 CRD（如 bucket.s3.aws.upbound.io），之后你就能像写 Deployment 一样写云资源。
# 1. 写入云厂商凭证
kubectl create secret generic aws-creds \
-n crossplane-system \
--from-file=credentials=/path/to/aws-key.json
# 2. 安装 provider（用 upbound 官方家族）
kubectl apply -f - <<EOF
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: provider-aws-s3
spec:
package: xpkg.upbound.io/upbound/provider-aws-s3:v1.0.0
EOF
# 3. 绑定凭证
kubectl apply -f - <<EOF
apiVersion: aws.upbound.io/v1beta1
kind: ProviderConfig
metadata:
name: default
spec:
credentials:
source: Secret
secretRef:
namespace: crossplane-system
name: aws-creds
key: credentials
EOF
六、用 Composition 封装“数据库即服务”
直接让业务方写底层 MR 既危险又啰嗦。更好的做法是定义一个 CompositeResourceDefinition（XR），再用 Composition 把“一个带备份策略的 RDS 套餐”打包好。业务方最终只提交一个极简的 Claim，背后的实例、子网、备份全部由 Crossplane 自动拼装。
# 定义组合资源 XR
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
name: xdatabases.example.org
spec:
group: example.org
names:
kind: XDatabase
plural: xdatabases
claimNames:
kind: Database
plural: databases
versions:
- name: v1alpha1
served: true
referenceable: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
size:
type: string
default: "small"
上面的 XR 暴露了一个 size 参数，Composition 根据它选择不同的云资源规格。这种“上层简单、底层灵活”的封装，正是 Crossplane 区别于裸 Terraform 的核心价值。
七、提交 Claim 完成自助开通
业务方完全不需要知道背后是 AWS 还是阿里云，只需要提交一个 Claim。配合 GitHub Actions 流水线，这个 YAML 可以直接进 Git 仓库走 PR 评审，再由 Argo CD 同步到集群——一条标准的 GitOps 基础设施交付链路就串起来了。
# 业务方只需关心这一个极简对象
apiVersion: example.org/v1alpha1
kind: Database
metadata:
name: orders-db
spec:
size: small
compositionRef:
name: rds-with-backup
---
# 查看开通进度
kubectl get database.orders-db -o wide
kubectl get managed # 观察底层 MR 是否 Ready
当 STATUS 变为 READY，云上的数据库实例就已经按套餐创建完成，连接信息会写回 Claim 的 status 字段，应用直接读取即可，无需任何人工介入。
八、生产落地清单
把 Crossplane 引入生产前，建议逐项核对下面这份清单，避免“能跑起来”和“敢用”之间出现落差：
| 检查项 | 要点 |
|---|---|
| Provider 版本锁定 | 固定 xpkg 版本，避免自动升级击穿兼容 |
| 凭证最小化 | 用子账号/角色限定 Provider 仅能操作所需资源 |
| Composition 评审 | 套餐变更走 Git PR，禁止随意改 XR schema |
| 删除保护 | 对关键 MR 加 finalizer 与 deletionPolicy 防误删 |
| 状态可观测 | 把 Crossplane 指标接入 集群监控体系 |
| 灾备演练 | 定期演练 etcd 备份恢复（参考 K8s 准入控制 加固边界） |
九、接入 GitOps：让基础设施变更可评审
Crossplane 的 YAML 天然适合放进 Git 仓库。配合 Argo CD 这类 GitOps 工具，所有基础设施变更都走 Pull Request：评审通过才同步到集群，谁在什么时候改了什么，Git 历史一目了然。这比在云控制台点来点去、事后凭记忆复盘要可靠得多，也天然满足了合规审计对“变更可追溯”的要求。
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: crossplane-infra
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/your-org/infra.git
path: clusters/prod
destination:
server: https://kubernetes.default.svc
namespace: crossplane-system
syncPolicy:
automated:
prune: true
selfHeal: true
上面这份 Application 把整个基础设施目录纳入自动同步并开启 selfHeal——这正是 Crossplane 声明式理念的延伸：不仅云资源会自愈，连“集群应该有哪些资源”本身也会被持续拉回期望状态。把 集群备份 与 Argo CD 的 Git 仓库一并纳入灾备，整条链路就具备了可恢复性。
十、小结
Crossplane 把“基础设施即代码”升级成了“基础设施即 Kubernetes 对象”：统一的控制平面、持续的漂移自愈、面向业务的自助 Claim，以及可评审的 GitOps 交付，让它特别适合已经深度使用 K8s 的团队。如果你正在用 Docker 和 Kubernetes 构建交付体系，又苦于多云资源散落、工单流转缓慢，Crossplane 值得作为下一块拼图纳入技术栈。下一步可以从一个非核心的存储桶或测试库试点，跑通后再逐步把数据库、网络纳入托管，循序渐进地收获声明式基础设施的红利。
