本文根据9月21日云栖大会—《智能运维：云原生大规模集群GitOps实践》实录整理而成，演讲信息如下：

演讲人：钟炯恩 阿里云智能集团运维专家

主要内容：

1. 云原生大规模运维挑战

2. 云原生运维管理实践

3. 云原生 GitOps 实践

4. 云原生智能运维工程体系

大家上午好，非常开心今天能够站在这里为大家分享我们团队最新的实践成果：在云原生大规模集群下的的 GitOps 实践。很多人说，现在我们都讲 AIOps 了，为什么我还在这里讲 GitOps 呢？这是一个好问题，其实 GitOps 和 AIOps 之间有非常大的关联，我们认为 GitOps 是在智能运维演进之路上非常重要的一环，所以我在这里加了个副标题《智能运维的工程演进之路》。我介绍一下我自己，我是来自阿里云计算平台的炯思，主要负责大数据以及 AI 平台的基础运维工作。 我会分这样四大块来讲讲我们的实践：首先是我们当前遇到挑战，有稳定性的，也有成本上的或者效率上的，如果需要同时兼顾，是否能够做到呢？然后我会讲讲为了解决这些问题，使用了怎么样的运维方案来应对 k8s 集群管理的复杂性。在云原生的管理体系上，我们继续展开 GitOps 的实践。在听这段的时候，大家可以带着问题想一下，GitOps 到底是不是用 Git 来完成所有的运维管理呢？最后我会讲讲的我们的智能运维工程体系，尤其会讲讲智能体这块的，我们也做了很多的智能体运维实践，我会讲讲 GitOps 在这样一个大模型的智能运维架构之下到底扮演一个什么样的角色。

01云原生大规模运维挑战

首先我们先来讲讲我们当前遇到的这个问题，面对越来越大的运维规模。稳定性、成本、效率这些点是否能够兼顾呢？这三个点是否是个不可能三角呢？让我们带着这个疑问继续向下走。

这是我们当前的运维规模：我们支撑了十多个大数据产品或 AI 产品，运维范围覆盖了一千多个云原生集群，里面有全托管或者半托管的 ACK 集群，也有 ASK 集群的 ECI 弹性容器，以及基于 VirtualCluster 提供的 k8s 多租户场景能力。同时，我们组成这些 k8s 集群的节点种类也非常多样，有虚拟机、神龙裸金属以及物理机。针对云原生节点运维里面也有挺多东西的，有供应管理、节点自愈等。在我们本次分享中不做过多展开，这次我们主要讲讲 k8s YAML 往上的应用层的实践，如果对节点感兴趣的人多可以下次专门开个专题讲讲。

由于云原生化后的应用较传统应用的部署成本下降了非常多，所以大家的部署意愿也都有了较大提升，基本上每天会安排非常多的部署计划。大家可以看到这个数字，我们平均每天有500次的应用实例发布。对这样高频的发布，我们肯定需要演进出了一套完整工程来应对。

当然，在落地这样的工程的过程中我们也遇到了很多挑战，我这边把最具代表性的几个给列了一下：

• 首先是发布频率和稳定性的冲突，一般云原生应用的无状态都做得比较好，稳定性的问题不是发布时的抖动等问题，而是来自配置的错配等问题。云原生发布和传统发布相比，提供了丰富的配置能力，原本内敛在应用内的配置，比如 endpoint/quota 等配置都逐渐上浮，表达在了部署终态中。这样做的好处是每次部署时的配置表达，越来越接近运行时的状态，坏处就是要如果这么高频率的发布，每次都能够改配置，这么多的配置确实容易改漏，带来配置错配引发的 Pod 拉起异常等一些系列的风险。所以从宏观的稳定性视角看，还是希望能够提升减少部署次数，提升每次部署的质量。

• 那么，针对配置问题，我们另外一个应对的策略就是提供版本化应用制品，把这些非常灵活的配置以模板的方式，下沉固化到应用制品中，这个大家日常使用 Helm 的时候也会有所感触：变量抽得多了部署就灵活了，但是如果对应的文档或者可解释性没跟上，反而容易引发更大的问题；反之，如果抽的变量太少，稍微动点东西，就要出一个新的应用制品版本也很头疼。于是，一个应用制品如何平衡灵活部署和参数版本固化，成了我们日常维护中常碰到的问题。

• 第三个点，也是和今天和我们讨论这个 GitOps 的主题密切相关：配置它是一个点，面向终态的，而部署过程是走向这个终态一条线。很多人觉得只要终态对了，让部署过程去不断逼近终态就好了，而问题就出在这个过程中。我举个例子，我觉得很多人肯定都碰到过，在 k8s 中的 YAML 某些关键字段的变化，会触发 Pod 重启，而面向终态的配置中，这是一种隐式的表达，你是不一定能看出重启语义的。不过你可能又会说我这个应用是无状态的，重启没事，但变更过程是批量的，这个重启有可能非常密集地在一分钟触发了，就非常容易打爆上游 meta 之类的服务。于是，大家可以看到我们如果放松对于过程的管控，依然会造成服务的抖动，或者甚至可能产生故障。因此如何平衡过程管理和终态管理，是我们面临的一个非常大的问题。

• 我们之前做的是飞天的运维，所以基本所有的运维能力都是自研的，但云原生场景下社区有很多现成的工具，我们到底是继续保持自研，还是复用开源能力呢？说实话，在这个问题上我们走过很多弯路。YAML 渲染这个事情看起来很简单，不就是 go template 跑一下就好了么？早期我们自己比较鲁莽地实现了一个类似 helm 的模板，但是带来的维护成本是巨大的：因为这个是一个类似 helm 但又不是 helm 的模板语法，大家在写模板的时候自己都会混淆，把 helm 的一些内置变量或语法用进来就跑飞了。后面我们就全面去掉这些功能，把 helm 作为一种标准的协议，helm chart 作为标准的交付物即可。这个我在后面也会展开讲一讲。

02 云原生运维管理实践

讲了这么多云原生场景下遇到的问题和挑战，第二章我们来展开讲讲我们是用怎么样的一套运维方案来应对 k8s 集群管理的复杂场景。这是我们运维方案的分层结构，我们自上向下来看一下：

• 这是我们支撑所业务产品，有 Flink、DataWorks、PAI 这些。对于这些产品，我们既有计算服务交付的需求，也有管控服务的需求。那么怎么交付呢？研发给出 bin，SRE把他们给运行起来吗？云原生下肯定不是这样。在云原生场景下，是研发给出 YAML，SRE 来 kubectl apply 吗？显然也不是。我们需要一个抽象模型将他们管理起来，于是我们就有了第二层：云原生应用全托管底座。

• 在这个云原生应用底座之上，研发和 SRE 一起交付一个应用定义，在定义中描述完整的应用部署拓扑关系，然后通过部署过程将这样一个应用定义实例化，在 k8s 集群之上运行起来。大家也可以注意到，应用下面有一层统一的云原生租户的接口，为什么需要这样一层？因为那些在 VitrualCluster 虚拟出来的 k8s 集群上部署的 YAML 同样也是应用，是独立的应用实例，它具有完整的部署拓扑。所以，管控在我们这里是应用实例，客户的实例在我们这里也是应用实例，大家都通过同一个应用模型的平面进行操作。

• 作为服务业务产品的工程团队，我们主要聚焦于应用向上的这两层。云原生基础设施这层，我们是直接使用 ACK 集群构建的，和大家在阿里云官网能购买到的 ACK 集群是一样的，帮我们屏蔽了 k8s master 等 k8s 系统组件的运维复杂性。

• 最下面一层，我们构建了统一节点资源池，这些节点以节点池的形式被扩容到这些 ACK 集群之中。不过 ACK 集群通用运维，有时候还没法完全满足我们的需求，所以针对节点这块，我们也有完整的节点管理能力，包括扩缩容、自愈等。不过因为 k8 的基础设施做了很好的通用抽象，这个节点池管理我们也做得非常通用，它不仅仅可以支持 k8s ，还可以支持飞天的集群，甚至还有一部分的历史遗留的 Hadoop 集群。非云原生的部分我们今天就不展开了，在这里提到只是为了说明一下灰色这层的通用性。

针对云原生应用这部分，我们继续展开讲一下，我们的应用模型是基于 Open Application Model 来构建，这是一个阿里和微软共同创立的云原生应用规范，它是一个应用程序模型，但不是一个编程模型，它的重点在于应用的组成和组件拓扑的描述，而不关注应用的具体实现。这种方式很好地进行了关注点分离，为什么这么说呢？

SRE 的视角一般是从集群视角进去，自顶向下看，一个集群由若干个应用实例组成，每个应用实例会包含几个 Helm 组件或 Kustomize 组件，SRE 为了让组件实例能够运行地更好，SRE 可能会在组件实例上附一些运维特征(trait)，比如负载均衡、加解密插件、autoScaler 等。因此，日常交付时 SRE 只需要关注到组件实例这层即可。不过遇到一些全局性的问题，比如突然间某个集群很多 Pod 起不来了，SRE 又能快速下探到具体的 Pod 中去排查报错，分析问题。

集群的视角反过来就是应用视角，从一个研发的视角看，他们比较关注将他的软件以何种工作负载运行，可能是 Deployment，也可能是 StatefulSet，毕竟他们的特性是有所不同的。他们会把这些期望的运行语义表达在 k8s 的 YAML 中，封装到了 helm chart 里面，以组件的形式进入到了应用中。在这里就和 SRE 的要做的事情串到了一起。

如果从这个图中看得还不是很清楚，我们可以透过一个应用的生产过程来看看：

这个视角，就是我们云原生应用的生产流程。研发会编写一个 Dockerfile 来打包他程序，然后在本地编写 helm chart 并部署验证，将 helm 作为组件放到 OAM 应用进行完整的拓扑编排。然后到了构建环节，研发写的 Dockerfile 会放到构建机跑起来，真正地构建出生产环境能用的镜像，并和 YAML 一起分发到各个 region 中，等待实例的拉起。一个应用先会在预发环境验证，在没有问题之后，就会上生产，生产实例的部署顺序又会被再一次编排，按照一定灰度批次慢慢发布。

大家可以看到这个生产过程，像接力比赛一样，研发逐渐地就把棒子交给了 SRE 以及运维的同学。这个是个渐进的过程，角色也是逐步过渡的，有些时候可能边界并没有那么清晰：举个例子，比如研发一开始对 Dockerfile 不熟悉，可能 SRE 会帮他们起个头；而反过来说，有些时候研发对于整个流程熟悉之后，也会进来编排应用，构建制品，提一些运维特征的需求等。所以我们可以看到，其实云原生的应用工程，不仅仅是个代码的工程，更是一个多人协作的工程，如何让不同角色的人在这样的流程中，能够互相协作配合，达成一个制品的完整交付和上线，才是最重要的。

这是我们生产的一些案例，大家可以看到，下面是不同研发同学的开发分支，他们提交到这个测试环境中，就会被整合到一个虚拟分支中，然后进行镜像构建及制品分发，最终自动部署测试实例，一气呵成：平均每个应用每天这样的自动流程至少触发十几次。右边这张图是我们应用交付的流程图，蓝色代表研发，橙色代表 SRE，我们也可以看到整个交付过程，研发和 SRE 都是在关注的，只是在 CI 环节由研发主导，到了 CD 环节由 SRE 主导。说到这里，大家已经基本清楚我们的云原生应用中核心模型了，然后我们来讲一下如何在云原生应用模型基础上去落地我们的 GitOps。

03 云原生 GitOps 实践

在开始 GitOps 部分介绍之前，我们先来思考一个问题，GitOps 是不是由 Git 来完成所有的事情？有些人可能觉得是，有些人可能觉得不是。我们带着这个疑问继续分析：

首先，我们来看一些基础的东西，相信大家和我一样，觉得 k8s 的架构和 Git 架构有非常多的相似点，我列了一下，大家是不是也是这样想的：

• k8s的 YAML 可以存储在文件系统的目录中，这些 YAML 文件可以被 Git 记录起来。

• 在 Git 中每次的文件修改可以生成 Git Commit，这个和 K8s 的 YAML 修改后的 ListWatch 事件非常相似，每改一次 YAML 就会出现一个事件，Operator也能够监听到一次事件。

• K8s 中，只要对具体某个资源 URL 做 CRUD 就能完成资源 YAML 的修改，在 Git 中与之对应的是 MergeRequest，如果 Github 用得比较多的同学，那么这个叫PullRequest。

• 针对对象的每次变化，会有一些控制器需要订阅这些事件。在 K8s 中，这个订阅者概念叫 Operator，在 Git 中，这个叫 Hook。

大家可以看到，基本上 K8s 中的每个概念在 Git 中都能找到一个相对应的，他们是那么得契合，于是我们就提出一个问题：是不是天然就可以用 Git 的方式来管理 K8s 集群？如果那么天然，为什么我们早不去搞呢？我们先试着从同行中找答案，看看业界是不是有什么 GitOps 的产品，我们可以借鉴学习一下。

• Fluxcd 也是 GitOps 概念提出方，他们开源了一系列 Controller 来帮助大家落地 GitOps 的目标。且先不说其背后公司 weaveworks 关闭的问题，毕竟是个开源产品，我们相信社区也是应该有能力将 Fluxcd 保持维护的。Fluxcd 适合小型的应用做 GitOps，大概几个环境这种，但对于我们这种动辄几百个应用实例部署在几百个集群上的的场景，就显得比较勉强了。

• ArgoCD 和 Fluxcd 相比，其 GitOps 显得更为精简直接，通过同步机制，将 K8s 集群中的局部控制权直接转移到了 Git 上，用户的理解起来也是挺清晰的。

• Jenkins X和Tekton的方案属于旧瓶酿新酒，你不能说他不能用，但他更像是一个 Git Hook的触发Pipeline。

通过不同产品以及我们的分析，我们能意识到，其实 GitOps 也可以从两个视角来看，有些人关注终态，有些关注过程，但他们确实都是 GitOps，他们同样重要，他们构成了 GitOps 的一体两面。

• 关注终态的人关注他们要什么；但关注过程的人会关注他们如何达成这个目标，这个过程可以很快的还是需要慢慢灰度推进的。

• 关注终态的人觉得通过 Git Diff，代码差异就能观察每次部署所有的变化；但关注过程的人会问这样一个问题：这些差异代表了什么？会重启吗？

• 关注终态的人觉得 Git上看到的，就会现状，所见即所得；但关注过程的人会问，这些终态生效了吗？是不是还有部署没完成？

从这些反差中，我们也可以有所体会，关注结果的人偏乐观，关注过程的人偏悲观。这里面没有对错，都是合理的，在不同的规模不同的场景下，我们的关注点就会有一些不同的侧重。

或者说我们最终的方案是既要用终态来进行管理，又要对整个过程有比较好的管控。

这是我们对于过程的一个比较重要的改良，我们并不是等终态提交完才开始执行，我们把是等执行完才提交终态。为什么呢？还是因为规模的问题，小集群中提交完终态可能执行就几分钟就结束了，但是大的集群，提交完终态之后，需要比较长的执行时间。对于发起人来说，他可能会觉得，反正终态已经写进去了，整个集群迟早会到终态的，我就不管了。于是日积月累，前一个长时间的执行还没完成，又来一个新的，这会导致集群处于一个复杂的不确定性态，可能时不时就处于执行的重启中。

我们设计的方案是基于一个 MergeRequest，一个 MergeRequest 会包住整个变更的生命周期，等 MergeRequest 关闭的时候，变更已经执行完成了。这样做的好处是，将每个变更都框定在一个有限的时间窗口内，使得这些终态是真的终态，而不是一个期望态。执行变更的同学只要把这个 MergeRequest 周期内所有的事情都处理完，一个变更就完整地结束了。

这是我们一个完整的 GitOps 云原生变更流程，首先用户会 Fork 一个开发分支出来，进行开发，然后开发完成之后，提交 MergeRequest。我们会解析 MergeRequest 中的 CodeDiff ，生成面向实体的及变更计划，这部分的技术细节我下一页会展开，然后这个计划给相关同学审批通过后，就开始执行这个变更计划了，在我们这边是有智能变更这样一个平台来完整。在智能变更中，他 By 实体粒度，其实就是应用实例粒度去调用应用的变更动作，将对应 Helm 包部署到云原生集群中，然后观测 Pod 正常拉起，变更结束，继而关闭 MergeRequest。

大家可以看到整个 GitOps 的变更过程充分表达并增强了 Git MergeRequest 原有的语义，同时我们也将上一章提到的云原生应用实例都串到了一起。说到这里，我必须要强调一点，有很多同学会觉得 GitOps 应该是个 GitBase 的方案，我并不是这样觉得的：GitOps 应该是个锦上添花的方案，在已有元数据管理方案，外面包一层 Git 化的变更。你如果把它把作为一个雪中送炭的方案，就会把 Git 作为核心存储，在 Commit 数量多了之后，这样的结构很容易遇到各种性能问题。

这个 GitOps 方案有非常重要的点，你们肯定会有问题，就是这个面向 MergeRequest 的变更计划到底是如何生成的？因为我们毕竟是做基础运维的么，对于 IaC 这块比较熟悉一下，我们借鉴了一下 Infrastructure as Code 的语法。那么 IaC 的语法是怎么样的呢？我们以申请一台 ECS 为例为大家展示一下：

• 第一个是 Terraform，应该也是这个领域影响最大的，使用自研了 HCL 这样一个语言来声明资源，里面能兼容 JSON，也能兼容表达式。对于一个没有接触过这个领域知识的人来讲，这个就增加了学习成本。需要学习一门这样偏声明式的编程语言。前面我们介绍 OAM 模型的时候，提到过，OAM 模型专注于声明式的编排，并不是一个编程模型。但这个 HCL 既有声明编排，又有编程，很难让人不觉得这是个编程模型，事实上，他已经算是一门编程语言。

• Crossplane 是一个 K8s 上声明编排资源的方案，他和 Terraform 有点像，但他确实彻底云原生化的方案，这个声明就是一个标准的k8s对象。但他的问题就是，标准的 YAML 没有了条件表达式，所以对于一些灵活的控制表达，就存在问题。

• Pulumi 是个相对新一个点 IaC 方案，他就很好地避免了前面两种方案所遇到问题，首先 IaC 方案需要是一个声明，而不是一个过程。这个声明可以直接用多种编程语言表达出来，它也不拘泥你用哪种语言。我觉得这个思路是对的，IaC 重点的是要描述不可变的基础设施，至于这个描述过程到底要用 python 的 if else，还是 Terraform 中的if else，有那么重要吗？

这是我们参考 Pulumi 实现的 GitOps 变更计划生成脚本，这个脚本会被放置各种需要进行 GitOps 的仓库中，他描述了这个仓库的每一个 Git 变化要如何执行落地。是的。在 Pulumi 中，他需要描述一个资源结果，而在我们的方案中，他其实描述的是一个变更过程。这就是我们前面讨论的 GitOps 的一体两面，我们到底是追求终态还是追求过程？在这个脚本中，大家可以看到我们的倾向，我们是既要终态，又要过程，而且是通过终态描述来生成执行过程，把整个来龙去脉说得清清楚楚。大家在右边可以看到我们在描述这样一个变更计划的时候，需要注意什么：

• 脚本中需要描述清楚变更对象是谁，禁止没有目标的变更

• 在脚本中要描述清楚要做什么，而是直接执行，因为这个执行过程是由我们 GitOps 的执行器来进行把控的。

通过我们这样的一个 GitOps 的变更描述方案，我们可以非常容易地将终态描述转换成变更过程，并且这个过程非常灵活，使用者可以在脚本执行过程定制任何自己想要的逻辑，比如校验某个关键文件的合法性，比如对于整个配置做个 dryrun，避免出现非预期的数据等。大家也可以看到，其实这个 GitOps 的变更方案不仅适合云原生的场景，也适合非云原生的场景。

而 GitOps ，其实只是我们对于运维变更平面收敛的第一步，自动化是最简单的目标，我们在这个过程中，我们追求的是变更的可解释性，让原本复杂的代码多层级的的代码，通过这样 GitOps 方式串到一个变更中。

04 云原生智能运维工程体系

下面，我们来讲讲智能运维，还记得我们一开始的问题么？ GitOps 到底和智能运维有什么关系。我们会这章来讲讲他们的关系。

首先，我们来看看当前的运维工程体系，我们对外输出的是运维产品，而我们是通过运维 PaaS 底座+运维 SaaS 应用来支撑这样完整的一套运维体系的。我们将各种运维能力分为这样六大场景：交付、监测、管理、控制、运营和服务。基本上整个建设路径也是这样自左向右渐进的，我们可以以一个新产品的交付来简单描述一下这个过程：首先是通过新地域开服以及业务部署将新产品部署上去，然后面对这么多的实例，我们就需要知道他们运行得好不好，于是我们需要加上可观测的能力来进行业务巡检或诊断，以及我们需要提供完整的业务管理能力来管理这些实例，同时为这些实例加上容灾切换、故障自愈等运维特性；当前我们做完前面四个场景之后，我们就需要有比较宏观的方式来衡量这一系列的管理以及运维效率，这时候就需要有工单分析、变更审计来对整个运维周期进行运营；另外一方面这个产品同时是面向客户的，如果客户有使用上的问题，我们需要进行答疑持续，所以我们也会做一些知识库做知识答疑以及 ChatOps。

当前大模型加持的智能运维，其实值得将前面的六大场景都重新做一遍，在做的时候，我们把智能体中用到的工具分成了两类：一类是读，一类是写，原本给人看分析工具，基本上都可以拿来给大模型看，尤其是报错信息这种，基本上能将 stackoverflow 的知识都能活学活用。写这块，大家可以看到，我们构筑的 GitOps 可以非常大的降低写入成本，把大模型放在同一个平面对各种运维对象进行操作。这里有个点非常重要，我这边页的副标题特地写了一下：智能体对可解释性有了更高的要求。为什么这么说呢？以前的工具很多可能都是割裂的，这个工具中的 app 变量到了另外一个工具上可能叫 cluster，而智能体使用的是一套完整的工具链，如果前后变量名不一致，你需要增加很多的解释成本，甚至可能让大模型产生幻觉。

那么到底哪些工具适合让大模型来用呢？我这边特地列了一下。看到这张图，大家肯定会产生非常大的疑问，为什么 API 都不推荐了呢？我这边可以给大家讲讲我们这边的情况：当你把一个运维场景拆解好，有哪些工具需要开发，然后那个开发工具的同学就跟我来吐槽，我这工具开发完，我感觉在外面加个条件判断都直接能运行了，要什么大模型，要什么智能体？所以我们可以看到，如果是一个比较固定的场景，智能体毫无优势。那么，智能体在什么场景有优势呢？比较灵活的场景。那么什么场景比较灵活呢？如果查询一组数据，你要写个 SQL 才能查出来，这个时候，大模型就有优势了，他可以非常快地把你的问题转换成 SQL 查出来，如果 SQL 运行报错了，他还会自省去修正 SQL，直到修正出一个正确的。所以，大家可以发现，大模型针对某个特定工具，他有学习成本，但是对于低代码或者 DSL 而言，大模型相比较人，有绝对的推理优势，大模型能举一反三。所以回到 gitops 上，我们会发现通过 GitOps ，能够让我们构建一个统一的树形配置面，这样一个配置面，对于大模型来说，就非常友好，新建集群就是增加一个目录，调整容量就是修改 quota 语义的那个值，大模型和我们人一样，会从其他集群拿配置参考，这样修改的配置就基本是对的。

于是，当我们使用智能体把六大场景夯实之后，智能运维的整个体系就自然呈现出来了。这里我还想再强调一次，前面我讲过 GitOps 较普通的运维而言，是个锦上添花的事情，而智能运维较整个运维体系而言，同样是个锦上添花的事情，只有底下的层次清晰了，抽象完善了，上面的智能体才能良好地运行。

好了，讲到这里我本次分享的内容差不多结束了，如果有兴趣的同学欢迎关注我们的云原生运维社区，我们有这样几个交流渠道：

• 针对云原生运维平台的这部分，我们全部做了开源，大家可以直接体验或者自己部署之后体验。

• 我们有多平台传播的公众号，叫阿里云大数据 AI 技术，我们会习惯于把我们一些进展以及技术细节写成文章，让更多的人能基于这些点去展开自己的实践。大家可以看到，我们近期披露的文章有智能体，有 GitOps ，也有 eBPF 等