共计 4584 个字符，预计需要花费 12 分钟才能阅读完成。
2023 年 9 月 20 日，KCL 我的项目通过了寰球顶级开源基金会云原生计算基金会（CNCF）技术监督委员会评定，正式成为 CNCF 沙箱我的项目。
这意味着 KCL 失去了云原生开源社区的认可，保障了我的项目的中立性，有利于开发者、合作伙伴等独特参加我的项目建设，合作共赢，并为云原生利用交付带来动静配置管理和自动化能力迈出了重要一步！
- 我的项目地址：https://github.com/kcl-lang/kcl
- 我的项目官网：https://kcl-lang.io
通过进入 CNCF 沙箱，KCL 社区将更多吸引更多开发者和用户参加共建，进一步推动我的项目在云原生业务场景的成熟利用，此外退出 CNCF 将为 KCL 提供一个加强的合作和翻新平台。它提供了与处于云原生技术前沿的多元化开发者、组织和行业专家社区进行交换的机会。咱们期待与其余 CNCF 我的项目进行更多单干，奉献咱们的技术专业知识，并摸索更多 CNCF 我的项目集成的可能性。
|什么是 CNCF|
CNCF，全称 Cloud Native Computing Foundation（云原生计算基金会），是 Linux 基金会旗下的子基金会。CNCF 致力于为云原生软件构建可继续生态系统，波及畛域包含存储、计算、编排、调度、CI/CD、DevOps、服务治理、服务网关等。
比方 Kubernetes 便是 CNCF 最具代表性的我的项目之一。
|什么是 CNCF 沙盒我的项目|
CNCF 社区将我的项目分为沙箱我的项目（Sandbox）、孵化我的项目（Incubating）、毕业我的项目（Graduated）。驰名的毕业我的项目有：Kubernetes、Prometheus、Istio、ETCD、Containerd、ArgoCD 和 Helm 等。残缺的毕业和孵化我的项目列表查看地址：
https://www.cncf.io/projects/
Sandbox 是 CNCF 创立的，旨在为开源我的项目提供一个无益的、中立的家园，以促成开源我的项目的单干与开发。入选沙箱的我的项目，是被 CNCF TOC 认可的，并值得进行试验和开发的后劲我的项目。
Sandbox 对应的是 CNCF 社区晚期我的项目，列表为：https://www.cncf.io/sandbox-projects/。进入 Sandbox 须要 66% 以上的 TOC（技术委员会）成员赞成，即全副 11 人 https://github.com/cncf/toc#members 中的 8 人投赞成票。
|什么是 KCL|
KCL 是一个 Rust 编写的开源的基于束缚的记录及函数语言，冀望通过成熟的编程语言技术和实际来改良对大量繁冗配置比方云原生 Kubernetes 配置场景的编写，致力于围绕配置的模块化、扩展性和稳定性，打造更简略的逻辑编写体验，构建更简略的自动化和生态集成门路。
我的项目次要里程碑如下：
- 2022 年 5 月，KCL 正式开源
- 2023 年 6 月，KCL 正式成为 CNCF Landscape 我的项目
2023 年 9 月，KCL 由 CNCF 利用交付 TAG 进行审核并通过 TOC 投票，顺利成为 CNCF Sandbox 我的项目 – https://github.com/cncf/sandbox/issues/48
|为什么须要 KCL|
正如记录音乐有五线谱，存储工夫序列数据有时序数据库一样，在云原生配置和自动化的特定问题域内，咱们应用专用配置和策略语言用于编写和治理规模化简单配置及策略。不同于混合编写范式、混合工程能力的高级通用语言，专用语言的外围逻辑是以收敛的无限的语法、语义汇合解决畛域问题近乎有限的变动和复杂性，将简单配置和策略编写思路和形式积淀到语言个性中。
此外，KCL 冀望通过更现代化的申明式配置语言和工具，在轻量级客户端 云原生 动静配置畛域 填补配置语言及工具的空白并解决如下问题：
- 维度爆炸: 大多数动态配置如云原生畛域的 Kubernetes YAML 配置须要为每个环境独自进行配置；在最蹩脚的状况下，它可能引入波及环境穿插链接的难以调试的谬误，稳定性和扩展性都较差。
- 配置漂移: 对于不同环境的动态管理应用程序和基础设施配置的形式，往往没有规范的形式去治理这些动静的不同环境的配置，采纳非标准化的办法比方脚本和胶水代码的拼盘，会导致复杂度呈指数增长，并导致配置漂移。
认知累赘: Kubernetes 等作为构建平台的平台技术手段在底层对立基础架构细节方面杰出，然而不足更下层的应用软件交付形象，对于一般开发者认知累赘较高，影响了更下层利用开发者的软件交付体验。
针对如上问题，KCL 冀望提供如下能力:
- 通过 代码形象 等伎俩屏蔽基础设施和平台的细节和复杂性，升高研发者 认知累赘
- 编辑 和校验 已有的存量配置或模版，间接解决云原生小配置场景问题如 Helm Chart 配置硬编码问题，但远不止如此
- 通过配置语言无副作用地 治理跨团队的大规模配置数据，晋升团队合作效率
具体来说，KCL 能够
- 在代码层面晋升 配置语义验证 的能力，比方 Schema 定义、字段可选 / 必选、类型、范畴等配置查看校验能力
- 提供 配置分块编写、组合和形象的能力，比方构造定义、构造继承、束缚定义和配置策略合并等能力
- 用 古代编程语言的形式 以编写代码 的形式晋升配置的灵便度，比方条件语句、循环、函数、包治理等个性晋升配置重用的能力
- 提供 齐备的工具链反对，丰盛的 IDE 插件、语言和生态工具链反对用以升高上手门槛，晋升应用体验
- 通过 包管理工具 和 OCI Registry 使得配置以更简略的形式在不同团队 / 角色之间分享，流传和交付
- 提供 高性能 的编译器满足规模化配置场景诉求，比方满足由一份基线配置依据部署上下文生成不同环境不同拓扑的配置的渲染性能以及配置自动化批改性能诉求
- 通过 多语言 SDK，KCL 语言插件 等伎俩晋升其 自动化 集成能力，在施展配置及策略编写价值的同时显著升高 KCL 的学习老本
除了语言本身，KCL 还提供了许多额定的工具如格式化，测试、文档等工具帮忙您应用、了解和查看编写的配置或策略；通过 VS Code 等 IDE 插件，包管理工具和 Playground 升高配置编写和分享的老本；通过 Rust, Go, 和 Python 多语言 SDK 自动化地治理和执行配置。
KCL 能做什么
动静配置管理
作为一种配置语言，KCL 为应用程序和平台开发人员 / SRE 提供的最重要的性能是动静配置管理。通过代码形象，咱们能够构建以利用为核心的模型屏蔽简单的基础设施和平台概念，为开发人员提供一个以应用程序为核心且易于了解的界面。此外，KCL 还容许平台人员疾速扩大和定义本人的模型，并且这些模型能够通过 OCI 注册表进行分享和复用。
此外，KCL 还反对与 Kubernetes Resource Model (KRM) 标准间接集成，KRM KCL 是一个通用的配置模型标准，用于形容和治理各种云原生资源，如容器、Pod、服务的配置操作和形象等。KRM KCL 标准提供了一种对立的形式来定义和治理这些资源，使得它们能够在不同的环境中进行移植和复用。它建设在一个齐全凋谢的 Kubernetes 世界当中，简直不与任何编排 / 引擎工具或者 Kubernetes 控制器绑定，它在关注点拆散的根底上容许平台人员扩大本人的形象，配置编辑和验证逻辑，并提供一个开发者敌对的配置管理界面。
GitOps 集成
无论是应用独立的 KCL 还是 KRM KCL 配置模式，咱们都反对 KCL 与各种以及 CI/CD 和 GitOps 工具的集成，KCL 容许开发人员以申明式的形式定义应用程序所需的资源，通过将 KCL 和 GitOps 工具相结合能够帮忙咱们更好地实现基础设施即代码（IaC），进步部署效率，简化应用程序的配置管理。
应用 GitOps，开发人员和运维团队能够通过别离批改利用和配置代码来管理应用程序的部署，GitOps 工具链能够基于 KCL 的自动化能力实现对配置的主动更改，从而实现继续部署并确保一致性。如果呈现问题，能够应用 GitOps 工具链疾速回滚。
|生态集成|
除了与 ArgoCD 等 GitOps 自动化工具进行集成，作为 CNCF 的我的项目，KCL 还与 CNCF 其余泛滥生态我的项目进行了集成，比方为现有的 CNCF 生态配置管理工具我的项目如 Helm、Kustomize、kpt 等提供 KCL 插件，在运行时提供 KCL Kubernetes Operator，以满足不同场景的配置管理需要等。此外咱们还提供如下集成反对：
- 多语言反对：咱们提供了多语言 SDK，帮忙用户以不同的语言操作 KCL，并将其集成到本人的应用程序中。
- 包治理反对：咱们提供了 KPM 包管理工具能够将 KCL 配置通过 docker hub, GitHub 容器注册表进行散发和复用。
Schema 生态反对：咱们反对其余生态系统的 Schema 一键迁徙到 KCL Schema，如 Go/Rust 构造定义、JsonSchema、Protobuf、OpenAPI、Terraform Provider Schema 等。
落地实际
首先，KCL 作为云原生畛域内的一个小语言，它能够间接被用于解决场景中简略的小问题，如通过 KCL 模型间接为 Kubernetes 资源注入环境变量等配置而不是编写脚本，通过 KCL 模型和 Helm KCL 插件无侵入解决 Helm Chart 的硬编码配置而不是 Fork Helm Chart 间接批改等。
其次，KCL 也能够被用于企业外部与各种 CI/CD 和利用配置交付引擎比方 KusionStack 相配合，实现关注点拆散、以利用为核心的可编程模型界面和 GitOps 流程，以简化当今混合多云环境中规模化利用的部署和运维操作，晋升公布运维效率和开发者体验。
当然，KCL 可能解决的问题和实际的场景远不止如此，咱们会陆续分享社区中采纳者的最佳实际，也欢送大家退出咱们的社区进行进一步交换和探讨 ❤️。https://github.com/kcl-lang/community
社区动静
在 KCL 开源短短的这一年里，咱们公布了许多版本，并与全世界许多贡献者和维护者单干构建了 KCL 社区，并失去了一些采纳者比方有赞和华为等公司的认可，通过退出 CNCF，咱们的指标是进步我的项目的知名度并促成社区采纳和参加，因为弱小且出名的基金会组织对于推动语言生态系统的倒退至关重要。
此外，咱们在开源社区也播种了来自全世界包含北美、欧洲、澳大利亚和台湾各地小伙伴的认可，感激一路陪伴 KCL 走来的各位用户和社区研发者，同时也欢送更多的小伙伴退出到咱们的社区一起共建 ❤️
结语
对 KCL 来说，退出 CNCF 并不代表胜利，它意味着一个新的开始，咱们将和社区的小伙伴们一起致力打造更好的 KCL 语言、工具链和 IDE 体验！最初，也欢送大家退出咱们的社区进行交换和奉献 👏👏👏
其余资源
- KCL 网站 : https://kcl-lang.io/
- KusionStack 网站: https://kusionstack.io/
- KCL 社区: https://github.com/kcl-lang/community
- KCL 2023 路线布局: https://kcl-lang.io/docs/community/release-policy/roadmap
- KCL GitHub Issues: https://github.com/kcl-lang/kcl/issues
- KCL GitHub Discussion: https://github.com/orgs/kcl-lang/discussions
