检查项内容
请您阅读版本兼容性差异，并确认不受影响。
补丁升级不涉及版本兼容性差异。
版本兼容性差异
大版本升级路径 版本差异 建议自检措施 v1.19升级至v1.21或v1.23 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及域名。
1.21及以上版本不支持管理ARM节点。 确认升级后无法管理ARM节点不影响您的使用场景。 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。正常升级流程不会触发此场景。
在Master升级完成后尽量避免使用暂停升级功能，快速升级完Node节点。
若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。 升级后请按需开放非安全系统配置。 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台节点。
