您可以通过容器服务管理控制台,可视化升级集群的K8s(Kubernetes)版本。您可以在集群列表页面查看集群的K8s版本,以及当前是否有新的版本可供升级。过期版本的集群存在运行不稳定和集群升级失败的风险,但是不影响已有业务的使用,建议您及时升级集群版本。本文介绍如何升级ACK集群K8s版本。

升级须知

升级说明

  • ACK保障最近的三个Kubernetes子版本的稳定运行,同时支持最新版本往前两个子版本的升级功能。例如当前最新版本为v1.24,则ACK支持v1.22和v1.20的升级功能。过期版本的集群存在运行不稳定和集群升级失败的风险,但是不影响已有业务的使用,建议您及时升级集群版本。关于容器服务ACK版本机制的更多信息,请参见版本机制
  • 集群升级过程中,集群上的应用不会中断。应用访问API Server可能会有短暂影响。
  • 集群升级前需要先执行升级前置检查,只有前置检查通过了才能进行集群升级。
  • ACK集群的Kubernetes版本升级只能一级一级的升级。例如低版本ACK集群的Kubernetes版本为v1.18,如果要升级到v1.24 Kubernetes版本,需进行三次手动升级,先升级到v1.20,然后升级到v1.22,最后升级到v1.24版本。
  • 集群升级策略定义了将使用怎样的策略对集群进行升级。目前默认策略为分批升级。分批升级会在升级Node阶段对集群内的节点进行分批升级。其具体策略为:
    • 根据节点池依次执行,同一时间点只有一个节点池进行升级。
    • 在同一个节点池内进行分批升级。第一批升级的节点数为1,后续的批次以2的幂数进行增长。如果暂停后重新恢复升级,依然遵循该分批策略。
    • 每一批节点的最大数量不会超过10。

注意事项

  • 集群升级需要使用yum下载升级所需的软件包,需要节点yum正常使用,比如可正常解析DNS,正常访问yum源地址。
  • 请勿在集群升级过程中添加或者删除节点,以及对集群进行其他操作。
  • 如果集群使用了自定义操作系统镜像,由于镜像非容器服务官方严格验证,我们将无法保证成功升级节点。
  • 如果您对Kubernetes集群有过任何的配置更改(例如打开了SWAP分区、黑屏操作修改kubelet配置),则升级过程有可能失败或者丢失自定义配置。
  • 在完成Kubernetes集群升级后,请您同步升级您本地的kubectl版本。安装kubectl,请参见安装kubectl。如果未及时升级,在使用本地kubectl的过程中可能会因为与集群API Server版本不同,发生类似invalid object doesn't have additional properties的报错。
  • Kubernetes 1.20及以后版本的集群升级前检查时,会检查当前版本是否使用了废弃API,详细内容,请参见废弃API说明
  • 如果集群水位过高,升级节点失败后存在Pod驱逐后无法被快速调度的风险,建议为节点预留部分资源(建议CPU不超过50%,内存不超过 70%)。

各版本特殊说明

  • 由于Kubernetes 1.24不再支持docker运行时,所以在集群升级到1.24之前,您需要通过节点池升级将节点的容器运行时docker轮转为containerd。相关信息,请参见将节点容器运行时从Docker迁移到Containerd。如您的集群为专有版,Master节点会在集群升级时自动将docker升级为containerd,升级时Master节点上所有的容器将会重建,如有自定义容器需要备份,请提前备份。
  • 由于Kubernetes 1.20版本的集群不支持selfLink字段,若您的集群使用FlexVolume存储插件且安装了alicloud-nas-controller组件,在将低版本集群升级至Kubernetes 1.20版本之前需要将alicloud-nas-controller的镜像升级到v1.14.8.17-7b898e5-aliyun或更高版本。
  • 在升级ACK集群的Kubernetes 1.16到1.18版本时,如果集群中的应用使用了云盘数据卷,且数据卷类型为Block Volume,请在升级前阅读CSI Block Volume升级说明
  • 在升级到Kubernetes v1.14之前,检查是否做了对应配置,排除访问LoadBalancer暴露出去的SLB地址不通的风险,请参见Kubernetes集群中访问LoadBalancer暴露的SLB地址不通
  • 由于老版本的FlexVolume(v1.11.2.5及以前)挂载的OSS卷在升级的时候会重新挂载,使用OSS卷的Pod在集群升级后需要重建。

升级原理

集群升级包括前置检查、控制平面升级和节点升级,下面介绍集群升级过程中的相关流程。

控制面升级流程

分类一:ACK托管版集群、ASK集群的控制面升级流程
  1. 升级控制面和托管组件,包括kube-apiserver、 kube-controller-manager和kube-scheduler等。
  2. 升级K8s组件,例如kube-proxy等。
分类二:ACK专有版集群的控制面升级流程
  1. (可选)依次升级Master节点上的ETCD和container runtime。
  2. 依次选择Master节点,一次只升级一个Master节点,并展示当前正在升级的Master节点的编号。
  3. 升级Master组件,包括kube-apiserver、 kube-controller-manager和kube-scheduler。
  4. 升级Master节点上的kubelet。
  5. 在所有Master节点升级完成后,升级K8s组件,例如kube-proxy等。

节点升级流程

集群中的Node会按照分批策略,对集群内的节点进行分批升级。具体策略如下。
  • 根据节点池依次执行,同一时间点只有一个节点池进行升级。
  • 在同一个节点池内进行分批升级。第一批升级的节点数为1,后续的批次以2的幂数进行增长。如果暂停后重新恢复升级,依然遵循该分批策略。
  • 每一批节点的最大数量不会超过10。

步骤一:升级前检查集群

说明 如果您在非生产环境中有待升级的集群,强烈建议您先对该集群进行升级验证,再在生产环境中启动集群升级。

请在集群升级前检查集群的健康状况,确保集群已具备升级条件。

  1. 登录容器服务管理控制台,在左侧导航栏中选择集群
  2. 集群列表页面中,选择目标集群,并在目标集群右侧的操作列下,选择更多 > 集群检查
  3. 容器智能运维左侧导航栏中,选择检查 > 升级检查
  4. 升级检查页面,单击执行升级检查
  5. 在弹出的升级检查页面,选中注意事项后,单击执行检查
    检查完成后,单击查看详情
    • 当检查报告中检查结果正常时,表示升级检查成功,您可以进行集群升级操作。
    • 当检查报告中检查结果异常时,请按界面提示进行修复。
      说明
      • 升级检查仅针对集群升级前进行的前置检查,即使不通过也不会影响当前集群的运行及集群状态。
      • Kubernetes 1.20及以后版本的集群升级前检查时,会检查当前版本是否使用了废弃API,检查结果不会影响升级流程,仅作为提示信息。详细内容,请参见废弃API说明

步骤二:升级集群

说明 当前集群显示可升级到新版本时,表示当前集群版本已停止维护,已有的业务不影响使用。建议您在业务低峰期时尽快升级集群版本。
  1. 登录容器服务管理控制台,在左侧导航栏中选择集群
  2. 集群列表页面,选择目标集群,并在目标集群右侧操作列下,选择更多 > 集群升级
  3. 单击升级
    说明 若单击前置检查,则如步骤一:升级前检查集群进行集群升级检查。
  4. 弹出升级提示页面,单击确定
    此时,您可以看到升级的全过程。
    说明
    • 如果在升级到某个阶段您需要暂停升级时,您可以通过单击暂停,暂停集群的升级进程。也可以在集群成功暂停之后,单击继续,恢复集群的升级进程。集群暂停状态为集群升级的中间状态,建议不要在此时对集群进行操作,并尽快完成升级过程。处于中间状态的集群会在7日之后关闭升级过程,同时清理一切升级相关的事件和日志信息。
    • 如果您需要取消集群升级,可以在暂停升级后,单击取消,取消对该集群的升级。取消升级之后,当前批次(分批策略)已经开始升级的节点会完成升级,还未开始升级的节点不会升级。取消升级后,已经完成的部分升级不会回滚,可继续重新做集群升级操作。
升级完成后,您可以在Kubernetes集群列表页面查看集群Kubernetes的版本,确认管控组件升级是否成功。并到节点管理 > 节点页面查看kubelet版本,确认节点升级是否成功。
说明
  • 如果集群升级过程中发生错误,集群升级进程会被系统暂停。具体失败原因会展示在页面下方详情中,您可根据提示进行修复。
  • 集群升级过程中,除非发生错误,否则请勿修改kube-upgrade命名空间下面的相关资源。
  • 如果集群升级失败,升级过程会暂停,需要分析失败原因并清理kube-upgrade命名空间下失败的Pod,确认修复成功后重启升级过程。

废弃API说明

Kubernetes 1.20及之后版本的集群升级前检查时,支持检查废弃API信息。在您检查结果的实例列表中可以看到集群使用的废弃API。

例如从Kubernetes 1.20版本升级至Kubernetes 1.22版本时,系统会扫描过去一天的审计日志,检查1.20版本集群中是否使用了废弃API。
  • 如果1.20版本集群中使用了废弃API,检查结果不会影响升级流程,仅作为提示信息。
  • 如果集群在1.22版本中继续使用废弃API,可能会有安全隐患。
废弃API根据请求来源(User Agent)分为以下四类,建议在升级前,通过以下表格中的类别判断废弃API的来源,对废弃API采取对应处理措施。
类别处理建议举例
coreKubernetes核心组件:ACK会在集群升级时由后台自动升级,检查页面不会展示,不需要用户进行升级。apiserver、scheduler、kube-controller-manager
ackACK组件:由ACK提供的组件,需要用户自行判断升级时机,ACK会展示并引导用户在组件管理页面升级组件。
说明
  • 您可以在容器服务管理控制台运维管理 > 组件管理页面升级组件,组件升级完成后,废弃API将不再显示。
  • 废弃API仅作为提示信息,不影响您的升级流程。集群升级后,会将已经废弃的API资源替换为新的资源。建议您在集群升级后不要使用废弃的API创建资源,避免造成安全隐患。
metrics-server、nginx-ingress-controller
OpenSource开源组件:社区的部分开源组件,ACK会展示清单,但用户需要自行判断是否升级,自行完成升级。如果有遗漏,会显示在unknown分类中。
说明 废弃API仅作为提示信息,不影响您的升级流程。请您按需对组件进行升级,避免影响部分功能。
rancher、elasticsearch-operator等
unknown未知来源:以上规则均无法匹配时,会标记为未知来源,ACK会展示清单,但用户需要自行判断是否升级,自行完成升级。
说明 废弃API仅作为提示信息,不影响您的升级流程。请您按需对组件进行升级,避免影响部分功能。
kubectl、agent、Go-http-client、okhttp
页面示例:3

常见集群升级失败问题

问题现象一

专有版集群Master节点升级超时。

问题原因一

Admission Webhook组件自签发的服务端证书未包含必要的SAN字段,导致Master组件启动失败。

解决方案一

通过以下命令查看Webhook使用的自签发证书是否具备SAN字段。下述命令需要在已配置kubectl的集群节点中执行。

  1. 执行如下命令,查看集群中所有的Admission Webhook。
    kubectl get mutatingwebhookconfigurations
    预期输出:
    NAME                                      WEBHOOKS   AGE
    ack-node-local-dns-admission-controller   1          27h
  2. 执行如下命令,查看对应Webhook配置的Service。
    kubectl get mutatingwebhookconfigurations ack-node-local-dns-admission-controller -oyaml | grep service -A 5
        service:
          name: ack-node-local-dns-admission-controller
          namespace: kube-system
          path: /inject
          port: 443
      failurePolicy: Ignore
  3. 执行如下命令,查找Service的ClusterIP。
    kubectl -n kube-system get service ack-node-local-dns-admission-controller
    预期输出:
    NAME                                      TYPE        CLUSTER-IP        EXTERNAL-IP   PORT(S)   AGE
    ack-node-local-dns-admission-controller   ClusterIP   192.168.XX.XX   <none>        443/TCP   27h
  4. 执行如下命令,通过ClusterIP访问Webhook获取证书,确保存在Subject Alternative Name字段。
    openssl s_client -connect 192.168.XX.XX:443 -showcerts </dev/null 2>/dev/null|openssl x509 -noout -text
    98

问题现象二

专有版集群ETCD升级失败。

问题原因二

云助手不可用。

解决方案二

云助手不可用,导致升级命令下发失败。请升级云助手后,重新执行集群升级操作。升级云助手,请参见升级或禁止升级云助手客户端

问题现象三

节点PLEG not healthy。

解决方案三

容器或者容器运行时无响应,您需要重启节点后重新执行升级。