更新时间:2024-01-26 GMT+08:00

兼容性风险检查

检查项内容

请您阅读版本兼容性差异,并确认不受影响。补丁升级不涉及版本兼容性差异。

版本兼容性差异

版本升级路径

版本差异

建议自检措施

v1.23升级至v1.25

在Kubernetes v1.25版本中, PodSecurityPolicy已被移除,并提供Pod安全性准入控制器(Pod Security Admission配置)作为PodSecurityPolicy的替代。

  • 如果您需要将PodSecurityPolicy的相关能力迁移到Pod Security Admission中,需要参照以下步骤进行:
    1. 确认集群为CCE v1.23的最新版本。
    2. 迁移PodSecurityPolicy的相关能力迁移到Pod Security Admission,请参见从PodSecurityPolicy迁移到Pod Security Admission
    3. 确认迁移后功能正常,再升级为CCE v1.25版本。
  • 如果您不再使用PodSecurityPolicy能力,则可以在删除集群中的PodSecurityPolicy后,直接升级为CCE v1.25版本。

v1.21升级至v1.23

社区较老版本的Nginx Ingress Controller来说(社区版本v0.49及以下,对应CCE插件版本v1.x.x),在创建Ingress时没有指定Ingress类别为nginx,即annotations中未添加kubernetes.io/ingress.class: nginx的情况,也可以被Nginx Ingress Controller纳管。但对于较新版本的Nginx Ingress Controller来说(社区版本v1.0.0及以上,对应CCE插件版本2.x.x),如果在创建Ingress时没有显示指定Ingress类别为nginx,该资源将被Nginx Ingress Controller忽略,Ingress规则失效,导致服务中断。

请参照nginx-ingress插件升级检查进行自检。

v1.19升级至v1.23

v1.19升级至v1.21

Kubernetes v1.21集群版本修复 了exec probe timeouts不生效的BUG,在此修复之前,exec 探测器不考虑 timeoutSeconds 字段。相反,探测将无限期运行,甚至超过其配置的截止日期,直到返回结果。 若用户未配置,默认值为1秒。升级后此字段生效,如果探测时间超过1秒,可能会导致应用健康检查失败并频繁重启。

升级前检查您使用了exec probe的应用的probe timeouts是否合理。

CCE的v1.19及以上版本的kube-apiserver要求客户侧webhook server的证书必须配置Subject Alternative Names (SAN)字段。否则升级后kube-apiserver调用webhook server失败,容器无法正常启动。

根因:Go语言v1.15版本废弃了X.509 CommonName,CCE的v1.19版本的kube-apiserver编译的版本为v1.15,若客户的webhook证书没有Subject Alternative Names (SAN),kube-apiserver不再默认将X509证书的CommonName字段作为hostname处理,最终导致认证失败。

升级前检查您自建webhook server的证书是否配置了SAN字段。

  • 若无自建webhook server则不涉及。
  • 若未配置,建议您配置使用SAN字段指定证书支持的IP及域名。

v1.15升级至v1.19

CCE v1.19版本的控制面与v1.15版本的Kubelet存在兼容性问题。若Master节点升级成功后,节点升级失败或待升级节点发生重启,则节点有极大概率为NotReady状态。

主要原因为升级失败的节点有大概率重启kubelet而触发节点注册流程,v1.15 kubelet默认注册标签(failure-domain.beta.kubernetes.io/is-baremetal和kubernetes.io/availablezone)被v1.19版本kube-apiserver视为非法标签。

v1.19版本中对应的合法标签为node.kubernetes.io/baremetal和failure-domain.beta.kubernetes.io/zone。

  1. 正常升级流程不会触发此场景。
  2. 在Master升级完成后尽量避免使用暂停升级功能,快速升级完Node节点。
  3. 若Node节点升级失败且无法修复,请尽快驱逐此节点上的应用,请联系技术支持人员,跳过此节点升级,在整体升级完毕后,重置该节点。

CCE的v1.15版本集群及v1.19版本集群将docker的存储驱动文件系统由 xfs切换成ext4,可能会导致升级后的java应用Pod内的import包顺序异常,既而导致Pod异常。

升级前查看节点上docker配置文件/etc/docker/daemon.json。检查dm.fs配置项是否为xfs。

  • 若为ext4或存储驱动为overlay则不涉及。
  • 若为xfs则建议您在新版本集群预先部署应用,以测试应用与新版本集群是否兼容。
{
      "storage-driver": "devicemapper",
      "storage-opts": [
      "dm.thinpooldev=/dev/mapper/vgpaas-thinpool",
      "dm.use_deferred_removal=true",
      "dm.fs=xfs",
      "dm.use_deferred_deletion=true"
      ]
}

CCE的v1.19及以上版本的kube-apiserver要求客户侧webhook server的证书必须配置Subject Alternative Names (SAN)字段。否则升级后kube-apiserver调用webhook server失败,容器无法正常启动。

根因:Go语言v1.15版本废弃了X.509 CommonName,CCE的v1.19版本的kube-apiserver编译的版本为v1.15。CommonName字段作为hostname处理,最终导致认证失败。

升级前检查您自建webhook server的证书是否配置了SAN字段。

  • 若无自建webhook server则不涉及。
  • 若未配置,建议您配置使用SAN字段指定证书支持的IP及域名。
须知:

为减弱此版本差异对集群升级的影响,v1.15升级至v1.19时,CCE会进行特殊处理,仍然会兼容支持证书不带SAN。但后续升级不再特殊处理,请尽快整改证书,以避免影响后续升级。

v1.17.17版本及以后的集群CCE自动给用户创建了PSP规则,限制了不安全配置的Pod的创建,如securityContext配置了sysctl的net.core.somaxconn的Pod。

升级后请参考资料按需开放非安全系统配置,具体请参见PodSecurityPolicy配置

1.15版本集群原地升级,如果业务中存在initContainer或使用Istio的场景,则需要注意以下约束:

1.16及以上的kubelet统计QosClass和之前版本存在差异,1.15及以下版本仅统计spec.containers下的容器,1.16及以上的kubelet版本会同时统计spec.containers和spec.initContainers下的容器,升级前后会造成Pod的QosClass变化,从而造成Pod中容器重启。

建议参考表4在升级前修改业务容器的QosClass规避该问题。

v1.13升级至v1.15

vpc集群升级后,由于网络组件的升级,master节点会额外占一个网段。在Master占用了网段后,无可用容器网段时,新建节点无法分配到网段,调度在该节点的pod会无法运行。

一般集群内节点数量快占满容器网段场景下会出现该问题。例如,容器网段为10.0.0.0/16,可用IP数量为65536,VPC网络IP分配是分配固定大小的网段(使用掩码实现,确定每个节点最多分配多少容器IP),例如上限为128,则此时集群最多支撑65536/128=512个节点,然后去掉Master节点数量为509,此时是1.13集群支持的节点数。集群升级后,在此基础上3台Master节点会各占用1个网段,最终结果就是506台节点。