現階段Kubernetes架構的8個問題

Kubernetes的架構非常適合大規模的組織，但是對於中小組織來說，它可能會過於複雜。

作為開源容器編排器，Kubernetes已經成為組織部署容器化應用程式的實際解決方案。這其中有一些充分的理由，其中包括Kubernetes提供高度的可靠性、自動化、可擴充套件性的事實。儘管如此，有此行業人士還是認為Kubernetes架構過於複雜。雖然已經有6年以上的應用歷史，但它還是有許多缺點。其中一些缺點是Kubernetes本身所固有的，而另一些缺點則是圍繞該平臺成長起來的生態系統的產物。

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

首先，Kubernetes架構始終是為需要管理超大規模應用程式環境的組織而構建的。對於谷歌公司來說(Borg編排者構成了成為開源Kubernetes專案的基礎)，Kubernetes是一個很好的工具。而對於擁有數十個資料中心以及數千個分佈在其中的應用程式和服務的Netflix、Facebook、AWS等其他大規模的公司來說，也是如此。

但是如果是一個規模較小的組織，並且只有一個可能只部署十幾個應用程式的資料中心，那麼Kubernetes架構無疑規模過於龐大，這可能就像駕駛推土機為後院花園翻土一樣大材小用。除非是大規模使用，否則配置和管理它需要解決大量的問題。

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

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

行業專家並不認為Kubernetes也是如此。如果現在正在使用OpenShift，但又想切換到VMware Tanzu，則其學習過程將非常艱鉅。儘管這兩個Kubernetes發行版都使用相同的基礎平臺Kubernetes，但是它們新增的方法和工具卻截然不同。

基於雲端計算的Kubernetes服務也有類似的分裂。Google Kubernetes Engine(GKE)與Amazon EKS(相當於AWS雲)等平臺相比，具有截然不同的使用者體驗和管理工具套件。

當然，這並不是Kubernetes架構本身的錯，而是不同供應商嘗試使其Kubernetes產品實現差異化的結果。但是從Kubernetes使用者的角度來看，這仍然是一個現實問題。

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

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

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

確實，Kubernetes架構可以做出明智的自動決策，以決定將工作負載放置在叢集中的位置。但是，Kubernetes並不是實現高可用性的靈丹妙藥。例如，它將在只有一個主節點的生產環境中執行，這是關閉整個叢集的方法(如果主要伺服器出現故障，則整個叢集將基本上停止執行)。

Kubernetes也不能自動保證在叢集中執行的不同工作負載之間正確分配資源。要進行設定，使用者需要人工設定資源配額。

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

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

如上所述，Kubernetes首先是針對Web規模的部署，這是有道理的。如果使用者有數千臺伺服器和數百個工作負載，將不會人工配置許多東西。但是如果是一家規模較小的公司，並且想要更好地控制叢集中工作負載的結構方式，那麼採用Kubernetes很難做到這一點。

Kubernetes試圖在保持工作負載正常執行方面做得很好(儘管如上所述，其能力取決於諸如使用者設定的管理者數量以及如何組織資源分配等因素)。

但是Kubernetes架構並不能幫助使用者監視工作負載或確保它們表現最佳。它不會在出現問題時向使用者發出警報，而且從叢集中收集監視資料也不太容易。Kubernetes發行版隨附的大多數監視儀表板也無法提供對環境的深入可見性。採用第三方工具可以使使用者獲得可見性，但是如果要執行Kubernetes，則必須設定、學習和管理這些工具。

同樣，Kubernetes也不擅長幫助使用者最佳化成本。它不會通知使用者叢集中的伺服器是否僅以20%的容量使用，這可能意味著使用者在過度配置的基礎設施方面浪費了資金。同樣，第三方工具可以幫助使用者應對諸如此類的挑戰，但它們會增加複雜性。

在Kubernetes中，完成幾乎所有任務都需要使用者編寫程式碼。通常情況下，其程式碼採用YAML檔案的形式，然後必須在Kubernetes 行上應用它們。

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

有時候，使用者不想編寫一個很長的YAML檔案(或從GitHub中提取一個檔案，然後人工調整其中的隨機部分以適合其環境)來部署簡單的工作負載。使用者希望按下一個按鈕或執行一個簡單的 (這指的是不需要十幾個引數的kubectl命令，其中許多引數都配置有必須複製和貼上的資料串)。需要在Kubernetes中做一些簡單的事情。但是這種情況很少發生。

Kubernetes的最後一個問題是，它的設計並不能很好地與其他型別的系統配合。它希望成為使用者用來部署和管理應用程式的唯一平臺。

如果使用者的所有工作負載都是容器化的，並且可以由Kubernetes進行協調，這是一個很好的結果。但是，如果使用者擁有無法作為容器執行的原有應用程式怎麼辦?或者，如果想在Kubernetes叢集上執行一部分工作負載，而又有一部分在外部執行呢?Kubernetes不提供執行這些操作的原生功能。其設計的前提是希望一直在容器中執行所有內容。

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

但是Kubernetes架構也有一些缺點。總體而言，如果使用者要管理原有的工作負載或部署規模不足以證明Kubernetes帶來的所有複雜性，那麼就不是一個很好的解決方案。為了證明它的全部價值，Kubernetes應該解決這些問題，以便它可以完全匹配其在IT生態系統某些領域中享有的聲譽。

原文地址：