更新时间:2022-05-19 GMT+08:00
分享

集群升级概述

云容器引擎(CCE)严格遵循社区一致性认证。为了能够方便您使用稳定又可靠的Kubernetes版本,请您务必在维护周期结束之前升级您的Kubernetes集群。

CCE在发布Kubernetes最新版本后,会对该版本所做的变更进行说明。详情请参见Kubernetes版本发布说明

您可以通过云容器引擎管理控制台,可视化升级集群的Kubernetes版本。

升级前,您需要在集群列表页面确认集群的Kubernetes版本,以及当前是否有新的版本可供升级。

确认方法如下:

单击“资源管理 > 集群管理”,查看待升级集群右上角是否存在“可升级”提示,若存在则该集群支持升级,若不存在,则该集群不支持升级。
图1 集群-可升级

集群升级路径

如下表格详细介绍了各集群版本能够升级到的目标版本,以及升级方式和升级影响。

表1 集群升级路径和影响说明

源版本

目标版本

升级方式

升级影响

v1.17

v1.15

v1.19

原地升级

需用户自行识别各版本差异。

v1.13

v1.15

滚动升级

重置升级

  • coredns配置中proxy配置项不支持,需要替换成forward。
  • 存储插件从原来的storage-driver替换成了Everest。

v1.11

v1.9

1.15

重置升级

  • 由于集群签名证书机制变更,所以会导致原本集群证书失效,请在升级完集群后重新获取证书或者kubeconfig文件。
  • v1.13版本的Kubernetes默认开启RBAC,需要应用适配RBAC。
  • v1.9版本的集群升级到v1.15后,集群中kube-dns会替换成CoreDNS,升级前需要自行备份kube-dns配置,升级后需要重新在coredns中配置。

v1.9

v1.7

Console中可创建的最新版本

迁移

需用户自行识别各版本差异。

升级方式

集群升级页面会根据集群版本以及不同局点提供升级方式,Master节点升级流程是一致的,Node节点的升级方式区别及优缺点如下:

表2 升级方式的区别和优缺点

升级名称

方式

优点

缺点

原地升级

节点上升级Kubernetes组件、网络组件和CCE管理组件,升级过程中业务Pod和网络均不受影响;升级过程中,存量节点将全部打上SchedulingDisabled标签,升级完成后,用户能够正常使用存量节点。

用户无需迁移业务,可以基本上保证业务不断。

原地升级不会升级节点的操作系统,如果希望升级操作系统,可以在节点升级完成后,清空对应的节点,并执行节点重置,升级到新版本的操作系统。

滚动升级

节点上只升级Kubernetes组件以及网络部分组件,存量节点将全部打上SchedulingDisabled标签,仅保证原本运行的应用不受影响,升级完成后,用户还需手动新建节点,并逐步释放老节点,将应用逐步迁移到新节点上,用户控制升级步骤。

可以基本上保证业务不断。

-

重置升级

对工作节点使用最新的node镜像进行操作系统重置。

时间最短,用户介入操作也较少。

如果节点上有数据或者配置,会丢失,同样会有一段时间业务受损。

大版本升级说明

表3 集群版本差异说明

升级前版本

目标版本

说明

v1.17

v1.19

v1.15

v1.17

v1.13

v1.15

v1.11

v1.13

v1.9

v1.11

v1.7

v1.9

分享:

    相关文档

    相关产品

close