云容器引擎（CCE）嚴格遵循社區一致性認證。為了能夠方便您使用穩定又可靠的Kubernetes版本，請您務必在維護周期結束之前升級您的Kubernetes集群。
CCE在發布Kubernetes最新版本后，會對該版本所做的變更進行說明。
您可以通過云容器引擎管理控制臺，可視化升級集群的Kubernetes版本。
升級前，您需要在集群列表頁面確認集群的Kubernetes版本，以及當前是否有新的版本可供升級。
確認方法如下：
登錄CCE控制臺，查看待升級集群左下角是否存在“存在更新版本”提示，若存在則該集群支持升級，若不存在，則該集群不支持升級。
集群-可升級
集群升級路徑
如下表格詳細介紹了各集群版本能夠升級到的目標版本，以及升級方式和升級影響。
集群升級路徑和影響說明
| 源版本 | 目標版本 | 升級方式 | 升級影響 |
|---|---|---|---|
| v1.19 | v1.21 | 原地升級 | 需用戶自行識別各版本差異，詳情請參見大版本升級須知。 |
| v1.17v1.15 | v1.19 | 原地升級 | 需用戶自行識別各版本差異，詳情請參見大版本升級須知。 |
| v1.13 | v1.15 | 滾動升級重置升級 | coredns配置中proxy配置項不支持，需要替換成forward。 存儲插件從原來的storage-driver替換成了Everest。 |
| v1.11v1.9 | Console中可創建的最新版本 | 手動遷移 | 需用戶自行識別各版本差異，詳情請參見大版本升級須知。 |
| v1.9.2v1.7 | Console中可創建的最新版本 | 手動遷移 | 需用戶自行識別各版本差異，詳情請參見大版本升級須知。 |
升級方式
在集群升級過程中，Master節點的升級流程都是一致的，而Node節點的升級流程存在區別，不同升級方式的優缺點如下：
升級方式的區別和優缺點
| 升級名稱 | 方式 | 優點 | 缺點 |
|---|---|---|---|
| 原地升級 | 節點上升級Kubernetes組件、網絡組件和CCE管理組件，升級過程中業務Pod和網絡均不受影響； 升級過程中，存量節點將全部打上SchedulingDisabled標簽，升級完成后，用戶能夠正常使用存量節點。 |
用戶無需遷移業務，可以基本上保證業務不斷。 | 原地升級不會升級節點的操作系統，如果希望升級操作系統，可以在節點升級完成后，清空對應的節點數據，并執行節點重置，升級到新版本的操作系統。 |
| 滾動升級 | 節點上只升級Kubernetes組件以及網絡部分組件，存量節點將全部打上SchedulingDisabled標簽，僅保證原本運行的應用不受影響。 須知 升級完成后，用戶還需手動新建節點，并逐步釋放老節點** ，將應用逐步遷移到新節點上，用戶控制升級步驟。 |
可以基本上保證業務不斷。 | **升級完成后，用戶需手動新建節點，并逐步釋放老節點，將業務遷移至新節點。**該過程中，新建節點會存在額外的費用。待業務遷移至新節點后，老節點可以刪除。 滾動升級完成后，如果需要繼續向高版本升級，需要先完成老節點的重置，否則無法通過升級前檢查。該過程可能會引起業務中斷。 |
| 重置升級 | 對工作節點使用最新的node鏡像進行操作系統重置。 | 時間最短，用戶介入操作也較少。 | 如果節點上有數據或者配置，會丟失，同樣會有一段時間業務受損。 |
大版本升級須知
大版本升級路徑 版本差異 建議自檢措施 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。正常升級流程不會觸發此場景。
在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"
??????]
}根因：Go語言v1.15版本廢棄了X.509
