升级前,您可以在CCE控制台确认您的集群是否可以进行升级操作。确认方法请参见集群升级概述。
注意事项
- 集群升级操作不可回退,请务必慎重并选择合适的时间段进行升级,以减少升级对您的业务带来的影响。
- 集群升级前请参考集群大版本发布说明了解每个集群版本发布的特性以及差异,否则可能因为应用不兼容新集群版本而导致升级后异常。
- 集群升级中 请勿关机、重启或删除节点 ,否则会导致升级失败。
- 集群升级前 请关闭弹性扩缩容策略 ,避免在升级过程中扩缩容节点,从而导致升级失败。
- 如果您本地修改了集群节点的配置,可能导致集群升级失败或升级后配置丢失,建议您通过集群的配置管理和节点池的配置管理修改配置,以便在升级时自动继承。
- 集群升级过程中,已运行工作负载业务不会中断,但API Server访问会短暂中断,如果业务需要访问API Server可能会受到影响。
- 请在升级集群前,请查看集群状态是否均为健康状态。若集群不正常,您可以自行修复,若仍有问题请提交工单联系我们协助您进行修复。
- 为了您的数据安全,强烈建议您先备份数据然后再升级,升级过程中不建议对集群进行任何操作。
- 集群升级过程中,将会给节点打上“node.kubernetes.io/upgrade”(效果为“NoSchedule”)的污点,并在集群升级完成后移除该污点。请您不要在节点上手动添加相同键名的污点,即使污点效果不同,也可能会在升级后被系统误删除。
约束与限制
- 当前仅支持虚拟机节点的CCE集群升级,暂不支持鲲鹏集群、CCE Turbo集群、使用私有镜像的CCE集群升级。
- 集群升级后,如版本特性中修复了容器引擎Containerd相关漏洞,存量节点需要手动重启Containerd才可以生效,对于存量Pod同样需要通过重启Pod才能生效。
- 1.15版本集群原地升级,如果业务中存在initContainer或使用Istio的场景,则需要注意以下约束:
1.16及以上的kubelet统计QosClass和之前版本存在差异,1.15及以下版本仅统计spec.containers下的容器,1.16及以上的kubelet版本会同时统计spec.containers和spec.initContainers下的容器,升级前后会造成Pod的QosClass变化,从而造成Pod中容器重启。建议参考下表在升级前修改业务容器的QosClass规避该问题。
升级前后QosClass变化
init容器(根据spec.initContainers计算) | 业务容器(根据spec.containers计算) | Pod(根据spec.containers和spec.initContainers计算) | 是否受影响 |
---|---|---|---|
Guaranteed | Besteffort | Burstable | 是 |
Guaranteed | Burstable | Burstable | 否 |
Guaranteed | Guaranteed | Guaranteed | 否 |
Besteffort | Besteffort | Besteffort | 否 |
Besteffort | Burstable | Burstable | 否 |
Besteffort | Guaranteed | Burstable | 是 |
Burstable | Besteffort | Burstable | 是 |
Burstable | Burstable | Burstable | 否 |
Burstable | Guaranteed | Burstable | 是 |
升级备份说明
目前集群升级备份方式有两种:
- 集群ETCD数据库备份 :CCE服务会在集群升级流程中对etcd数据库进行备份,无需用户确认。
- Master节点整机备份 :在升级界面对集群的Master节点进行整机备份, 需要用户手动确认 ,备份过程会使用云备份服务,备份通常耗时在20分钟左右,若当前局点云备份任务排队较多时,备份时间可能同步延长,推荐用户使用进行整机备份。