Since its last appearance on the Radar, Crossplane adoption has continued to grow, particularly for extending Kubernetes clusters. In our work, we've found Crossplane excels in specific use cases rather than as a general-purpose infrastructure-as-code (IaC) tool. Our earlier observations still hold true: Crossplane works best as a companion to workloads deployed within Kubernetes, not as a full replacement for tools like Terraform. Teams that went "all-in" on Crossplane as their primary IaC solution often struggled, whereas those using it pragmatically — for targeted, custom use-cases — saw strong results. Offloading resource lifecycle management to Crossplane while using XRD APIs for lightweight customization has proven especially effective. Crossplane is particularly valuable when managing resources whose lifecycles are straightforward but not native to Kubernetes. While it can now create Kubernetes clusters — a capability that was previously missing — we advise caution when adopting Crossplane as a complete Terraform replacement. In our experience, it works best when IaC serves as the foundational layer, with Crossplane layered on top for specialized requirements.
Crossplane是基于Kubernetes Operator模式实现的另一种类型的工具，但它的副作用延伸到了Kubernetes集群之外。在上一期技术雷达中，我们提到了将Kube管理的云服务作为一种技术使用，而Crossplane正是这样做的。其思想是利用Kubernetes控制平面来提供你部署所依赖的云服务，即使它们还没有部署在集群上，例如管理数据库实例、负载平衡器和访问控制策略等。这款工具有两个值得关注的理由。首先，它展示了Kubernetes底层控制平面强大而灵活的执行环境。支持的自定义资源范围没有限制。其次，Crossplane为我们提供了除Terraform、CDK或Pulumi这些常用方案之外的另一种选择。Crossplane为主要的云服务提供了一组预定义的Provider，这些Provider涵盖最通用的配置服务。它并不是要试图成为一个通用的基础设施即代码 (IaC) 工具，而是要成为与Kubernetes部署工作相配套的工具。Crossplane通常与GitOps的实践联系在一起，它是独立的，并且允许你在需要管理外部云资源时，仍然留在Kubernetes的生态系统中。然而，Crossplane并不能帮助配置Kubernetes，你至少需要一个其他的IaC工具来引导集群。
