撰稿 | 言征

出品 | 51CTO技術(shù)棧（微信號：blog51cto）

Kubernetes集群不是在升級，就是在升級的路上。而對于維護(hù)K8s集群的團(tuán)隊來說，最擔(dān)心的莫過于，系統(tǒng)因?yàn)镵8s升級而引發(fā)了服務(wù)器大規(guī)模崩潰。

想象一下，K8s升級發(fā)生在某個晚上，突然某個集群因?yàn)閺?qiáng)制更新，導(dǎo)致了所有服務(wù)器的崩潰，也沒有快速的方法來恢復(fù)，造成的損失將會有多么大呢？

圖片

因此，舊版本的穩(wěn)定性就會顯得尤其重要。那么既然如此，Kubernetes為何不推出一個LTS版本呢？

1、升級太快，公司跟不上節(jié)奏

企業(yè)期望穩(wěn)定性并不是出于保守或惰性，而是太多現(xiàn)實(shí)的原因——客戶與供應(yīng)商達(dá)成的合同、監(jiān)管和法定要求、技術(shù)風(fēng)險政策的限制，都在此列。

但為了靈活而生的K8s，似乎在作為基礎(chǔ)設(shè)施的層面上，并不是一個足夠穩(wěn)重的搭檔，它的更新速度非?？欤蟠蟪鰳I(yè)務(wù)迭代。

即便K8s社區(qū)支持的深度和廣度足夠可靠的支持使用者能從社區(qū)類似的問題中找到答案，即便大多數(shù)組織能夠忍受部署K8s的痛苦，但頻繁的升級操作卻讓許多用戶叫苦不迭。

據(jù)一位開發(fā)者反映，在K8s之上運(yùn)行GKE升級方案中，經(jīng)常會導(dǎo)致服務(wù)中斷數(shù)周。對于如何修復(fù)或升級控制平面和節(jié)點(diǎn)池，給出的默認(rèn)值選項(xiàng)也非常抽象，集群在不知情下的情況下升級并任意中斷服務(wù)，更會讓人感到恐慌。

不斷重寫東西，對于中小型團(tuán)隊而言幾乎是不可能的。

2、跟上K8s版本發(fā)布節(jié)奏，有多難

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

圖片

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

圖片

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

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

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

現(xiàn)實(shí)情況是，穩(wěn)定大于一切。沒有人期望公司能夠跟上K8s這樣的發(fā)布節(jié)奏。因?yàn)楦瞎?jié)奏的代價很高：

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

其次，在臨時環(huán)境中進(jìn)行驗(yàn)證的時間以及維護(hù) Kubernetes 集群升級所需的大量時間，一個明顯的問題就出現(xiàn)了。

最后，這些組件和模塊需要經(jīng)過持續(xù)的維護(hù)和更新，以確保其安全性和穩(wěn)定性。

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

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

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

• 檢查所有第三方擴(kuò)展，例如網(wǎng)絡(luò)和存儲插件
• 更新 etcd（全部實(shí)例）
• 更新 kube-apiserver（全部控制平面主機(jī)）
• 更新 kube-controller-manager
• 更新 kube 調(diào)度程序
• 更新云控制器管理器（如果有使用）
• 更新 kubectl
• 排空每個節(jié)點(diǎn)并更換節(jié)點(diǎn)或升級節(jié)點(diǎn)，然后讀取并監(jiān)視以確保其繼續(xù)工作
• kubectl convert根據(jù)清單上的要求運(yùn)行

的確，上述這些并不是什么“造火箭”的技術(shù)，而且所有這些都可以自動化，但這仍然需要有人熟練掌握這些版本。最重要的是，它并不比創(chuàng)建一個新集群容易得多。

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

考慮到團(tuán)隊不想使用 K8s版本的 .0，通常是 0.2，這會損失相當(dāng)長的14個月時間來等待該標(biāo)準(zhǔn)。然后啟動新集群并開始將服務(wù)遷移到其中。對于大多數(shù)團(tuán)隊來說，這涉及大量的重復(fù)和資源浪費(fèi)，因?yàn)橹辽僭谝欢螘r間內(nèi)運(yùn)行的節(jié)點(diǎn)數(shù)量可能會增加一倍。CI/CD 管道需要修改，文檔需要更改，DNS 條目必須交換。

有些情況或許并不是那么困難，但它由于每一個細(xì)節(jié)都至關(guān)重要，即使采用自動化，其中一個步驟的悄然失敗，所造成的風(fēng)險也足以高到令想干人整日提心吊膽。于是，集群似乎就處于不斷落后的狀態(tài)，除非哪天團(tuán)隊被通知：將“跟上升級進(jìn)度”視為他們給組織帶來的“關(guān)鍵價值”。

不少人都有類似的經(jīng)歷：基礎(chǔ)團(tuán)隊的集群已經(jīng)閑置太久，維護(hù)者擔(dān)心它是否還能夠進(jìn)行安全升級。因此為了避免給整個現(xiàn)有系統(tǒng)帶來嚴(yán)重的麻煩，通常都會在運(yùn)行舊集群的前三個月，告訴領(lǐng)導(dǎo)層：“我需要稍微超出預(yù)算來啟動一個新集群，并逐個命名空間切換到它?！?/p>

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

4、假如K8s有LTS版本

當(dāng)然，想要永久使用一個版本而不升級，也是不太可能的。因此有人建議，有沒有一種可能，K8s可以有一種“死胡同”版本，沒有任何升級路徑。這個LTS版本提供正式發(fā)布后 24 個月的支持，并且Kubernetes團(tuán)隊不會提供到下一個 LTS 的升級。

這種做法似乎更符合目前很多組織的安全升級的現(xiàn)狀。這樣的話，運(yùn)維團(tuán)隊的工作流程就變成了運(yùn)行 24 個月的集群，然后組織需要遷移它們并創(chuàng)建一個新的集群。

而且，這個工作流程有很多意義。首先，定期創(chuàng)建新節(jié)點(diǎn)將成為最佳實(shí)踐，組織可以升級底層 Linux 操作系統(tǒng)和虛擬機(jī)管理程序。雖然這個頻率顯然要短于每兩年一升級，但這將是一個很好的檢查點(diǎn)。

其次，基礎(chǔ)設(shè)施的運(yùn)維團(tuán)隊需要再次審視整個堆棧，從新的 ETCD、新版本的 Ingress 控制器開始，而不是像以往，除非絕對必要，組織很可能不愿意觸及所有關(guān)鍵部分。

然后，這種做法可能對于商業(yè)產(chǎn)品或OSS工具來說，也是一個不錯的切入點(diǎn)。目前不少云廠商都有類似的收費(fèi)版K8s（托管平臺），比如谷歌的GKE（Google Kubernetes Engine）允許用戶使用1.24版本584天，1.26版本可以使用572天。而微軟Azure的LTS日期更為寬松，從正式發(fā)布日期算起為期2年，AWS的EKS則更長，從發(fā)布到LTS結(jié)束，版本支持的時間約為800天。

K8s社區(qū)可以通過提供大量關(guān)于LTS版本升級的指導(dǎo)來協(xié)助這些產(chǎn)品或工具。而這也不至于令維護(hù)人員束縛在升級項(xiàng)目上。

5、K8s該不該有一個LTS版本？

有業(yè)內(nèi)人士認(rèn)為，K8s（以及相關(guān)軟件）存在定期引進(jìn)重大更改的情況，開發(fā)者在工作中需要很多的時間精力去完成升級工作。因此，應(yīng)該提供LTS版本。

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

總結(jié)下來，支持派的專家認(rèn)為，K8s是一個復(fù)雜的軟件集合，有很多移動部件，繼續(xù)維護(hù)原狀來進(jìn)行測試變得太多棘手，可以說已經(jīng)達(dá)到了大多數(shù)人在整個職業(yè)生涯中不需要考慮的規(guī)模。將如此繁雜的升級工作交給同一波維護(hù)人員是不公平的。

在世界各地的托管平臺和OSS堆棧間建立一個更nice的中間場地。對于世界各地的 K8s運(yùn)營商來說，不必處于“繁忙且不安”的不斷升級現(xiàn)有集群的狀態(tài)，這將是一個巨大的好處。

此外，這樣還將有利于簡化第三方生態(tài)系統(tǒng)，從而可以更輕松地針對將存在一段時間的、已知穩(wěn)定目標(biāo)進(jìn)行驗(yàn)證。

同時，這樣還會鼓勵集群運(yùn)維員采用更好的工作流程，推動其養(yǎng)成定期創(chuàng)建新集群的習(xí)慣，而不是永久保留一個集群升級到天黑，直至刷到“宕機(jī)”。

但反對派的觀點(diǎn)也不容易忽視：“LTS為運(yùn)維人員帶來了便捷，但也會給開發(fā)人員增加潛在的向后移植安全修復(fù)的復(fù)雜性，而且獲得LTS支持的成本同樣很高。”

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

“經(jīng)常進(jìn)行升級和發(fā)布，才能確保堆棧中的所有內(nèi)容都得到充分理解，并且防止讓堆棧變得僵化，而且盡早而不是堆積的升級，往往更容易處理。”

6、折中的方案

針對上述兩種觀點(diǎn)，一位K8s某個發(fā)行版的前開發(fā)人員提到了一種折中的看法：“有些客戶出于各種原因希望延長支持期限。真正的問題應(yīng)該是，LTS是否應(yīng)該留給發(fā)行版?！?/p>

許多發(fā)行版會選擇不提供比上游更長期的版本，但會提供一些更商業(yè)的產(chǎn)品，這些產(chǎn)品對于客戶足夠重要且需付費(fèi)?！叭绻孠ubernetes作者承擔(dān)LTS的責(zé)任，那么項(xiàng)目速度方面就會犧牲不少。因此還是將LTS留給K8s分銷商更合適?！?/p>

不可否認(rèn)，在容器思維盛行的開發(fā)范式下，Kubernetes 作為容器編排領(lǐng)域的王者，不管你喜歡還是討厭，它都已經(jīng)成為行業(yè)廣泛采用的標(biāo)準(zhǔn)平臺。那么，各位又是如何看待K8s版本升級過快的問題呢？

參考鏈接：

https://matduggan.com/author/mathew/