檢查項內容

請您閱讀版本兼容性差異，并確認不受影響。

補丁升級不涉及版本兼容性差異。

版本兼容性差異

大版本升級路徑
版本差異
建議自檢措施
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 ，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臺節點。