K8s组合原语之争
3 节点1 篇4 来源
Kubernetes 组合原语之争的核心在于:平台团队是否应继续为每个业务场景手写控制器,还是采用如 kro (Kube Resource Orchestrator) 这样的共享原语来定义资源依赖关系。Adam Crowder 指出,Kubernetes 提供了 CRD、CEL 等“食材”,但缺乏描述资源间顺序与数据流动的“食谱”。这导致 Helm、Argo CD 和 Crossplane 各自构建了类似的逻辑内核。
【背景】kro 于 2025 年 9 月移入 Kubernetes SIG Cloud Provider,主张将组合逻辑视为基础设施原语而非独立平台。
争议焦点在于抽象的成本转移:kro 通过 ResourceGraphDefinition 将依赖顺序从 CEL 引用中自动推导,消除了声明与引用漂移的风险,但也意味着平台团队需承担 API 契约的维护责任。相比之下,Crossplane v2.4 仍采用显式的 Composition Pipeline 函数链来处理状态收敛。读者需关注的是,这种“接线即数据”的模式能否真正减少数千个组织中的重复控制器代码,还是仅仅将复杂性从 Go 代码迁移到了 YAML 定义中。
事情怎么走到这一步
The New Stack 发表 Adam Crowder 的文章,论证 Kubernetes 缺少组合原语,介绍 kro 如何通过 CEL 引用推导依赖顺序以消除漂移。
thenewstack.io ↗Toon Consulting 发布关于 Crossplane 组合管线的深度解析,强调其基于函数管道和观察/期望状态差异的确定性收敛模型,与 kro 的图推导形成技术对照。
toon.consulting ↗Shattered.io 报道 Kubernetes 1.34 生命周期结束及 1.37 发布,提及上游架构对可组合性的持续追求,为讨论提供版本背景。
shattered.io ↗
还没定论的部分
- kro 的 Graph 原语(无实例、仅响应集群现有资源)在实际生产环境中如何保证与 GitOps 流程的兼容性?
- 当依赖顺序完全由 CEL 引用推导时,如何处理循环引用或复杂的条件性依赖场景?