|
| 1 | +--- |
| 2 | +slug: 2023-09-06-dcm-using-kcl |
| 3 | +title: "动态配置管理新范式: KRM KCL" |
| 4 | +authors: |
| 5 | + name: KCL Team |
| 6 | + title: KCL Team |
| 7 | +tags: [KCL, Kubernetes Resource Model, Dynamic Configuration Management] |
| 8 | +--- |
| 9 | + |
| 10 | +## 前言 |
| 11 | + |
| 12 | +> 随着云原生技术的发展，我们更多地转向云基础设施，Kubernetes 和 Terraform 等 IaC 工具已成为越来越流行的管理和部署基于云 API 的应用程序的工具。但是随之而来衍生出的复杂性问题和认知负担问题在近几年达到了高峰。 |
| 13 | +
|
| 14 | + |
| 15 | + |
| 16 | +Kubernetes 和云 API 越来越复杂的原因主要有以下几点： |
| 17 | + |
| 18 | ++ **不断增加的功能和能力**：Kubernetes 和云 API 都是为了应对不断增长的应用需求和云计算的发展而不断演进。为了满足用户的需求，它们不断引入新的功能和能力，如自动扩展、服务发现、负载均衡、权限管理等。这些新功能的引入增加了系统的复杂性。虽然我们已经有了各式各样的自动化手段，随着时间的推移，因为不同资源类型的数量、这些资源类型的潜在设置数量以及这些资源类型之间的复杂关系呈指数级增长 |
| 19 | ++ **复杂的配置和管理需求**：随着应用规模的增长，配置和管理 Kubernetes 和云 API 变得越来越复杂。例如，需要管理大量的容器实例和资源、配置复杂的网络和存储、实现高可用性和负载均衡，需要针对不同的环境和拓扑重复的进行配置等。这些复杂的配置和管理需求增加了 Kubernetes 和云 API 的复杂性，开玩笑的说甚至在 Kubernetes 领域常常伴随催生了一批 YAML 工程师。 |
| 20 | + |
| 21 | +尽管 Kubernetes 和云 API 的复杂性愈发增加，但它们提供了强大的功能和灵活性，可以帮助组织更好地管理和扩展其应用程序。通过使用适当的工具、工程实践和方法，可以减轻这种复杂性，并更有效地利用这些技术来满足业务需求。动态配置管理技术便是其中之一可以一定程度帮助解决 Kubernetes 和云 API 的复杂性。 |
| 22 | + |
| 23 | +## 什么是动态配置管理 |
| 24 | + |
| 25 | +我们遵循动态配置管理的创建者 Chris Stephenson 的[原始定义](https://humanitec.com/blog/what-is-dynamic-configuration-management)并进行一定程度的延伸 |
| 26 | + |
| 27 | +> 动态配置管理（DCM）是一种用于构建计算工作负载配置的方法。开发人员创建工作负载规范，描述成功运行工作负载所需的一切。然后，该规范用于动态创建配置，以便在特定环境中部署工作负载。使用 DCM，开发人员不需要为其工作负载定义或维护任何特定于环境的配置。 |
| 28 | +
|
| 29 | +对于开发人员来说，DCM 支持以工作负载为中心的开发，这意味着可以使用单一工作负载规范将工作负载及其资源和配置部署到所有环境；对于平台工程师来说，DCM 帮助定义如何以及在何处配置资源和工作负载；这有助于提高组织的一致性和合规性。它还使得提供自助式内部开发者平台 (IDP)变得更加容易。 |
| 30 | + |
| 31 | +与动态配置管理相对应的方式是静态配置管理，静态配置会带来一系列问题 |
| 32 | + |
| 33 | ++ 💥 维度爆炸: |
| 34 | ++ 扩展性：并且能够已可扩展的方式 |
| 35 | ++ 稳定性： |
| 36 | ++ 效率低：往往没有标准的方式去管理这些动态的不同环境的配置 |
| 37 | + |
| 38 | +## 为什么需要一种新范式 |
| 39 | + |
| 40 | +DCM 只是意味着开发人员以抽象的、与环境无关的方式描述他们的工作负载与资源的关系。他们描述这种关系的格式称为工作负载规范。该规范是通用的并且跨环境工作，这意味着它没有提供足够的信息来配置工作负载和资源本身。为了真正获得可执行配置，我们需要将工作负载规范应用于配置基线（对于应用程序和基础设施配置），并根据部署的上下文生成它们。 |
| 41 | + |
| 42 | ++ 特别是在 Kubernetes 缺乏客户端的轻量级解决方案，现有的方案或者规范比较抽象能力和扩展性获得平衡，甚至就是一些胶水代码和脚本的拼盘，稳定性和效率都收到一定桎梏 |
| 43 | ++ 局限在某一种或者某几种编排引擎上，扩展性和开发效率受到桎梏 |
| 44 | ++ 现有存量配置的扩展或定制能力不足，需要有一种方式能够补充与现有配置生态如 Helm, Kustomize, Terraform 等 |
| 45 | + |
| 46 | +正如记录音乐有五线谱，存储时间序列数据有时序数据库一样，在平台工程的特定问题域内，一批配置和策略语言用于编写和管理规模化复杂配置及策略。不同于混合编写范式、混合工程能力的高级通用语言，这类专用语言的核心逻辑是以收敛的有限的语法、语义集合解决领域问题近乎无限的变化和复杂性，将规模化复杂配置和策略编写思路和方式沉淀到语言特性中。 |
| 47 | + |
| 48 | +TODO：补充范式思路 |
| 49 | + |
| 50 | +## KRM KCL 规范 |
| 51 | + |
| 52 | +随着云计算和微服务架构的迅猛发展，动态配置管理成为了现代软件开发中不可或缺的一部分。为了满足这一需求，KRM KCL 规范应运而生。KRM KCL 规范是一种新的技术范式，旨在为动态配置管理提供更高效、更可靠的解决方案。 |
| 53 | + |
| 54 | +KRM KCL 规范是基于 Kubernetes Resource Model（KRM）的一种配置规范。KRM是一个通用的配置模型，用于描述和管理各种云原生资源，如容器、Pod、服务等。KRM 提供了一种统一的方式来定义和管理这些资源，使得它们可以在不同的环境中进行移植和复用。它建立在一个完全开放的世界当中，几乎不与任何编排/引擎工具或者 Kubernetes 控制器绑定，它在关注点分离的基础上允许平台人员扩展自己的抽象，并且对于社区中已有的抽象，我们可以直接采用。并且已经提供了几十种已有的模型开箱即用。 |
| 55 | + |
| 56 | +KCL 配置语言是 KRM KCL Spec 的核心组成部分。KCL 是一种声明性的配置语言，它允许用户描述应用程序的配置需求，并将其与底层基础设施进行关联。KCL 具有丰富的语法和语义，可以灵活地描述各种配置需求，如环境变量、资源限制、依赖关系等。KCL 旨在通过定义 API 抽象来隐藏基础设施和平台的详细信息，以减轻负担，并通过配置语言无副作用地管理跨团队的大规模配置，并提供编写、组合和抽象配置块的能力，如结构定义、约束和逻辑等。在平台工程实践中 KCL 不是一种仅用于编写 K-V 对的语言，而是一种面向平台工程领域的专用语言 |
| 57 | + |
| 58 | +KRM KCL Spec 的另一个重要特性是其对动态配置管理的支持。传统的配置管理工具往往依赖于静态配置文件，需要手动修改和部署。而 KRM KCL Spec 天然提供了配置自动修改的方式，可以在客户端使用也可以通过 KCL Operator 与 Kubernetes 集成，在运行时实现配置自动修改，无需重复开发 Kubernetes Webhook 编写大量的配置处理逻辑 |
| 59 | + |
| 60 | +除了动态配置管理，KRM KCL Spec 还具有一些其他的优势。首先，它基于Kubernetes，可以与现有的Kubernetes生态系统进行无缝集成。其次，KRM KCL Spec提供了丰富的工具和库，使得开发人员可以轻松地创建、测试和维护配置。最后，KRM KCL Spec采用了开放的标准，可以与其他的配置管理工具进行互操作，并且具备如下特点 |
| 61 | + |
| 62 | ++ **声明式**：配置描述以代码方式抽象和组织，用户可以通过编辑器或 IDE 查看、编辑，代码中清晰描述了资源、服务、网络等多方面的配置。 |
| 63 | ++ **面向终态**：面向终态且实现无关，通过高度抽象并内置特定领域的基础能力，具象的业务由使用者编写声明。使用者通过统一的描述代码和 GitOps 流程避免人工操作及私有 scripting 的非统一模式和引入的安全问题。 |
| 64 | ++ **稳定性**：任何配置代码的修改都可能造成非预期的结果，甚至异常或故障发生。结合版本控制和语言本身的稳定性特性。不同版本的配置代码可以通过 git commit/tag 按需切换，可审计性，以满足研发、测试、生产阶段的需求，如异常后回滚到某个验证可用的版本。结合版本控制的代码化可以有效避免 configuration drift。 |
| 65 | ++ **可复用扩展**：配置代码往往有“一次编写，多次使用”的特点，结合动态参数化的配置代码往往使差异环境、差异用户等多维度的配置复用需求变得简单。通过与 OCI 等标准软件供应链的方式集成，将配置代码与业务代码同等对待，更好地实现 IaC |
| 66 | + |
| 67 | +总而言之，KRM KCL Spec 是一种全新的动态配置管理范式，它以KRM和KCL为基础，为现代软件开发提供了更高效、更可靠的配置解决方案。它的动态配置管理能力、灵活的语法和语义以及与Kubernetes的集成，无论是在云原生应用开发还是在微服务架构中，KRM KCL Spec都将为开发人员带来更好的配置管理体验。 |
| 68 | + |
| 69 | +## 如何使用 KRM KCL 规范 |
| 70 | + |
| 71 | +TODO |
| 72 | + |
| 73 | +### 规范示例 |
| 74 | + |
| 75 | +### 客户端 |
| 76 | + |
| 77 | +### 运行时 |
| 78 | + |
| 79 | +## 小结 |
| 80 | + |
| 81 | +TODO |
| 82 | + |
| 83 | +## 更多资源 |
| 84 | + |
| 85 | +- [KCL 网站](https://kcl-lang.io/) |
| 86 | +- [KusionStack 网站](https://kusionstack.io/) |
| 87 | + |
| 88 | +## 参考 |
| 89 | + |
| 90 | ++ Declarative Application Management in Kubernetes: https://docs.google.com/document/d/1cLPGweVEYrVqQvBLJg6sxV-TrE5Rm2MNOBA_cxZP2WU/edit# |
| 91 | ++ CNCF Platforms White Paper: https://tag-app-delivery.cncf.io/whitepapers/platforms/ |
| 92 | ++ Google SRE Workbook: https://sre.google/workbook/configuration-specifics/ |
| 93 | ++ What is Dynamic Configuration Management: https://humanitec.com/blog/what-is-dynamic-configuration-management |
| 94 | ++ Implementing Dynamic Configuration Management with Score and Humanitec: https://humanitec.com/blog/implementing-dynamic-configuration-management-with-score-and-humanitec |
| 95 | ++ What is Platform Engineering: https://platformengineering.org/blog/what-is-platform-engineering |
| 96 | ++ What is Internal Developer Platform: https://internaldeveloperplatform.org/what-is-an-internal-developer-platform/ |
| 97 | ++ What Team Structure is Right for DevOps to Flourish: https://web.devopstopologies.com/#anti-types |
0 commit comments