蚂蚁大规模 Kubernetes 集群无损升级实践指南【探索篇】

文｜王连平（花名：烨川 )

蚂蚁集团高级开发工程师

负责蚂蚁 Kubernetes 集群容器交付

专注于集群交付能力、交付性能及交付 Trace 等相关领域

本文 12623 字 阅读 20 分钟

—— 庖丁解牛，让升级不再烦恼

PART. 1

背 景

蚂蚁 Sigma 作为蚂蚁集团核心的基础设施，经过多年的发展其规模已经处于业界领先位置，大规模集群对 Kubernetes 的稳定性及功能性提出更高的要求。蚂蚁 Sigma 力争在万级规模的云原生环境下，挑战高效稳定、无损无感的云原生操作系统升级，给用户带来极致稳定的、功能新颖的云原生服务。 

 为什么要持续迭代升级 ？

Kubernetes 社区的活跃度非常高，众多的云原生爱好者为社区贡献智慧，推动社区版本不断更新。升级是为了紧跟社区的步伐，及时享用社区沉淀下来的优秀特性，进而给公司带来更大利益。

 为什么升级那么难 ？

按照蚂蚁 Sigma 的规模，升级对我们来讲是一件非常不容易的事情，主要体现在：

- 在升级准备阶段，要全量推动客户端进行升级，业务方要安排专门的人投入进来，耗时耗力；

- 在升级过程中，为了规避版本滚动时对 Kubernetes 资源操作可能带的来不可预期后果，升级过程中一般会关停流量，业务体感不好；

- 对于升级时间窗口选择，为了给用户更好的服务体验，升级要放到业务量少的时间进行，这对平台运维人员不太友好。

因此，升级过程中如何提升用户、研发、SRE 的幸福感是我们想要达成的目标。我们期望实现无损升级来降低升级风险，解耦用户来提升幸福感，高效迭代来提供更强大的平台能力，最终实现无人值守。

本文将结合蚂蚁 Sigma 系统升级实践，从 Kubernetes 系统升级的目标、挑战开始，逐步剖析相关的 Kubernetes 知识，针对这些挑战给出蚂蚁 Sigma 的一些原则和思考。

【两种不同的升级思路】

在介绍挑战和收益前，我们先了解下当前集群升级的方式。Kubernetes 升级与普通软件升级类似，主要有以下两种常见的升级方式：替换升级和原地升级。

- 替换升级：将应用运行的环境切换到新版本，将旧版本服务下线，即完成替换。在 Kubernetes 升级中，即升级前创建新版本的 Kubernetes 集群，将应用迁移到新的 Kubernetes 集群中，然后将旧版本集群下线。当然，这种替换升级可以从不同粒度替换，从集群为度则是切换集群；从节点维度，则管控节点组件单独升级后，kubelet 节点升级时迁移节点上的 Pod 到新版本节点，下线旧版本节点。

- 原地升级：将升级的软件包原地替换，旧服务进程停止，用新的软件包重新运行服务。在 Kubernetes 升级中，apiserver 和 kubelet 采用原地软件包更新，然后重启服务，这种方式与替换升级最大的区别在于节点上的 workload 不用迁移，应用不用中断，保持业务的连续性。

上述两种方式各有优缺点，蚂蚁 Sigma 采用的是原地升级。

【方法论-庖丁解牛】

采用原地升级时也必然会遇到原地升级的问题，其中最主要问题就是兼容性问题，主要包含两个方面：Kubernetes API 和组件内部的控制逻辑兼容性。

Kubernetes API 层面包含 API 接口、resource 结构和 feature 三方面变化，而组件内部控制逻辑变化主要是 resource 在 Kubernetes 内部流转行为的变化。

前者是影响用户及集群稳定性最重要的因素，也是我们重点解决的问题。

API 接口的变化固然要涉及到客户端的升级，特别是对于 deprecated 和 removed 的 API，客户端无法再使用旧版本的 API 接口。resource 接口的变化主要指 resource 字段变化，字段的调整意味着 API 能力的变化，同一 resource 在新旧版本中存在字段上的差异会导致 API 能力上差异，主要体现在新增某个字段、废弃某个字段和字段默认值变化。feature 方面，主要是一些 feature 的 GA 导致 featrue 开关能力被移除，以及一些新的 feature 的加入。

面对上述的核心问题，我们将升级中遇到的兼容性问题按照升级阶段分为“升级前”、“升级中”和“升级后”三个阶段。

- 升级前，将面临大量客户端升级推动问题，通过探索版本之间的差异和多版本客户端并存的问题，我们来制定一些规则，这将大大减少客户端升级的数量，提升升级的效率。

- 升级中，将面临多版本 apiserver 并存的问题，以及数据的存储版本转换问题，当然还会有可回滚性的问题，这些问题我们将采用精细化流量控制能力避免篡改，压制 resource 存储版本和 GVK 版本保证可回滚，同时对于 etcd 中的数据进行版本迁移，如此实现无损升级和回滚。

- 升级后，对于少量的可能引发不可接受故障的客户端，我们通过识别资源修改请求意图，降低篡改的风险。

还有一个重要的环节，整个过程我们要做到自动化、可视化，在升级过程中流量的充分灰度是很有必要的，升级节奏的自动化推进和应急场景下的人工可控性也是非常重要的，这些将在另一篇文章中详细介绍。

整体来看，我们通过客户端最小化升级和滚动自动化升级能力、提升升级的效率，通过精细化流量控制、灰度可回滚能力以及长效的字段管控能力，提升整个升级过程的可靠性、稳定性。

PART. 2

升级前

集群升级必然会有 API 的更新和迭代，主要体现在 API 新增、演进和移除，在 Kubernetes 中 API 的演进一般是 Alpha、beta、GA，一个 resouce 的 API version 会按照上述版本进行迭代，当一个 API 新增时，最开始是 Alpha 阶段，例如"cert-manager.io/v1alpha3"，经过若干次迭代，新特性进入 beta 版本，最后进入稳定的 GA 版本，这个过程可能跨若干个大的社区版本，一些版本会在 GA 版本稳定运行一定时间后被 deprached 掉，并且被 deprached 的 API 版本在一段时间后会被直接移除，这就对我们的客户端有了升级的刚性需求。

在介绍客户端升级前，先介绍下一般 resource API 变化有哪些方面。

【Schema 变化】

不同版本的 Kubernetes 资源的 Schema 字段可能存在差异，主要表现在以下两个方面：

- 字段的增加/删除/修改

- 字段的默认值调整

字段增删改