撰稿 | 言征
出品 | 51CTO技術棧（微信號：blog51cto）
Kubernetes集群不是在升級，就是在升級的路上。而對于維護K8s集群的團隊來說，最擔心的莫過于，系統因為K8s升級而引發了服務器大規模崩潰。
想象一下，K8s升級發生在某個晚上，突然某個集群因為強制更新，導致了所有服務器的崩潰，也沒有快速的方法來恢復，造成的損失將會有多么大呢？
圖片
因此，舊版本的穩定性就會顯得尤其重要。那么既然如此，Kubernetes為何不推出一個LTS版本呢？
1、升級太快，公司跟不上節奏
企業期望穩定性并不是出于保守或惰性，而是太多現實的原因——客戶與供應商達成的合同、監管和法定要求、技術風險政策的限制，都在此列。
但為了靈活而生的K8s，似乎在作為基礎設施的層面上，并不是一個足夠穩重的搭檔，它的更新速度非常快，大大超出業務迭代。
即便K8s社區支持的深度和廣度足夠可靠的支持使用者能從社區類似的問題中找到答案，即便大多數組織能夠忍受部署K8s的痛苦，但頻繁的升級操作卻讓許多用戶叫苦不迭。
據一位開發者反映，在K8s之上運行GKE升級方案中，經常會導致服務中斷數周。對于如何修復或升級控制平面和節點池，給出的默認值選項也非常抽象，集群在不知情下的情況下升級并任意中斷服務，更會讓人感到恐慌。
不斷重寫東西，對于中小型團隊而言幾乎是不可能的。
2、跟上K8s版本發布節奏，有多難
Kubernetes 遵循“N-2”支持政策（最近的 3 個次要版本獲得安全和錯誤修復）以及“15周”的發布周期。因此，一個版本會支持14個月（12 個月的支持期和 2 個月的升級期）。
圖片
如果我們將此與Debian的支持周期進行比較，我們可以看到直接明顯的區別。
圖片
比如，RedHat就是建立在組織無法經常升級的基礎上的，它向用戶展示了一些組織可以以何種節奏推出大型變更。
然而，即便是云供應商有能力保持最新，也不會讓他們的客戶遵守這些極其緊迫的時間窗口。谷歌的GCP 可以接觸到許多 Kubernetes 維護人員，且與該項目密切合作，但也沒有讓客戶遵守這些時間表。
AWS 或 Azure 同樣也沒有這樣做。
現實情況是，穩定大于一切。沒有人期望公司能夠跟上K8s這樣的發布節奏。因為跟上節奏的代價很高：
首先，驗證集群是否可以升級以及是否安全需要使用第三方工具，或者很好地了解哪些 API 何時被棄用。
其次，在臨時環境中進行驗證的時間以及維護 Kubernetes 集群升級所需的大量時間，一個明顯的問題就出現了。
最后，這些組件和模塊需要經過持續的維護和更新，以確保其安全性和穩定性。
因此，通過提供 LTS 版本，可以為用戶提供一個穩定的基礎，使他們能夠在長期內使用 Kubernetes 而不必頻繁升級。
3、升級K8s集群，不如新建一個
沒有手動升級過K8s集群的人，自然不知道其中的辛酸，下面粗略的清單。
- 檢查所有第三方擴展，例如網絡和存儲插件
- 更新 etcd（全部實例）
- 更新 kube-apiserver（全部控制平面主機）
- 更新 kube-controller-manager
- 更新 kube 調度程序
- 更新云控制器管理器（如果有使用）
- 更新 kubectl
- 排空每個節點并更換節點或升級節點，然后讀取并監視以確保其繼續工作
- kubectl convert根據清單上的要求運行
的確，上述這些并不是什么“造火箭”的技術，而且所有這些都可以自動化，但這仍然需要有人熟練掌握這些版本。最重要的是，它并不比創建一個新集群容易得多。
即便升級充其量只是比創建新集群稍微容易（通常是更困難）一些，團隊也會陷入困境，不清楚到底怎樣做才是正確的行動方針。然而，鑒于發布速度如此之快，為每個新版本建立一個新集群并將服務遷移到該集群在邏輯上可能確實具有挑戰性。
考慮到團隊不想使用 K8s版本的 .0，通常是 0.2，這會損失相當長的14個月時間來等待該標準。然后啟動新集群并開始將服務遷移到其中。對于大多數團隊來說，這涉及大量的重復和資源浪費，因為至少在一段時間內運行的節點數量可能會增加一倍。CI/CD 管道需要修改，文檔需要更改，DNS 條目必須交換。
有些情況或許并不是那么困難，但它由于每一個細節都至關重要，即使采用自動化，其中一個步驟的悄然失敗，所造成的風險也足以高到令想干人整日提心吊膽。于是，集群似乎就處于不斷落后的狀態，除非哪天團隊被通知：將“跟上升級進度”視為他們給組織帶來的“關鍵價值”。
不少人都有類似的經歷：基礎團隊的集群已經閑置太久，維護者擔心它是否還能夠進行安全升級。因此為了避免給整個現有系統帶來嚴重的麻煩，通常都會在運行舊集群的前三個月，告訴領導層：“我需要稍微超出預算來啟動一個新集群，并逐個命名空間切換到它。”
即便這種流程方式看起來不太溫和。
4、假如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版本升級的指導來協助這些產品或工具。而這也不至于令維護人員束縛在升級項目上。
5、K8s該不該有一個LTS版本？
有業內人士認為，K8s（以及相關軟件）存在定期引進重大更改的情況，開發者在工作中需要很多的時間精力去完成升級工作。因此，應該提供LTS版本。
許多其他開源軟件都提供具有支持多年的LTS版本，例如Ubuntu/Debian 提供5年的LTS版本，NodeJS提供2.5年的支持。還有人認為，即便是2年的支持期對于大型企業而言也不夠長。
總結下來，支持派的專家認為，K8s是一個復雜的軟件集合，有很多移動部件，繼續維護原狀來進行測試變得太多棘手，可以說已經達到了大多數人在整個職業生涯中不需要考慮的規模。將如此繁雜的升級工作交給同一波維護人員是不公平的。
在世界各地的托管平臺和OSS堆棧間建立一個更nice的中間場地。對于世界各地的 K8s運營商來說，不必處于“繁忙且不安”的不斷升級現有集群的狀態，這將是一個巨大的好處。
此外，這樣還將有利于簡化第三方生態系統，從而可以更輕松地針對將存在一段時間的、已知穩定目標進行驗證。
同時，這樣還會鼓勵集群運維員采用更好的工作流程，推動其養成定期創建新集群的習慣，而不是永久保留一個集群升級到天黑，直至刷到“宕機”。
但反對派的觀點也不容易忽視：“LTS為運維人員帶來了便捷，但也會給開發人員增加潛在的向后移植安全修復的復雜性，而且獲得LTS支持的成本同樣很高。”
在他們看來，K8s是為了靈活性而生的，本來不適合那些想要使用90年代軟件開發流程的大公司。
“經常進行升級和發布，才能確保堆棧中的所有內容都得到充分理解，并且防止讓堆棧變得僵化，而且盡早而不是堆積的升級，往往更容易處理。”
6、折中的方案
針對上述兩種觀點，一位K8s某個發行版的前開發人員提到了一種折中的看法：“有些客戶出于各種原因希望延長支持期限。真正的問題應該是，LTS是否應該留給發行版。”
許多發行版會選擇不提供比上游更長期的版本，但會提供一些更商業的產品，這些產品對于客戶足夠重要且需付費。“如果讓Kubernetes作者承擔LTS的責任，那么項目速度方面就會犧牲不少。因此還是將LTS留給K8s分銷商更合適。”
不可否認，在容器思維盛行的開發范式下，Kubernetes 作為容器編排領域的王者，不管你喜歡還是討厭，它都已經成為行業廣泛采用的標準平臺。那么，各位又是如何看待K8s版本升級過快的問題呢？
參考鏈接：
