作者 | 高相林（禅鸣）
导读： 集群降级是 Kubernetes 集群生命周期中最为重要的一环，也是泛滥使用者最为审慎看待的操作之一。为了更好地了解集群降级这件事件的外延内涵，咱们首先会对集群降级的必要性和难点进行论述；随后会对集群降级前必须要做的前置查看进行逐个解说；接下来会对两种常见的降级形式进行开展介绍；最初对集群降级的三个步骤进行解说，帮忙读者从实践走入实际。
降级的必要性 & 难点
在 Kubernetes 畛域，得益于沉闷的开源社区，Kubernetes 的迭代速度较快，目前放弃在每个季度发行一个新版本的节奏。新版本的 Kubernetes 有着更为先进的新个性、更加全面的平安加固和破绽修复。前一段时间社区刚刚实现了 1.19 版本的正式公布。
对于倒退如此疾速的开源我的项目，跟上社区的步调就显得更为重要，而集群降级能力就是帮忙咱们跟上社区步调的不二抉择。咱们能够从以下两个方面对集群降级的必要性进行阐明：
- 对于 Kubernetes 集群的使用者 ：更新的 Kubernetes 版本意味着更新的 feature，更加全面的安全补丁，和诸多的 bugfix。咱们能够通过集群降级性能充沛享受沉闷的 Kubernetes 开源社区带来的倒退红利；
- 对于 Kubernetes 集群的运维者 ：通过集群降级性能能够拉齐所治理的集群版本，缩小集群版本的碎片化，从而缩小 Kubernetes 版本碎片化带来的治理老本和保护老本。
讲完了集群降级的必要性，咱们来具体看一下集群降级的难点。
目前少数 Kubernetes 使用者对集群降级这件事持有着十分激进的态度，胆怯集群在降级的过程中呈现不可预期的状况，也有使用者将集群降级称之为“给航行中的飞机换引擎”。那么，使用者对于降级的激进态度次要来源于什么起因呢？我认为有以下几点：
- 通过长时间的运行后，Kubernetes 集群曾经累计了简单的运行时状态；
- Kubernetes 集群运维者会依据集群承载的不同业务，对集群进行不同的配置，从而导致每个集群都有本人的差异化配置，可能会造成“千集群千面”；
- 对于云上运行的 Kubernetes 集群来说，其应用了大量的云计算底层资源。泛滥的底层云资源就会带来泛滥的不确定性因素。
“千集群千面”的状况的存在，导致了集群降级须要以一套逻辑实现各种不同状况集群的降级工作，这也正是集群降级的艰难之处。
降级预检
正如咱们后面所说，给正在对外提供服务的 Kubernetes 集群降级，就好比是“给航行中的飞机换引擎”。因为集群降级面临着泛滥难点，也使得泛滥的 Kubernetes 集群维护者对集群降级这件事件比拟缓和。
咱们能够通过具体的降级预检，来打消集群降级的不确定性。对于下面列举的集群降级的难点，咱们也能够别离进行具体的降级预检，隔靴搔痒，将难点逐个击破。降级预检次要能够分为三个方面：
- 外围组件健康检查
- 节点配置查看
- 云资源查看
1. 外围组件健康检查
说到外围组件健康检查，就不得不分析一下集群的衰弱对于集群降级的重要性。一个不衰弱的集群很可能会在降级中呈现各种异样的问题，就算幸运实现了降级，各种问题也会在后续应用中逐步凸显进去。
有人会说，我的集群看起来挺衰弱的，然而降级之后就呈现问题了。一般来说，之所以会产生这种状况，是因为在集群在降级之前，这个问题曾经存在了，只不过是在经验了集群降级之后才显现出来。
在理解了外围组件健康检查的必要性之后，咱们来看一下都须要对那些组件进行查看：
- 网络组件：须要确保网络组件版本和须要降级到的指标 Kubernetes 版本兼容；
- apiservice：须要确保集群内的 apiservice 都可用；
- 节点：须要确定节点全副衰弱。
2. 节点配置查看
节点作为承载 Kubernetes 的底层元计算资源，不仅运行着 Kubelet、Docker 等重要的零碎过程，也充当着集群和底层硬件交互接口的角色。
确保节点的衰弱性和配置的正确性是确保整个集群衰弱性重要的一环。上面就对所需的查看项进行解说。
- 操作系统配置：须要确定根底的零碎组件（yum、systemd 和 ntp 等零碎服务是否失常）和内核参数是否配置正当；
- kubelet：须要确定 kubelet 的过程衰弱、配置正确；
- Docker：须要确定 Docker 的过程衰弱、配置正确。
3. 云资源查看
运行在云上的 Kubernetes 集群依赖着泛滥云资源，一旦集群所依赖的云资源不衰弱或者配置谬误，就会影响到整个集群的失常运行。咱们次要对下列云资源的状态和配置进行预检：
- apiserver 所应用的 SLB：须要确定实例的衰弱状态和端口配置（转发配置和访问控制配置等）；
- 集群所应用的 VPC 和 VSwitch：须要确定实例的健康状况；
- 集群内的 ECS 实例：须要确定其健康状况和网络配置。
两种常见的降级形式
在软件降级畛域，有两种支流的软件降级形式，即原地降级和替换降级。这两种降级形式同样实用于 Kubernetes 集群，它们采纳了不同软件降级思路，但也都存在着各自的利弊。上面咱们来对这两种集群降级形式进行逐个解说。
1. 原地降级
原地降级是一种精细化的、对这个那个集群改变量绝对较小的一种降级形式。在降级容器的 worker 节点时，该降级形式会通过在 ECS 上原地替换 Kubernetes 组件的形式（次要为 kubelet 和其相干组件），实现整个集群的降级工作。阿里云容器服务 Kubernetes 为客户提供的集群降级就是基于这种形式的。
以将 Kubernetes 的版本从 1.14 降级到 1.16 为例。首先咱们会对 ECS A 上的本来为 1.14 的 Kubelet 及其配置降级为 1.16，在实现节点 ECS A 上的组件降级之后，该节点也就被胜利的降级到了 1.16。而后咱们再对 ECS B 进行雷同的操作，将其降级为 1.16，从而实现整个集群的降级工作。
在这个过程中节点放弃运行，ECS 的相干配置也不会被批改。如图所示：
1）长处
- 原地降级通过原地替换 kubelet 组件的形式对节点进行版本升级，从而保障了节点上的 Pod 不会因为集群降级而重建，确保了业务的连贯性；
- 该种降级形式不会对底层 ECS 自身进行批改和替换，保障了依赖特定节点调度的业务能够失常运行，也对 ECS 的包年包月客户更加敌对。
2）毛病
- 原地降级形式须要在节点上进行一系列降级操作，能力实现整个节点的降级工作，这就导致整个降级过程不够原子化，可能会在两头的某一步骤失败，从而导致该节点降级失败；
- 原地降级的另一个毛病是须要预留一定量的资源，只有在资源足够的状况下降级程序能力在 ECS 上实现对节点的降级。
2. 替换降级
替换降级又称轮转降级，绝对于原地降级，替换降级是一种更加粗狂和原子化的降级形式。替换降级会一一将旧版本的节点从集群中移除，并用新版本全新的节点来替换，从而实现整个 Kubernetes 集群的降级工作。
同样以将 Kubernetes 的版本从 1.14 降级到 1.16 为例。应用代替轮转形式的状况下，咱们会将集群中 1.14 版本的节点顺次进行排水并从集群中移除，并间接退出 1.16 版本的节点。行将 1.14 节点的 ECS A 从节点剔除，并将 1.16 节点的 ECS C 退出集群，再将 ECS B 从集群中删除，最初将 ECS D 退出到集群中。
这样就实现了所有节点的轮转工作，整个集群就也就降级到 1.16 了。如图所示：
1）长处
代替降级通过将旧版本的节点替换为新版本的节点从而实现集群降级。这个替换的过程相较于原地降级更为原子化，也不存在那么简单的中间状态，所以也不须要在降级之前进行太多的前置查看。绝对应地，降级过程中可能会呈现的各种稀奇古怪的问题也会缩小很多。
2）毛病
- 代替降级将集群内的节点全副进行替换和重置，所有节点都会经验排水的过程，这就会使集群内的 pod 进行大量迁徙重建，对于 pod 重建容忍度比拟低的业务、只有单正本的利用、stateful set 等相干利用不够敌对，可能会因而产生不可用或者故障；
- 所有的节点经验重置，贮存在节点本地磁盘上的数据都会失落；
- 这种降级形式可能会带来宿主机 IP 变动等问题，对包年包月用户也不够敌对。
集群降级三部曲
一个 Kubernetes 集群次要由负责集群管控的 master，执行工作负载的 worker 和泛滥功能性的零碎组件组成。对一个 Kubernetes 集群降级，也就是对集群中的这三个局部进行别离降级。
故集群降级的三部曲为：
- 滚动降级 master
- 分批降级 worker
- 零碎组件降级（次要为 CoreDNS，kube-proxy 等外围组件）
上面咱们来对集群降级三部曲进行具体的解说。
1. 滚动降级 master
master 作为集群的大脑，承当了与使用者交互、任务调度和各种功能性的工作解决。集群 master 的部署形式也比拟多样，能够通过 static pod 进行部署，能够通过本地过程进行部署，也能够通过 Kubernetes on Kubernetes 的形式在另一个集群内通过 pod 的形式部署。
总而言之，无论 master 为哪种部署形式，想要降级 master 次要就是对 master 中的三大件进行版本升级，次要包含：
- 降级 kube-apiserver
- 降级 kube-controller-manager
- 降级 kube-scheduler
须要留神，为了保障 Kubernetes apiserver 的可用性不中断，master 中的 kube-apiserver 起码须要有两个，这样才能够实现滚动降级，从而保障 apiserver 不会呈现 downtime。
2. 分批降级 worker
在实现 master 的降级工作之后，咱们才能够开始对 worker 进行降级。Worker 降级次要是对节点上的 kubelet 及其依赖组件（如 cni 等）进行降级。为了保障集群中 worker 不会同时产生大批量的 kubelet 重启，所以咱们须要对 worker 节点进行分批降级。
须要留神，咱们必须要先降级 master，再降级 worker。因为高版本的 kubelet 在连贯低版本的 master 时，很可能会呈现不兼容的状况，从而导致节点 not ready。对于低版本的 kubelet 连贯高版本的 apiserver，开源社区保障了 apiserver 对于 kubelet 两个版本的向后兼容性，即 1.14 的 kubelet 能够连贯到 1.16 的 apiserver，而不会产生兼容性问题。
3. 外围零碎组件降级
为了保障集群中各个组件的兼容性，咱们须要在降级集群的同时对集群中的外围零碎组件进行同步降级，次要包含：
- Dns 组件 ：依据社区的版本兼容矩阵，将 CoreDNS 的版本升级为与集群版本绝对应的版本；
社区的版本兼容矩阵：https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md
- 网络转发组件 ：Kube-proxy 的版本是追随 Kubernetes 的版本进行演进的，所有咱们须要将 kube-proxy 的版本升级到与 Kubernetes 版本雷同的版本。
课程举荐
去年，CNCF 与 阿里云联结公布了《云原生技术公开课》曾经成为了 Kubernetes 开发者的一门“必修课”。
明天，阿里云再次集结多位具备丰盛云原生实践经验的技术专家，正式推出《云原生技术实际公开课》。课程内容由浅入深，专一解说“落地实际”。还为学习者打造了实在、可操作的试验场景，不便验证学习成绩，也为之后的实际利用打下坚实基础。点击链接查看课程：https://developer.aliyun.com/learning/roadmap/cloudnative2020
“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术畛域、聚焦云原生风行技术趋势、云原生大规模的落地实际，做最懂云原生开发者的公众号。”