作者 | 云昭

目前，不管對(duì)于運(yùn)維部門、還是后端的架構(gòu)部門而言，掌握 Kubernetes 已經(jīng)是必備項(xiàng)，因?yàn)樗鉀Q了微服務(wù)的部署問題，而且已然是容器編排的事實(shí)標(biāo)準(zhǔn)。Kubernetes 已成為界內(nèi)家喻戶曉的名字。不可否認(rèn)，它是許多開發(fā)人員的理想解決方案。

但是 Kubernetes 真的完美無瑕嗎？雖然開發(fā)者對(duì) Kubernetes 提供的各種可能性充滿熱情，但也有沮喪的一面：與 Kubernetes 并肩同行，“沿途”將伴生出許多繁雜的問題。這就是為什么越來越多的組織開始尋找更易于使用的替代品的原因。

那么，Kubernetes 為什么開始被某些企業(yè)嫌棄了呢？

Kubernetes 驚艷問世 

Kubernetes 最初是由 Google 作為 Borg 的開源版本開發(fā)的，Borg 是他們過于復(fù)雜的容器管理平臺(tái)，但后來演變成一場(chǎng)全球運(yùn)動(dòng)（與國(guó)內(nèi)而言，也掀起了一場(chǎng)“開源+訂閱”的團(tuán)隊(duì)協(xié)作模式的浪潮）。它目前歸屬于云原生計(jì)算基金會(huì) (CNCF)，并由大型貢獻(xiàn)者社區(qū)維護(hù)。

任何 Kubernetes 基礎(chǔ)設(shè)施的核心都是容器，它剝離了虛擬機(jī)管理程序等不必要的部分，并將操作系統(tǒng)和應(yīng)用程序的必要組件封裝到一個(gè)整潔的包中。

目前，Kubernetes 已成為自動(dòng)化軟件部署、容器管理和基礎(chǔ)設(shè)施擴(kuò)展的事實(shí)標(biāo)準(zhǔn)。它運(yùn)行具有內(nèi)置默認(rèn)副本和自動(dòng)擴(kuò)展的容器化應(yīng)用程序，以確保應(yīng)用程序穩(wěn)健運(yùn)行且可以快速地?cái)U(kuò)展。

Kubernetes 遭棄之迷 

1. Kubernetes 可能會(huì)矯枉過正

大多數(shù)組織的運(yùn)營(yíng)規(guī)模不及 Google 或 Facebook。Facebook 號(hào)稱擁有 18 個(gè)數(shù)據(jù)中心，占地 4000 萬平方英尺，耗資 200 億美元。據(jù) Mcafee 統(tǒng)計(jì)顯示，“少于 1000 人員工規(guī)模的公司平均僅運(yùn)行 22 個(gè)自定義應(yīng)用程序。” 這些應(yīng)用程序雖然仍需要現(xiàn)代技術(shù)和方法來有效地管理它們。然而，技術(shù)實(shí)力過于強(qiáng)大的 Kubernetes，對(duì)于這些少量應(yīng)用程序而言，未免顯得“殺雞用牛刀”，甚至還會(huì)分散應(yīng)用程序本身的注意力。

2. Kubernetes 配置過于復(fù)雜

Kubernetes 向來以其陡峭的學(xué)習(xí)曲線和操作復(fù)雜性而聞名。但你可能不知道 Kubernetes 的最初目的很簡(jiǎn)單——“彈性運(yùn)行分布式系統(tǒng)”。但在目前的情況下，這個(gè)簡(jiǎn)單的目的似乎變得過于混亂。

如果公司購(gòu)買云廠商，例如 AWS 或 Azure 上使用 Kubernetes 它們自然會(huì)基本上隱藏所有相關(guān)部署的復(fù)雜性。但如果在本地運(yùn)行 Kubernetes ，就意味著接下來需要本地的開發(fā)人員來管理這些復(fù)雜性——包括 etcd、負(fù)載平衡、可用性、自動(dòng)擴(kuò)展、網(wǎng)絡(luò)、故障部署回滾、持久存儲(chǔ)等。

除了構(gòu)建服務(wù)來處理公有云通常為您解決的上述復(fù)雜性之外，以 DIY 方式在本地部署 Kubernetes 還涉及大量核心代碼修改。

即使是創(chuàng)造 Kubernetes 的谷歌，也不得不承認(rèn)：“很難正確配置 Kubernetes”，而像 Istio 這樣的工具也很難設(shè)置和開始使用。

Kubernetes 有些過猶不及，因?yàn)橄虢鉀Q的問題太多，而導(dǎo)致平臺(tái)被拉向過多的發(fā)展方向。

3. 部署和維護(hù)成本高

盡管 Kubernetes 可以免費(fèi)使用，但它真正實(shí)施起來卻是一個(gè)昂貴的產(chǎn)品：隱形成本非常龐大：管理基礎(chǔ)設(shè)施以及優(yōu)化在其上運(yùn)行的工作負(fù)載相當(dāng)重。因此，“免費(fèi)的也是昂貴的”，就部署和維護(hù)所需的時(shí)間和人力而言，Kubernetes 的成本很高。 

4. 艱難繁瑣的過渡

遷移到 Kubernetes 是一項(xiàng)艱巨而艱巨的工作。要在這方面取得成功，企業(yè)需要將原來的架構(gòu)進(jìn)行部分甚至完全的重構(gòu)。同時(shí)，還需要一個(gè)龐大的團(tuán)隊(duì)來確保 Kubernetes 集群正在運(yùn)行。即使您設(shè)法構(gòu)建了一個(gè)維護(hù)良好的 Kubernetes 設(shè)置，從基本集群過渡到可靠的生產(chǎn)環(huán)境，還有大量工作要做。

光環(huán)漸消退，新需求明朗 

首先，容器和云編排需要一種“秉持初心”的方法。在試圖為軟件世界中的所有人提供一切的過程中，Kubernetes 變得過于復(fù)雜。Kubernetes 的魅力已經(jīng)開始消退，不少企業(yè)開始尋找在容器編排領(lǐng)域，可以提供一種“秉持初心”的替代方案。

其次，需要一種更簡(jiǎn)單的入門方法。Kubernetes 的不同部分需要額外的工具來補(bǔ)充它，現(xiàn)在已經(jīng)有各種不同的工具來幫助處理和管理 Kubernetes 的復(fù)雜性。這意味著開發(fā)者必須先學(xué)會(huì)操作多個(gè)迷你工具，然后才能開始在生產(chǎn) Kubernetes 集群中運(yùn)行應(yīng)用程序。

當(dāng)嘗試跨多個(gè)基礎(chǔ)架構(gòu)提供商進(jìn)行部署時(shí)，這種工作負(fù)載會(huì)更加復(fù)雜。許多人希望從這個(gè)學(xué)習(xí)過程中解脫出來，并拼湊組合出趁手的新工具來使用。任何可以幫助避免這種混亂的替代方案都是可喜的變化。 

再者，開發(fā)人員能夠在沒有 DevOps 團(tuán)隊(duì)的情況下進(jìn)行構(gòu)建。當(dāng)涉及到一個(gè)以其復(fù)雜性而聞名的系統(tǒng)時(shí)，構(gòu)建過程可能會(huì)顯著減慢。這是因?yàn)閷?duì)于以前沒有使用過基礎(chǔ)設(shè)施的開發(fā)人員來說，熟悉 Kubernetes 開發(fā)工作流程可能非常困難。

此外，即使是非常熟悉該框架的開發(fā)人員也需要 Kubernetes 專家和 DevOps 團(tuán)隊(duì)來幫助他們克服遇到的各種瓶頸。這最終會(huì)降低生產(chǎn)力，并延長(zhǎng)發(fā)布周期。

因此，組織正在尋找方法來消除開發(fā)人員對(duì) DevOps 團(tuán)隊(duì)的依賴。他們希望為開發(fā)人員提供在需要時(shí)訪問所需資源的靈活性和自主權(quán)。 

?Kubernetes 的替代品 

Kubernetes 已經(jīng)主導(dǎo)了容器管理領(lǐng)域多年。在完全意識(shí)到對(duì)替代方案的需求之后，就會(huì)導(dǎo)致新解決方案的興起，以期望可以在更少麻煩，更低的復(fù)雜性的情況下勝任 Kubernetes 可以完成的工作。

放眼當(dāng)下容器編排領(lǐng)域，誰會(huì)有可能滿足這些需求，并能取代 Kubernetes 呢？

不少人把目光投向了 Cycle.io。Cycle 是一個(gè)為開發(fā)人員構(gòu)建的低運(yùn)維平臺(tái)，是 Kubernetes 的競(jìng)爭(zhēng)對(duì)手。開發(fā)者看好有以下幾個(gè)原因：Cycle 將強(qiáng)大的容器編排與預(yù)配置的服務(wù)、自動(dòng)化網(wǎng)絡(luò)、基礎(chǔ)設(shè)施管理、完整的 DNS 解決方案、鏡像優(yōu)化等功能深度融合在一起；Cycle 有助于自動(dòng)向所有服務(wù)器提供平臺(tái)更新，企業(yè)可以從任何受支持的提供商部署本地的基礎(chǔ)架構(gòu)。這樣，跨云服務(wù)提供商的基礎(chǔ)架構(gòu)、數(shù)據(jù)和應(yīng)用程序，而不會(huì)被其中任何一個(gè)所束縛；此外，Cycle 完全符合 OCI，理念側(cè)重于“質(zhì)量?jī)?yōu)先于數(shù)量”。 

當(dāng)然容器編排領(lǐng)域還有許多不錯(cuò)的工具作為備選項(xiàng)，這里不一一詳述。

寫在最后 

當(dāng)下的 Kubernetes 非常流行，帶來了許多令人驚嘆的特性，擁躉者非常之多。許多采用 Kubernetes 的團(tuán)隊(duì)也非常滿意。然而，這些團(tuán)隊(duì)的實(shí)例卻大多是由谷歌或亞馬遜等有實(shí)力的云廠商來代為管理。這就會(huì)為企業(yè)的實(shí)際業(yè)務(wù)的開展埋下了隱患：一個(gè)是忽略了思考公司是否真的需要這些特性，另一個(gè)就是企業(yè)和開發(fā)者不能僅僅依靠這些“代為管理”式的抽象來支撐工作， 只有了解引底層發(fā)生了什么，才能做到真正的可控。

而不要僅僅因?yàn)槠渌硕歼@么做，就使用 Kubernetes。仔細(xì)評(píng)估實(shí)際的業(yè)務(wù)需求：你需要弄清楚你想要解決什么問題，你想要解決的痛點(diǎn)，以及你是否真的需要 Kubernetes。回答完這些問題后，您應(yīng)該將 Kubernetes 與其他更簡(jiǎn)單、更有效的選項(xiàng)（例如 Cycle）一起查看，并權(quán)衡每個(gè)選項(xiàng)的硬成本和軟成本。

例如，如果計(jì)劃在大規(guī)模的基礎(chǔ)設(shè)施上部署一系列同質(zhì)服務(wù)，那么 Kubernetes 可能是最佳選擇。只是要意識(shí)到額外的復(fù)雜性和操作成本。有些成本可以通過使用 Kubernetes 云服務(wù)環(huán)境來避免。如果你只是在尋找一個(gè)易于維護(hù)和擴(kuò)展的可靠編排服務(wù)，那就大材小用了。

畢竟，任何技術(shù)都是為業(yè)務(wù)所面臨的問題而服務(wù)的。你真的需要 Kubernetes？

參考鏈接：

https://dzone.com/articles/the-need-for-a-kubernetes-alternative

https://www.theregister.com/2021/02/25/google_kubernetes_autopilot/

https://dzone.com/articles/image-optimization-common-mistakes-and-solutions

https://zhuanlan.zhihu.com/p/346301133