Skip to main content

1 post tagged with "KCL"

查看所有标签

· 阅读需要 1 分钟

简介

KCL 团队很高兴地宣布 KCL v0.6.0 新版本现在已经可用!本次发布为大家带来了三方面的重点更新:语言工具链社区集成 & 扩展支持

  • 使用功能更完善错误更少的 KCL 语言、工具链和 IDE 提升代码编写体验和效率
  • 使用包管理 KPM 和 OCI Registry 等工具直接使用和共享您的云原生领域模型,降低学习和上手成本
  • 使用 Helmfile KCL 插件和 KCL Operator 等云原生集成扩展同时支持在客户端和运行时对 Kubernetes 资源进行原地修改和验证,避免配置硬编码

进一步您可以在 KCL v0.6.0 发布页面 或者 KCL 官方网站 获得下载安装指南和详细发布信息。

KCL 是一个面向云原生领域开源的基于约束的记录及函数编程语言,期望通过成熟的编程语言技术和实践来改进对大量繁杂配置比如云原生 Kubernetes 配置场景的编写,致力于围绕配置的模块化、扩展性和稳定性,打造更简单的逻辑编写体验,构建更简单的自动化和生态集成路径。

本文重点介绍 KCL v0.6.0 版本的更新内容以及 KCL 社区的近期动态。

语言更新

🔧 类型系统增强

支持 KCL 配置块属性类型自动推导,在 KCL v0.6.0 版本之前,下述代码中的 key1key2 属性会被类型系统推导为 str | int 类型,版本更新之后,我们进一步增强了配置属性的类型精确推导,key1key2 属性会获得范围更小更精确的对应类型

config = {
key1 = "value1"
key2 = 2
}
key1 = config.key1 # key1 的类型为 str
key2 = config.key2 # key2 的类型为 int

此外,我们优化了 Schema 语义检查和联合类型检查等错误信息以及系统库函数的类型检查错误信息。

更多信息详见

🏄 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"}]
}

更多信息详见

IDE & 工具链更新

IDE 更新

功能更新

  • 跳转性能大幅度提升,支持毫秒级跳转
  • 支持 KCL 包中的变量以及 Schema 属性补全
  • 支持 KCL Schema 属性文档属性悬停提示
  • 支持无用 Import 语句快速修复

ide-quick-fix

  • 支持右键格式化文件和代码片段

ide-format

  • 支持内置函数和系统库中函数信息的悬停提示

ide-func-hover

更多 IDE 支持

我们将 KCL 语言服务器 LSP 集成到了 NeoVim 和 Idea 中,使得可以在 NeoVim 和 IntelliJ IDEA 中体验到和 VS Code IDE 支持的补全、跳转和悬停等功能

  • NeoVim KCL 插件

kcl.nvim

  • IntelliJ 插件

intellij

更多 IDE 插件下载安装方式和功能说明可参考:

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

从 kpm 包生成模型文档

  1. 创建 kpm 包,为其中的 Service 模型添加文档注释(使用 docstring 表示)。在文档中可以包含对模型和属性的说明、示例代码和用法等,以帮助其他开发人员快速上手并正确地使用。

➜ kpm init demo

➜ cat > demo/server.k << EOF
schema Service:
"""
Service is a kind of workload profile that describes how to run your application code. This
is typically used for long-running web applications that should "never" go down, and handle
short-lived latency-sensitive web requests, or events.

Attributes
----------
workloadType : str = "Deployment" | "StatefulSet", default is Deployment, required.
workloadType represents the type of workload used by this Service. Currently, it supports several
types, including Deployment and StatefulSet.
image : str, default is Undefined, required.
Image refers to the Docker image name to run for this container.
More info: https://kubernetes.io/docs/concepts/containers/images
replicas : int, default is 2, required.
Number of container replicas based on this configuration that should be ran.

Examples
--------
# Instantiate a long-running service and its image is "nginx:v1"

svc = Service {
workloadType: "Deployment"
image: "nginx:v1"
replica: 2
}
"""
workloadType: "Deployment" | "StatefulSet"
image: str
replica: int
EOF

  1. 生成 Markdown 格式的包文档: 以下命令将 demo 包文档输出到当前工作目录下的 doc/ 目录:
kcl-go doc generate --file-path demo

docgen

更多使用方式请通过 kcl-go doc generate -h 查看

  1. 通过流水线实现文档的自动同步

通过在 Github workflow 中跟踪模型的更新,并重新生成文档,即可实现文档的自动同步。可参照 Kusionstack/catalog 中的做法,生成文档并自动向文档仓库提交变更 PR。

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/providers/schema)

{
"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.27

kpm 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 files

kpm 支持添加本地路径作为依赖

"不同的项目对应的 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 run

kpm 增加对已经存在的包 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 exists

对一个已经 push 到 Registry 中的 kcl 包,在不改变 tag 的情况下改动包的内容,会产生很大的风险,因为这个包有可能已经被其他人使用了,因此,如果您需要 push 您的包,我们建议

  • 变更您的 tag, 并且建议您遵守语义化版本的规范。
  • 如果迫不得已需要在 tag 不能变更的情况下改变包的内容,您只能到 Registry 上删除已有的 tag。

社区集成 & 扩展更新

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 po

2. 部署注解修改模型

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
EOF

3. 部署一个 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 注解

registry

此外,我们已经在 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 存储 foobar 信息

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/vault

GitLab CI 集成

在之前的文章中,我们提到了使用 Github Action 作为 CI 通过 GitOps 方式进行应用发布,此次版本中我们进一步提供了 GitLab CI 集成,用例详情可参考:https://kcl-lang.io/docs/user_docs/guides/ci-integration/gitlab-ci

其他更新与错误修复

完整更新和错误修复列表详见

文档更新

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 等在过去两个月使用 KCL 过程中提出的宝贵反馈和讨论 🙌

常见问题及解答

详见 KCL 常见问题

其他资源

感谢所有 KCL 用户和社区小伙伴在此次版本更新过程中提出的宝贵反馈与建议。

更多其他资源请参考:

欢迎加入我们的社区进行交流 👏👏👏:https://github.com/kcl-lang/community

· 阅读需要 1 分钟

前言

随着云原生技术的发展,我们更多地转向云基础设施,Kubernetes 和 Terraform 等 IaC 工具已成为越来越流行的管理和部署基于云 API 的应用程序的工具。但是随之而来衍生出的复杂性问题和认知负担问题在近几年达到了高峰。

cognitive-loading

Kubernetes 和云 API 越来越复杂的原因主要有以下几点:

  • 不断增加的功能和能力:Kubernetes 和云 API 都是为了应对不断增长的应用需求和云计算的发展而不断演进。为了满足用户的需求,它们不断引入新的功能和能力,如自动扩展、服务发现、负载均衡、权限管理等。这些新功能的引入增加了系统的复杂性。虽然我们已经有了各式各样的自动化手段,随着时间的推移,因为不同资源类型的数量、这些资源类型的潜在设置数量以及这些资源类型之间的复杂关系呈指数级增长
  • 复杂的配置和管理需求:随着应用规模的增长,配置和管理 Kubernetes 和云 API 变得越来越复杂。例如,需要管理大量的容器实例和资源、配置复杂的网络和存储、实现高可用性和负载均衡,需要针对不同的环境和拓扑重复的进行配置等。这些复杂的配置和管理需求增加了 Kubernetes 和云 API 的复杂性,开玩笑的说甚至在 Kubernetes 领域常常伴随催生了一批 YAML 工程师。

尽管 Kubernetes 和云 API 的复杂性愈发增加,但它们提供了强大的功能和灵活性,可以帮助组织更好地管理和扩展其应用程序。通过使用适当的工具、工程实践和方法,可以减轻这种复杂性,并更有效地利用这些技术来满足业务需求。动态配置管理技术便是其中之一可以一定程度帮助解决 Kubernetes 和云 API 的复杂性。

什么是动态配置管理

我们遵循动态配置管理的创建者 Chris Stephenson 的原始定义并进行一定程度的延伸

动态配置管理(DCM)是一种用于构建计算工作负载配置的方法。开发人员创建工作负载规范,描述成功运行工作负载所需的一切。该规范用于动态创建配置,以便在特定环境中部署工作负载。使用 DCM,开发人员不需要为其工作负载定义或维护任何特定于环境的配置。

动态配置管理意味着开发人员以抽象的与环境无关的方式描述他们的工作负载与资源的关系。他们描述这种关系的格式称为工作负载规范或者以应用为中心的规范。该规范是通用的并且跨环境工作,这意味着它没有提供足够的信息来配置工作负载和资源本身。为了获得可以执行的配置,我们需要将规范应用于配置基线(对于应用程序和基础设施配置),并根据部署的上下文生成它们。对于开发人员来说,动态配置管理需要提供开发者可以理解的以应用为中心的配置界面;对于平台工程师来说,动态配置管理可以帮助定义如何处理配置资源和工作负载规范;这有助于提高组织的一致性和合规性。它还使得提供自助式内部开发者平台 (IDP) 变得更加容易。

与动态配置管理相对应的方式是静态配置管理,静态配置会带来一系列问题

  • 维度爆炸: 大多数静态配置需要为每个环境单独进行配置;在最糟糕的情况下,它可能引入涉及环境交叉链接的难以调试的错误,稳定性和扩展性都较差。
  • 配置漂移: 对于不同环境的静态管理应用程序和基础设施配置的方式,往往没有标准的方式去管理这些动态的不同环境的配置,采用非标准化的方法会导致复杂度呈指数增长,并导致配置漂移。

为什么需要一种新范式

正如记录音乐有五线谱,存储时间序列数据有时序数据库一样,在平台工程的特定问题域内,一批配置和策略语言用于编写和管理规模化复杂配置及策略。不同于混合编写范式、混合工程能力的高级通用语言,这类专用语言的核心逻辑是以收敛的有限的语法、语义集合解决领域问题近乎无限的变化和复杂性,将复杂配置和策略编写思路和方式沉淀到语言特性中。

对于云 API, 我们借助 Terraform 等 IaC 工具可以获得大量的已经编写好的 Module 配置,但是对于 Kubernetes 仍然缺乏客户端的轻量级的配置组合和抽象解决方案,现有的方案或者规范难以在抽象能力和扩展性获得平衡,甚至对于一些极端场景,开发者往往编写许多胶水代码和脚本对配置进行处理逻辑,稳定性和效率都受到一定桎梏。比如 Helm Chart 等工具虽然提供了模版编程方式,但编程体验和效率均不佳,此外当用户需要动态调整 Helm Chart 的 values.yaml 参数依赖或者遇到需要设置的参数上游的 Helm Chart 不支持时,往往需要以侵入的方式 Fork 维护上游 Helm Chart 或者辅以 Kustomize 等工具,这带来的额外的维护成本和复杂性。

于是我们思考需要有一个统一规范描述来同时承载配置语言能力,并且可以尽可能无副作用地同时满足规模化配置场景下的稳定性、扩展性、效率等特性,并且解决静态配置管理的问题

  • 抽象和组合能力:通过可编程 Schema 的方式提供给平台人员屏蔽底层底层基础设施细节和平台,并提供给开发人员一个更好更稳定的 API 抽象。
  • 稳定性:通过语言内置开箱提供的稳定特性如规则编写,静态类型等特性,使得风险尽可能左移,在 VCS 中编写实时发现错误,可审计可追溯可回滚,易于自动化。
  • 可复用扩展性:就像应用软件供应链那样,应当将基础设施配置也视为软件供应链中的一环,用户可以通过标准的方式分发复用配置,对于常用的配置用户可以在开源世界中轻易获得它,对于内部平台,我们可以轻易编写和扩展配置代码。
  • 高性能:由于动态配置管理提倡由一份基线配置根据部署上下文生成不同环境不同拓扑的配置,对于配置代码本身的执行渲染性能有较高的要求,开发者通常不希望花费数十分钟才看到真实配置输出而影响软件迭代升级的效率

KRM KCL 规范

KRM KCL 规范是基于 Kubernetes Resource Model(KRM)的一种配置规范。KRM 是一个通用的配置模型,用于描述和管理各种云原生资源,如容器、Pod、服务等。KRM 提供了一种统一的方式来定义和管理这些资源,使得它们可以在不同的环境中进行移植和复用。它建立在一个完全开放的 Kubernetes 世界当中,几乎不与任何编排/引擎工具或者 Kubernetes 控制器绑定,它在关注点分离的基础上允许平台人员扩展自己的抽象,配置编辑和验证逻辑,并且对于社区中已有的模型抽象如 Open Application Model (OAM) 等,可以直接进行复用,因为 OAM 配置本身也满足 KRM 规范。

KCL 配置语言是 KRM KCL 规范 的核心组成部分。KCL 是一种声明性的配置语言,它允许用户描述应用程序的配置需求,并将其与底层基础设施进行关联。KCL 具有丰富的语法和语义,可以灵活地描述各种配置需求,如环境变量、资源限制、依赖关系等。KCL 旨在通过定义 API 抽象来隐藏基础设施和平台的详细信息,以减轻负担,并通过配置语言无副作用地管理跨团队的大规模配置,并提供编写、组合和抽象配置块的能力,如结构定义、约束和逻辑等。在平台工程实践中 KCL 不是一种仅用于编写 K-V 对的语言,而是一种面向平台工程领域的专用语言

KRM KCL 规范的另一个重要特性是其对动态配置管理的支持。传统的配置管理工具往往依赖于静态配置文件,需要手动修改和部署。而 KRM KCL 规范天然提供了配置自动修改的方式,可以单独在客户端使用也可以通过 KCL Operator 与 Kubernetes 集成,在运行时实现配置自动修改,无需重复开发 Kubernetes Webhook 编写大量的配置处理逻辑。

除了动态配置管理,KRM KCL 规范 还具有一些其他的优势。首先,它基于 Kubernetes,可以与现有的 Kubernetes 生态系统进行无缝集成。其次,KRM KCL 规范提供了丰富的工具和库,使得开发人员可以轻松地创建、测试和维护配置。最后,KRM KCL 规范采用了开放的标准,可以与其他的配置管理工具如 Kubectl, Helm, Kustomize 等进行互操作,并且具备如下特点

  • 声明式:配置描述以代码方式抽象和组织,用户可以通过编辑器或 IDE 查看、编辑,代码中清晰描述了资源、服务、网络等多方面的配置。
  • 面向终态:面向终态且实现无关,通过高度抽象并内置特定领域的基础能力,具象的业务由使用者编写声明。使用者通过统一的描述代码和 GitOps 流程避免人工操作及私有脚本的非统一模式和引入的安全问题。
  • 稳定性:任何配置代码的修改都可能造成非预期的结果,甚至异常或故障发生。结合版本控制和语言本身的稳定性特性。不同版本的配置代码可以通过 Git 按需切换,可审计性,以满足研发、测试、生产阶段的需求,如异常后回滚到某个验证可用的版本。结合版本控制的代码化可以有效避免配置漂移。
  • 可复用扩展:配置代码往往有 “一次编写,多次使用” 的特点,结合动态参数化的配置代码往往使差异环境、差异用户等多维度的配置复用需求变得简单。通过与 OCI 等标准软件供应链的方式集成,将配置代码与业务代码同等对待,更好地实现基础设施即代码 (IaC)

总而言之,KRM KCL 规范是一种全新的动态配置管理范式,它以 KRM 和 KCL 为基础,为现代软件开发提供了更高效、更可靠的配置解决方案。它的动态配置管理能力、灵活的语法和语义以及与 Kubernetes 的集成,无论是在云原生应用开发还是在微服务架构中,KRM KCL 规范都将为开发人员带来更好的配置管理体验。

如何使用 KRM KCL 规范

krm-kcl-form

在 KRM KCL 规范,我们将 KCL 配置模型的行为主要分成三类

  • Mutation: 输入 KCL 参数 params 和 KRM 列表并输出修改后 KRM 列表。
  • Validation: 输入 KCL 参数 params 和 KRM 列表并输出 KRM 列表和资源验证结果。
  • Abstraction: 输入 KCL 参数 params 并输出 KRM 列表

我们可以使用 KCL 以可编程的方式实现如下能力:

  • 使用 KCL 对资源进行修改,如根据某个条件添加/修改 label 标签或 annotation 注释或在包含 PodTemplate 的所有 Kubernetes Resource Model (KRM) 资源中注入 Sidecar 容器配置等。
  • 使用 KCL Schema 验证所有 KRM 资源,如约束只能以 Root 方式启动容器等。
  • 使用抽象模型生成 KRM 资源或者对不同的 KRM API 进行组合并使用。

此外配置模型 source 可以引用自 OCI,Git, Filesystem, 和原始 KCL 代码,我们可以借助 KCL IDE 和 KPM 包管理工具编写模型并上传到 OCI Registry 以实现模型复用,并且这些模型可以根据场景需求分别用在客户端或者运行时。

客户端

我们以一个经典的工作负载 Web 服务作为例子演示 KRM KCL 规范在客户端使用的例子。

此外,我们以统一的编程界面方式为 Kubernetes 社区的 Kubectl, Helm, Kustomize, KPT 等配置管理工具提供了插件支持,编写几行配置代码即可无侵入地完成对存量 Kustomize YAML,Helm Charts 的编辑和校验以及定义自己的抽象模型并分享复用。

下面以 Kubectl 工具对 KCL 的集成为例进行详细说明。您可以在这里获取 Kubectl KCL 插件的安装方式

首先执行如下命令获取一个配置示例

git clone https://github.com/kcl-lang/kubectl-kcl.git && cd ./kubectl-kcl/examples/

然后执行如下命令显示配置

$ cat krm-kcl-abstraction.yaml

apiVersion: krm.kcl.dev/v1alpha1
kind: KCLRun
metadata:
name: web-service
spec:
params:
name: app
containers:
nginx:
image: nginx
ports:
- containerPort: 80
service:
ports:
- port: 80
source: oci://ghcr.io/kcl-lang/web-service

在上述配置中,我们使用了在 OCI 上已经预定好的一个 Kubernetes Web 服务应用抽象模型 oci://ghcr.io/kcl-lang/web-service, 并通过 params 字段配置了该模型所需的配置字段。通过执行如下命令可以获得原始的 Kubernetes YAML 输出并下发到集群:

$ kubectl kcl apply -f krm-kcl-abstraction.yaml

deployment.apps/app created
service/app created

除了使用 YAML 作为用户的输入界面,KCL 作为一个编写配置和策略的 DSL,它还允许开发者和平台人员在客户端以统一的 KCL 编写方式编写和维护大规模配置

standalone-kcl-form

运行时

在运行时,我们通过 KCL Operator 提供了 Kubernetes 集群集成,允许您在将资源应用到集群时使用 Access Webhook 根据 KCL 配置生成、变异或验证资源。Webhook 将捕获创建、应用和编辑操作,并通过 KCLRun 在与每个操作关联的配置上执行资源。使用 KCL Operator, 通过几个步骤您就可以在 Kubernetes 集群内部以很轻量的方式地通过 KCL 代码自动化地完成资源配置的管理和安全验证,无需重复开发 Webhook Server 在运行时动态修改和验证配置。

此外借助 KCL 良好的建模和抽象能力,我们可以为不同的资源 API 定义进行功能抽象/组合并以 KCL Schema 的形式对外透出,并且可以由 KCL Schema 进一步自动生成 OpenAPI Schema 定义供集群其他客户端调用,而无需为 API 抽象/组合手动维护复杂的 OpenAPI Schema 定义。

下面以一个简单的资源 annotation 注解修改示例介绍 KCL Operator 的使用方式

安装 KCL Operator

kubectl apply -f https://raw.githubusercontent.com/kcl-lang/kcl-operator/main/config/all.yaml

使用以下命令观察并等待 pod 状态为 Running

kubectl get po

部署注解修改模型

kubectl apply -f- << EOF
apiVersion: krm.kcl.dev/v1alpha1
kind: KCLRun
metadata:
name: set-annotation
spec:
params:
annotations:
managed-by: kcl-operator
source: oci://ghcr.io/kcl-lang/set-annotation
EOF

部署一个 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 注解

小结

通过动态配置管理的方式可以降低现代云原生配置的复杂性,通过 KRM KCL 规范以及标准的 OCI 模型,我们可以实现动态配置管理,并使平台人员和应用开发人员都可以轻松地使用这些设置,降低认知负担。

更多资源

参考