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

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

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

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

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

但為了靈活而生的K8s，似乎在作為基礎(chǔ)設(shè)施的層面上，并不是一個(gè)足夠穩(wěn)重的搭檔，它的更新速度非常快，大大超出業(yè)務(wù)迭代。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

升級(jí)K8s集群，不如新建一個(gè)

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

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

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

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

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

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

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

即便這種流程方式看起來(lái)不太溫和。

假如K8s有LTS版本

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

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

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

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

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

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

K8s該不該有一個(gè)LTS版本？

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

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

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

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

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

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

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

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

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

折中的方案

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

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

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