深刻Kubernetes 的“无人区” — 蚂蚁金服双十一的调度系统

1、前言

通过超过半年的研发，蚂蚁金服在今年完成了 Kubernetes 的全面落地，并使得核心链路100% 运行在 Kubernetes。到今年双十一，蚂蚁金服内部经过 Kubernetes 管理了数以万计的机器以及数十万的业务实例，超过90%的业务已经平稳运行在 Kubernetes 上。整个技术切换过程平稳透明，为云原生的资源基础设施演进迈好了关键的一步。

本文主要介绍 Kubernetes 在蚂蚁金服的使用状况，双十一大促对 Kubernetes 带来前所未有的挑战以及咱们的最佳实践。但愿经过分享这些咱们在实践过程当中的思考，让你们在应用 Kubernetes 时可以更加轻松自如。

2、蚂蚁金服的 Kubernetes 现状

2.1 发展历程与落地规模

Kubernetes 在蚂蚁金服落地主要经历了四个阶段：

1. 平台研发阶段：2018年下半年蚂蚁金服和阿里集团共同投入 Kubernetes 技术生态的研发，力求经过 Kubernetes 替换内部自研平台；

2. 灰度验证：2019年初 Kubernetes 在蚂蚁金服灰度落地，经过对部分资源集群进行架构升级以及灰度替换生产实例两种方式，让 Kubernetes 得以小规模的验证；

3. 云化落地（蚂蚁金服内部基础设施云原生化）：2019年4月蚂蚁金服内部完成 Kubernetes 适配云化环境的目标，并于618以前完成云化机房100% 使用 Kubernetes 的目标，这是 Kubernetes 第一次在蚂蚁金服内部获得规模化的验证；

4. 规模化落地：2019年618以后，蚂蚁金服内部开始全面推进 Kubernetes 落地，在大促以前完成核心链路100% 运行在 Kubernetes的目标，并完美支撑了双十一大考。

2.2 统一资源调度平台

Kubernetes 承载了蚂蚁金服在云原生时代对资源调度的技术目标：统一资源调度。经过统一资源调度，能够有效提高资源利用率，极大的节省资源成本。要作到统一调度，关键在于从资源层面将各个二层平台的调度能力下沉，让资源在 Kubernetes 统一分配。

蚂蚁金服在落地 Kubernetes 实现统一调度目标时遵循了标准化的扩展方式：

• 一切业务扩展均围绕 Kubernetes APIServer，经过CRD + Operator方式完成业务功能的适配和扩展；

• 基础服务经过 Node 层定义的资源接口完成个性化适配，有益于造成资源接入的最佳实践。

得益于持续的标准化工做，咱们在落地 Kubernetes 的大半年内应用了多项技术，包含安全容器，统一日志，GPU 精细调度，网络安全隔离及安全可信计算等，并经过 Kubernetes 统一使用和管理这些资源服务了大量在线业务以及计算任务型业务。

3、双十一 Kubernetes 实践

下面咱们经过如下几种场景介绍蚂蚁金服内部是如何使用 Kubernetes，以及在此过程当中咱们面对的挑战和实践之路。

3.1 资源分时复用

在大促过程当中，不一样业务域的洪峰流量一般都是在不一样时间段来临，而应对这些不一样时间到来的业务流量每每都须要大量的额外计算资源作保障。在以往的几回活动中，咱们尝试了经过应用快速腾挪的方式来作到资源上的分时复用，可是服务实例上下线须要预热，腾挪耗时不可控，大规模调度的稳定性等因素都影响了最终腾挪方案的实践效果。

今年双十一咱们采用了资源共享调度加精细化切流的技术以达到资源分时利用的目标，为了达到资源充分利用和极速切换的目标，咱们在如下方面作了加强：

• 在内部的调度系统引入了联合资源管理（Union-Resource Management），他能够将波峰波谷不重叠的业务实例摆放在相同的资源集合内，达到最大化的资源利用。

• 研发了一套融合资源更新，流量切换及风险控制的应用分时复用平台，经过该平台SRE能够快速稳定的完成资源切换以应对不一样的业务洪峰。

整套平台和技术最终实现了使人激动的成果：蚂蚁金服内部不一样业务链路数以万计的实例实现了最大程度的资源共享，这些共享资源的实例可分钟级完成平滑切换。这种技术能力也突破了当下资源水平伸缩能力的效率限制，为资源的分时复用打开了想象空间。

3.2 计算型任务混部

Kubernetes 社区的落地案例中，咱们每每看到的都是各类各样的在线业务，计算型业务每每经过“圈地”式的资源申请和独立的二层调度跑在 Kuberentes 集群中。可是在蚂蚁内部咱们从决定使用 Kubernetes 的第一天起，就将 Kubernetes 融合计算型业务实现资源的统一调度做为咱们的目标。

在蚂蚁金服内部咱们持续的使用 Kubernetes 支持各种计算业务，例如各种AI 训练任务框架，批处理任务和流式计算等。他们都有一个共同的特色：资源按需申请，即用即走。

咱们经过 Operator 模型适配计算型任务，让任务在真正执行时才会调用 Kubernetes API 申请 Pod 等资源，并在任务退出时删除 Pod 释放资源。同时咱们在调度引擎中引入了动态资源调度能力和任务画像系统，这为在线和计算的不一样等级业务提供了分级资源保障能力，使在线业务不受影响的状况下资源被最大化的利用。

今年双十一除了洪峰时间段（00：00~02：00），蚂蚁金服 Kubernetes 上运行的任务均未作降级，每分钟仍有数以百计的计算任务在 Kubernetes 上申请和释放。将来蚂蚁金服内部将会持续推进业务调度融合，将 Kubernetes 打形成为资源调度的航空母舰。

3.3 规模化核心

蚂蚁金服是目前少数运行了全球最大规模的 Kubernetes 集群的公司之一，单集群机器规模过万，Pods 数量数十万。随着相似计算型任务混部和资源分时复用这类业务的落地，资源的动态使用以及业务自动化运维都对 Kubernetes 的稳定性和性能带来的巨大的挑战。

首先须要面对的挑战是调度性能，社区的调度器在5k规模测试中调度性能只有1~2 pods/s，这显然没法知足蚂蚁金服的调度性能需求。

针对同类业务的资源需求每每相同的特色，咱们自研了批量调度功能，再加上例如局部的filters性能优化等工做，最终达到了百倍的调度性能提高！

在解决了调度性能问题后，咱们发现规模化场景下 APIServer 逐渐成为了影响 Kubernetes 可用性的关键组件，CRD+Operator 的灵活扩展能力更是对集群形成巨大的压力。业务方有100种方法能够玩垮生产集群，让人防不胜防。

形成这种现象一方面是因为社区今年之前在规模化上的投入较少 APIServer 能力较弱，另外一方面也是由 Operator 模式的灵活性决定。开发者在收益于 Operator 高灵活度的同时，每每为集群管理者带来业务不受控制的风险。即便对 Kubernetes 有必定熟悉程度的开发者，也很难保障本身写出的 Operator 在生产中不会引爆大规模的集群。

面对这种“核按钮”不在集群管理员手上的状况，蚂蚁内部经过两方面入手解决规模化带来的问题：

1. 咱们经过持续总结迭代过程当中的经验，造成了内部的最佳实践原则，以帮助业务更好的设计Operator

• CRD 在定义时须要明确将来的最大数量，大量CR 业务最好采用 aggregate-apiserver 进行扩展；

• CRD 必须 Namespaced scope，以控制影响范围；

• MutatingWebhook + 资源 Update 操做会给运行时环境带来不可控破坏，尽可能避免使用这种组合；

• 任何 controllers 都应该使用 informers，而且对写操做配置合理限流；

• DaemonSet 很是高阶，尽可能不要采用这类设计，若是必需请在 Kubernetes 专家的辅导下使用；

  2.咱们已经在 Kubernetes 实施了一系列的优化，包含多维度流量控制，WatchCache 处理全量 List 请求，controller 自动化解决更新冲突，以及 APIServer 加入自定义索引等。

经过规范和优化，咱们从 client 到 server 对 API 负载作了总体链路的优化，让资源交付能力在落地的大半年内提高了6倍，集群每周可用率达到了3个9，让 Kubernetes 平稳顺滑的支撑了双十一的大促。

3.4 弹性资源建站

近几年大促蚂蚁金服都会充分利用云化资源，经过快速弹性建站的方式将全站业务作“临时”扩容，并在大促后回收站点释放资源。这样的弹性建站方式为蚂蚁节省了大量的资源开支。

Kubernetes 提供了强大的编排能力，但集群自身的管理能力还比较薄弱。蚂蚁金服从 0 开始，基于 Kubernetes on Kubernetes 和面向终态的设计思路，开发了一套管理系统来负责蚂蚁几十个生产集群的管理，提供面向大促的快速弹性建站功能。

经过这种方式咱们能够自动化的完成站点搭建，3小时内交付可当即使用的包含数千个 Nodes 的 Kubernetes 集群。今年双十一咱们在一天内交付了所有弹性云化集群，随着技术的不断提高和磨练，咱们指望将来可以按天交付符合业务引流标准的集群，让蚂蚁金服的站点随时随地可弹。

4、展望将来，迎接挑战

云原生时代已经到来，蚂蚁金服内部已经经过 Kubernetes 迈出了云原生基础设施建设的第一步。虽然当前在实践中仍然有许多挑战在等着咱们去应对，但相信随着咱们在技术上持续的投入，这些问题会一一获得解决。

4.1 平台与租户

当前咱们面对的一大挑战是多租户带来的不肯定性。蚂蚁金服内部不可能为每一个业务部门都维护一套Kubernetes集群，而单个 Kubernetes 集群的多租户能力十分薄弱，这体如今如下两个维度：

1. APIServer 和 etcd 缺乏租户级别的服务保障能力；

2. Namespace 并不能有效的隔离所有资源，而且因为Namespace 只提供了部分资源能力，对平台型的接入方也很不友好。

将来咱们会在核心能力如 Priority and Fairness for API Server Requests 以及 Virtual Cluster 上持续的作技术投入和应用，有效保障租户的服务能力保障和隔离。

4.2 自动化运维

除了资源调度，Kubernetes 下一阶段的重要场景就是自动化运维。这涉及到应用资源全生命周期的面向终态自行维护，包含但不限于资源自动交付及故障自愈等场景。

随着自动化程度的不断提高，如何有效控制自动化带来的风险，让自动化运维可以真正提高效率而不是任什么时候刻都须要承担删库跑路的风险是接下来的一个重要难题。

蚂蚁金服在落地 Kubernetes 的过程当中经历过相似的状况：从初期高度自动化带来无限的兴奋，到遭遇缺陷不受控制最终爆炸引起故障后的无比沮丧，这些都说明了在 Kubernetes 上作自动化运维仍有很长的路要走。

为此咱们接下来和阿里集团兄弟部门一块儿推进 Operator 的标准化工做。从接入标准，Operator 框架，灰度能力建设和控制治理上入手，让 Kubernetes 上的自动化运维变的更加可视可控。

5、结束语

今年咱们实现了 Kubernetes 由 0-1 的落地，经受了双十一双大促真实场景的考验。但云原生的基础设施建设还是刚刚起步，接下来咱们将在弹性资源交付，集群规模化服务以及技术风险与自动化运维上持续发力，以技术支撑和推进业务服务完成云原生的落地。

最后，也欢迎志同道合的伙伴加入咱们，一块儿参与建设云原生场景下的基础设施！可点击【金融级分布式架构】公众号【加入咱们】-【超多岗位】 tab 获取职位信息。

做者介绍

曹寅，蚂蚁金服 Kubernetes 落地负责人，2015年加入蚂蚁金服，主要从事容器技术及平台研发相关工做，2018年开始负责蚂蚁Kubernetes的研发落地。 曾在阿里云弹性计算工做四年，对云计算基础设施领域有着深入的理解。