当某个集群版本支持升级能力后，您可以随时进行升级操作。
您可以在CCE控制台中确认您的集群是否可以进行升级操作，确认方法：单击“资源管理 > 集群管理”，查看待升级集群右上角是否存在“可升级”提示，若存在则该集群支持升级，若不存在，则该集群不支持升级。
- 当前仅支持虚拟机节点的CCE集群升级。
- 集群升级时若需要升级CoreDNS插件，请确保节点数大于等于CoreDNS的实例数，且CoreDNS的所有实例都处于运行状态，否则将导致升级失败。1.13版本的集群若需升级到更高版本，需先将CoreDNS插件升级当前集群可用的最新版本。
- 1.13版本内升级时，集群上的应用只会在升级网络组件时有短暂中断。
如下表格详细介绍了各集群版本能够升级到的目标版本，以及升级方式和升级影响。
表1 集群升级路径和影响说明
源版本 | 目标版本 | 升级方式 | 升级影响 |
v1.15 | v1.17 | 滚动升级 重置升级 |
|
v1.13 | v1.15 | 滚动升级 重置升级 |
|
集群升级页面会根据集群版本以及不同局点提供三种升级方式，三种方式的控制节点升级流程是一致的，用户节点的升级方式区别及优缺点如下：
表2 升级方式的区别和优缺点
升级名称 | 方式 | 优点 | 缺点 |
滚动升级 | 节点上只升级Kubernetes组件以及网络部分组件，存量节点将全部打上SchedulingDisabled标签，仅保证原本运行的应用不受影响，升级完成后，用户还需手动新建节点，并逐步释放老节点，将应用逐步迁移到新节点上，用户控制升级步骤。 | 可以基本上保证业务不断。 | |
重置升级 | 对用户节点使用最新的node镜像进行操作系统重置。 | 时间最短，用户介入操作也较少。 | 如果节点上有数据或者配置，会丢失，同样会有一段时间业务受损。 |
平滑升级 | 采取传统软件升级方式，在用户节点按组件逐个进行升级，您可以通过提交工单申请开启。 | 用户介入的操作较少，等同于一键式升级。 | 跨版本由于OS会升级，节点会重启，会有一段时间业务受损。 |
须知：从1.15版本开始使用滚动升级达成不断服的升级能力，平滑升级的场景后续将由滚动升级覆盖。
表3 集群跨大版本升级说明
升级前版本 | 目标版本 | 说明 |
| v1.15 | v1.17 | 支持在Console中将v1.15升级到v1.17。 社区v1.15与v1.17版本之间的CHANGELOG v1.16到v1.17的变化： https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.17.md v1.15到v1.16的变化： https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.16.md 在CCE所创的集群中，Kubernetes v1.15.11版本是Flexvolume插件（storage-driver）被CSI插件（Everest）兼容接管的过渡版本，v1.17及之后版本的集群中将彻底去除对Flexvolume插件的支持，请您将Flexvolume插件的使用切换到CSI插件上。 |
v1.13 | v1.15 | 暂不支持在Console中将v1.13升级到v1.15，您可以通过提交工单申请升级。 集群升级到新版本后，不支持回退到老版本。 社区v1.13与v1.15版本之间的CHANGELOG v1.14到v1.15的变化： https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.15.md v1.13到v1.14的变化： https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.14.md v1.13.11-r1升级到v1.15.11-r1版本的集群后，原v1.13的fuxi Flexvolume（即storage-driver插件）容器存储由v1.15的CSI（即Everest插件，插件版本v1.1.6及以上）接管，原有功能保持不变，但请注意不要新建fuxi Flexvolume的存储，否则将导致部分存储功能异常。 |
