在系列上一篇文章 https://my.oschina.net/u/4724... 中，咱们介绍了如何应用 KCL 编写并治理 Kubernetes 配置并将配置下发到集群，这一篇咱们通过 KCL 与其余 Kubernetes 配置管理工具的对比方 Kustomize 进一步介绍 KCL 在 Kubernetes 配置管理场景中的用法。
简介
KCL 是一个开源的基于束缚的记录及函数语言。KCL 通过成熟的编程语言技术和实际来改良对大量繁冗配置的编写，致力于构建围绕配置的更好的模块化、扩展性和稳定性，更简略的逻辑编写，以及更快的自动化集成和良好的生态延展性。
KCL 冀望在 Kubernetes YAML 资源管理层面解决如下问题：
- 用生产级高性能编程语言以编写代码的形式晋升配置的灵便度，比方条件语句、循环、函数、包治理等个性晋升配置重用的能力
- 在代码层面晋升配置语义验证的能力，比方字段可选 / 必选、类型、范畴等配置查看能力
- 提供配置分块编写、组合和形象的能力，比方构造定义、构造继承、束缚定义等能力
本篇文章是 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 资源
# Create a directory to hold the basemkdir base# Create a base/deployment.yamlcat <<EOF > base/deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata: name: ldap labels: app: ldapspec: 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# Create a base/kustomization.yamlcat <<EOF > base/kustomization.yamlresources:- deployment.yamlEOF
- 创立一个 prod 目录并搁置生产环境的配置
# Create a directory to hold the prod overlaymkdir prod# Create a prod/deployment.yamlcat <<EOF > prod/deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata: name: ldapspec: replicas: 6 template: spec: volumes: - name: ldap-data emptyDir: null gcePersistentDisk: readOnly: true pdName: ldap-persistent-storageEOFcat <<EOF > prod/kustomization.yamlresources: - ../basepatchesStrategicMerge: - deployment.yamlEOF此时咱们能够失去一个根本的 Kustomize 目录
.├── base│ ├── deployment.yaml│ └── kustomization.yaml└── prod ├── deployment.yaml └── kustomization.yaml其中，base 目录寄存的是根本的 deployment 配置，prod 环境寄存的是须要笼罩的 deployment 配置，在其中指定了 metadata.name 等字段用于示意对哪个资源进行笼罩
咱们能够通过如下命令行显示 prod 环境的实在 deployment 配置
$ kubectl kustomize ./prodapiVersion: apps/v1kind: Deploymentmetadata: labels: app: ldap name: ldapspec: 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也能够通过如下命令行间接将配置下发到集群当中
$ kubectl apply -k ./proddeployment.apps/ldap createdKCL
咱们能够编写如下 KCL 代码并命名为 main.k ，KCL 受 Python 启发，根底语法非常靠近 Python, 比拟容易学习和上手
apiVersion = "apps/v1"kind = "Deployment"metadata = { name = "ldap" labels.app = "ldap"}spec = { replicas = 1 # When env is prod, override the `replicas` attribute with `6` if option("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 = {} # When env is prod # override the `emptyDir` attribute with `None` # patch a `gcePersistentDisk` attribute with the value `{readOnly = True, pdName = "ldap-persistent-storage"}` if option("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 \ <(kcl main.k) \ <(kcl main.k -D env=prod) |\ more输入如下:
8c8< replicas: 1---> replicas: 630c30,33< emptyDir: {}---> emptyDir: null> gcePersistentDisk:> readOnly: true> pdName: ldap-persistent-storage能够看到生产环境的配置和根本配置的 diff 次要在于 replicas 和 emptyDir 等字段，与预期相符。
此外，咱们能够应用 KCL 命令行工具的 -o 参数将编译产生的 YAML 输入到文件中，并查看文件之间的 diff。
# Generate base deploymentkcl main.k -o deployment.yaml# Generate prod deploymentkcl main.k -o prod-deployment.yaml -D env=prod# Diff prod deployment and base deploymentdiff prod-deployment.yaml deployment.yaml当然咱们也能够将 KCL 工具与 kubectl 等工具联合应用，将生产环境的配置下发到集群当中。
$ kcl main.k -D env=prod | kubectl apply -f -deployment.apps/ldap created能够从命令行的后果看出看出与咱们应用间接应用 Kustomize 配置和 kubectl apply 的一个 Deployment 体验完全一致，并且无更多的副作用。
最初，通过 kubectl 查看部署状态。
$ kubectl get deployNAME READY UP-TO-DATE AVAILABLE AGEldap 0/6 6 0 15s小结
本期内容大略简略介绍了用 KCL 编写简单多环境 Kubernetes 配置的疾速入门和应用 Kustomize 工具进行 Kubernetes 多环境配置管理的比照，能够看出相比于 Kustomize, KCL 在实现配置复用和笼罩的根底上，通过代码化的形式缩小了配置文件的个数和代码行数，晋升了信息密度比，并且同 Kustomize 一样是一个纯客户端计划，能够将配置和策略的验证尽可能左移，并不会对集群有额定依赖或造成累赘，甚至无需一个实在的 Kubernetes 集群。
除了 Kustomize, 目前阶段 Helm 也在 Kubernetes 配置定义和治理畛域也非常风行，相熟 Kubernetes 的小伙伴可能更喜爱显式配置编写形式。那么相较于 Helm，用 KCL 来写配置文件渲染，又有什么异同呢？思考到有很多小伙伴曾经在应用 Helm 这样的工具，下一期我将介绍用 KCL 的形式来写 Helm 对应的配置代码，敬请期待！！
如果您喜爱这篇文章，肯定记得珍藏 + 关注！！更多精彩内容请拜访:
- KCL 仓库地址：https://github.com/KusionStac...
- Kusion 仓库地址：https://github.com/KusionStac...
- Konfig 仓库地址：https://github.com/KusionStac...
如果您喜爱这些我的项目，欢送 Github Star 激励一下 ，同时欢送拜访上面的链接退出咱们的社区进行交换
https://github.com/KusionStac...