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沒有提供原生的功能來做這類事情。它的設計假設是每個人都想一直使用容器運行所有的內容。
總結
爲了避免有人指責我討厭Kubernetes，讓我重申一下，它是編排大型容器化應用程序的強大工具。然而Kubernetes架構也有一些缺點。總的來說，如果您需要管理的工作負載，或者您的部署規模不夠大，不足以證明Kubernetes帶來的複雜性，那麼它就不是一個很好的解決方案。爲了證明它的全部價值，Kubernetes應該解決您的複雜問題，這樣它才能完全達到它在it生態系統的某些領域所享有的聲譽。
推薦
從Ice到Kubernetes容器技術，微服務架構經歷了什麼？
隨手關注或者”在看“，誠摯感謝！
本文分享自微信公衆號 - 雲原生技術愛好者社區（programmer_java）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。