不斷重寫東西，對於中小型團隊而言幾乎是不可能的。

跟上K8s版本發布節奏，有多難

Kubernetes 遵循「N-2」支持政策（最近的 3 個次要版本獲得安全和錯誤修復）以及「15周」的發布周期。因此，一個版本會支持14個月（12 個月的支持期和 2 個月的升級期）。

如果我們將此與Debian的支持周期進行比較，我們可以看到直接明顯的區別。

比如，RedHat就是建立在組織無法經常升級的基礎上的，它向用戶展示了一些組織可以以何種節奏推出大型變更。

然而，即便是雲供應商有能力保持最新，也不會讓他們的客戶遵守這些極其緊迫的時間窗口。谷歌的GCP 可以接觸到許多 Kubernetes 維護人員，且與該項目密切合作，但也沒有讓客戶遵守這些時間表。

AWS 或 Azure 同樣也沒有這樣做。

現實情況是，穩定大於一切。沒有人期望公司能夠跟上K8s這樣的發布節奏。因為跟上節奏的代價很高：

首先，驗證集群是否可以升級以及是否安全需要使用第三方工具，或者很好地了解哪些 API 何時被棄用。

其次，在臨時環境中進行驗證的時間以及維護 Kubernetes 集群升級所需的大量時間，一個明顯的問題就出現了。

最後，這些組件和模塊需要經過持續的維護和更新，以確保其安全性和穩定性。

因此，通過提供 LTS 版本，可以為用戶提供一個穩定的基礎，使他們能夠在長期內使用 Kubernetes 而不必頻繁升級。

升級K8s集群，不如新建一個

沒有手動升級過K8s集群的人，自然不知道其中的辛酸，下面粗略的清單。

• 檢查所有第三方擴展，例如網絡和存儲插件
• 更新 etcd（全部實例）
• 更新 kube-apiserver（全部控制平面主機）
• 更新 kube-controller-manager
• 更新 kube 調度程序
• 更新雲控制器管理器（如果有使用）
• 更新 kubectl
• 排空每個節點並更換節點或升級節點，然後讀取並監視以確保其繼續工作
• kubectl convert根據清單上的要求運行

的確，上述這些並不是什麼「造火箭」的技術，而且所有這些都可以自動化，但這仍然需要有人熟練掌握這些版本。最重要的是，它並不比創建一個新集群容易得多。

即便升級充其量只是比創建新集群稍微容易（通常是更困難）一些，團隊也會陷入困境，不清楚到底怎樣做才是正確的行動方針。然而，鑒於發布速度如此之快，為每個新版本建立一個新集群並將服務遷移到該集群在邏輯上可能確實具有挑戰性。

考慮到團隊不想使用 K8s版本的 .0，通常是 0.2，這會損失相當長的14個月時間來等待該標準。然後啟動新集群並開始將服務遷移到其中。對於大多數團隊來說，這涉及大量的重複和資源浪費，因為至少在一段時間內運行的節點數量可能會增加一倍。CI/CD 管道需要修改，文檔需要更改，DNS 條目必須交換。

有些情況或許並不是那麼困難，但它由於每一個細節都至關重要，即使採用自動化，其中一個步驟的悄然失敗，所造成的風險也足以高到令想幹人整日提心弔膽。於是，集群似乎就處於不斷落後的狀態，除非哪天團隊被通知：將「跟上升級進度」視為他們給組織帶來的「關鍵價值」。

不少人都有類似的經歷：基礎團隊的集群已經閒置太久，維護者擔心它是否還能夠進行安全升級。因此為了避免給整個現有系統帶來嚴重的麻煩，通常都會在運行舊集群的前三個月，告訴領導層：「我需要稍微超出預算來啟動一個新集群，並逐個命名空間切換到它。」

即便這種流程方式看起來不太溫和。

假如K8s有LTS版本

當然，想要永久使用一個版本而不升級，也是不太可能的。因此有人建議，有沒有一種可能，K8s可以有一種「死胡同」版本，沒有任何升級路徑。這個LTS版本提供正式發布後 24 個月的支持，並且Kubernetes團隊不會提供到下一個 LTS 的升級。

這種做法似乎更符合目前很多組織的安全升級的現狀。這樣的話，運維團隊的工作流程就變成了運行 24 個月的集群，然後組織需要遷移它們並創建一個新的集群。

而且，這個工作流程有很多意義。首先，定期創建新節點將成為最佳實踐，組織可以升級底層 Linux 作業系統和虛擬機管理程序。雖然這個頻率顯然要短於每兩年一升級，但這將是一個很好的檢查點。

其次，基礎設施的運維團隊需要再次審視整個堆棧，從新的 ETCD、新版本的 Ingress 控制器開始，而不是像以往，除非絕對必要，組織很可能不願意觸及所有關鍵部分。

然後，這種做法可能對於商業產品或OSS工具來說，也是一個不錯的切入點。目前不少雲廠商都有類似的收費版K8s（託管平台），比如谷歌的GKE（Google Kubernetes Engine）允許用戶使用1.24版本584天，1.26版本可以使用572天。而微軟Azure的LTS日期更為寬鬆，從正式發布日期算起為期2年，AWS的EKS則更長，從發布到LTS結束，版本支持的時間約為800天。

K8s社區可以通過提供大量關於LTS版本升級的指導來協助這些產品或工具。而這也不至於令維護人員束縛在升級項目上。

K8s該不該有一個LTS版本？

有業內人士認為，K8s（以及相關軟體）存在定期引進重大更改的情況，開發者在工作中需要很多的時間精力去完成升級工作。因此，應該提供LTS版本。

許多其他開源軟體都提供具有支持多年的LTS版本，例如Ubuntu/Debian 提供5年的LTS版本，NodeJS提供2.5年的支持。還有人認為，即便是2年的支持期對於大型企業而言也不夠長。

總結下來，支持派的專家認為，K8s是一個複雜的軟體集合，有很多移動部件，繼續維護原狀來進行測試變得太多棘手，可以說已經達到了大多數人在整個職業生涯中不需要考慮的規模。將如此繁雜的升級工作交給同一波維護人員是不公平的。

在世界各地的託管平台和OSS堆棧間建立一個更nice的中間場地。對於世界各地的 K8s運營商來說，不必處於「繁忙且不安」的不斷升級現有集群的狀態，這將是一個巨大的好處。

此外，這樣還將有利於簡化第三方生態系統，從而可以更輕鬆地針對將存在一段時間的、已知穩定目標進行驗證。

同時，這樣還會鼓勵集群運維員採用更好的工作流程，推動其養成定期創建新集群的習慣，而不是永久保留一個集群升級到天黑，直至刷到「宕機」。

但反對派的觀點也不容易忽視：「LTS為運維人員帶來了便捷，但也會給開發人員增加潛在的向後移植安全修復的複雜性，而且獲得LTS支持的成本同樣很高。」

在他們看來，K8s是為了靈活性而生的，本來不適合那些想要使用90年代軟體開發流程的大公司。

「經常進行升級和發布，才能確保堆棧中的所有內容都得到充分理解，並且防止讓堆棧變得僵化，而且儘早而不是堆積的升級，往往更容易處理。」

折中的方案

針對上述兩種觀點，一位K8s某個發行版的前開發人員提到了一種折中的看法：「有些客戶出於各種原因希望延長支持期限。真正的問題應該是，LTS是否應該留給發行版。」

許多發行版會選擇不提供比上游更長期的版本，但會提供一些更商業的產品，這些產品對於客戶足夠重要且需付費。「如果讓Kubernetes作者承擔LTS的責任，那麼項目速度方面就會犧牲不少。因此還是將LTS留給K8s分銷商更合適。」

不可否認，在容器思維盛行的開發範式下，Kubernetes 作為容器編排領域的王者，不管你喜歡還是討厭，它都已經成為行業廣泛採用的標準平台。那麼，各位又是如何看待K8s版本升級過快的問題呢？