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

在系列上一篇文章/post/717625…中，咱们介绍了如何运用 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 库房地址：github.com/KusionStack…
• Kusion 库房地址：github.com/KusionStack…
• Konfig 库房地址：github.com/KusionStack…

如果您喜爱这些项目，欢迎 GithubStar 鼓励一下 ，同时欢迎拜访下面的链接加入咱们的社区进行沟通

github.com/KusionStack…