12.1 升级预检

大家把为正在对外提供服务的Kubernetes集群升级比作“给飞行中的飞机换引擎”,所以升级的难度可想而知。

升级难度主要源自两点:一是集群经过长时间的运行,积累了复杂的运行时状态;二是集群已经被进行了各种个性化配置。这两点都会带来升级流程中难以处理的情况,从而导致升级失败。

这就需要我们在升级集群之前对集群进行全面的检查,从而保证升级可以顺利完成。下面我们就以阿里云容器服务Kubernetes集群升级预检为例,对预检的各个检查项进行详细的介绍。

集群升级预检功能目前被放置在运维中心里。如图12-1所示,运维中心支持集群升级前置检查、组件升级前置检查和集群检查三种检查类型。本章主要对集群升级前置检查进行介绍与解析。

图12-1 运维中心的组成

12.1.1 核心组件检查项

说到集群健康检查,就不得不剖析一下集群的健康对于集群升级的重要性。一个不健康的集群很可能会在升级中出现各种异常的问题,就算侥幸完成了升级,各种问题也会在后续使用中逐渐凸显出来。

也有的用户会说,我的集群看起来挺健康的,但是升级之后就出现问题了。一般来说,之所以会发生这种情况,是因为在集群在升级之前这个问题已经存在了,只不过是在经历了集群升级之后才显现出来。

了解了在升级前对集群做健康检查的重要性之后,我们来对前置检查的各个检查项进行分类讲解。我们将核心组件检查项分为三类,分别是云资源检查,核心组件检查以及节点配置检查。

1.集群云资源

容器服务Kubernetes需要依赖阿里云底层的各种资源,集群所依赖的云资源一旦不健康,或发生配置错误,都会影响整个集群的状态。

下面就我们需要检查的云资源、它们所包含的检查项,以及检查项异常可能带来的影响进行分析,具体分析如表12-1所示。

表12-1

2.集群核心组件

集群核心组件的健康与否影响着整个集群的健康。下面我们就所需要检查的组件、它们所包含的检查项,以及检查项异常可能带来的影响进行分析,具体分析如表12-2所示。

表12-2

续表

3.集群节点配置

节点作为承载Kubernetes的底层元计算资源,不仅运行着Kubelet、Docker等重要的系统进程,也充当着集群和底层硬件交互接口的角色。

确保节点的健康性和配置的正确性是确保整个集群健康性的重要一环。下面我们就所需要检查的节点组件、它们所包含的检查项,以及检查项异常可能带来的影响进行分析,具体分析如表12-3所示。

表12-3

12.1.2 前置检查增项

1.节点水位检查

目前容器服务Kubernetes的集群升级方式为原地升级。这种升级方式可以保证整个集群“平滑”升级,但相应也要为集群升级预留一定的资源,以保证集群的顺利升级。

具体的资源检查项主要有剩余可运行Pod数量、磁盘剩余容量、可用句柄数、进程数,以及可用内存。

对于剩余的可运行Pod数量,我们需要确保集群至少可以创建一个新Pod,用于运行升级CRD Controller的组件,且被升级的节点至少可以运行一个Pod用于节点升级;对于系统磁盘剩余容量,至少要有1GB的剩余空间用于存储升级临时文件;对于可用句柄数和进程数,要求有10%余量可用;对于内存,至少需要200MB用于升级。

2.升级依赖资源检查

目前容器服务Kubernetes在升级集群的过程中,除了对管控面板和节点进行升级之外,也会升级集群中的kube-proxy和CoreDNS系统组件。所以在升级之前,我们也需要对kube-proxy和CoreDNS的相关配置进行检查,防止升级后发生错误。

3.废弃资源与不兼容项检查

Kubernetes的不同版本之间可能存在着资源废弃与不兼容的情况,我们需要在升级集群之前对这些检查点进行逐一检查,并进行相应的处理。这里以升级到1.16版和升级到1.18版为例说明。

升级到1.16版之前需要对CoreDNS所使用的Corefile进行检查,并将Corefile迁移到CoreDNS 1.6版所支持的版本中。这是因为,Kubernetes社区推荐的Kubernetes 1.16版所对应的CoreDNS为1.6版。与之前版本的CoreDNS相比,其主要的配置变化为将默认的转发插件从proxy切换到了forward组件,并从镜像中移除了proxy插件。这就导致如果我们不提前修改Corefile的话,在我们升级完Kubernetes与CoreDNS之后,CoreDNS会因为无法识别Corefile中的proxy插件而导致程序崩溃。

升级到1.18版之前需要对集群和本地工作流水线中的工作负载进行检查,需要确保所有工作负载都不再使用extensions/v1beta1、apps/v1beta1和apps/v1beta2这三个APIVersion。因为这三个APIVersion会在1.18版中被彻底删除,所以位于apps/v1beta1和apps/v1beta1下的资源使用apps/v1替代,位于extensions/v1beta1下的资源daemonsets、deployments、replicasets使用apps/v1替代,位于extensions/v1beta1下的资源networkpolicies使用networking.k8s.io/v1替代。