KCL: Crossplane Composition 游戏规则改变者

本文转译自 Yury Ysarev 2024 年 8 月分享的《KCL: The Game-Changer for Crossplane Composition Building》 原文内容。

https://blog.upbound.io/kcl-benefits-crossplane-composition-building

在不断变化的云原生技术领域中，Crossplane 凭借其通过高级控制平面管理基础设施的能力脱颖而出。通过扩展 Kubernetes，Crossplane 提供了一个统一框架，能够通过强大的抽象来定义、部署和管理云端资源。历史上，Crossplane 主要依赖严格的声明式方法来描述组合逻辑。然而，随着“组合函数”（Composition Functions）的引入，控制平面构建者现在拥有了丰富的语言生态系统。KCL（一种功能强大的表达方式）便是这种能力扩展的绝佳例子，它为定义基础设施提供了一种更为表达性强和灵活的方法。

KCL 为何能提升开发者体验

KCL 的设计充分考虑了简单性和稳健性，提供了多种功能，可显著改善使用 Crossplane 时的开发人员体验。与传统 YAML 不同，KCL 为定义配置提供了更具表现力和类型安全的环境，从而降低了语法错误的可能性并提高了工作效率。

• 声明式和灵活的语法：KCL 的语法比 YAML 更具表现力，允许开发人员编写更简洁、更易读的配置。KCL 的这种声明性与基础设施即代码 (IaC) 范式完美契合，使开发人员能够以直截了当的方式描述他们所需的状态。

• 类型安全和验证: KCL 的突出特点之一是其类型安全特性。它确保配置符合预定义类型，并在开发过程的早期捕获错误。这在复杂的 Crossplane 组合中特别有用，因为小错误可能会导致严重问题。

• 可读性和简洁性：KCL 简洁易读的语法使理解和管理复杂配置变得更加容易。这种清晰度降低了配置错误的风险，并有助于与团队成员更清楚地沟通配置更改。

与 Crossplane 集成

KCL 的贡献者们为 Crossplane 生态系统做出了重大贡献，包括 function-kcl 的开发 https://github.com/crossplane-contrib/function-kcl/。该项目充当了 KCL 和 Crossplane 之间的桥梁，使开发人员能够使用 KCL 定义 Crossplane 组合。这种集成将 KCL 的强大功能直接带入 Crossplane 环境，从而实现更精简、更高效的配置管理。

function-kcl 博客文章 https://blog.crossplane.io/function-kcl/ 深入介绍了 KCL 如何增强 Crossplane 组合。它探讨了将 KCL 与 Crossplane 集成的好处，并提供了这种组合如何简化配置过程的实际示例。

function-kcl 项目利用 KCL 的功能，在构建 Crossplane 组合时提供更强大、更用户友好的体验。通过允许开发人员编写生成 YAML 配置的 KCL 脚本，它结合了两全其美的优势：KCL 的可读性和可维护性以及 YAML 的广泛采用和工具。

体验 KCL 的个人旅程

为了展示 KCL 的实际优势，我想重点介绍一下此拉取请求 https://github.com/upbound/configuration-aws-eks/pull/65 中记录的一个成功实验。在这个项目中，我利用 KCL 增强了 AWS EKS https://www.upbound.io/resources/events/webinars/creating-functional-aws-eks-cluster-with-crossplane-upbound 集群的配置过程。

KCL 最显著的优势之一是简洁。与等效的 Patch & Transform YAML 表示相比，KCL 配置文件明显更短。长度的减少使配置更易于管理且更易于导航。KCL 简洁的语法对于 API 的形式来说感觉很自然，从而允许更直接和可读的配置。

此外，KCL 提供了恰到好处的功能来有效处理循环和条件。这种平衡提供了管理复杂配置所需的灵活性，同时保持了清晰度。简洁性和表达能力的结合使 KCL 成为简化基础设施管理流程、降低配置错误风险和简化与团队成员沟通配置更改的宝贵工具。

KCL 函数入门的关键学习点

1. 读取函数请求和值

使用 KCL 和 Crossplane 的一个基本步骤是了解如何读取函数请求和值。function-kcl 文档 https://github.com/crossplane-contrib/function-kcl/tree/main?tab=readme-ov-file#read-the-function-requests-and-values-through-the-option-function 提供了有关使用 option 函数访问输入数据的详细说明。以下是文档的摘录：

* Read the ObservedComposedResources from option("params").ocds.
* Read the DesiredCompositeResource from option("params").dxr.
* Read the DesiredComposedResources from option("params").dcds.
* Read the function pipeline's context from option("params").ctx.
* Return an error using assert {condition}, {error_message}.

在这里，您可以找到从 XR 读取输入字段、访问观察状态和期望状态、从函数上下文中获取数据甚至返回自定义错误消息的方法。

2. 使用条件语句

KCL 支持条件语句，允许开发人员创建更加动态和响应更快的配置。在AWS EKS 配置中可以找到使用条件语句的示例。以下是相关代码片段：

clusterSecurityGroupId = option("params")?.ocds?[kubernetesCluster.metadata.name]?.Resource?.status?.atProvider?.vpcConfig?[0]?.clusterSecurityGroupId or False
if clusterSecurityGroupId:
  clusterSecurityGroupImport = {
    apiVersion = "ec2.aws.upbound.io/v1beta1"
    kind = "SecurityGroup"
    metadata.name = clusterSecurityGroupId
    spec.providerConfigRef.name = providerConfigName
    spec.deletionPolicy = deletionPolicy
    spec.forProvider = {
      region = region
      tags = {
        "eks.aws.platform.upbound.io/discovery" = id
      }
    }
  }

此功能增强了部署过程的灵活性和控制力。

3. 使用循环

KCL 的另一个强大功能是支持循环，这可以简化重复资源定义的创建。AWS EKS 配置中提供了一个说明性示例。以下是演示循环用法的代码片段：

nodeGroupRolePolicies = [
  "arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy",
  "arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy",
  "arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy",
  "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly",
]

nodeGroupRolePolicyAttachments = [{
  apiVersion = "iam.aws.upbound.io/v1beta1"
  kind = "RolePolicyAttachment"
  metadata.name = xrName + "-nodegroup-rpa-{}".format(i)
  spec.providerConfigRef.name = providerConfigName
  spec.deletionPolicy = deletionPolicy
  spec.forProvider = {
    policyArn = p
    roleSelector = {
      matchControllerRef = True
      matchLabels = {
        "role" = "nodegroup"
      }
    }
  }
} for i, p in nodeGroupRolePolicies]

此功能减少了冗余并提高了配置的可维护性。

4. 在组合资源之间传递数据，无需修补 XR 状态

从历史上看，在组合资源之间共享数据需要修补组合资源 (XR) 状态，详情请参阅 Crossplane 修补文档: 

https://docs.crossplane.io/latest/concepts/patch-and-transform/#patching-between-resources

此方法引入了额外的复杂性，并且需要额外的步骤，例如使用状态字段扩展 XR 规范、发布和使用 XR 状态中的数据。

KCL 函数简化了此过程，允许在配置语言本身内直接在组合资源之间传递数据。这消除了 XR 状态修补的需要，并简化了组件之间数据流的管理。借助 KCL，资源可以直接引用其他资源的输出，从而使配置更加直观并降低出错的可能性。

例如，考虑 AWS EKS 配置示例，其中 Cluster 资源 atProvider 字段的数据被读取并嵌入到新的规范中 SecurityGroup。以下是相关代码片段：

clusterSecurityGroupId = option("params")?.ocds?[kubernetesCluster.metadata.name]?.Resource?.status?.atProvider?.vpcConfig?[0]?.clusterSecurityGroupId or False
if clusterSecurityGroupId:
  clusterSecurityGroupImport = {
    apiVersion = "ec2.aws.upbound.io/v1beta1"
    kind = "SecurityGroup"
    metadata.name = clusterSecurityGroupId
    spec.providerConfigRef.name = providerConfigName
    spec.deletionPolicy = deletionPolicy
    spec.forProvider = {
      region = region
      tags = {
        "eks.aws.platform.upbound.io/discovery" = id
      }
    }
  }

这说明 KCL 能够有效促进资源之间的数据共享，简化配置过程并减少额外步骤的需要。

这些关键学习点为在 Crossplane 项目中有效利用 KCL 奠定了基础。通过掌握这些概念，开发人员可以充分利用 KCL 的强大功能来创建强大而动态的基础架构配置。这些基础步骤对于使用 KCL 引导 Composition 构建非常有用，但该语言本身提供了更多深度和功能可供探索，详情请参阅 https://www.kcl-lang.io/ 上的详尽文档。

此外，function-kcl 示例目录 https://github.com/crossplane-contrib/function-kcl/tree/main/examples 提供了丰富的实用示例，可重复使用并适用于各种 Crossplane 用例。

与其他函数的比较

1. Patch & Transform 函数

在 KCL 之前，Crossplane 中的动态配置管理是通过 function-patch-and-transform 等方法实现的。这种方法通过对基本 YAML 定义应用补丁和转换来实现一定程度的动态配置。虽然它在修改静态配置方面提供了灵活性，但它在处理循环和条件等更复杂的逻辑时往往受到限制，这要求开发人员在 YAML 的约束下工作。

2. Go Templating 函数

Crossplane 生态系统中的另一种方法是使用function-go-templating。此方法在 YAML 模板中引入了动态功能，例如循环、条件和流控制。虽然它增加了更复杂配置所需的灵活性，但也带来了与可维护性相关的重大挑战。管理和调试复杂的模板化 YAML 文件很快就会变得繁琐，尤其是在可读性和简单性至关重要的大型项目中。

相比之下，KCL 提供了一种平衡的方法，将静态 YAML 的优点与高级逻辑功能相结合。它提供了一种更清晰、更易于维护的语法来表达条件和迭代，而没有大量模板的缺点。KCL 的设计简化了管理复杂配置的过程，使其成为现代基础设施配置的有力选择。

进一步提升开发者体验：不只是在 YAML 中嵌入 KCL

虽然将 KCL 嵌入 YAML 配置中是向前迈出的宝贵一步，但它并不是完美的开发人员体验。YAML 中 KCL 表达式的混合有时会使配置的可读性和维护变得复杂。意识到这一点后，我发起了另一个拉取请求 https://github.com/upbound/configuration-aws-eks/pull/68 来增强我们的工作流程。

在这次增强中，我们开始使用专用的 KCL 文件进行配置定义。这种方法可以更清晰地分离关注点，其中 KCL 处理逻辑和动态方面，而 YAML 则作为输出格式。通过在 KCL 中编写配置，然后为 Crossplane 组合生成必要的 YAML，我们实现了更精简和更易于维护的设置。这种分离还使调试和修改配置变得更加容易，因为逻辑结构包含在 KCL 文件中，而生成的 Composition YAML 仍然干净且专注于其目的。

用户反馈和未来计划

我已经开始向 Upbound 用户介绍 KCL，反馈非常积极。用户对 KCL 为他们的配置工作流程带来的清晰度和可维护性改进表示赞赏。我们很高兴很快分享一篇详细的博客文章，重点介绍一个真实的用户故事，强调 KCL 在 Composition Building 中的应用。

结论

KCL 正在彻底改变开发人员与 Crossplane 交互的方式。通过提供更具表现力、类型安全且模块化的配置管理方法，KCL 增强了开发人员的体验并降低了构建 Crossplane 组合的复杂性。随着 Crossplane 生态系统的不断发展，采用 KCL 可能会在实现更高效、无错误的基础设施管理方面发挥关键作用。

虽然 KCL 确实存在学习曲线，但其丰富的文档和实际示例使过渡更加顺畅。此外，KCL Cheatsheet https://www.kcl-lang.io/assets/images/cheatsheet-9dd02ca1109d7a0b8f94114807250496.png 等资源对于快速上手非常有用。

Upbound 最近举办了一场网络研讨会 https://resources.upbound.io/all-content/whats-new-with-crossplane-v1-16，Jared 和 Viktor 分享了他们对 KCL 的实用看法。他们强调，KCL 比 CUE 更简单，同时避免了过于简单的方法，从而有效地平衡了简单性和功能性。

无论您是经验丰富的 Crossplane 用户还是刚刚开始使用，将 KCL 集成到您的工作流程中都可以带来显著的好处，简化开发流程并使您能够专注于真正重要的事情：构建出色的应用程序。

如果您想更深入地了解 Crossplane 之旅，此后还将介绍如何使用 AWS 提供商使用 Upbound/Crossplane 创建功能齐全的 AWS EKS 集群。

https://www.upbound.io/resources/events/webinars/creating-functional-aws-eks-cluster-with-crossplane-upbound