CrossPlane解决了什么痛点？
Crossplane 的定位其实和我们之前聊的 Terraform/ARM/Bicep 不完全在同一个维度上——它不只是又一个”写模板部署资源”的工具,而是想解决这几类工具共同带来的一批更结构性的痛点。
痛点一:基础设施和应用部署是两套割裂的体系
传统做法里,应用用 Kubernetes/Helm 部署,基础设施(数据库、消息队列、网络)用 Terraform 部署,两者是完全不同的工具、不同的 CI 流水线、不同的权限模型、不同的审计方式。开发者申请一个数据库,可能要走一个完全独立于”部署我的服务”的流程,甚至要找平台团队手动跑 Terraform。Crossplane 的做法是把云资源也变成 Kubernetes 的 Custom Resource,直接跑在 K8s 控制平面里,这样应用和基础设施用的是同一套 API、同一套 kubectl/GitOps 工作流,不用两条腿走路。
痛点二:Terraform 这类工具是”一次性执行”,不会持续纠偏
我们前面聊过 Terraform 的 state——它是一次 apply 时刻的快照,之后如果有人手动改了资源(drift),Terraform 不会自动发现,得等下一次有人主动跑 plan/apply 才能感知到差异。Crossplane 本质上是标准的 Kubernetes controller(reconciler)模式,它会像管理 Pod、Deployment 一样持续对比”期望状态 vs 实际状态”,默认每隔一段时间就主动去云端核对一遍,发现漂移会自动纠正回期望状态,不需要人工触发一次运行。这对需要强一致性、自愈能力的平台场景是个明显优势。
痛点三:state 文件本身是个薄弱环节
Terraform 的 state 要额外找地方存(S3、Azure Storage 等)、要处理锁、要防止敏感信息泄露、要处理并发冲突。Crossplane 不维护单独的 state 文件——所有”期望状态”就是 K8s 里的 Custom Resource 对象,存在 etcd 里,天然继承 Kubernetes 已有的存储、RBAC、审计日志(audit log)、事件(events)体系,不用重新发明一套状态管理和权限系统。
痛点四:面向应用开发者的抽象和自助服务
这是 Crossplane 比较独特的一点:平台团队可以用 Composition(组合)机制定义一个高阶的自定义 API,比如”一个 Database”这个抽象,把底层具体用的是 AWS RDS 还是 Azure Database for PostgreSQL 还是 GCP Cloud SQL 完全隐藏起来。应用开发者只需要提交一个很简单的 “give me a Database” 请求(claim),不需要懂云厂商细节、不需要有云账号权限,Crossplane 会在背后把它翻译成具体云资源。这本质上是在解决”平台工程(platform engineering)”里的核心痛点:怎么在保证治理和安全的前提下,让业务团队自助拿到基础设施,而不用人人都精通每个云的 IaC 细节。
痛点五:GitOps 对基础设施不友好
像 ArgoCD、Flux 这类 GitOps 工具是围绕 Kubernetes 清单设计的,直接管理 Terraform 的 GitOps 流程通常需要额外工具(比如 Atlantis)、而且模型上比较别扭(比如没法很自然地”持续 sync”)。因为 Crossplane 的资源就是 K8s 对象,ArgoCD/Flux 可以像管理任何应用一样原生管理基础设施的期望状态,不需要专门适配。
值得说明的一点
Crossplane 目前是 CNCF 的项目,而且最近的毕业(graduation)投票已经通过——意味着它在多厂商中立性、可持续性、治理规范等方面达到了 CNCF 对”成熟项目”的要求,不是一个小众实验性项目。
简单总结的话:如果你的痛点是”要不要选 Terraform 还是 ARM/Bicep”,那是同类工具间的选型;但如果你的痛点是”想把基础设施配置也纳入 Kubernetes 的统一控制、自愈、GitOps 体系里,或者想给业务团队做一层自助式的平台抽象”,Crossplane 解决的是这个更上一层的问题,很多团队实际上是 Terraform 管底层网络/账号这种”平台地基”,Crossplane 管上层给业务团队用的自助式资源申请。
Sources: