作者 | 高相林（禪鳴）

**導讀：**叢集升級是 Kubernetes叢集生命週期中最為重要的一環，也是眾多使用者最為謹慎對待的操作之一。為了更好地理解叢集升級這件事情的內涵外延，我們首先會對叢集升級的必要性和難點進行闡述；隨後會對叢集升級前必須要做的前置檢查進行逐一講解；接下來會對兩種常見的升級方式進行展開介紹；最後對叢集升級的三個步驟進行講解，幫助讀者從理論走入實踐。

升級的必要性&難點

在 Kubernetes 領域，得益於活躍的開源社群，Kubernetes 的迭代速度較快，目前保持在每個季度發行一個新版本的節奏。新版本的 Kubernetes 有著更為先進的新特性、更加全面的安全加固和漏洞修復。前一段時間社群剛剛完成了 1.19 版本的正式釋出。

對於發展如此快速的開源專案，跟上社群的步伐就顯得更為重要，而叢集升級能力就是幫助我們跟上社群步伐的不二選擇。我們可以從以下兩個方面對叢集升級的必要性進行說明：

• 對於 Kubernetes 叢集的使用者：更新的 Kubernetes 版本意味著更新的 feature，更加全面的安全補丁，和諸多的 bugfix。我們可以通過叢集升級功能充分享受活躍的 Kubernetes 開源社群帶來的發展紅利；

• 對於 Kubernetes 叢集的運維者：通過叢集升級功能可以拉齊所管理的叢集版本，減少叢集版本的碎片化，從而減少 Kubernetes 版本碎片化帶來的管理成本和維護成本。

講完了叢集升級的必要性，我們來詳細看一下叢集升級的難點。

目前多數 Kubernetes 使用者對叢集升級這件事持有著非常保守的態度，害怕叢集在升級的過程中出現不可預期的情況，也有使用者將叢集升級稱之為“給飛行中的飛機換引擎”。那麼，使用者對於升級的保守態度主要來源於什麼原因呢？我認為有以下幾點：

• 經過長時間的執行後，Kubernetes 叢集已經累計了複雜的執行時狀態；

• Kubernetes 叢集運維者會根據叢集承載的不同業務，對叢集進行不同的配置，從而導致每個叢集都有自己的差異化配置，可能會造成“千叢集千面”；

• 對於雲上執行的 Kubernetes 叢集來說，其使用了大量的雲端計算底層資源。眾多的底層雲資源就會帶來眾多的不確定性因素。

“千叢集千面”的情況的存在，導致了叢集升級需要以一套邏輯完成各種不同情況叢集的升級工作，這也正是叢集升級的困難之處。

升級預檢

正如我們前面所說，給正在對外提供服務的 Kubernetes 叢集升級，就好比是“給飛行中的飛機換引擎”。因為叢集升級面臨著眾多難點，也使得眾多的 Kubernetes 叢集維護者對叢集升級這件事情比較緊張。

我們可以通過詳細的升級預檢，來消除叢集升級的不確定性。對於上面列舉的叢集升級的難點，我們也可以分別進行詳細的升級預檢，對症下藥，將難點逐一擊破。升級預檢主要可以分為三個方面：

• 核心元件健康檢查
• 節點配置檢查
• 雲資源檢查

1. 核心元件健康檢查

說到核心元件健康檢查，就不得不剖析一下叢集的健康對於叢集升級的重要性。一個不健康的叢集很可能會在升級中出現各種異常的問題，就算僥倖完成了升級，各種問題也會在後續使用中逐漸凸顯出來。

有人會說，我的叢集看起來挺健康的，但是升級之後就出現問題了。一般來說，之所以會發生這種情況，是因為在叢集在升級之前，這個問題已經存在了，只不過是在經歷了叢集升級之後才顯現出來。

在瞭解了核心元件健康檢查的必要性之後，我們來看一下都需要對那些元件進行檢查：

• 網路元件：需要確保網路元件版本和需要升級到的目標 Kubernetes 版本相容；
• apiservice：需要確保叢集內的 apiservice 都可用；
• 節點：需要確定節點全部健康。

2. 節點配置檢查

節點作為承載 Kubernetes 的底層元計算資源，不僅執行著 Kubelet、Docker 等重要的系統程序，也充當著叢集和底層硬體互動介面的角色。

確保節點的健康性和配置的正確性是確保整個叢集健康性重要的一環。下面就對所需的檢查項進行講解。

• 作業系統配置：需要確定基礎的系統元件（yum、systemd 和 ntp 等系統服務是否正常）和核心引數是否配置合理；
• kubelet：需要確定 kubelet 的程序健康、配置正確；
• Docker：需要確定 Docker 的程序健康、配置正確。

3. 雲資源檢查

執行在雲上的 Kubernetes 叢集依賴著眾多雲資源，一旦叢集所依賴的雲資源不健康或者配置錯誤，就會影響到整個叢集的正常執行。我們主要對下列雲資源的狀態和配置進行預檢：

• apiserver 所使用的 SLB：需要確定例項的健康狀態和埠配置（轉發配置和訪問控制配置等）；
• 叢集所使用的 VPC 和 VSwitch：需要確定例項的健康狀況；
• 叢集內的 ECS 例項：需要確定其健康狀況和網路配置。

兩種常見的升級方式

在軟體升級領域，有兩種主流的軟體升級方式，即原地升級和替換升級。這兩種升級方式同樣適用於 Kubernetes 叢集，它們採用了不同軟體升級思路，但也都存在著各自的利弊。下面我們來對這兩種叢集升級方式進行逐一講解。

1. 原地升級

原地升級是一種精細化的、對這個那個叢集改動量相對較小的一種升級方式。在升級容器的 worker 節點時，該升級方式會通過在 ECS 上原地替換 Kubernetes 元件的方式（主要為 kubelet 和其相關元件），完成整個叢集的升級工作。阿里雲容器服務 Kubernetes 為客戶提供的叢集升級就是基於這種方式的。

以將 Kubernetes 的版本從 1.14 升級到 1.16 為例。首先我們會對 ECS A 上的原本為 1.14 的 Kubelet 及其配置升級為 1.16，在完成節點 ECS A 上的元件升級之後，該節點也就被成功的升級到了 1.16。然後我們再對 ECS B 進行相同的操作，將其升級為 1.16，從而完成整個叢集的升級工作。

在這個過程中節點保持執行，ECS 的相關配置也不會被修改。如圖所示：

1）優點

• 原地升級通過原地替換 kubelet 元件的方式對節點進行版本升級，從而保證了節點上的 Pod 不會因為叢集升級而重建，確保了業務的連貫性；

• 該種升級方式不會對底層 ECS 本身進行修改和替換，保證了依賴特定節點排程的業務可以正常執行，也對 ECS 的包年包月客戶更加友好。

2）缺點

• 原地升級方式需要在節點上進行一系列升級操作，才能完成整個節點的升級工作，這就導致整個升級過程不夠原子化，可能會在中間的某一步驟失敗，從而導致該節點升級失敗；

• 原地升級的另一個缺點是需要預留一定量的資源，只有在資源足夠的情況下升級程式才能在 ECS 上完成對節點的升級。

2. 替換升級

替換升級又稱輪轉升級，相對於原地升級，替換升級是一種更加粗狂和原子化的升級方式。替換升級會逐個將舊版本的節點從叢集中移除，並用新版本全新的節點來替換，從而完成整個 Kubernetes 叢集的升級工作。

同樣以將 Kubernetes 的版本從 1.14 升級到 1.16 為例。使用替代輪轉方式的情況下，我們會將叢集中 1.14 版本的節點依次進行排水並從叢集中移除，並直接加入 1.16 版本的節點。即將 1.14 節點的 ECS A 從節點剔除，並將 1.16 節點的 ECS C 加入叢集，再將 ECS B 從叢集中刪除，最後將 ECS D 加入到叢集中。

這樣就完成了所有節點的輪轉工作，整個叢集就也就升級到 1.16 了。如圖所示：

1）優點

替代升級通過將舊版本的節點替換為新版本的節點從而完成叢集升級。這個替換的過程相較於原地升級更為原子化，也不存在那麼複雜的中間狀態，所以也不需要在升級之前進行太多的前置檢查。相對應地，升級過程中可能會出現的各種稀奇古怪的問題也會減少很多。

2）缺點

• 替代升級將叢集內的節點全部進行替換和重置，所有節點都會經歷排水的過程，這就會使叢集內的 pod 進行大量遷移重建，對於 pod 重建容忍度比較低的業務、只有單副本的應用、stateful set 等相關應用不夠友好，可能會因此發生不可用或者故障；

• 所有的節點經歷重置，儲存在節點本地磁碟上的資料都會丟失；

• 這種升級方式可能會帶來宿主機 IP 變化等問題，對包年包月使用者也不夠友好。

叢集升級三部曲

一個 Kubernetes 叢集主要由負責叢集管控的 master，執行工作負載的 worker 和眾多功能性的系統元件組成。對一個 Kubernetes 叢集升級，也就是對叢集中的這三個部分進行分別升級。

故叢集升級的三部曲為：

• 滾動升級 master
• 分批升級 worker
• 系統元件升級（主要為 CoreDNS，kube-proxy 等核心元件）

下面我們來對叢集升級三部曲進行詳細的講解。

1. 滾動升級master

master 作為叢集的大腦，承擔了與使用者互動、任務排程和各種功能性的任務處理。叢集 master 的部署方式也比較多樣，可以通過 static pod 進行部署，可以通過本地程序進行部署，也可以通過 Kubernetes on Kubernetes 的方式在另一個叢集內通過 pod 的方式部署。

總而言之，無論 master 為哪種部署方式，想要升級 master 主要就是對 master 中的三大件進行版本升級，主要包括：

• 升級 kube-apiserver
• 升級 kube-controller-manager
• 升級 kube-scheduler

需要注意，為了保證 Kubernetes apiserver 的可用性不中斷，master 中的 kube-apiserver 最少需要有兩個，這樣才可以實現滾動升級，從而保證 apiserver 不會出現 downtime。

2. 分批升級 worker

在完成 master 的升級工作之後，我們才可以開始對 worker 進行升級。Worker 升級主要是對節點上的 kubelet 及其依賴元件（如 cni 等）進行升級。為了保證叢集中 worker 不會同時發生大批量的 kubelet 重啟，所以我們需要對 worker 節點進行分批升級。

需要注意，我們必須要先升級 master，再升級 worker。因為高版本的 kubelet 在連線低版本的 master 時，很可能會出現不相容的情況，從而導致節點 not ready。對於低版本的 kubelet 連線高版本的 apiserver，開源社群保證了 apiserver 對於 kubelet 兩個版本的向後相容性，即 1.14 的 kubelet 可以連線到 1.16 的 apiserver，而不會發生相容性問題。

3. 核心系統元件升級

為了保證叢集中各個元件的相容性，我們需要在升級叢集的同時對叢集中的核心繫統元件進行同步升級，主要包括：

• Dns 元件：根據社群的版本相容矩陣，將 CoreDNS 的版本升級為與叢集版本相對應的版本；

社群的版本相容矩陣：https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md

• 網路轉發元件：Kube-proxy 的版本是跟隨 Kubernetes 的版本進行演進的，所有我們需要將 kube-proxy 的版本升級到與 Kubernetes 版本相同的版本。

課程推薦

去年，CNCF 與 阿里雲聯合釋出了《雲原生技術公開課》已經成為了 Kubernetes 開發者的一門“必修課”。

今天，阿里雲再次集結多位具有豐富雲原生實踐經驗的技術專家，正式推出《雲原生技術實踐公開課》。課程內容由淺入深，專注講解“ 落地實踐”。還為學習者打造了真實、可操作的實驗場景，方便驗證學習成果，也為之後的實踐應用打下堅實基礎。點選連結檢視課程：https://developer.aliyun.com/learning/roadmap/cloudnative2020

“阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”