KCL 与其他 Kubernetes配置管理工具的异同 - Kustomize 篇 [一个自研编程语言能做什么？(系列 2)]

在系列上一篇文章https://juejin.cn/post/7176250368827850810中，我们介绍了如何使用 KCL 编写并管理 Kubernetes 配置并将配置下发到集群，这一篇我们通过 KCL 与其他 Kubernetes 配置管理工具的对比如 Kustomize 进一步介绍 KCL 在 Kubernetes 配置管理场景中的用法。

简介

KCL是一个开源的基于约束的记录及函数语言。KCL 通过成熟的编程语言技术和实践来改进对大量繁杂配置的编写，致力于构建围绕配置的更好的模块化、扩展性和稳定性，更简单的逻辑编写，以及更快的自动化集成和良好的生态延展性。

KCL 期望在 Kubernetes YAML 资源管理层面解决如下问题：

1. 用生产级高性能编程语言以编写代码的方式提升配置的灵活度，比如条件语句、循环、函数、包管理等特性提升配置重用的能力
2. 在代码层面提升配置语义验证的能力，比如字段可选 / 必选、类型、范围等配置检查能力
3. 提供配置分块编写、组合和抽象的能力，比如结构定义、结构继承、约束定义等能力

本篇文章是 KCL 可以做什么系列文章第二篇，重点讲述 KCL 语言一些进阶用法以及与 Kustomize 工具的区别，后续会持续更新和分享 KCL 的一系列特点、使用场景和其他 Kubernetes 配置管理工具的异同，大家敬请期待！

KCL 和 Kustomize 的区别

Kustomize 提供了一种无需模板和即可自定义 Kubernetes 资源基础配置和差异化配置的解决方案，通过文件级的 YAML 配置方式完成配置合并或覆盖。在 Kustomize 中用户需要更详细地了解将要发生更改的内容和位置，对于复杂递归过深的基础 YAML 可能不太容易通过选择器来匹配 Kustomize 文件。

而在 KCL 中，用户可以直接把对应代码需要修改的配置书写在对应的地方，免去了阅读基础 YAML 的成本，同时能够通过代码的方式复用配置片段，避免 YAML 配置的大量复制粘贴，信息密度更高，更不容易出错。

下面以一个经典的 Kustomize 多环境配置管理例子详细说明 Kustomize 和 KCL 在 Kubernetes 资源配置管理上的区别。

Kustomize

Kustomize 有 base 和 overlay 的概念，bases 和 overlays 一般是一个包含kustomization.yaml文件的目录，一个 base 可以被多个 overlay 使用

我们可以执行如下命令行获得一个典型的 Kustomize 工程

• 创建 base 目录并新建一个 deployment 资源

 #Createadirectorytoholdthebase mkdirbase #Createabase/deployment.yaml cat<<EOF>base/deployment.yaml apiVersion:apps/v1 kind:Deployment metadata: name:ldap labels: app:ldap spec: replicas:1 selector: matchLabels: app:ldap template: metadata: labels: app:ldap spec: containers: -name:ldap image:osixia/openldap:1.1.11 args:["--copy-service"] volumeMounts: -name:ldap-data mountPath:/var/lib/ldap ports: -containerPort:389 name:openldap volumes: -name:ldap-data emptyDir:{} EOF #Createabase/kustomization.yaml cat<<EOF>base/kustomization.yaml resources: -deployment.yaml EOF 

• 创建一个 prod 目录并放置生产环境的配置

 #Createadirectorytoholdtheprodoverlay mkdirprod #Createaprod/deployment.yaml cat<<EOF>prod/deployment.yaml apiVersion:apps/v1 kind:Deployment metadata: name:ldap spec: replicas:6 template: spec: volumes: -name:ldap-data emptyDir:null gcePersistentDisk: readOnly:true pdName:ldap-persistent-storage EOF cat<<EOF>prod/kustomization.yaml resources: -../base patchesStrategicMerge: -deployment.yaml EOF 

此时我们可以得到一个基本的 Kustomize 目录

. ├──base │├──deployment.yaml │└──kustomization.yaml └──prod ├──deployment.yaml └──kustomization.yaml 

其中，base 目录存放的是基本的 deployment 配置，prod 环境存放的是需要覆盖的 deployment 配置，在其中指定了metadata.name等字段用于表示对哪个资源进行覆盖

我们可以通过如下命令行显示 prod 环境的真实 deployment 配置

$kubectlkustomize./prod apiVersion:apps/v1 kind:Deployment metadata: labels: app:ldap name:ldap spec: replicas:6 selector: matchLabels: app:ldap template: metadata: labels: app:ldap spec: containers: -args: ---copy-service image:osixia/openldap:1.1.11 name:ldap ports: -containerPort:389 name:openldap volumeMounts: -mountPath:/var/lib/ldap name:ldap-data volumes: -gcePersistentDisk: pdName:ldap-persistent-storage readOnly:true name:ldap-data 

也可以通过如下命令行直接将配置下发到集群当中

$kubectlapply-k./prod deployment.apps/ldapcreated 

KCL

我们可以编写如下 KCL 代码并命名为 main.k ，KCL 受 Python 启发，基础语法十分接近 Python, 比较容易学习和上手

apiVersion="apps/v1" kind="Deployment" metadata={ name="ldap" labels.app="ldap" } spec={ replicas=1 #Whenenvisprod,overridethe`replicas`attributewith`6` ifoption("env")=="prod":replicas=6 #Assign`metadata.labels`to`selector.matchLabels` selector.matchLabels=metadata.labels template.metadata.labels=metadata.labels template.spec.cOntainers=[ { name=metadata.name image="osixia/openldap:1.1.11" args=["--copy-service"] volumeMounts=[{name="ldap-data",mountPath="/var/lib/ldap"}] ports=[{cOntainerPort=80,name="openldap"}] } ] template.spec.volumes=[ { name="ldap-data" emptyDir={} #Whenenvisprod #overridethe`emptyDir`attributewith`None` #patcha`gcePersistentDisk`attributewiththevalue`{readOnly=True,pdName="ldap-persistent-storage"}` ifoption("env")=="prod": emptyDir=None gcePersistentDisk={ readOnly=True pdName="ldap-persistent-storage" } } ] } 

上述 KCL 代码中我们分别声明了一个 Kubernetes Deployment 资源的apiVersion、kind、metadata和spec等变量，并分别赋值了相应的内容，特别地，我们将metadata.labels字段分别重用在spec.selector.matchLabels和spec.template.metadata.labels字段。可以看出，相比于 Kustomize 或者 YAML ，KCL 定义的数据结构更加紧凑，而且可以通过定义局部变量实现配置重用。

在 KCL 中，我们可以通过条件语句和 option 函数动态地接收外部参数，为不同的环境需要设置不同的配置值生成不同环境的资源。比如对于如上代码，我们编写了一个条件语句并输入一个名为env的动态参数，当env为prod时，我们将replicas字段由1覆盖为6，并且对名为ldap-data的 volume 配置进行一些调整，如将emptyDir字段修改为None, 增加gcePersistentDisk的配置值等。

可以使用如下命令查看不同环境配置的 diff

diff\ <(kclmain.k)\ <(kclmain.k-Denv=prod)|\ more 

输出如下:

8c8 <replicas:1 --- >replicas:6 30c30,33 <emptyDir:{} --- >emptyDir:null >gcePersistentDisk: >readOnly:true >pdName:ldap-persistent-storage 

可以看到生产环境的配置和基本配置的 diff 主要在于replicas和emptyDir等字段，与预期相符。

此外，我们可以使用 KCL 命令行工具的 -o 参数将编译产生的 YAML 输出到文件中，并查看文件之间的 diff 。

 #Generatebasedeployment kclmain.k-odeployment.yaml #Generateproddeployment kclmain.k-oprod-deployment.yaml-Denv=prod #Diffproddeploymentandbasedeployment diffprod-deployment.yamldeployment.yaml 

当然我们也可以将 KCL 工具与 kubectl 等工具结合使用，将生产环境的配置下发到集群当中。

$kclmain.k-Denv=prod|kubectlapply-f- deployment.apps/ldapcreated 

可以从命令行的结果看出看出与我们使用直接使用 Kustomize 配置和 kubectl apply 的一个 Deployment 体验完全一致，并且无更多的副作用。

最后，通过 kubectl 检查部署状态。

$kubectlgetdeploy NAMEREADYUP-TO-DATEAVAILABLEAGE ldap0/66015s 

小结

本期内容大概简单介绍了用 KCL 编写复杂多环境 Kubernetes 配置的快速入门和使用 Kustomize 工具进行 Kubernetes 多环境配置管理的对比，可以看出相比于 Kustomize, KCL 在实现配置复用和覆盖的基础上，通过代码化的方式减少了配置文件的个数和代码行数，提升了信息密度比，并且同 Kustomize 一样是一个纯客户方案，可以将配置和策略的验证尽可能左移，并不会对集群有额外依赖或造成负担，甚至无需一个真实的 Kubernetes 集群。

除了 Kustomize, 目前阶段 Helm 也在 Kubernetes 配置定义和管理领域也十分流行，熟悉 Kubernetes 的小伙伴可能更喜欢显式配置编写方式。那么相较于 Helm ，用 KCL 来写配置文件渲染，又有什么异同呢？考虑到有很多小伙伴已经在使用 Helm 这样的工具，下一期我将介绍用 KCL 的方式来写 Helm 对应的配置代码，敬请期待！！

如果您喜欢这篇文章，一定记得收藏 + 关注！！更多精彩内容请访问:

• KCL 仓库地址： https://github.com/KusionStack/KCLVM
• Kusion 仓库地址： https://github.com/KusionStack/kusion
• Konfig 仓库地址： https://github.com/KusionStack/Konfig

如果您喜欢这些项目，欢迎 GithubStar 鼓励一下 ，同时欢迎访问下面的链接加入我们的社区进行交流

https://github.com/KusionStack/community