?k8s已經(jīng)成為一個家喻戶曉的容器編配的工具。不可否認，它已經(jīng)成為許多開發(fā)人員的理想解決方案。但是Kubernetes真的完美無瑕嗎？相反，你可以從對Kubernetes提供的各種可能性充滿熱情，轉(zhuǎn)變?yōu)樵噲D解決一路上出現(xiàn)的許多問題而感到沮喪。這就是為什么越來越多的組織開始尋找更容易使用的 Kubernetes 替代品。本文強調(diào)了這些替代品的必要性，并提出了一個強有力的競爭者，以取代Kubernetes。

Kubernetes試圖解決的問題

Kubernetes 最初是谷歌開發(fā)的開源版本的 Borg，它是谷歌過于復(fù)雜的容器管理平臺，但后來發(fā)展成為一個全球性的運動。它目前由云計算原生計算基金會(CNCF)控制，并由大量貢獻者維護。

Kubernetes 已經(jīng)成為自動化軟件部署、容器管理和基礎(chǔ)設(shè)施伸縮的事實標準。它運行具有內(nèi)置默認副本和自動伸縮的容器化應(yīng)用程序，以確保它們是健康的、在線的并且可以快速伸縮。

任何 Kubernetes 基礎(chǔ)設(shè)施的核心都是容器，它去掉了 VM 中不必要的部分，比如管理程序(hypervisor) ，只將操作系統(tǒng)和應(yīng)用程序的必要組件包裝成一個整潔的包。

組織尋求替代方案面臨的挑戰(zhàn)

1. Kubernetes可能會過度消耗

大多數(shù)組織的運營規(guī)模不及谷歌或 Facebook。我們說的是18個數(shù)據(jù)中心，占地4000萬平方英尺，花費200億美元。McAfee 稱，“員工少于1000人的公司平均運行22個定制應(yīng)用程序?！蓖猓@些應(yīng)用程序仍然需要現(xiàn)代技術(shù)和方法來有效地管理它們。然而，Kubernetes 的技術(shù)實力過于強大，甚至可能分散人們對應(yīng)用程序本身的注意力。

2. Kubernetes 太過復(fù)雜

Kubernetes 最初的目標相當簡單——“靈活地運行分布式系統(tǒng)”但是這個簡單的目的在目前的情況下似乎變得太混亂了。甚至谷歌的評論也說，“用戶很難正確配置 Kubernetes”，而像 Istio 這樣的工具也很難安裝和使用。Kubernetes斯試圖解決太多的問題，導(dǎo)致平臺被拉向太多的方向。

3. 擁有和維護費用高

盡管 Kubernetes 可以免費使用，但這是一種非常昂貴的產(chǎn)品。它具有管理基礎(chǔ)設(shè)施以及優(yōu)化運行在其上的工作負載的隱性成本。所以，就保持形狀所花費的時間而言，Kubernetes是昂貴的。

4. 艱難繁瑣的過渡

移民到 Kubernetes 是一項艱巨而艱難的任務(wù)。要做到這一點，您需要重構(gòu)體系結(jié)構(gòu)的一些部分或全部。您還需要一個龐大的團隊來確保 Kubernetes 集群的運行。即使您設(shè)法構(gòu)建了一個維護良好的 Kubernetes 設(shè)置，要從一個基本的集群到一個可靠的生產(chǎn)環(huán)境，仍然有大量的工作要做。

人們在尋找什么？

容器與云編排的一種自主方法

在軟件世界，Kubernetes 試圖為所有人提供所有東西，但它已變得過于復(fù)雜。Kubernetes 的魅力已經(jīng)消失殆盡，人們開始尋找替代方案，為容器編排提供一種固執(zhí)己見的方式。

更簡單的開始方式

各種各樣的工具被用來幫助處理和管理 Kubernetes 錯綜復(fù)雜的問題。Kubernetes 的不同地區(qū)需要額外的工具來加以補充。這意味著在開始在生產(chǎn) Kubernetes 集群中運行應(yīng)用程序之前，您必須學(xué)習(xí)操作多個迷你工具。當您嘗試跨多個基礎(chǔ)設(shè)施提供程序進行部署時，這種工作負載會變得更加復(fù)雜。許多人希望能夠從這個學(xué)習(xí)過程中解脫出來，把大量不同的工具拼湊起來，以便開始學(xué)習(xí)。任何有助于避免這種混亂局面的替代方案都是可喜的變化。

開發(fā)人員可以在沒有 DevOps 團隊的情況下進行構(gòu)建

當涉及到使用以復(fù)雜性著稱的系統(tǒng)時，構(gòu)建過程會顯著減慢。這是因為對于以前沒有使用過基礎(chǔ)設(shè)施的開發(fā)人員來說，習(xí)慣 Kubernetes 開發(fā)工作流是相當困難的。此外，即使是非常熟悉該框架的開發(fā)人員也需要 Kubernetes 專家和 DevOps 團隊幫助他們克服遇到的各種瓶頸。這最終會降低生產(chǎn)力并延長發(fā)布周期。因此，組織正在尋找消除開發(fā)人員對 DevOps 團隊依賴的方法。他們希望給予開發(fā)人員在需要時訪問所需資源的靈活性和自主權(quán)。

為什么使用cycle作為Kubernetes的替代品？

K8s家族在容器管理領(lǐng)域占據(jù)統(tǒng)治地位已有數(shù)年之久，直到人們充分認識到需要一種替代方案。這種需求導(dǎo)致了新的解決方案的出現(xiàn)，這些方案可以做到Kubernetes所做的事情，而不會帶來麻煩和復(fù)雜性。其中一個解決方案是 Cycle.io，這是一個為開發(fā)者打造的低端操作平臺，可以與Kubernetes競爭。

Cycle 將強大的容器編排與預(yù)先配置的服務(wù)、自動化網(wǎng)絡(luò)、基礎(chǔ)設(shè)施管理、完整的 DNS 解決方案和映像管理相結(jié)合。它幫助向所有服務(wù)器自動交付平臺更新。該循環(huán)還允許您從任何受支持的提供程序部署自己的基礎(chǔ)設(shè)施。因此，您可以在任何云服務(wù)提供商之間擁有自己的基礎(chǔ)設(shè)施、數(shù)據(jù)和應(yīng)用程序，而不必被鎖定在其中任何一個服務(wù)提供商之中。該周期是完全符合 OCI (開放容器倡議)的，并側(cè)重于優(yōu)先考慮質(zhì)量超過數(shù)量。

結(jié)論

多年來，Kubernetes一直是每個人都要求采納的熱門話題。所以，被它的受歡迎程度掃地出門才是公平的。但是，重要的是要記住容器編排是關(guān)于解決您的業(yè)務(wù)面臨的技術(shù)問題。你需要弄清楚你想要解決的問題是什么，你正在尋找的目標是哪些痛點，以及你是否真的需要Kubernetes。在你回答這些問題之后，你應(yīng)該看看 Kubernetes 和其他更簡單更有效的選項，比如 Cycle，并權(quán)衡每個選項的硬成本和軟成本。我希望本文可以作為一個指南，幫助您獲得一個新的視角，并為您的組織做出正確的決策。?