关于kubernetes:蚂蚁大规模-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 字段可能存在差别，次要体现在以下两个方面：

• 字段的减少 / 删除 / 批改
• 字段的默认值调整

字段增删改

Kubernetes 的 resource 如果对某个字段的调整，包含：减少、删除、批改三种。对于“减少”操作，能够在新 GV(GroupVersion)呈现也能够在旧 GV 中呈现。对于“删除”和“批改”，个别只会在新的 GV 中呈现。

基于以上条件，对于新版本 APISever 引入的 resource 字段调整，能够得出以下论断：

字段默认值变动

字段默认值变动是指，在新旧 apiserver 中 resource 某个字段默认值填充不统一。字断默认值变动可能带来的两个问题：

• container hash 变动，会导致容器重启
• 影响管制组件的管制动作

字段变动带来的影响次要在客户端新旧版本穿插拜访和 apiserver 多版本并存穿插拜访上，具体影响在下文中介绍。

客户端降级

客户端降级是为了兼容新版本 API，保障在降级后不呈现问题，同时实现 operator 精确化、差异化降级，晋升降级效率。低版本客户端不降级会遇到的如下问题：

外围问题

依照新旧版本 GVK(GroupVersionKind)的变动梳理一下降级过程中低版本客户端可能呈现的各种状况：

如上图所示，外围问题次要有以下三种：

1. 低版本客户端拜访曾经被 depreached/removed 的 GroupVersionKind

2. 低版本客户端操作的 resource 存在字段减少问题

3. 低版本操作的 resource 存在字段默认值变动问题

针对第一个问题，拜访曾经被 depreached 特地是被 removed 的 GVK 时，服务器端间接返回类 404 谬误，示意此 rest url 或者次 GVK 曾经不存在。

针对第二个和第三个问题，都呈现在低版本客户端的 Update 操作，为什么对于 patch 操作不会呈现问题呢？因为 Update 操作是全量更新，patch 操作是部分更新，全量更新的状况下，如果客户端版本低没有新增字段或者没默认值变动的字段，此时去 Update 此 resource，提交的申请数据中不会呈现此字段，然而此字段在 apiserver 外部会被补全和填充，如此此字段的值就齐全依赖 apiserver 外部的逻辑了。

针对字段减少的状况，咱们做了一个试验，如下：

1.18 版本中 Ingress 中多了一个 patchType 的字段，咱们首先通过 1.18 的客户端进行创立，并设定 pathType=Prefix，而后通过 1.16 版本的客户端进行 Update，发现此职被批改为 pathType 的默认值。如下：

思考与解决

针对第一个问题，解决形式比拟明确，客户端必须降级，因为 GVK 曾经从新版本的 apiserver 中移除了。依照 Kubernetes 社区的 API 废除规定（给定类别的 API 版本在新的、稳定性未升高的 API 版本公布之前不可被废除；除了每类 API 版本中的最新版本，旧的 API 版本在其被发表被废除之后至多肯定时长内仍需被反对），咱们能够显式地管制一些 API 向下兼容，来满足一些低版本客户端的需要，然而此形式不是有限的，在某个高版本中总是会被移除掉的，所以不举荐这么做来提早或容忍客户端的降级。

针对第二个和第三个问题，都波及到 Update 操作，因为 Update 操作会呈现误操作的状况。如果用户客户端版本较低，然而用户并不关怀 resource 的新增字段，也不想应用这些新性能，他能够齐全不理睬此字段，对于 create/delete/patch 都没有问题，同时 patch 操作也不会针对此字段进行。所以管制好 Update 操作的客户端就能够防止新增字段的篡改行为。

PART. 3 降级中

Kubernetes 集群的降级次要蕴含客户端降级、外围组件降级，外围组件包含 apiserver、controller-manger、scheduler 和 kubelet。

这里的客户端是狭义上的客户端，即业务的 operator 及管控的 operator 都称为客户端。客户端的降级由客户端自行做流量灰度，大版本升级过程中最外围的是 apiserver 降级过程中可能会呈现脏数据问题。

这里提到的脏数据问题次要体现在以下两个方面：

• 多版本 apiserver 穿插操作同一资源
  是高下版本 apiserver 中对有 Schema 变动资源的操作会呈现篡改问题，其问题实质与多版本客户端操作同一有 Schema 变动的资源时产生的篡改统一。只不过这里是 apiserver 版本不一样，客户端版本是否统一都会引起篡改问题。
• 存储在 etcd 中的数据如何保障正确更新
  是大家个别不太留神的问题，因为 apiserver 降级过程中会帮咱们很好的解决，但也不是百分百完满解决，这里独自拿出来讲一下也有助于大家对 Kubernetes 数据存储有更深刻的理解。

脏数据的问题在降级过程中很容易联想到可回滚性，咱们无奈保障降级百分百胜利，然而咱们肯定要有可回滚能力，依照社区的倡议 Kubernetes 在降级过程中不倡议回滚，它会带来更多的兼容性问题。

上述这些问题将在下文具体讲述。

多版本 apiserver 并存】

从降级的过程中能够看到，在流量管控时次要管控的流量有两项：

• Updateu/patch 动作的流量
• 残余其余所有流量

这里重点提到的是 Update 流量，作为管控的次要起因也同低版本客户端篡改字段起因一样。

客户端的问题是，当 apiserver 都是高版本时，客户端存在高下版本同时操作同一 resource 时会呈现篡改，所以咱们会推动具备 Update 动作的客户端进行降级。

降级 apiserver 时另外一个问题呈现了，从流程上看，降级过程中流量会同时打到 1.16 和 1.18 版本的客户端上，这样即便客户端高版本，通过不同版本的 apiserver 写操作同一 resource 同样会呈现篡改景象。

多版本 apiserver 穿插拜访

此问题，咱们同样依照前文提到的 resource 变动的类型来讲述。

• 字段变动

字段变动蕴含减少、删除和批改三种，对于删除和批改会在新的 GVK 中呈现，所以咱们只思考减少的情景。如下图所示，Kubernetes 的 Pod 在 1.18 版本比 1.16 版本中多了一个字段 ”NewFiled”，降级过程中如果穿插拜访同一 PodA 则会呈现 PodA 存储的数据一直一直变动，首先通过 1.18 版本 apiserver 创立 PodA，而后通过 1.16 的 apiserver Update 后 PodA 的新增字段会被删除，再通过 1.18 版本的 apiserver Update 字段又被填充回来。

针对此此问题，有以下论断：

（1）对于字段减少状况，当通过旧版本 apiserver 更新带有新字段的资源时存在字段默认值被删除的危险；对于字段删除和批改两种状况，无此危险；

（2）如果新增字段被用于计算 container hash，但因为 apiserver 降级时 kubelet 还处于 1.16 版本，所以仍旧依照 1.16 版本计算 hash，apiserver 穿插变动不会导致容器重建。

• 字段默认值变动

字段默认值变动是指，在新旧 apiserver 中，对某个资源字段默认值填充不统一。如下图所示，1.16 版本的 Kubernetes 中 Pod 字段 ”FiledKey” 默认值为 ”default_value_A”，到 1.18 版本时该字段默认值变为 ”default_value_B”，通过 1.18 apiserver 创立 PodA 后，再通过 1.16 版本 apiserver 更新会呈现默认值被篡改的问题。这种状况的产生条件绝对刻薄，个别 Update 之前会拉下集群中以后的 Pod 配置，更改关怀的字段后从新 Update 回去，这种形式会放弃默认值变动的字段值，然而如果用户不拉取集群 Pod 配置，间接 Update 就会呈现问题。

针对此此问题，有以下论断：

• 某个字段在应用默认填充性能时，其值将依赖 apiserver 中 defaulting 值进行变动。
• 如果新增字段被用于计算 container hash，将引发容器重建危险。

思考与解决

后面介绍了多版本 apiserver 穿插拜访的问题，接下来咱们如何解此问题。

解决这个问题的实质是管控 Update/patch 两种操作的流量，说到这里可能有人会有疑难，通过多版本 apiserver 获取 resource 岂不是也有字段不同的问题？如果有，那么 get/watch 流量也须要管控。

这里有个前置事实须要讲一下，降级 apiserver 之前会存在多个版本的客户端，这些客户端有些能看到字段变动有些看不到，然而降级前是他们是一个稳固状态。高版本客户端看不到新增字段时也能够稳固运行，对新增字段带来的新个性并没有很强的依赖，对于低版本客户端压根儿看不到新增字段更不关怀新个性。咱们外围指标是保障降级过程中没有字段篡改的问题来躲避降级过程中同一 resource 视图频繁切换，带来的不可控的管控行为。

蚂蚁 Sigma 曾经落地管控层面的 Service Mesh 能力，那么在降级过程中利用弱小的 mesh 能力来做精细化流量管控，躲避了穿插拜访的问题咱们降级过程中的光明地带也会变得越来越窄，心里会虚浮很多。

etcd 数据存储更新

Kubernetes 中的数据存储有一套本人残缺的实践，这里咱们先简略介绍下 Kubernetes 中一个资源从申请进入到存入 etcd 的几次变换，之后再具体介绍降级过程中可能遇到的问题及咱们的思考。

Kubernetes 资源版本转换

• apiserver 中的资源版本

Kubernetes 中的 resource 都会有一个 internal version，因为在整个迭代过程中一个 resource 可能会对应多个 version，比方 deployment 会有 extensions/v1beta1，apps/v1。

为了避免出现问题，kube-apiserver 必须要晓得如何在每一对版本之间进行转换（例如，v1⇔v1alpha1，v1⇔v1beta1，v1beta1⇔v1alpha1），因而其应用了一个非凡的 internal version，internal version 作为一个通用的 version 会蕴含所有 version 的字段，它具备所有 version 的性能。Decoder 会首先把 creater object 转换到 internal version，而后将其转换为 storage version，storage version 是在 etcd 中存储时的另一个 version。

• apiserver request 解决

一次 request 申请在 apiserver 中的流转：

、、、Go
http filter chain | => | http handler

auth ⇒ sentinel ⇒ apf => conversion ⇒ admit ⇒ storage
、、、

一个资源读取 / 存储的过程如下：

数据存储兼容性

本文将偏重解说 Kubernetes 中 API resource 存储的数据在降级过程中如何保障兼容性的。次要答复以下两个问题：

问题一：Kubernetes 中存储在 etcd 中的 API resource 长什么样？

Kubernetes 中的 resource 都会有一个 internal version，这个 internal version 只用作在 apiserver 内存中数据处理和流转，并且这个 Internal version 对应的数据是以后 apiserver 反对的多个 GV 的选集，例如 1.16 中反对 apps/v1beta1 和 apps/v1 版本的 deployments。

然而存储到 etcd 时，apiserver 要先将这个 internal 版本转换为 storage 版本 storage 版本怎么确定的呢？

如下，分为两种状况：

• core resource
  存储版本在 apiserver 初始化时确定，针对某个 GroupVersion 分两步确定其存储版本：

(1)确定与本 GV 应用同一存储版本 group resource —> StorageFactory 中动态定义的 overrides

(2)在 group 中抉择优先级最高的 version 作为存储版本 —> Schema 注册时依照动态定义程序获取

• custom resource
  自定义 CR 的存储版本确定在 CRD 的配置中
  （详见：CRD 配置) https://kubernetes.io/zh/docs…

问题二：不同版本的 Kubernetes 中 如何做到存储数据兼容？

storage version 在 Kubernetes 版本迭代更新中不是变化无穷的，也会一直的更新。首先咱们看一个 Kubernetes 中的存储版本的降级规定：给定 API 组的“storage version（存储版本）”在既反对老版本也反对新版本的 Kubernetes 公布 版本进去以前不能够晋升其版本号。

这条规定换句话说，当某个 Kubernetes 版本中某个 resource 的 storage version 有变动时，此版本的 Kubernetes 肯定是同时反对新旧两个 storage version 的。如此加上 Schema 中多个 version 之间的转换能力，就能轻松做到版本的降级和降级了。

对于降级或者降级，apiserver 能够动静的辨认以后 etcd 中存储的是什么版本的数据，并将其转换为 Internal 版本，而后写入到 etcd 时再转换为以后降级后的最新的 Storage Version 进行存入。

思考与解决

从上文能够看到，apiserver 具备动静转换存储版本的的能力，然而要对旧版本的数据进行一次读写操作。动静转换的能力也不是有限的，在某个 Kubernetes 版本中转换的版本是以后版本兼容反对的几个版本。

假如某个 resource 数据在 etcd 中始终没有读取，此时 Kubernetes 的版本曾经升了好几个版本，并且 apiserver 曾经不再兼容 etcd 中的版本，当读取到此数据时就会报错，首先这条数据是无奈再拜访到了，重大的可能导致 apiserver crash。

因而咱们须要在版本升级过程中保障把 etcd 中的数据都转换为最新版本。很天然的，大家会想到通过本人实现一个转换器来解决这个问题，思路没有问题，但这会给人一种反复造轮子的感觉，因为 apiserver 在各个版本中曾经有了转换器的能力，咱们只须要把原生的转换能力利用好就行，每次降级后用 apiserver 原有存储数据转换能力把数据做一下更新，这样能够轻松躲避屡次版本升级后数据残留或不兼容问题。不要小看这个动作，很容易被疏忽，能够设想一下在本来就缓和的降级过程中忽然呈现 apiserver crash 的诡异景象，这个时候心田肯定是解体的。

降级可回滚

提到降级大家天然地会想到回滚，Kubernetes 集群的降级相似业务利用的迭代公布，如果过程呈现问题怎么办，最疾速的止血形式就回退版本。

一个单体的应用服务很容易做到版本回退，但对于数据中心操作系统的回滚没有那么容易，其问题波及到很多方面，这里咱们认为以下几个问题是 Kubernetes 降级回滚中遇到的常见的辣手问题：

• API 不兼容，导致回退后组件调用失败
• etcd 中数据存储不兼容问题

API 不兼容

API 兼容性问题后面曾经具体讲述了 API 变动的几种类型，这里再提下次要为 API 接口的变动和 Schema 的字段变动。

对于 API 接口的变动问题并不大，起因是降级前所有控制器与客户端与低版本的 apiserver 曾经达到一个稳固的状态，也就是说 API 接口是可用的，所以回退后问题不大。然而通常在降级到高的 apiserver 版本后会有一些新的 GVK 呈现，如一些 Alpha 的能力呈现或者 Beta 版本的 GV 变成了 GA 版本。

一个实在的例子：1.16 到 1.18 降级过程中新增了 v1beta1.discovery.k8s.io 这个 GV，这种状况下低版本的 apiserver 是不辨认新版的 GV 的，apiserver 回滚后尽管能失常启动，然而在执行波及到这个 GV 的操作时就会出问题，比方删除一个 namespace 时会删除这个 ns 下所有的资源，将遍历所有的 GV，此时会呈现卡壳 ns 删不掉的景象。

另外一个是 Schema 的变动，对于回滚其实能够看成另外一种降级，从高版本“降级”到低版本，这个过程遇到的问题与低版本“降级”到高版本是统一的，即高下版本客户端拜访篡改问题和多版本 apiserver 并存穿插拜访问题，然而客户端问题在回滚过程中并不存在，因为高版本的客户端向下是兼容的。对于穿插拜访的问题，穿插拜访的问题同样会利用精细化流量管制做躲避。

etcd 数据存储不兼容

数据存储问题在降级过程中遇到，在回滚过程中同样遇到，其外围在当一个 resource 的存储版本在高版本的 apiserver 中产生了变动，并且新的存储 GV 在低版本的 apiserver 中不辨认，导致回退后通过旧版本的 apiserver 获取对应资源时产生谬误，这个谬误就是产生在 Storagte Version 到 Internel Version 转换过程中。

一个例子：在 1.16 中 csinodes 的存储版本为 v1beta1，到 1.18 中升级成了 v1 版本，如果从 1.18 间接回退到 1.16，csinode 这个资源获取会出错，起因是 1.16 的 apiserver 中压根儿没有这个 v1 版本的 csinode。

讲到这里可能会有人问，为什么要跨版本升级呢？

上述这个问题如果是从 1.16 到 1.17 再到 1.18 一一版本升级就不会呈现了，这个想法十分好，但对于蚂蚁 Sigma Kubernetes 这种体量来讲频繁的降级难度较大，这也是咱们做此事的原生能源，将降级变得更自动化、效率更高，当这个指标实现后此问题也就不复存在了，在以后阶段回退存储版本不兼容问题依然辣手。

思考与解决

降级自身就是一次引入泛滥变量的操作，咱们尽量做到在变动中找到一条能把控的路子，最根本的方法论就是控制变量，所以对于 API 兼容性问题，咱们外围的准则为：新个性没有必要开启的先进性压抑，保障可回滚。

压抑的次要指标有两个：

• 高版本 apiserver 中新增的 GVK
  保障它们在降级的这个版本中不会呈现
• etcd 中的数据的存储版本
  存储版本对用户是通明的，咱们也要保障压抑调整对用户也是无感的，调整和压抑的伎俩能够通过对 apiserver 代码做兼容性调整来实现。

对于其余兼容性问题，目前没有很好的计划解决，以后咱们的次要通过降级回滚 e2e 测试裸露问题，针对不兼容的问题做相应兼容性批改。

兼容性压抑的伎俩只存在于降级过程中，也是降级过程中长期景象。压抑调整的时候咱们须要充沛的考量是否会引入其余不可控问题，这个要具体看 GVK 本身的变动来定。当然，所有还要从实践回到实际，充沛的 e2e 测试也是须要的。有了实践和测试两把利刃的加持，我置信兼容性问题会迎刃而解。

以上是降级过程中遇到的三个辣手的问题，以及相干的解决思路，接下来介绍下降级后的保障工作。

PART. 4 降级后

大版本升级时无奈保障 100% 的客户端都降级到对应的最新版本。尽管降级前咱们会推动 Update 流量的客户端进行降级，然而可能做不到 100% 降级，更重要的，降级后可能也会呈现某个用户用低版本的客户端进行拜访。咱们冀望通过 webhook 可能防止降级后低版本客户端意外篡改 resource 字段，达到真正的降级无损的目标。

字段管控次要准则一句话总结：避免默认值变动的字段，被用户应用低版本客户端以 Update 的形式批改为新的 default 值。

字段管控

残留问题

字段管控的最大挑战是，如何精确的辨认出用户是否是无心篡改字段。判断用户是否无心篡改须要拿到两个要害信息：

• 用户原始申请内容
  用户原始申请内容是判断用户是否无心篡改的要害，如果原始申请中有某个字段的内容，阐明用户是明确要批改，此时不须要管控。
• 用户客户端版本信息
  否则，要看用户客户端版本是否低于以后集群版本，如果不低于集群版本阐明用户有此字段明确批改不须要管控，如果低于集群版本这个字段用户可能看不到就须要管控了。

那么问题来了，如何拿到这两个信息呢？先说用户原始申请内容，这个信息依照 Kubernetes 的能力，咱们无奈通过 webhook 或者其余插件机制很轻松的拿到申请内容，apiserver 调用 webhook 时的内容曾经是通过版本转换后的内容。

再说用户客户端版本信息，这个信息尽管能够从 apiserver 的监控中拿到，当然咱们为了与管控链路对接，并不是间接拉取的监控信息，而是在 apiserver 中做了信息补充。

思考与解决

解决此问题实质上是了解“用户原始用意”，可能辨认出哪些动作是无心的篡改哪些是真正的需要，此动作须要依赖以下两个信息：

• 用户原始申请信息
• 用户客户端版本信息

上述两个信息存在的获取和准确性问题是咱们后续的工作方向之一，以后咱们还没很好的方法。了解用户的用意并且是实时了解是十分艰难的，折中方法是定义一套规定，依照规定来辨认用户是否在应用低版本的客户端篡改一些外围字段，咱们宁肯误杀一千也不放过一个坏操作，因为造成业务容器的不合乎预期，意外行为很轻松就会带来一个 P 级故障。

PART. 5 晋升成果

以上的这些摸索在蚂蚁 Sigma 曾经实战，降级效率失去了很大的晋升，次要体现在以下几个方面：

• 降级过程不必再停机了，公布工夫缩短为 0，整个过程防止了大量 Pod 提早交付，平台用户甚至没有任何体感，即便降级过程中排查问题也能够从容地应答，让降级过程更宁静、更放松、更顺滑；
• 降级后期推动的客户端降级数量失去了大幅升高，数量缩小了 80%，整体降级推动工夫缩小了约 90%，缩小了 80% 的业务方人力投入，整个降级工作轻松了许多；
• 降级的过程实现了自动化推动，为了避免意外产生降级过程还能够随时实现人工染指，降级过程解放了 Sigma 研发和 SRE 的双手，能够端起咖啡看进度了；
• 降级过程实现流量精准化管制，针对集群上千个命名空间的流量依照规定实现了灰度测试，针对新版本实例进行几十次 BVT 测试，从两眼一抹黑到心中有底气的转变还是挺棒的。

PART. 6 将来之路

整体来讲，做好降级外围就是要做好兼容性这件事，同时也要把整个过程做的更自动化一些，观测性做的更好一些，接下来有几个方向的工作要持续进行：

1. 更精准

以后在管控的信息获取上还有缺失，在流量的管控上以后采纳 namespace 的维度来解决，这些都存在精度不够的问题。后面也提到过，咱们正在进行管控组件 Mesh 化能力建设，将来会有更灵便的细粒度流量管控和数据处理能力。同时，借助 Mesh 能力，实现管控组件降级过程中多版本流量灰度测试，对降级做到准确、可控。

2. 平台化

本文介绍的这些挑战和技术计划，其实都是降级过程中的一部分，整个过程蕴含了后期的客户端最小化降级、外围组件滚动降级和后续的管控，这个过程繁琐且易出错，咱们冀望把这些过程规范化、平台化，把相似差异化比对、流量管控、流量监控等的工具集成到平台中，让降级更不便。

3. 更高效

社区迭代速度十分快，以后的迭代速度是无奈跟上社区，咱们通过上述更智能、平台化的能力，晋升基础设施的降级速度。当然，降级的速度也与集群的架构有十分大的关系，后续蚂蚁会走向联邦集群的架构，在联邦架构下能够对特定的用户 API 做向前兼容和转换，由此能够极大地解耦客户端与 apiserver 的降级关系。

对于蚂蚁 Sigma 规模级别的 Kubernetes 集群来讲降级不是一件容易的事，Sigma 作为蚂蚁最外围的运行底座，咱们想做到通过技术手段让基础设施的迭代降级达到真正的无感、无损，让用户不再期待，让本人不再焦虑。面对 Kubernetes 这个硕大无朋要实现上述指标颇有挑战性，但这并不能阻止咱们摸索的步调。道长且阻，行则将至，作为寰球 Kubernetes 规模化建设头部的蚂蚁团体将持续向社区输入更稳固、更易用的技术，助力云原生成为技术驱动倒退的外围能源。

蚂蚁 Sigma 团队致力于规模化云原生调度平台的建设，为业务提供更快更好更稳的容器资源交付，近期咱们在集群稳定性、高性能方面也获得了显著的成绩，欢送大家互相交换。

「参考资料」

《Kubernetes API 策略》

《Kubernetes 1.16 版本介绍》

《Kubernetes 集群正确降级姿态》

求贤若渴：

蚂蚁团体 Kubernetes 集群调度零碎撑持了蚂蚁团体在线、实时业务的百万级容器资源调度, 向下层各类金融业务提供规范的容器服务及动静资源调度能力, 肩负蚂蚁团体资源老本优化的责任。咱们有业界规模最大 Kubernetes 集群，最深刻的云原生实际，最优良的调度技术。

欢送无意在 Kubernetes/ 云原生 / 容器 / 内核隔离混部 / 调度 / 集群治理深耕的同学退出，北京、上海、杭州期待大家的退出。

分割邮箱: xiaoyun.maoxy@antgroup.com

本周举荐浏览

攀登规模化的顶峰 – 蚂蚁团体大规模 Sigma 集群 ApiServer 优化实际

蚂蚁团体万级规模 k8s 集群 etcd 高可用建设之路

蚂蚁大规模 Sigma 集群 Etcd 拆分实际

Service Mesh 在中国工商银行的摸索与实际