Kubernetes架構非常適合有一定服務規模的組織，但它對其他人來說可能過于復雜。

開源容器編排平臺Kubernetes已經成為任何在生產環境中部署容器化應用程序的人事實上的解決方案。這有很多原因，包括Kubernetes提供了高度的可靠性、自動化和可伸縮性。盡管如此，我有時認為Kubernetes的架構被過分夸大了。盡管現在已經6歲多了，它還是有各種各樣的缺點。其中一些是Kubernetes本身固有的，而另一些則是圍繞平臺發展起來的生態系統的產物。

在您加入Kubernetes的行列之前，請考慮以下關于開源容器編排平臺的問題。

Kubernetes是為有一定網絡規模的公司設計的。

首先，Kubernetes體系結構是為那些需要管理非常大規模的應用程序環境的公司而構建的。

如果您是谷歌(它的Borg orchestrator為后來的開源Kubernetes項目奠定了基礎)，那么Kubernetes是一個偉大的工具。如果你是Netflix、Facebook、亞馬遜(Amazon)或其他擁有數十個數據中心、數百個應用程序和服務的網絡規模公司，這也是正確的。

但是，如果您是一個擁有一個數據中心和十幾個應用程序需要部署的較小的組織，那么Kubernetes體系結構可以說是多余的。這就像用推土機為后院草地翻土一樣。除非大規模地使用它，否則配置和管理它所需要的努力是不值得的。

這并不是說Kubernetes永遠不適合小規模的部署。我認為它正朝著那個方向發展。但是，現在每當我啟動Kubernetes集群，在少數服務器上部署一兩個應用程序時，我就確信使用更簡單的解決方案會更好。

支離破碎的Kubernetes生態

Kubernetes架構的另一個問題是，有太多的Kubernetes發行版——以及與之相關的太多不同的工具、哲學和觀點——Kubernetes生態系統已經高度斷裂。

當然，在某種程度上，任何開源生態系統都會發生破裂。

例如，Red Hat Enterprise Linux與Ubuntu Linux有不同的包管理器、管理工具等。然而，Red Hat和Ubuntu的相似之處多于它們的不同之處。如果你是Red Hat的系統管理員，如果你想要遷移到Ubuntu，你不需要花六個月的時間來教自己新的工具。

我不認為Kubernetes也能這么說。如果你現在正在使用OpenShift，但想要切換到VMware Tanzu，你將面臨一個非常陡峭的學習曲線。盡管這兩個Kubernetes發行版使用相同的底層平臺——Kubernetes，但它們所添加的方法和工具卻截然不同。

基于云計算的Kubernetes服務也存在類似的分裂。谷歌Kubernetes引擎(GKE)的用戶體驗和管理工具套件與Amazon EKS等AWS云平臺截然不同。

當然，這不是Kubernetes架構本身的錯。這是不同供應商試圖將Kubernetes產品區分開來的結果。但從Kubernetes用戶的角度來看，這仍然是一個真正的問題。

Kubernetes的組件太多了

我們談論Kubernetes時，好像它是一個單一的平臺，但實際上它包含了超過6個不同的組件。這意味著，當你安裝或更新Kubernetes時，你必須分別處理每個部分。而且大多數Kubernetes發行版都缺乏很好的自動化解決方案來做這些事情。

當然，Kubernetes確實是一個復雜的平臺，它需要多個部分來工作。但是與其他復雜的平臺相比，Kubernetes在將其各個部分集成到一個易于管理的整體方面做得特別差。典型的Linux發行版也由許多不同的軟件組成。但是您可以以一種集中的、精簡的方式安裝和管理它們。Kubernetes的架構并非如此。

Kubernetes不會自動保證高可用性

使用Kubernetes的一個最常見的原因是，它神奇地以一種方式管理你的應用程序，以確保它們永遠不會失敗，即使你的部分基礎設施失敗。

Kubernetes體系結構確實能夠智能、自動地決定在集群中將工作負載放置在何處。然而，Kubernetes并不是高可用性的靈丹妙藥。例如，它在只有一個主節點的生產環境中正常運行，這將導致整個集群崩潰。(如果主服務器故障，整個集群將基本停止工作。)

Kubernetes也不能自動保證在集群中運行的不同工作負載之間合理分配資源。為此，您需要手動設置資源配額。

很難手動控制Kubernetes

盡管Kubernetes需要大量的手動干預來提供高可用性，但如果您真正想要手動控制的話，它會使手動控制變得相當困難。

可以肯定的是，有一些方法可以修改Kubernetes執行探針時間，以確定容器是否正確地執行，或者強制工作負載在集群中的特定服務器上運行。但是Kubernetes體系結構的設計初衷并不是讓管理員手動進行這些更改。它假設您總是喜歡使用默認值。

這是有意義的，因為(如上所述)Kubernetes首先是為web規模的部署而創建的。如果您有數千臺服務器和數百個工作負載，您不需要手動配置很多東西。但是，如果您是一個規模較小的企業，希望對集群內的工作負載結構有更多的控制，那么Kubernetes很難做到這一點。

Kubernetes監控和性能優化存在一些挑戰

Kubernetes試圖讓您的工作負載保持正常運行(盡管如上所述，它做到這一點的能力取決于一些因素，比如您設置了多少個主機以及您如何結構化的進行資源分配)。

但是Kubernetes體系結構并不能幫助您監控工作負載或確保它們的性能達到最佳。當出現問題時，它不會向您發出警報，而且從集群中收集監控數據并不容易。Kubernetes發行版附帶的大多數監視儀表板也沒有提供對環境的深入可見性。有第三方工具可以給你提供可見性，但如果你想運行Kubernetes，這些是你必須建立、學習和管理的另一件事。

同樣，Kubernetes也不擅長幫助您優化成本。如果集群中的服務器僅被使用了20%的容量，它不會通知您，這可能意味著您在過度供應的基礎設施上浪費資源。在這里，第三方工具可以幫助您應對類似的挑戰，但它們增加了更多的復雜性。

Kubernetes將一切都簡化為代碼

在Kubernetes中，完成任何任務都需要編寫代碼。通常，這些代碼采用YAML文件的形式，然后必須應用于Kubernetes命令行。

許多人將Kubernetes體系結構的一切皆代碼的需求視為一種特性，而不是一個bug。然而，當然我理解使用單一方法和工具(意味著YAML文件)管理整個平臺的價值，但我確實希望Kubernetes能為需要它們的人們提供其他選項。

有時候，我不想編寫一個很長的YAML文件(或者從GitHub中提取一個YAML文件，然后手動調整其中的隨機部分以適應我的環境)來部署一個簡單的工作負載。我真希望我可以按下一個按鈕或運行一個簡單的命令(我指的是kubectl命令不需要12個參數,其中許多配置了神秘的數據字符串必須復制粘貼)有沒有辦法在Kubernetes做一些簡單的操作就可以完成這個過程。但就目前而言無法實現。

Kubernetes想要控制一切

我對Kubernetes的最后一個抱怨是，它的設計并不能很好地與其他類型的系統一起運行。它希望成為您用于部署和管理應用程序的唯一平臺。

如果您的所有工作負載都是容器化的，并且可以由Kubernetes進行編排，那就太好了。但是，如果您的遺留應用程序不能作為容器運行呢?或者，如果希望在Kubernetes集群上運行部分工作負載，而在外部運行另一部分工作負載，又該怎么辦?Kubernetes沒有提供原生的功能來做這類事情。它的設計假設是每個人都想一直使用容器運行所有的內容。