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

升级前须知

升级前,您可以在CCE控制台确认您的集群是否可以进行升级操作。确认方法请参见集群升级概述

注意事项

  • 集群升级操作不可回退,请务必慎重并选择合适的时间段进行升级,以减少升级对您的业务带来的影响。
  • 集群升级前请参考Kubernetes版本发布说明了解每个集群版本发布的特性以及差异,否则可能因为应用不兼容新集群版本而导致升级后异常。
  • 集群升级中请勿关机或重启节点,否则会导致升级失败。
  • 集群升级前请关闭弹性扩缩容策略,避免在升级过程中扩缩容节点,从而导致升级失败。
  • 如果您本地修改了集群节点的配置,可能导致集群升级失败或升级后配置丢失,建议您通过集群的配置管理和节点池的配置管理修改配置,以便在升级时自动继承。
  • 集群升级过程中,已运行工作负载业务不会中断,但API Server访问会短暂中断,如果业务需要访问API Server可能会受到影响。
  • 请在升级集群前,请查看集群状态是否均为健康状态。若集群不正常,您可以自行修复,若仍有问题请提交工单联系我们协助您进行修复。
  • 为了您的数据安全,强烈建议您先备份数据然后再升级,升级过程中不建议对集群进行任何操作。
  • 1.17及以上版本不再支持通过AOM服务进行负载的弹性伸缩,升级前后请根据AOM弹性伸缩切换至HPA/CustomHPA说明进行弹性伸缩策略的切换。

约束与限制

  • 当前仅支持虚拟机节点的CCE集群升级,暂不支持鲲鹏集群、CCE Turbo集群、使用私有镜像的CCE集群升级。
  • 1.15版本集群原地升级,如果业务中存在initContainer或使用Istio的场景,则需要注意以下约束:

    1.16及以上的kubelet统计QosClass和之前版本存在差异,1.15及以下版本仅统计spec.containers下的容器,1.16及以上的kubelet版本会同时统计spec.containers和spec.initContainers下的容器,升级前后会造成Pod的QosClass变化,从而造成Pod中容器重启。建议参考表1在升级前修改业务容器的QosClass规避该问题。

    表1 升级前后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

升级前检查

请在集群升级前检查集群和节点的健康状况,确保集群和节点正常可用。

检查方式一:控制台查看

在CCE控制台,单击左侧栏目树的“资源管理”,分别单击“集群管理”“节点管理”,查看集群和节点的状态是否正常。

检查方式二:Kubectl命令查看

  1. 执行如下命令,确保集群的所有模块都处于健康状态。

    kubectl get cs

    命令行终端显示如下信息:
     NAME                 STATUS    MESSAGE              ERROR
     scheduler            Healthy   ok
     controller-manager   Healthy   ok
     etcd-0               Healthy   {"health": "true"}
     etcd-1               Healthy   {"health": "true"}
     etcd-2               Healthy   {"health": "true"}

    回显中所有Status必须为Healthy,不能包含其他状态。

  2. 执行如下命令,确保所有节点都处于Ready状态。

    kubectl get nodes

    所有节点只能Ready状态,不能包含其他状态。

     NAME                   STATUS    ROLES     AGE       VERSION
     xxx.xxx.xx.xx   Ready     <none>    38d       v1.9.7-r1
     xxx.xxx.xx.xx   Ready     <none>    38d       v1.9.7-r1
     xxx.xxx.xx.xx   Ready     <none>    38d       v1.9.7-r1

升级前排查项

在集群升级前,请根据如下Checklist进行排查,以便提前发现风险和问题。

表2 集群升级排查项

类别

检查项

集群

确认当前集群的Node IP(包括EIP),是否有作为其他的配置或者白名单等。

执行升级前预检查功能。

工作负载

记录工作负载的数量、工作负载状态,便于升级后对比。

针对您使用的数据库(例如云专线、Redis、Mongdb等),要提前考虑白名单、路由或安全组策略变化等问题。

存储

记录存储状态,保证升级后存储不丢失。

网络

检查使用的负载均衡服务、Ingress,并做好备份。

针对使用云专线的业务场景,需重点关注业务所在的节点或实例IP是否会因为升级而发生变化,若有变化需提前在云专线开通路由。

插件

社区Kubernetes 1.9版本升级1.11版本时,集群的kube-dns会被卸载并替换为CoreDNS,请备份您配置在kube-dns中的DNS地址,以便在域名解析异常时重新在CoreDNS中进行配置。

运维

私有配置:在升级前的集群中检查是否在节点或容器中放置了数据面密码、证书、环境变量等配置,当容器重启(例如节点异常重新调度pod),会导致配置丢失,业务异常。

检查并备份内核参数或者系统配置。

升级备份说明

目前集群升级备份方式有两种:

  • 集群ETCD数据库备份:CCE服务会在集群升级流程中对etcd数据库进行备份,无需用户确认。
  • Master节点整机备份:在升级界面对集群的Master节点进行整机备份,需要用户手动确认,备份过程会使用云备份服务,备份通常耗时在20分钟左右,若当前局点云备份任务排队较多时,备份时间可能同步延长,推荐用户使用进行整机备份。
分享:

    相关文档

    相关产品

close