共计 13104 个字符，预计需要花费 33 分钟才能阅读完成。
KCL 团队很快乐地发表 KCL v0.6.0 新版本当初曾经可用 ！本次公布为大家带来了三方面的重点更新： 语言 、 工具链 、 社区集成 & 扩大反对。**
- 应用性能更欠缺谬误更少的 KCL 语言、IDE 和工具链晋升代码编写体验和效率
- 应用 包管理工具 KPM 和 OCI Registry 等工具间接应用和共享您的云原生畛域模型，升高学习和上手老本
- 应用 Helmfile KCL 插件和 KCL Operator 等云原生集成扩大同时反对在客户端和运行时对 Kubernetes 资源进行原地批改和验证**
进一步您能够在发布页面或者 KCL 官方网站取得下载安装指南和详细信息。
- 发布页面： https://github.com/kcl-lang/kcl/releases/tag/v0.6.0
- 官网网站： https://kcl-lang.io
语言更新
🔧 类型零碎加强
反对 KCL 配置块属性类型主动推导，在 KCL v0.6.0 版本之前，下述代码中的 key1 和 key2 属性会被类型零碎推导为 str | int 类型，版本更新之后，咱们进一步加强了配置属性的类型准确推导，key1 和 key2 属性会取得范畴更小更准确的对应类型
config = {
key1 = "value1"
key2 = 2
}
key1 = config.key1 # key1 的类型为 str
key2 = config.key2 # key2 的类型为 int此外，咱们优化了 Schema 语义检查和联结类型查看等错误信息以及零碎库函数的类型查看错误信息。
更多信息详见: https://github.com/kcl-lang/kcl/pull/678
🏄 API 更新
- KCL Schema 模型解析 GetSchemaType API 获取 KCL 包相干信息和 Schema 属性默认值
🐞 谬误修复
KCL 必选属性查看谬误修复
在之前的 KCL 版本中，KCL 必选属性查看会脱漏嵌套的 Schema 属性查看，在 KCL v0.6.0 版本中，咱们修复了此类相似的问题
schema S:
a: int
b: str
schema L:
# 在之前的版本中，会脱漏 [S] 和 {str:S} 中的 S 的 a, b 属性必选查看
# 在 KCL v0.6.0 版本之后，咱们修复了此类问题
ss?: [S]
sss?: {str:S}
l = L {ss = [S {b = "b"}]
}更多信息详见: https://github.com/kcl-lang/kcl/pull/672
工具链更新
IDE 性能更新
- 跳转性能大幅度晋升，反对毫秒级跳转
- 反对 KCL 包中的变量以及 Schema 属性补全
- 反对 KCL Schema 属性文档悬停提醒
- 反对无用 Import 语句疾速修复
- 反对右键格式化文件和代码片段
- 反对内置函数和零碎库中函数信息的悬停提醒
更多 IDE 反对
过来两周，咱们将 KCL 语言服务器 LSP 集成到了 NeoVim 和 Idea 中，使得能够在 NeoVim 和 IntelliJ IDEA 中体验到和 VS Code IDE 反对的补全、跳转和悬停等性能
- NeoVim KCL 插件
- IntelliJ 插件
更多 IDE 插件下载安装形式和性能阐明可参考：**
- https://kcl-lang.io/docs/user_docs/getting-started/install#ne…
- https://kcl-lang.io/docs/user_docs/getting-started/install#in…
KCL 格式化工具更新
反对对缩进不正确的配置块进行格式化
- 格式化前
config = {
a ={
x = 1
y =2
}
b = {
x = 1
y = 2
}
}- 格式化后
config = {
a = {
x = 1
y = 2
}
b = {
x = 1
y = 2
}
}KCL 文档工具更新
- 新增 Markdown 文档导出反对
- 反对导出文档索引页
- 反对导出文档自定义款式模版
- 反对导出文档 HTML 本义
- 文档生成加强，反对对文档正文中示例代码片段的解析和渲染
- 通过在 Github workflow 中跟踪模型的更新，并从新生成文档，即可实现文档的主动同步，生成的文档如下图所示。具体参考: https://github.com/KusionStack/catalog/pull/31/files
KCL 导入工具更新
在 KCL v0.6.0 版本，KCL 导入 Import 工具新增反对了 JsonSchema, Terraform Provider Schema, Go 构造体 转换为 KCL，以及一键反对 JSON/YAML 配置数据转换为 KCL 配置代码，比方对于如下的 Terraform Provider Json (通过 terraform providers schema -json > provider.json 命令取得，详情请参考 https://developer.hashicorp.com/terraform/cli/commands/provid…)
{
"format_version": "0.2",
"provider_schemas": {
"registry.terraform.io/aliyun/alicloud": {
"provider": {
"version": 0,
"block": {"attributes": {},
"block_types": {},
"description_kind": "plain"
}
},
"resource_schemas": {
"alicloud_db_instance": {
"version": 0,
"block": {
"attributes": {
"db_instance_type": {
"type": "string",
"description_kind": "plain",
"computed": true
},
"engine": {
"type": "string",
"description_kind": "plain",
"required": true
},
"security_group_ids": {
"type": [
"set",
"string"
],
"description_kind": "plain",
"optional": true,
"computed": true
},
"security_ips": {
"type": [
"set",
"string"
],
"description_kind": "plain",
"optional": true,
"computed": true
},
"tags": {
"type": [
"map",
"string"
],
"description_kind": "plain",
"optional": true
}
},
"block_types": {},
"description_kind": "plain"
}
},
"alicloud_config_rule": {
"version": 0,
"block": {
"attributes": {
"compliance": {
"type": [
"list",
[
"object",
{
"compliance_type": "string",
"count": "number"
}
]
],
"description_kind": "plain",
"computed": true
},
"resource_types_scope": {
"type": [
"list",
"string"
],
"description_kind": "plain",
"optional": true,
"computed": true
}
}
}
}
},
"data_source_schemas": {}}
}
}通过 KCL Import 工具能够输入为如下 KCL 代码
"""
This file was generated by the KCL auto-gen tool. DO NOT EDIT.
Editing this file might prove futile when you re-run the KCL auto-gen generate command.
"""schema AlicloudConfigRule:"""
AlicloudConfigRule
Attributes
----------
compliance: [ComplianceObject], optional
resource_types_scope: [str], optional
"""
compliance?: [ComplianceObject]
resource_types_scope?: [str]
schema ComplianceObject:
"""
ComplianceObject
Attributes
----------
compliance_type: str, optional
count: int, optional
"""
compliance_type?: str
count?: int
schema AlicloudDbInstance:
"""
AlicloudDbInstance
Attributes
----------
db_instance_type: str, optional
engine: str, required
security_group_ids: [str], optional
security_ips: [str], optional
tags: {str:str}, optional
"""
db_instance_type?: str
engine: str
security_group_ids?: [str]
security_ips?: [str]
tags?: {str:str}
check:
isunique(security_group_ids)
isunique(security_ips)包管理工具 KPM 更新
kpm pull 反对通过包名拉取 kcl package
kpm 反对通过 kpm pull <package_name>:<package_version> 的形式拉取对应的包。以 k8s包为例，你能够通过以下命令间接下载对应的包到本地。
kpm pull k8s或者
kpm pull k8s:1.27kpm pull 下载的包，将会为您保留在 执行命令的目录 /<oci registry>/<package_name>目录下, 以 kpm 默认的 registry 为例，在应用 kpm pull k8s命令后，您能在 执行命令的目录 /ghcr.io/kcl-lang/k8s目录下找到您下载的内容。
$ tree ghcr.io/kcl-lang/k8s -L 1
ghcr.io/kcl-lang/k8s
├── api
├── apiextensions_apiserver
├── apimachinery
├── kcl.mod
├── kcl.mod.lock
├── kube_aggregator
└── vendor
6 directories, 2 fileskpm 反对增加本地门路作为依赖
“ 不同的我的项目对应的 KCL 包不一样，他们之间存在依赖关系，然而他们保留在不同的目录下，我心愿这些保留在不同目录下的包可能被对立治理起来，而不是只有把他们放在一起他们能力通过编译。”
对于上述问题，kpm add 目前反对将本地门路作为依赖增加到 kcl 包中，您只须要 kpm add <local_package_path> 这样的命令，便能够将您本地的包作为三方库增加到以后包的依赖中。
kpm pull k8s实现后您能够在“执行命令的目录 /ghcr.io/kcl-lang/k8s”找到下载的 k8s 包。应用 kpm init mynginx 命令，创立一个新的 kcl 包。
kpm init mynginx而后，进入这个包内
cd mynginx在这个包内，您能够应用 kpm add 命令将您方才下载到本地的 k8s 包作为三方库增加到 mynginx 的依赖中。
kpm add ../ghcr.io/kcl-lang/k8s/接下来在 main.k 中增加上面的内容
import k8s.api.core.v1 as k8core
k8core.Pod {
metadata.name = "web-app"
spec.containers = [{
name = "main-container"
image = "nginx"
ports = [{containerPort: 80}]
}]
}通过 kpm run 能够进行失常的编译
kpm runkpm 减少对曾经存在的包 tag 进行查看
kpm push 中减少了对 tag 反复的查看，为了避免出现雷同 tag 的包存在不同的内容的状况，咱们在 kpm 中减少了对 push 性能的限度，如果您 push 的 kcl 包的版本曾经存在，那么，您将无奈 push 以后的 kcl 包。您将会失去如下信息：
kpm: package 'my_package' will be pushed.
kpm: package version '0.1.0' already existsKCL 文档工具更新
- 新增 Markdown 文档导出反对
- 反对导出文档索引页
- 反对导出文档自定义款式模版
- 反对导出文档 HTML 本义
- 文档生成加强，反对对文档正文中示例代码片段的解析和渲染
- 通过在 Github workflow 中跟踪模型的更新，并从新生成文档，即可实现文档的主动同步。具体参考: https://github.com/KusionStack/catalog/pull/31/files
社区集成 & 扩大更新
Helmfile KCL 插件
Helmfile 是用于部署 Helm Chart 的申明性标准和工具，通过 Helmfile KCL 插件您能够
- 通过无侵入的 Hook 形式编辑或者验证 Helm Chart 配置，将 Kubernetes 配置管理的数据局部和逻辑局部拆散
-
- 批改资源标签 / 注解, 注入 Sidecar 容器配置
- 应用 KCL Schema 校验资源，定义本人的形象模型并分享复用
- 优雅地保护多环境、多租户场景配置，而不是简略地复制粘贴
上面以一个简略示例进行具体阐明，应用 Helmfile KCL 插件无需您装置与 KCL 任何相干的组件，只需本机具备 Helmfile 工具的最新版本即可。
咱们能够编写一个如下所示 helmfile.yaml 文件
repositories:
- name: prometheus-community
url: https://prometheus-community.github.io/helm-charts
releases:
- name: prom-norbac-ubuntu
namespace: prometheus
chart: prometheus-community/prometheus
set:
- name: rbac.create
value: false
transformers:
# Use KCL Plugin to mutate or validate Kubernetes manifests.
- apiVersion: krm.kcl.dev/v1alpha1
kind: KCLRun
metadata:
name: "set-annotation"
annotations:
config.kubernetes.io/function: |
container:
image: docker.io/kcllang/kustomize-kcl:v0.2.0
spec:
source: |
[resource | {if resource.kind == "Deployment": metadata.annotations: {"managed-by" = "helmfile-kcl"}} for resource in option("resource_list").items]在上述配置中，咱们援用了 Prometheus Helm Chart, 并通过一行 KCL 代码就能够实现 Prometheus 的所有的 Deployment 资源注入标签 managed-by="helmfile-kcl"，通过如下命令咱们能够将上述配置下发到集群
helmfile apply更多用例能够参考这里
KCL Operator
KCL Operator 提供了 Kubernetes 集群集成，容许您在将资源利用到集群时应用 Access Webhook 依据 KCL 配置生成、变异或验证资源。Webhook 将捕捉创立、利用和编辑操作，并 KCLRun 在与每个操作关联的配置上执行资源，比方能够应用 KCL 语言实现如下性能
- 应用 KCL 对资源进行批改，如依据某个条件增加 / 批改 label 标签或 annotation 正文或在蕴含 PodTemplate 的所有 Kubernetes Resource Model (KRM) 资源中注入 Sidecar 容器配置等。
- 应用 KCL Schema 验证所有 KRM 资源，如束缚只能以 Root 形式启动容器等。
- 应用形象模型生成 KRM 资源或者对不同的 KRM API 进行组合并应用。
上面以一个简略的资源 annotation 注解批改示例介绍 KCL Operator 的应用形式
0. 前置条件
通过 k3d 等工具筹备一个 Kubernetes 集群以及 kubectl 工具
1. 装置 KCL Operator
kubectl apply -f https://raw.githubusercontent.com/kcl-lang/kcl-operator/main/config/all.yaml应用以下命令察看并期待 pod 状态为 Running。
kubectl get po2. 部署注解批改模型
kubectl apply -f- << EOF
apiVersion: krm.kcl.dev/v1alpha1
kind: KCLRun
metadata:
name: set-annotation
spec:
# 设置注解批改模型所需的动静参数，在此处咱们能够增加咱们想要批改 / 增加的标签
params:
annotations:
managed-by: kcl-operator
# 援用 OCI 上注解批改模型
source: oci://ghcr.io/kcl-lang/set-annotation
EOF3. 部署一个 Pod 资源验证模型后果
执行如下命令部署一个 Pod 资源
kubectl apply -f- << EOF
apiVersion: v1
kind: Pod
metadata:
name: nginx
annotations:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
EOF
kubectl get po nginx -o yaml | grep kcl-operator咱们能够看到如下输入
managed-by: kcl-operator咱们能够发现 Nginx Pod 上主动增加了 managed-by=kcl-operator 注解
此外，咱们曾经在 KCL 官网 Registry 中开箱提供了多达 30 个内置模型能够容许您在轻易实现对已有 Kubernetes 资源的编辑、校验和形象。
比方应用 web-service 模型间接实例化出一个 web 利用所需的 Kubernetes 资源；应用 set-annotation 模型对已有的 k8s 资源增加 annotation；应用 https-only 模型校验您的 Ingress 配置只能设置为 https, 否则报错。
您能够在上面的链接中取得更多模型代码示例：https://github.com/kcl-lang/krm-kcl/tree/main/examples
Vault 集成
仅需三步，咱们就能够应用 Vault 来存储并治理敏感信息并在 KCL 中应用。
首先咱们装置并应用 Vault 存储 foo 和 bar 信息
vault kv put secret/foo foo=foo
vault kv put secret/bar bar=bar而后编写如下 KCL 代码 (main.k)
apiVersion = "apps/v1"
kind = "Deployment"
metadata = {
name = "nginx"
labels.app = "nginx"
annotations: {
"secret-store": "vault"
# Valid format:
# "ref+vault://PATH/TO/KV_BACKEND#/KEY"
"foo": "ref+vault://secret/foo#/foo"
"bar": "ref+vault://secret/bar#/bar"
}
}
spec = {
replicas = 3
selector.matchLabels = metadata.labels
template.metadata.labels = metadata.labels
template.spec.containers = [
{
name = metadata.name
image = "${metadata.name}:1.14.2"
ports = [{containerPort = 80}]
}
]
}最初能够通过 Vals 命令行工具取得解密后的配置
kcl main.k | vals eval -f -更多详情和用例能够参考 https://kcl-lang.io/docs/user_docs/guides/secret-management/v…
GitLab CI 集成
在之前的文章中，咱们提到了应用 Github Action 作为 CI 通过 GitOps 形式进行利用公布，此次版本中咱们进一步提供了 GitLab CI 集成，用例详情可参考：https://kcl-lang.io/docs/user_docs/guides/ci-integration/gitl…
其余更新
- 残缺更新和谬误修复列表详见: https://github.com/kcl-lang/kcl/compare/v0.5.0…v0.6.0
文档更新
KCL 网站 新增 KCL v0.6.0 文档内容并反对版本化语义选项，目前反对 v0.4.x, v0.5.x 和 v0.6.0 版本抉择，同时欢送社区同学进行文档共建。
社区动静
- 感激 @jakezhu9 对 KCL Import 工具包含 Terraform Provider Schema, JsonSchema, Json, YAML 等配置格局 / 数据到 KCL Schema/ 配置的转换 🙌
- 感激 @xxmao123 对 KCL LSP 语言服务器接入到 Idea IDE 插件的奉献 🙌
- 感激 @starkers 对 KCL NeoVim 插件的奉献 🙌
- 感激 @starkers 对 mason.nvim registry 减少 KCL 的装置反对 🙌
- 感激 @Ekko 对 KCL 云原生工具集成以及 KCL Operator 的奉献 🙌
- 感激 @prahaladramji 对 KCL Homebrew 装置脚本的降级更新与奉献 🙌
- 感激 @yyxhero 在 Helmfile KCL 插件反对中提供的帮忙与反对 🙌
- 感激 @nkabir, @mihaigalos, @prahaladramji, @yamin-oanda, @dhhopen,@magick93, @MirKml, @kolloch, @steeling, @果然多 i 等在过来两个月应用 KCL 过程中提出的贵重反馈和探讨 🙌
下一步打算
预计 2023 年 11 月，咱们将公布 KCL v0.7.0 版本，更多详情请参考 KCL 2023 路线布局 和 KCL v0.7.0 Milestone，如果您有更多的想法和需要，欢送在 KCL Github 仓库发动 Issues 或探讨，也欢送退出咱们的社区进行交换 🙌 🙌 🙌
- KCL 2023 路线布局: https://kcl-lang.io/docs/community/release-policy/roadmap
- KCL v0.7.0 Milestone: https://github.com/kcl-lang/kcl/milestone/7
- KCL GitHub Issues: https://github.com/kcl-lang/kcl/issues
- KCL GitHub Discussion: https://github.com/orgs/kcl-lang/discussions
- KCL 社区: https://github.com/kcl-lang/community
其余资源
❤️ 感激所有 KCL 用户和社区小伙伴在此次版本更新过程中提出的贵重反馈与倡议。受限于文章篇幅，后续咱们会撰写更多 KCL v0.6.0 新版本性能解读系列文章，敬请期待!
更多其余资源请参考：
- KCL 网站: https://kcl-lang.io/**
- KusionStack 网站: https://kusionstack.io/**