带你走进云原生技术：云原生开放运维体系探索和实践

本文是云原生开放协同技术探索与实践一阶段的总结和综述。

蚂蚁基础技术在过去3年多以来持续、深入推进全面的云原生化技术演进，我们将在线、离线计算资源装进了一台计算机，将服务体系通过 mesh 的思路和技术手段进行了下沉解耦，可以说比较充分的拥抱了云原生技术，并获取了其带来的技术红利。

当完成了资源、服务的云原生化，我们发现在云原生基础能力之上的运维体系与云原生技术开放、共享的思路有较大的距离，在技术体系上也与云原生技术声明式、白盒化的思路相悖，同时由于缺少匹配的技术支撑，历史包袱等问题也成为了云原生运维难以真正代际演进的障碍。今天我要介绍的就是蚂蚁在这样的背景下在云原生运维方向进行的技术探索和实践。

规模化云原生运维探索

我们先来回顾一下在蚂蚁真实的实践方式和面对的问题。首先，我们来看看蚂蚁践行多年的经典运维中台，这类运维平台一般包括了控制器、业务模型、编排引擎、原子任务及管道，在蚂蚁这样的平台是一系列服务的集合，他们较好的满足了集中式、标准化、低变更频率的应用发布及运维需求。但这种模式在实践中也存在着明显的不足。

首先对于非标准应用、应用个性化需求、高成本需求、非紧急需求、技改类需求，往往无法较好的满足。在蚂蚁的实践中，非标运维需求、对核心应用模型及运维模型冲击较大的高成本改造需求、大量基础能力或运维功能的透出需求等长期无法得到较好的满足，需求往往是合理的，是难以获得足够的优先级执行落地。在研发阶段，运维平台长期积累了高复杂度的业务逻辑，修改测试涉及跨系统的长改造链路，同时基础能力的透出、运维能力的产品化依赖前端、服务端研发资源。这些问题使得运维平台研发日渐吃力，特别是在产品 GUI、业务模型、编排引擎等变更热点上，受限于扩展机制能力不足，内部实践中甚至出现过线上不断修改代码、发布服务以满足需求的情况。平台上线后，统一的质保和线上全链路功能验证同样面对较大的压力。对于最终的使用者，命令式按钮背后的黑盒计算透明度低，审计难，结果难预测，同时激情操作、操作界面不熟悉等问题也一直影响着线上的稳定性。这些问题长期存在，我们寄希望于代际的技术演进来解决这些问题。

当云原生基础服务逐渐稳定后，对于自身场景不在运维平台管理范围内的应用，研发同学自发的借助云原生社区工具链解决问题。基于 Kubernetes 生态高度开放、高度可配置的特点，研发者可以自助、灵活、透明的声明式应用运行、运维需求，以应用粒度完成发布、运维操作。

用户通过 kustomize 等社区技术缩短了对接基础设施的路径，并通过如 velocity 等文本模板技术部分解决了静态 YAML 文件在较多变量时维度爆炸的问题，解决了默认值设定的问题，同时通过 code review 的方式进行多因子变更及评审。由于 Kubernetes 及其生态提供了面向资源、服务、运维、安全的横向能力，使得这种简单的方式可有很好的普遍性和适用性，通过对不同的 Kubernetes 集群 “播放” 这些数据即可完成对基础设施的变更，本质上是一种声明数据的流转。面向 git 仓库的研发方式和 gitops 流程支持对运维产品研发资源的诉求较低，往往可以比较简单的搭建起来，不强依赖产品研发资源投入。相比经典运维中台，这些好处清晰明确，但从工程视角缺点也非常明显。

首先 Kubernetes API 的设计较为复杂，仅是 Kubernetes 原生提供的 low level API 就暴露了 500 多种模型，2000 多字段，场景上几乎涵盖了基础设施应用层的方方面面，即使是专业同学也很难理解所有细节。其次这种方式的工程化程度很低，违反 DRY 原则，违反各团队职责能力高内聚低耦合的原则，即使在有一定的工具支持的情况下，在内部的典型案例中一个多应用的 infra 项目仍然维护了多达 5 万多行 YAML，同时由于团队边界造成的多个割裂的平台，用户需在多个平台间切换，每个平台的操作方式各异，加上跳板机黑屏命令，完成一次完整的发布需要 2 天时间。

由于低工程化程度的问题，各团队间协同依赖人肉拉群同步，最终 YAML 由多个团队定义的部分组合而成，其中一大部分属于 Kubernetes 及运维平台团队的定义，这些内容需要持续跟踪同步避免腐化，长期维护成本高。

KUSION: 云原生开放协同技术栈

以上两种模式各有利弊，优势和问题都比较清晰。那么能不能既要也要呢，能不能在继承经典运维平台优势的情况下，充分利用云原生技术带来的红利，打造一个开放、透明、可协同的运维体系？

带着这样的问题，我们进行了探索和实践，并创建了基于基础设施代码化思路的云原生可编程技术栈 Kusion。

大家都知道 Kubernetes 提供了声明式的 low level API，提倡其上生态能力通过 CRD 扩展的方式定义并提供服务，整个生态遵循统一的 API 规范约束，复用 API 技术和工具。Kubernetes API 规范提倡 low level API 对象松耦合、可复用，以支持 high level API 由 low level API “组合” 而成。Kubernetes 自身提供了利于开源传播的极简方案，并不包括 API 之上的技术和方案。

回到云原生技术的本源，我们回看了 Kubernetes 前身 Borg 的应用技术生态。如下图示，在 BorgMaster 之上，Borg 团队研发了 Borg 接入三件套，即 BCL（Borg Configuration Language），Command-line tools，以及相应的 web service。用户可以通过 BCL 声明式编写需求，通过 Command-line tools 将 BCL 文件执行到 Borg 集群，并通过 web GUI 视图查看任务细节。经过大量的调研，我们了解到 Google 内部的运维能力及产品生态、质量技术生态都依赖这三件套构建而成，在内部也进行了多年的迭代演进。

这给了我们启发，今天我们有了容器技术、服务体系，有了大量用户和差异化的需求，有了一定数量的自动化运维平台，我们希望能通过云原生专用的语言和工具来链接 Kubernetes 生态、各个运维平台以及大量的用户，通过唯一事实定义消除运维平台孤岛，完成云原生基础设施在应用、运维层面的代际演进，达到 “Fusion on Kubernetes” 的目标。

带着这样的目标，我们持续地进行做技术探索和实践，目前已经形成了 Kusion 技术栈，并在蚂蚁的生产实践中进行应用。

Kusion 技术栈基于这样的基础能力而工作，包括如下组成部分：

• 云原生配置策略专用语言 KCL (Kusion Configuration Language)

• KCL 解释器及其 Plugin 扩展机制

• KCL 研发工具集: Lint, Format, Doc-Gen，IDE Plugin(IDEA, VsCode)

• Kusion Kubernetes 生态工具: OpenAPI-tool, KusionCtl(Srv)

• Konfig 配置代码库，其中包括平台侧及用户侧代码

• OCMP (Open CloudNative Management Practice) 实践说明书