如果你已經使用 Kubernetes 一段時間了，則可能需要考慮計劃定期升級。從 Kubernetes 1.19 開始，每個開源版本都提供一年的補丁。你需要升級到最新的可用次要版本或補丁版本才能獲得安全性和錯誤修復。但是，如何在不停機的情況下升級基礎架構的關鍵部分呢？本文將指導你了解在任何環境中升級 Kubernetes 時要考慮的常見模式。

我們不會深入研究執行升級的所有工具和注意事項。如果你使用的是集群管理工具或托管 Kubernetes 服務，你應該查閱你的文檔以獲得最適合你環境的選項。你還需要注意，某些工作負載和環境可能會限制你選擇的升級策略。

我們將討論集群升級的一些高級模式：

• 原地升級
• 藍綠升級
• 滾動升級
• 金絲雀升級

這些模式類似于應用程序升級選項，但由于其潛在的影響可能需要考慮一些獨特的因素。升級基礎設施可能會產生相當大的成本，具體取決于升級需要多長時間以及你的規模有多大。

控制平面組件

Kubernetes 控制平面由 Kubernetes API Server、etcd 數據庫、controller manager,、scheduler以及你的環境中可能擁有的任何其他控制器（例如云或ingress ）組成。升級 API Server是升級集群的第一步。Kubernetes 將狀態存儲在 etcd 中，并且隨著任何重大應用程序升級，你需要確保至少有一個備份，并且你已經驗證可以恢復備份。在某些情況下，API Server升級可能還需要 etcd 升級。

數據平面組件

Kubernetes 數據平面由 kubelet、容器運行時以及你在集群工作負載中使用的任何網絡、日志記錄或存儲驅動程序組成。對于許多集群，至少需要 kube-proxy 和 CNI 插件更新。你的數據平面組件可以小于等于你的 API Server版本。理想情況下，你的主機操作系統、容器運行時和數據平面組件可以相互獨立升級。將這些組件解耦，將確保你可以在出現錯誤修復、新功能或安全補丁時快速升級。

Kubernetes 托管服務

如果你使用Amazon Elastic Kubernetes Service (EKS)等托管 Kubernetes 服務，則會為你處理控制平面升級。如果你使用的是托管數據平面服務，例如托管節點組 (MNG)，你的數據平面升級也應該由你的云提供商自動處理。

即使使用托管服務，你仍然有責任驗證已安裝在集群中的工作負載、附加控制器和第三方插件（例如 CNI）。在測試或開發環境中升級集群之前，應測試這些組件的 API 兼容性。

在所有這些升級策略中，你應該避免在集群升級期間進行應用程序升級。如果可能，請保持你的工作負載使用相同的版本，以最大限度地減少可能錯誤地歸因于 Kubernetes 升級的故障。還要盡量減少其他潛在問題，例如scheme升級或應用程序 API 兼容性。

對于任何 Kubernetes 升級，你應該按以下順序升級組件：

1. 控制平面
2. 數據平面和節點
3. 附加組件
4. 工作負載

這些升級模式將幫助你決定如何升級最適合你的集群和環境的組件。

01.原地升級

In-Place Upgrade

執行原地升級時，你必須格外小心，確保組件保持健康，因為你是在當前服務于生產流量的集群上執行工作。原地升級可以包括包更新（例如 yum、apt）、配置管理自動化（例如 Ansible、Chef）或 VM/容器鏡像更改。理想情況下，你的升級將是腳本化和自動化的（包括回滾），但如果這是你第一次升級，在開發或測試環境中手動進行升級可能會有所幫助。

原地升級意味著所有組件將大致同時升級。如果你通過配置管理更改所需的 API Server版本并推送新配置，則所有 API Server在收到新配置后都會升級。這與我們稍后討論的滾動升級不同。

原地升級的主要好處是：

• 在任何規模下，它都是最快的。
• 如果手動完成，則可以更好地控制組件和升級過程。
• 它很容易適用于多種環境（本地或云）。
• 從基礎設施成本的角度來看，它是最便宜的。

根據你的流程、規模和工具，原地升級可能是能夠編寫腳本的最直接的方法。腳本可以在本地或在開發集群中進行測試，而無需重新配置集群管理員團隊可能無法訪問的資源——例如負載均衡器或 DNS。

如果要使用此方法進行升級，原地升級還需要考慮以下限制：

• 如果你的所有 API Server或控制器同時升級，則可能導致停機。
• 如果你想從 Kubernetes 1.16 遷移到 1.20，你必須將整個集群四次升級到每個次要版本。
• 驗證每個步驟可能是一個手動過程，這可能會增加額外的時間和出錯的機會。
• 你應該在失敗的情況下測試回滾計劃，因為某些升級無法輕松恢復。（例如，scheme更改）。

02.藍/綠升級

藍/綠集群升級需要你使用新版本的 Kubernetes 創建第二個集群。你需要部署新的控制平面和數據平面，然后將所有工作負載復制到新集群，然后再將流量從舊集群切換到新集群。你可以使用藍/綠來更新集群的每個組件，但整體集群升級更易于部署和回滾。

息是，設置新集群通常比升級集群更容易。關于如何將工作負載部署到新集群，你有多種選擇。如果你的工作負載已經是 GitOps 或持續交付的一部分，你可以在升級之前或期間將部署同時轉到新集群和舊集群。如果你沒有自動部署，你可以使用Velero 之類的工具來備份你現有的工作負載并將它們部署到新集群。

創建新的“Green”集群可以讓你對新版本按預期工作充滿信心，并讓你控制何時切換版本。新集群還可用于驗證自動化工具，例如 Terraform 模塊或 GitOps 存儲庫。你可以隨時通過 DNS 或負載均衡器進行更改，甚至可以在維護時段或低利用率期間進行更改。

藍/綠升級的主要好處是：

• 在發送流量之前預先驗證所有組件是否正常。
• 你可以一次升級多個版本（例如，從 1.16 直接升級到 1.20）。
• 你可以更改可能難以測試的基礎架構的其他部分（例如，切換區域、添加區域、更改實例類型）。
• 回滾是最安全和最容易的。

藍/綠部署要考慮的缺點包括：

• 這是基礎架構成本中最昂貴的策略，因為你必須在遷移期間運行兩倍的計算容量。
• 如果你有數千個工作程序節點，你可能無法獲得運行完整的第二個集群所需的所有計算容量。
• 如果你有多個并發集群升級，則此策略很難擴展到數十個或數百個集群。
• 除非你有備用服務器，否則在沒有虛擬化的情況下在本地實現藍/綠并不容易。
• 如果你有很多端點要更新，一次切換所有流量可能并不容易。負載均衡器可能需要預先調整并預熱緩存。請注意 DNS 生存時間 (TTL)，它可能會或可能不會用于分散負載。
• 一次切換所有集群流量需要跨團隊協調遷移到新集群；以及工程周期來驗證工作負載的規模是否正確。

當你擁有較少數量的集群或少于幾百個工作節點時，藍/綠可能是一個很好的策略。它允許你跳過版本并且回滾是安全的，但它可能會需要更多的基礎設施支出和協調時間。

03.滾動升級

如果你熟悉 Kubernetes 部署策略，你就會熟悉滾動升級。滾動升級將部署組件的一個升級為新副本，然后縮減一個舊副本。它將繼續這種模式，直到所有舊組件都被刪除。滾動升級的增量性質比原地升級和藍/綠策略有一些優勢。

與原地升級類似，你需要一次升級 Kubernetes 的一個次要版本。當需要升級多個版本時，這可能是額外的工作，但它是唯一受支持的選項。根據你要升級的組件，你可以使用不同的工具來升級每個組件。

對于像控制平面這樣的資源，你可能希望將帶有升級的 API Server的新服務器添加到控制平面，然后關閉舊服務器。如果你使用的是 AWS，則可以更改 Auto Scaling 組啟動配置 AMI 并一次替換一個實例。其他控制平面組件（例如調度程序）可能在集群內作為容器運行，因此你可以使用標準的 Kubernetes 滾動部署升級來升級這些組件。

與藍/綠相比，滾動升級的主要區別在于你的外部流量路由（DNS 和負載均衡器）將保持指向同一位置。在進行生產集群升級之前，你需要確保在不同的集群或環境中測試所有附加組件和工作負載。

請注意，AWS 托管節點組、kOps、Cluster-API和許多其他 Kubernetes 集群管理工具使用滾動升級策略。好處包括：

• 與原地升級相比，更安全的更新和回滾。
• 成本低于藍色/綠色，并且資源耗盡的可能性較小。
• 如果出現問題，可以在升級過程中暫停。
• 可以在本地環境模擬。

滾動升級是最常見的自動化工具。它們在速度和成本之間取得了很好的平衡，也減少手動工作和風險。

升級生產集群時，你現有的所有工作負載仍將被部署；只要你測試了它們的兼容性，你的升級就應該是可自動化的。

使用滾動升級時的進一步考慮包括：

• 滾動升級可能會很慢，具體取決于你的規模。
• 在升級期間，你可能需要協調控制器、守護進程或插件升級。
• 你可能無法進行集群范圍的更改，例如添加可用區或更改架構。

04.金絲雀升級

Canary 應用程序部署一次為應用程序的新版本提供少量流量。Canary 升級可以被認為是具有藍/綠優勢的滾動升級。

通過 Canary 升級，你將使用要部署的版本創建一個新的 Kubernetes 集群。然后添加一個小型數據平面并將你現有的應用程序以較小的規模部署到新集群。通過負載均衡器配置、DNS 循環或服務網格將新的集群工作負載添加到現有的生產流量中。

現在，你可以監控流向新集群的流量，慢慢擴展新集群中的工作負載并縮減舊集群中的工作負載。你可以一次完成一項工作，并且可以根據自己的習慣緩慢或快速完成。如果任何單個工作負載開始出現錯誤，你可以縮減新集群中的單個工作負載，使其自動使用舊集群。

Canary 集群升級的好處包括：

• 新集群更容易創建和驗證。
• 你可以在升級期間跳過次要 Kubernetes 版本（例如，1.16 到 1.20）。
• 可以在每個團隊的基礎上選擇加入應用程序部署。
• 由于增加的流量使用，錯誤的影響最小。
• 你可以在升級期間進行大型基礎架構更改。
• 集群從小規模開始，因此基礎設施成本較低，你可以在擴展時預熱緩存和負載均衡器。

如果你想進行較大的更改（例如更改架構）或者你想添加額外的可用區，那么 Canary 是一個不錯的選擇。通過啟動較小的集群并根據工作負載增加它，你可以確保在新實例更高效或工作負載請求和限制發生變化時不會過度配置基礎設施。

與任何事情一樣，需要權衡取舍。使用金絲雀部署時，你應該注意以下一些問題：

• 回滾應用程序可能需要手動干預來更改負載均衡器或縮小新集群的規模。
• 調試應用程序可能更難，因為你需要知道發生了哪些集群錯誤。
• 如果你有數十個或數百個集群，隨著集群的升級，你的集群數量可能會增加 50% 或更多。

   Canary 是最復雜的升級策略，但它受益于自動化部署、健康檢查和性能監控。

結論

無論你選擇哪種升級策略，重要的是要了解它們的工作原理以及隨著 Kubernetes 使用量的增長可能出現的任何問題。你需要有一個升級策略，因為 Kubernetes 有頻繁的發布和偶爾的錯誤。

與新版本保持同步可能是你的基礎設施安全流程的重要組成部分，并使應用程序能夠快速利用新功能。如果你部署了 Kubernetes 并遷移了所有工作負載，而沒有考慮如何升級，那么現在是開始計劃的最佳時機。

如果你沒有運行自己的 Kubernetes 集群的業務需求，我強烈建議你使用可用的托管 Kubernetes 選項之一。選擇托管控制平面和數據平面可以為你每年節省數天或數周的規劃和升級時間。每個托管選項可能執行不同的升級，但它們都允許你專注于工作負載和業務價值，而不是控制平面高可用性或數據平面兼容性。