升级集群的流程和方法
云容器引擎(CCE)严格遵循社区一致性认证,每年发布3个Kubernetes版本,每个版本发布后提供至少24个月的维护周期,CCE保证维护周期内的Kubernetes版本的稳定运行。
为了保障您的服务权益,请您务必在维护周期结束之前升级您的Kubernetes集群,您可在集群列表页面确认集群的Kubernetes版本,以及当前是否有新的版本可供升级。主动升级集群有以下好处:
- 降低安全和稳定性风险:Kubernetes版本迭代过程中,会不断修复发现的安全及稳定性漏洞,长久使用EOS版本集群会给业务带来安全和稳定性风险。
- 支持新功能和新操作系统:Kubernetes版本的迭代过程中,会不断带来新的功能、优化。您可通过CCE集群版本发布说明查看最新版本的特性说明。
- 避免大跨度兼容风险:Kubernetes版本的迭代过程中,会不断带来API变更与功能废弃。长久未升级的集群,在需要升级时需要更大的运维保障投入。周期性的跟随升级能有效缓解版本差异累积导致的兼容性风险。建议用户每季度升级一次补丁版本,每年升级一次大版本至当前支持的最新版本。
- 更加有效的技术支持:对于EOS的Kubernetes版本集群,CCE不再提供安全补丁和问题修复,同样无法保证EOS版本集群的技术支持质量。
集群升级路径
CCE 集群基于社区Kubernetes版本迭代演进,版本号由社区Kubernetes版本和CCE补丁版本两部分构成,因此提供两类集群升级路径。
- Kubernetes版本升级:
Kubernetes版本号
支持升级到的Kubernetes版本号
v1.13及以下
不支持
v1.15
v1.19
v1.17
v1.19
v1.19
v1.21、v1.23
v1.21
v1.23、v1.25
v1.23
v1.25、v1.27、v1.28
v1.25
v1.27、v1.28
v1.27
v1.28
v1.28
v1.29
v1.29
v1.30
- 当前Kubernetes版本的维护情况请参见CCE集群版本生命周期表。
- 已停止维护的版本无法一步直接升级到最新版本,需要进行连续多次升级,例如v1.15 -> v1.19 -> v1.23 -> v1.27/v1.28。
- 补丁版本需要升级至最新补丁后方可进行Kubernetes版本升级,控制台将根据当前集群版本自动为您生成最佳升级路径。
- 补丁版本升级
1.19及以上版本的CCE集群采取了补丁版本管理策略,旨在不进行大版本升级的情况下,为在维集群提供新的特性、Bugfix和漏洞修复。
新的补丁版本发布以后您可在任意补丁版本一次直升到最新补丁版本,补丁版本发布记录请参见补丁版本发布记录。
集群升级流程
集群升级流程包括升级前检查、备份、升级和升级后验证几个步骤,下面介绍集群升级过程中的相关流程。
在确定集群的目标版本后,请您仔细阅读升级注意事项,避免升级时出现功能不兼容的问题。
- 升级前检查
升级集群前,CCE会对您的集群进行必要的检查,包括集群状态、插件状态、节点状态、工作负载兼容性等多方面进行检查,确保集群满足升级的条件,检查项目请参考升级前检查项。如果出现检查异常项,请参考控制台中的提示进行修复。
- 备份
通过硬盘快照的方式帮您备份集群控制节点,以保存CCE组件镜像、组件配置、Etcd数据等关键数据。建议您在升级前进行备份。如果在升级过程中出现不可预期的情况,可以基于备份为您快速恢复集群。
备份方式
备份对象
备份方式
备份时间
回滚时间
说明
etcd数据备份
etcd数据
升级流程中自动备份
1-5min
2h
必选备份,升级过程中自动进行,用户无需关注
CBR整机备份
Master节点磁盘,包括组件镜像、配置、日志以及etcd数据
通过页面一键备份(手动触发)
20min-2h(受当前区域云备份任务排队情况影响)
20min
该功能逐步由EVS快照备份替代
EVS快照备份
Master节点磁盘,包括组件镜像、配置、日志以及etcd数据
通过页面一键备份(手动触发)
1-5min
20min
该功能上线中
对于已上线的区域,EVS快照备份将替代CBR整机备份
- 配置与升级
执行升级前,需要对升级参数进行配置,我们已为您提供了默认配置,您也可以根据需要进行配置,升级参数配置完成后,将进入正式升级流程,对插件、控制节点、用户节点依次进行升级。
- 插件升级配置:此处列出了您的集群中已安装的插件。在集群升级过程中系统会自动升级已选择的插件,以兼容升级后的集群版本,您可以单击插件右侧的“配置”重新定义插件参数。
插件右侧如有标记,表示当前插件不能同时兼容集群升级起始和目标版本,在集群版本升级完成后将为您升级该插件 ,该插件在集群升级过程中可能无法正常使用。
- 节点升级配置
- 每批最大升级节点数:您可以设置每批升级的最大节点数量。
升级时节点池之间会依次进行升级。节点池内的节点分批升级,第一批升级1个节点,第二批升级2个节点,后续每批升级节点数以2的幂数增加,直到达到您设置的每批最大升级节点数,并会持续作用在下一个节点池中。默认每批最大升级节点数为20,最高可配置为60。
- 节点优先级配置:您可以自行定义节点升级的优先级顺序。如不设置该优先级,系统将根据默认策略生成优先级顺序执行升级。
- 添加节点池优先级:自定义节点池升级的优先级顺序。如不设置,默认策略为节点数量少的节点池优先升级。
- 添加节点优先级:自定义节点池内节点升级的优先级顺序。如不设置,默认策略为负载较轻(根据节点Pod数量、节点资源请求率、节点PV数量等维度计算负载情况)的节点优先升级。
- 节点升级批次应用范围:您可以自定义选择,默认为集群。
- 节点升级批次配置应用到整个集群,整个升级过程不重置升级批次。
- 节点升级批次配置应用范围为节点池,升级到每个节点池重置升级批次。
- 每批最大升级节点数:您可以设置每批升级的最大节点数量。
- 插件升级配置:此处列出了您的集群中已安装的插件。在集群升级过程中系统会自动升级已选择的插件,以兼容升级后的集群版本,您可以单击插件右侧的“配置”重新定义插件参数。
- 升级后验证
升级完成后,会自动为集群执行集群状态检查、节点状态检查等,您需要手动进行业务验证、新建节点验证、新建Pod验证等,确保升级后集群功能正常。详情请参见升级后验证。
升级方式
升级方式 |
介绍 |
升级范围 |
优点 |
约束 |
---|---|---|---|---|
原地升级 |
节点上升级Kubernetes组件、网络组件和CCE管理组件,升级过程中业务Pod和网络均不受影响。 升级过程中,节点分批进行升级,存量节点将不可调度,升级完成的批次支持调度新业务。 |
|
可一键式升级,用户无需迁移业务,可以基本上保证业务不断。 |
原地升级仅在v1.15及以上版本集群支持。 |
迁移 |
将老版本集群的业务迁移到新版本集群,适用于需要大幅度跨版本集群升级的需求。 |
集群内资源均重新部署。 |
可避免老版本连续升级导致的版本不兼容问题。 |
- |