i007.cc

i007.cc

优先队列-降维打击

05.价值资料

Crossplane和terraform的区别

这个问题其实是把我们之前分别聊的两块内容(Terraform 的机制、Crossplane 解决的痛点)放到一起对比,核心区别可以从几个维度看:

架构模型:命令行工具 vs. Kubernetes 控制器

Terraform 本质上是一个 CLI 工具,你在某个时间点(本地、CI 里)运行 terraform apply,它读一次配置、读一次 state、算一次差异、执行一次变更,然后就结束了,不会自己在后台持续运行。Crossplane 不是这样的执行模型,它是跑在 Kubernetes 集群里的一组 controller/operator,常驻运行,不断地做 reconcile 循环——这跟 Deployment、StatefulSet 这些原生 K8s 资源的工作方式完全一样。这是两者最根本的差异,后面很多区别都是从这一点派生出来的。

执行方式:一次性 apply vs. 持续调谐

正因为上面这点,Terraform 对 drift(资源被手动改动、和配置不一致)是”事后发现”的——只有下次有人跑 plan/apply 才会看到差异。Crossplane 因为是常驻 controller,默认会持续核对期望状态和云端实际状态,发现漂移会自动纠正,不需要人为触发。如果你的场景需要强自愈能力、不希望人工改动长期偏离配置,Crossplane 天然更合适。

状态管理:独立 state 文件 vs. Kubernetes 原生存储

Terraform 需要一份 state 文件记账,要单独考虑存哪里(远程 backend)、怎么加锁、怎么保护里面的敏感信息,这是我们最早聊的那个话题。Crossplane 没有独立的 state 概念,期望状态就是 K8s 里的 Custom Resource,存在 etcd 里,直接复用 Kubernetes 已有的存储、RBAC、审计、事件系统,不用额外发明一套。

交互接口:HCL 配置语言 vs. Kubernetes API

Terraform 用自己的 DSL——HCL——来描述资源,操作方式是命令行加 CI 流水线。Crossplane 里一切都是标准的 Kubernetes 对象(YAML manifest),意味着 kubectl get/describe/edit 这些日常运维手感是通用的,而且天然能被 ArgoCD、Flux 这类 GitOps 工具当作普通应用来管理,不需要专门适配基础设施场景(Terraform 要做到类似效果通常得引入 Atlantis 之类的额外工具)。

能力覆盖:两者都能管云资源,但侧重点不同

单看”调用云 API 创建一个 VM/数据库”这件事,两者都能做,Terraform 的 provider 生态更庞大、更成熟(几乎覆盖所有云厂商和 SaaS),Crossplane 的 provider 生态在快速发展但整体上还没 Terraform 那么全。不过 Crossplane 多出一层 Terraform 没有的东西:Composition(资源组合/抽象层)。平台团队可以把”一个数据库”这种高阶概念暴露给业务团队,底层具体是 AWS RDS 还是 Azure Database 完全隐藏,这是我们上一条讲的”平台工程”能力,Terraform 本身没有对等的原生机制(虽然可以靠 module 做一定程度的封装,但没有 Crossplane 这种基于 K8s API 的自助式申请+权限隔离模型)。

权限和多租户

Terraform 的执行通常是”谁跑 apply 谁就有权限”,权限模型比较粗放,要做精细化多租户隔离得自己搭一层平台(比如 Terraform Cloud 的工作区权限,或自建审批流程)。Crossplane 因为一切都是 K8s 对象,可以直接用 K8s 原生的 RBAC、Namespace、准入控制(OPA Gatekeeper/Kyverno)来做精细化的权限隔离和策略校验,这对做内部开发者平台(IDP)、需要给几十上百个业务团队分权限的场景更友好。

学习曲线和适用团队

Terraform 相对独立,不需要 Kubernetes 知识就能上手,几乎是行业标准,招人、找资料都容易。Crossplane 要求团队已经比较熟悉 Kubernetes 的运作方式(controller、CRD、reconcile 这些概念),学习曲线陡一些,更适合本身就是 Kubernetes 重度用户、想把基础设施管理也统一到 K8s 体系里的团队。

一句话总结

Terraform 是”命令式触发的一次性基础设施编排工具”,Crossplane 是”Kubernetes 原生的、持续自愈的基础设施控制平面,外加一层面向开发者的自助式抽象”。很多组织的实际做法是两者搭配:底层的账号、网络、landing zone 这类相对稳定、变更频率低的基础设施用 Terraform 管,上层面向业务团队的自助式资源申请(数据库、缓存、消息队列这类)用 Crossplane 做抽象和持续调谐,而 Crossplane 自己的 provider 有时候底层也是调用 Terraform 或直接调用云 API 来实现的。

发表回复