Kubernetes的架構(gòu)非常適合大規(guī)模的組織，但是對于中小組織來說，它可能會過于復雜。

作為開源容器編排器，Kubernetes已經(jīng)成為組織部署容器化應用程序的實際解決方案。這其中有一些充分的理由，其中包括Kubernetes提供高度的可靠性、自動化、可擴展性的事實。盡管如此，有此行業(yè)人士還是認為Kubernetes架構(gòu)過于復雜。雖然已經(jīng)有6年以上的應用歷史，但它還是有許多缺點。其中一些缺點是Kubernetes本身所固有的，而另一些缺點則是圍繞該平臺成長起來的生態(tài)系統(tǒng)的產(chǎn)物。

在部署Kubernetes之前，企業(yè)需要考慮以下開源容器編排器的一些問題。

1. Kubernetes是為大規(guī)模的公司設計的

首先，Kubernetes架構(gòu)始終是為需要管理超大規(guī)模應用程序環(huán)境的組織而構(gòu)建的。對于谷歌公司來說（Borg編排者構(gòu)成了成為開源Kubernetes項目的基礎），Kubernetes是一個很好的工具。而對于擁有數(shù)十個數(shù)據(jù)中心以及數(shù)千個分布在其中的應用程序和服務的Netflix、Facebook、AWS等其他大規(guī)模的公司來說，也是如此。

但是如果是一個規(guī)模較小的組織，并且只有一個可能只部署十幾個應用程序的數(shù)據(jù)中心，那么Kubernetes架構(gòu)無疑規(guī)模過于龐大，這可能就像駕駛推土機為后院花園翻土一樣大材小用。除非是大規(guī)模使用，否則配置和管理它需要解決大量的問題。

2. Kubernetes有很多發(fā)行版

Kubernetes架構(gòu)的另一個問題是，Kubernetes有很多發(fā)行版，以及大量與其相關(guān)的不同的工具、理念和觀點。

當然，在某種程度上，任何開源生態(tài)系統(tǒng)中都會發(fā)生分裂。例如，RedHat Linux與Ubuntu Linux具有不同的軟件包管理器、管理工具等。但是，RedHat和Ubuntu的相似之處遠大于區(qū)別。對于使用Red Hat系統(tǒng)的管理員來說，如果要遷移到Ubuntu，則不需要花費六個月的時間自學新工具。

行業(yè)專家并不認為Kubernetes也是如此。如果現(xiàn)在正在使用OpenShift，但又想切換到VMware Tanzu，則其學習過程將非常艱巨。盡管這兩個Kubernetes發(fā)行版都使用相同的基礎平臺Kubernetes，但是它們添加的方法和工具卻截然不同。

基于云計算的Kubernetes服務也有類似的分裂。Google Kubernetes Engine（GKE）與Amazon EKS（相當于AWS云）等平臺相比，具有截然不同的用戶體驗和管理工具套件。

當然，這并不是Kubernetes架構(gòu)本身的錯，而是不同供應商嘗試使其Kubernetes產(chǎn)品實現(xiàn)差異化的結(jié)果。但是從Kubernetes用戶的角度來看，這仍然是一個現(xiàn)實問題。

3. Kubernetes是多個部分組成的平臺

人們將Kubernetes當作一個平臺，但實際上它由6個以上的不同組件組成。這意味著當安裝或更新Kubernetes時，必須分別處理每個組件。而且大多數(shù)Kubernetes發(fā)行版都缺乏執(zhí)行這些操作的自動化解決方案。

當然，Kubernetes是一個復雜的平臺，它需要多個部分組合才能工作。但是與其他復雜平臺相比，Kubernetes在將其各個部分集成到一個易于管理的整體方面做得特別糟糕。典型Linux發(fā)行版也包含許多不同的軟件。但是用戶能夠以集中、簡化的方式安裝和管理它們。Kubernetes架構(gòu)并非如此。

4. Kubernetes不會自動地保證高可用性

使用Kubernetes的最常被提及的原因之一是，它以一種神奇的方式管理應用程序，保證它們永遠不會失敗，即使部分基礎設施出現(xiàn)故障。

確實，Kubernetes架構(gòu)可以做出明智的自動決策，以決定將工作負載放置在集群中的位置。但是，Kubernetes并不是實現(xiàn)高可用性的靈丹妙藥。例如，它將在只有一個主節(jié)點的生產(chǎn)環(huán)境中運行，這是關(guān)閉整個集群的方法（如果主要服務器出現(xiàn)故障，則整個集群將基本上停止運行）。

Kubernetes也不能自動保證在集群中運行的不同工作負載之間正確分配資源。要進行設置，用戶需要人工設置資源配額。

5.很難人工控制Kubernetes

盡管Kubernetes需要大量的人工干預才能提供高可用性，但是如果確實要這樣做，它會使人工控制變得相當困難。

可以肯定的是，有一些方法可以修改Kubernetes執(zhí)行的探測時間，以確定容器是否正常運行，或者強制工作負載在集群中的特定服務器上運行。但是，Kubernetes架構(gòu)的設計并不期望管理員會進行這些人工更改。

如上所述，Kubernetes首先是針對Web規(guī)模的部署，這是有道理的。如果用戶有數(shù)千臺服務器和數(shù)百個工作負載，將不會人工配置許多東西。但是如果是一家規(guī)模較小的公司，并且想要更好地控制集群中工作負載的結(jié)構(gòu)方式，那么采用Kubernetes很難做到這一點。

6. Kubernetes監(jiān)視和性能優(yōu)化面臨挑戰(zhàn)

Kubernetes試圖在保持工作負載正常運行方面做得很好（盡管如上所述，其能力取決于諸如用戶設置的管理者數(shù)量以及如何組織資源分配等因素）。

但是Kubernetes架構(gòu)并不能幫助用戶監(jiān)視工作負載或確保它們表現(xiàn)最佳。它不會在出現(xiàn)問題時向用戶發(fā)出警報，而且從集群中收集監(jiān)視數(shù)據(jù)也不太容易。Kubernetes發(fā)行版隨附的大多數(shù)監(jiān)視儀表板也無法提供對環(huán)境的深入可見性。采用第三方工具可以使用戶獲得可見性，但是如果要運行Kubernetes，則必須設置、學習和管理這些工具。

同樣，Kubernetes也不擅長幫助用戶優(yōu)化成本。它不會通知用戶集群中的服務器是否僅以20%的容量使用，這可能意味著用戶在過度配置的基礎設施方面浪費了資金。同樣，第三方工具可以幫助用戶應對諸如此類的挑戰(zhàn)，但它們會增加復雜性。

7. Kubernetes將所有內(nèi)容簡化為代碼

在Kubernetes中，完成幾乎所有任務都需要用戶編寫代碼。通常情況下，其代碼采用YAML文件的形式，然后必須在Kubernetes命令行上應用它們。

許多人會把Kubernetes架構(gòu)的所有代碼要求作為功能而不是錯誤。然而，雖然使用單一方法和工具（即YAML文件）可以管理整個平臺，但確實希望Kubernetes能為需要它們的人提供其他選擇。

有時候，用戶不想編寫一個很長的YAML文件（或從GitHub中提取一個文件，然后人工調(diào)整其中的隨機部分以適合其環(huán)境）來部署簡單的工作負載。用戶希望按下一個按鈕或運行一個簡單的命令（這指的是不需要十幾個參數(shù)的kubectl命令，其中許多參數(shù)都配置有必須復制和粘貼的數(shù)據(jù)串）。需要在Kubernetes中做一些簡單的事情。但是這種情況很少發(fā)生。

8. Kubernetes希望控制一切

Kubernetes的最后一個問題是，它的設計并不能很好地與其他類型的系統(tǒng)配合。它希望成為用戶用來部署和管理應用程序的唯一平臺。

如果用戶的所有工作負載都是容器化的，并且可以由Kubernetes進行協(xié)調(diào)，這是一個很好的結(jié)果。但是，如果用戶擁有無法作為容器運行的原有應用程序怎么辦？或者，如果想在Kubernetes集群上運行一部分工作負載，而又有一部分在外部運行呢？Kubernetes不提供執(zhí)行這些操作的原生功能。其設計的前提是希望一直在容器中運行所有內(nèi)容。

結(jié)論

Kubernetes其實是編排大型容器化應用程序的強大工具。 Kubernetes有很多適合的用例。

但是Kubernetes架構(gòu)也有一些缺點?？傮w而言，如果用戶要管理原有的工作負載或部署規(guī)模不足以證明Kubernetes帶來的所有復雜性，那么就不是一個很好的解決方案。為了證明它的全部價值，Kubernetes應該解決這些問題，以便它可以完全匹配其在IT生態(tài)系統(tǒng)某些領(lǐng)域中享有的聲譽。