阿里巴巴的 Kubernetes 应用管理实践经验与教训

导读：本文整理自孙健波在 ArchSummit 大会 2019 北京站演讲稿记录。首先介绍了阿里巴巴基于 Kubernetes 项目进行大规模应用实践过程当中遇到的问题；随后会逐一介绍解决这些问题的现有实践及其自己存在的局限性；最后会介绍阿里巴巴目前正在进行的尝试和社区在这一领域的发展方向。

现在，阿里巴巴内部维护了数十个大规模的 K8s 集群，其中最大的集群约 1 万个节点，每一个集群会服务上万个应用；在阿里云的 Kubernetes 服务 ACK 上，咱们还维护了上万个用户的 K8s 集群。咱们在必定程度上解决了规模和稳定性问题以后，发现其实在 K8s 上管理应用还有很大的挑战等着咱们。

应用管理的两大难题

今天咱们主要讨论这两个方面的挑战：

• 对应用研发而言，K8s API 针对简单应用过于复杂，针对复杂应用难以上手；
• 对应用运维而言，K8s 的扩展能力难以管理；K8s 原生的 API 没有对云资源所有涵盖。

整体而言，咱们面临的挑战就是：如何基于 K8s 提供真正意义上的应用管理平台，让研发和运维只需关注到应用自己。

研发对应用管理的诉求

K8s all in one 的 YAML 文件

让咱们来看一下这样一个 K8s 的 yaml 文件，这个 yaml 文件已是被简化过的，可是咱们能够看到它仍然仍是比较长。

面对这样一个广受“复杂”诟病的 YAML 文件，我相信你们都会忍不住想该怎么简化。

自上而下，咱们大体把它们分为三块：

• 一块是扩缩容、滚动升级相关的参数，这一块应该是应用运维的同窗比较关心的；
• 而后中间一块是镜像、端口、启动参数相关的，这一块应该是开发的同窗比较关心的；
• 最后一块你们可能根本看不懂，一般状况下也不太须要明白，能够把它们理解为 K8s 平台层的同窗须要关心的。

看到这样一个 yaml 文件，咱们很容易想到，只要把里面的字段封装一下，把该暴露的暴露出来就行了。确实，咱们内部就有 PaaS 平台这么作。

只透出部分字段：简单却能力不足

内部的某个 PaaS 平台精心挑选了部分字段，并作了一个漂亮的前端界面给用户，只透出给用户 5 个左右的字段，大大下降了用户理解 K8s 的心智负担。而后底层实现用相似模板的方式把用户这五个字段渲染出来一个完整的 yaml 文件。突出的字段大概以下图所示：

不得不说这种方式是很是有效的，针对简单无状态的应用，精简 API 能够大大下降 K8s 的门槛，快速而且高效的对接用户，PaaS 平台也顺利让你们使用了起来。同时，我也从一些技术分享中了解到许多其余公司也是用这种相似的方式简化的 K8s API。

可是当用户的业务开始大规模对接之后，咱们就会天然而然遇到有状态的复杂应用，用户就会开始抱怨 PaaS 平台能力不够了。好比咱们的 Zookeeper 多实例选主、主从切换这些逻辑，在这五个字段里就很难展开了。

归根结底就是屏蔽大量字段的方式会限制基础设施自己的能力演进，可是 K8s 的能力是很是强大而灵活的。咱们不可能为了简化而放弃掉 K8s 强大的能力。

就好比当前这个例子，咱们很容易想到，针对复杂有状态的应用，应该经过 K8s 里面的 CRD 和 Operator 来解决。

CRD+Operator: K8s 扩展能力强大却难以上手

确实，咱们内部对接复杂应用云原生化的时候，也推荐他们编写 Operator，可是常常出现这样一段对话。

中间件的工程师跟咱们说，我这有个 Zookeeper 该用哪一种 K8s 的 Workload 接入啊？ 咱们想了想，K8s 设计如此精妙，天然没有解决不了的问题，因而咱们推荐他们使用 Operator。他们就懵了，说大家搞云原生的这几年造新词的能力绝对一流，以前都没据说过。

想一想也是，业务方理解这些新概念不难，可是真的要本身去上手实现，仍是很是困难的。咱们天然也以为业务方更应该专一于他们的业务自己，因而咱们不得不帮他们一块儿写。

能够看到，咱们亟需一个统一的模型去解决研发对应用管理的诉求。

运维对应用管理的诉求

除了研发侧的问题以外，咱们在运维侧也遇到了很大的挑战。

运维能力众多却难以管理

K8s 的 CRD Operator 机制很是灵活而强大，不光是复杂应用能够经过编写 CRD Operator 实现，咱们的运维能力也大量经过 Operator 来扩展，好比灰度发布、流量管理、弹性扩缩容等等。咱们经常赞叹于 K8s 的灵活性，它让咱们基础平台团队对外提供能力很是方便，可是对应用运维来讲，他们要使用咱们提供的这些运维能力，却变得有些困难。

好比咱们上线了一个 CronHPA，能够定时设置在每一个阶段会根据 CPU 调整实例数的范围。应用运维并不知道跟原生不带定时功能的 HPA 会产生冲突，而咱们也没有一个统一的渠道帮助管理这么多种复杂的扩展能力，结果天然是引发了故障。这血的教训提醒咱们要作事前检查，熟悉 K8s 的机制很容易让咱们想到为每一个 Operator 加上 admission webhook。

这个 admission webhook 须要拿到这个应用绑定的全部运维能力以及应用自己的运行模式，而后作统一的校验。若是这些运维能力都是一方提供的还好，若是存在两方，甚至三方提供的扩展能力，咱们就没有一个统一的方式去获知了。事实上若是咱们想的更远一些就会发现，咱们须要一个统一的模型来协商并管理这些复杂的扩展能力。

云资源难以描述和统一交付

当咱们把应用的 Operator 以及对应的运维能力都写好之后，咱们很容易想到要打包交付这个应用，这样不管是公有云仍是专有云均可以经过一个统一的方式去交互。社区的主流方式目前就是使用 Helm 来打包应用，而咱们也采用了这样的方式给咱们的用户交付，可是却发现咱们的用户需求远不止于此。

云原生应用有一个很大的特色，那就是它每每会依赖云上的资源，包括数据库、网络、负载均衡、缓存等一系列资源。

当咱们使用 Helm 打包时，咱们只能针对 K8s 原生 API，而若是咱们还想启动 RDS 数据库，就比较困难了。若是不想去数据库的交互页面，想经过 K8s 的 API 来管理，那就又不得不去写一个 CRD 来定义了，而后经过 Operator 去调用实际云资源的 API。

这一整套交付物实际上就是一个应用的完整描述，即咱们所说的“应用定义”。但事实上，咱们发现“应用定义”这个东西，在整个云原生社区里实际上是缺失的。这也是为何阿里巴巴内部有不少团队开始尝试设计了本身的“定义应用”。

这种定义方式最终全部的配置仍是会所有堆叠到一个文件里，这跟 K8s API all-in-one 的问题实际上是同样的，甚至还更严重了。并且，这些应用定义最终也都成为了黑盒，除了对应项目自己可使用，其余系统基本没法复用。天然就更没法使得多方协做复用了。

每一个公司和团队都在本身定义应用

不光是阿里巴巴内部的团队须要应用定义，事实上几乎每一个基于 K8s 管理应用的公司和团队都在本身定义应用。以下所示，我就搜到了两家公司的应用定义：

应用定义其实是应用交付/分发不可或缺的部分。可是在具体的实践中，咱们感觉到这些内部的应用定义都面临着以下的问题：

1. 定义是否足够开放，是否能够复用？
2. 如何与开源生态协做？
3. 如何迭代与演进？

这三个问题带来的挑战都是巨大的，我在上文已经提到，一个应用定义须要容易上手，但又不失灵活性，更不能是一个黑盒。应用定义一样须要跟开源生态紧密结合，没有生态的应用定义注定是没有将来的，天然也很难持续的迭代和演进。

区分使用者的分层模型与模块化的封装

让咱们回过头来从新审视咱们面临的挑战，归根结底在于 K8s 的 All in One API 是为平台提供者设计的，咱们不能像下图左侧显示的同样，让应用的研发、运维跟 K8s 团队同样面对这一团 API。

一个合理的应用模型应该具备区分使用者角色的分层结构，同时将运维能力模块化的封装。让不一样的角色使用不一样的 API，正如上图右侧部分。

OAM： 以应用为中心的 K8s API 分层模型

OAM(Open Application Model) 正是这样一个以应用为中心的 K8s API 分层模型：

• 从研发的角度，他操做和关注的 API 对象叫 Component；
• 从运维的角度，模块化的运维能力封装就是 Trait，而运维能够经过 App Config 将 Component 和 Trait 自由组合，最终实例化成一个运行的应用；
• K8s 团队自己则仍然基于 K8s 的原生 API 迭代这一层能力。

针对研发时常抱怨的 K8s API 太复杂，咱们经过关注点分离，区分使用者面对的 API 来解决，同时提供了几种核心的 Workload，让研发只须要填写少数几个字段就能够完成组件的定义；针对复杂应用定义，咱们经过扩展的 Workload，容许研发对接 CRD Operator 的方式对接自定义 Workload。

针对运维须要的模块化封装运维能力和全局管理的需求，OAM 模型经过 Trait 来提供。Trait 是运维能力的体现，不一样的 Trait 也对应了不一样类型的运维能力，如日志收集 Trait、负载均衡 Trait、水平扩缩容 Trait 等等；同时 OAM 自己就提供了一个全局管理的标准，OAM 模型的实现层能够轻松针对 OAM 定义里的种种 Trait 描述进行管理和检查。

针对云资源，OAM 向上也提供了统一的 API，也是经过关注点分为三类：

• 一类是研发关注的云资源，如数据库 RDS、对象存储 OSS 等，经过扩展 Workload 接入；
• 另外一类是运维关注的云资源，如负载均衡 SLB 等，经过 Trait 接入；
• 最后一类也是运维关注的云资源，可是可能包含多个应用之间的联动关系，如虚拟专有网络 VPC 等，经过应用的 Scope 接入。Scope 则是 OAM 中管理多应用联动关系的概念。

能够看到，OAM 经过统一的一套标准，解决了咱们今天提到的全部难题。让咱们继续深刻到 OAM 中看看不一样的概念具体是什么。

OAM Component：研发关注的 API

Component 就是 OAM 模型提供给研发的API对象，以下所示：

能够看到 Component 自己就是一个 K8s 的CRD，spec 字段里面的部分就是 Component 具体的定义。其中第一个重要的字段就是 workloadType，这个决定了应用的运行模式。

针对简单应用，OAM 提供了 6 种核心 Workload，以下表所示：

主要经过是否可访问、是否可复制、是否长久运行来区分。如 Server，就表明了你们最经常使用的 K8s 里面 Deployment+Service 的组合。

填写了核心 workloadType 的 Component，只须要定义 Container 里的注入镜像、启动参数等字段，就如咱们最开始所说的屏蔽掉大量字段的 PaaS 同样，为用户大大下降了门槛。

而针对复杂的有状态应用，OAM 则容许经过扩展 Workload 来实现，以下图所示，咱们能够定义一个新的叫 openfaas 的 WorkloadType，它的定义实际上彻底等价于一个 CRD 定义。

OAM 模型中，使用自定义的 Workload 也是经过 Component，只是 WorkloadType 改成你自定义的 WorkloadType 名称。

OAM Trait：可发现、可管理的运维能力

Trait 就是模块化的运维能力，咱们能经过命令行工具发现一个系统里支持哪些 Traits（运维能力）。

这时候，运维要查看具体的运维能力该怎么使用，是很是简单的：

能够看到，他能够在 Trait 定义里清晰的看到这个运维能力能够做用于哪一种类型的 Workload，包括能填哪些参数、哪些必填/选填、参数的做用描述是什么。 你也能够发现，OAM 体系里面，Component 和 Trait 这些 API 都是 Schema，因此它们是整个对象的字段全集，也是了解这个对象描述的能力“到底能干嘛?”的最佳途径。

事实上，你们可能已经发现，Trait 的定义和 CRD 是对等的，而你彻底也能够经过 Operator 实现 Trait。

因此 OAM 事实上将本来散乱的 Operator 经过不一样的角色有机的管理起来了。

OAM Application Config：组装 Component 和 Trait，应用实例化运行

Component 和 Trait 最终经过 Application Configuration 结合，并真实运行起来。

更重要的是，这个 OAM 应用描述文件是彻底自包含的，也就是说经过 OAM YAML，做为软件分发商，咱们就能够完整地跟踪到一个软件运行须要的全部资源和依赖。这就使得如今对于一个应用，你们只须要一份 OAM 的配置文件，就能够快速、在不一样运行环境上把应用随时运行起来，把这种自包含的应用描述文件完整地交付到任何一个运行环境中。

而咱们图中的 Rudr 项目就是 OAM 的一个实现，也能够理解为 OAM 的一个解释器，将 OAM 的统一描述转换为背后众多的 Operator。同时 Rudr 也是一个统一管理的媒介，若是 Application Configuration 中出现了一个 Component 绑定 2 个 Trait 而且互相冲突的状况，就能够快速被检验并发现问题，以下图所示。

一样，包括复杂应用的编排、云资源的拉起、Workload 与 Trait 交互等等，均可以在这个 OAM 解释器中实现。

你们能够经过 Rudr 项目中的教程文档体验 OAM 的这些交互过程。

OAM 加持下的 Kubernetes PaaS

事实上，OAM 加持下的 PaaS 基于 Kubernetes，将众多 Operator 分层的管理了起来。

对于研发，一般他关心的应用多是一个由 web 和数据库组合而成的应用，数据库组件的背后多是一个 RDS Operator 实现。而 web 应用背后，则能够是咱们开源的 K8s 原生 StatefulSet的加强项目 OpenKruise，OpenKruise 中提供的包括原地升级等加强能力则经过 Trait 的方式去配置。而额外的一些监控报警、日志等能力，则由一个个独立的 Operator 去实现，由运维在第二层去关注和管理。

最终 K8s 团队联合各类基础软件的提供商，围绕 K8s 原生 API，以 Operator 的形式不断提供扩展能力，经过 OAM 这样统一的规范和标准向外标准化输出。

更重要的是，OAM 的统一描述大大提升了 Operator 的复用能力，使得 Operator 的编写主须要关注业务逻辑自己。好比原先你写一个 Zookeeper Operator，你须要写实例的服务发现、须要写升级时主备切换的编排逻辑、须要写实例备份的逻辑，而这一切在 OAM 的标准化下，你将能够轻松在社区找到相似组成部分。

OAM 加持下的 Kubernetes PaaS，使得不一样的 Operator 能够像乐高积木同样灵活组装，使得应用定义成为了社区共同建设的项目，使得应用管理变得统一，功能却更增强大！

---

本文做者：孙健波（天元）

原文连接

本文为阿里云内容，未经容许不得转载。