自上次在技术雷达中亮相以来，Crossplane 的采用率持续增长，尤其是在扩展 Kubernetes 集群方面。在我们的实践中发现，Crossplane 在特定用例中表现出色，而非作为通用的基础设施即代码（IaC）工具。我们早先的观察仍然成立：Crossplane 最适合作为 Kubernetes 内部署工作负载的辅助工具，而不是完全替代 Terraform 等工具。那些将 Crossplane 作为主要 IaC 解决方案的团队往往举步维艰，而那些务实地将其用于特定定制用例的团队则取得了显著成效。将资源生命周期管理下放给 Crossplane，同时利用 XRD API 进行轻量级定制，证明尤其有效。当管理那些生命周期简单但并非 Kubernetes 原生支持的资源时，Crossplane 的价值尤为突出。虽然它现在可以创建 Kubernetes 集群——这一功能以前缺失——我们仍建议在将 Crossplane 作为 Terraform 完全替代方案时保持谨慎。根据我们的经验，最佳做法是以 IaC 作为基础层，再在其上使用 Crossplane 来满足特定需求。
Crossplane是基于Kubernetes Operator模式实现的另一种类型的工具，但它的副作用延伸到了Kubernetes集群之外。在上一期技术雷达中，我们提到了将Kube管理的云服务作为一种技术使用，而Crossplane正是这样做的。其思想是利用Kubernetes控制平面来提供你部署所依赖的云服务，即使它们还没有部署在集群上，例如管理数据库实例、负载平衡器和访问控制策略等。这款工具有两个值得关注的理由。首先，它展示了Kubernetes底层控制平面强大而灵活的执行环境。支持的自定义资源范围没有限制。其次，Crossplane为我们提供了除Terraform、CDK或Pulumi这些常用方案之外的另一种选择。Crossplane为主要的云服务提供了一组预定义的Provider，这些Provider涵盖最通用的配置服务。它并不是要试图成为一个通用的基础设施即代码 (IaC) 工具，而是要成为与Kubernetes部署工作相配套的工具。Crossplane通常与GitOps的实践联系在一起，它是独立的，并且允许你在需要管理外部云资源时，仍然留在Kubernetes的生态系统中。然而，Crossplane并不能帮助配置Kubernetes，你至少需要一个其他的IaC工具来引导集群。
