结论先行
希望在 Kubernetes 内提供自服务基础设施 API、持续对账、GitOps 管理云资源，选 Crossplane。需要成熟的执行式 IaC、广泛 Provider、复杂编排和一次性部署，选 Terraform/OpenTofu。
两者可以共存，但不要同时管理同一批云资源。
核心差异
| 维度 |
Crossplane |
Terraform |
| 模型 |
Kubernetes 控制器，持续对账 |
执行式 IaC，plan/apply |
| 状态 |
集群内 CRD + 外部资源 |
state 文件/远程后端 |
| 扩展 |
Provider + XRD/Composition |
Provider + 模块 |
| 自服务 |
原生 CRD/claim |
需要平台层封装 |
| 漂移处理 |
持续 reconcile |
下次 plan 发现 |
| 学习曲线 |
Kubernetes + Composition |
HCL + 状态管理 |
| 生态 |
云厂商 Provider 增长中 |
非常成熟 |
| 适用场景 |
平台工程、K8s 自服务 |
云资源编排、迁移、批处理 |
怎么选
- 平台团队要给业务提供数据库/队列/存储的自服务 API：Crossplane。
- 已有 Terraform 模块和 state，团队熟悉 HCL：继续 Terraform。
- 需要持续修正云资源漂移：Crossplane。
- 需要一次性创建大量云资源、复杂依赖：Terraform。
- 希望所有基础设施都在 Kubernetes 里声明：Crossplane。
- 需要多云和成熟 Provider 覆盖：Terraform 更稳。
注意
- Crossplane 删除 Composite 资源可能级联删除云资源，先确认
deletionPolicy。
- Terraform state 要加密和锁保护，避免多人同时 apply。
- 两者都不要和手工控制台操作混用，漂移会互相覆盖。
- Crossplane 控制面故障时不会自动删除资源，但会停止对账。
- Terraform 的 plan 结果要审查，尤其是删除和替换操作。
相关命令