Kubernetes的架構(gòu)非常適合大規(guī)模的組織，但是對(duì)于中小組織來(lái)說(shuō)，它可能會(huì)過(guò)于復(fù)雜。
作為開(kāi)源容器編排器，Kubernetes已經(jīng)成為組織部署容器化應(yīng)用程序的實(shí)際解決方案。這其中有一些充分的理由，其中包括Kubernetes提供高度的可靠性、自動(dòng)化、可擴(kuò)展性的事實(shí)。盡管如此，有此行業(yè)人士還是認(rèn)為Kubernetes架構(gòu)過(guò)于復(fù)雜。雖然已經(jīng)有6年以上的應(yīng)用歷史，但它還是有許多缺點(diǎn)。其中一些缺點(diǎn)是Kubernetes本身所固有的，而另一些缺點(diǎn)則是圍繞該平臺(tái)成長(zhǎng)起來(lái)的生態(tài)系統(tǒng)的產(chǎn)物。
在部署Kubernetes之前，企業(yè)需要考慮以下開(kāi)源容器編排器的一些問(wèn)題。
1. Kubernetes是為大規(guī)模的公司設(shè)計(jì)的
首先，Kubernetes架構(gòu)始終是為需要管理超大規(guī)模應(yīng)用程序環(huán)境的組織而構(gòu)建的。對(duì)于谷歌公司來(lái)說(shuō)(Borg編排者構(gòu)成了成為開(kāi)源Kubernetes項(xiàng)目的基礎(chǔ))，Kubernetes是一個(gè)很好的工具。而對(duì)于擁有數(shù)十個(gè)數(shù)據(jù)中心以及數(shù)千個(gè)分布在其中的應(yīng)用程序和服務(wù)的Netflix、Facebook、AWS等其他大規(guī)模的公司來(lái)說(shuō)，也是如此。
但是如果是一個(gè)規(guī)模較小的組織，并且只有一個(gè)可能只部署十幾個(gè)應(yīng)用程序的數(shù)據(jù)中心，那么Kubernetes架構(gòu)無(wú)疑規(guī)模過(guò)于龐大，這可能就像駕駛推土機(jī)為后院花園翻土一樣大材小用。除非是大規(guī)模使用，否則配置和管理它需要解決大量的問(wèn)題。
2. Kubernetes有很多發(fā)行版
Kubernetes架構(gòu)的另一個(gè)問(wèn)題是，Kubernetes有很多發(fā)行版，以及大量與其相關(guān)的不同的工具、理念和觀點(diǎn)。
當(dāng)然，在某種程度上，任何開(kāi)源生態(tài)系統(tǒng)中都會(huì)發(fā)生分裂。例如，RedHat Linux與Ubuntu Linux具有不同的軟件包管理器、管理工具等。但是，RedHat和Ubuntu的相似之處遠(yuǎn)大于區(qū)別。對(duì)于使用Red Hat系統(tǒng)的管理員來(lái)說(shuō)，如果要遷移到Ubuntu，則不需要花費(fèi)六個(gè)月的時(shí)間自學(xué)新工具。
行業(yè)專(zhuān)家并不認(rèn)為Kubernetes也是如此。如果現(xiàn)在正在使用OpenShift，但又想切換到VMware Tanzu，則其學(xué)習(xí)過(guò)程將非常艱巨。盡管這兩個(gè)Kubernetes發(fā)行版都使用相同的基礎(chǔ)平臺(tái)Kubernetes，但是它們添加的方法和工具卻截然不同。
基于云計(jì)算的Kubernetes服務(wù)也有類(lèi)似的分裂。Google Kubernetes Engine(GKE)與Amazon EKS(相當(dāng)于AWS云)等平臺(tái)相比，具有截然不同的用戶(hù)體驗(yàn)和管理工具套件。
當(dāng)然，這并不是Kubernetes架構(gòu)本身的錯(cuò)，而是不同供應(yīng)商嘗試使其Kubernetes產(chǎn)品實(shí)現(xiàn)差異化的結(jié)果。但是從Kubernetes用戶(hù)的角度來(lái)看，這仍然是一個(gè)現(xiàn)實(shí)問(wèn)題。
3. Kubernetes是多個(gè)部分組成的平臺(tái)
人們將Kubernetes當(dāng)作一個(gè)平臺(tái)，但實(shí)際上它由6個(gè)以上的不同組件組成。這意味著當(dāng)安裝或更新Kubernetes時(shí)，必須分別處理每個(gè)組件。而且大多數(shù)Kubernetes發(fā)行版都缺乏執(zhí)行這些操作的自動(dòng)化解決方案。
當(dāng)然，Kubernetes是一個(gè)復(fù)雜的平臺(tái)，它需要多個(gè)部分組合才能工作。但是與其他復(fù)雜平臺(tái)相比，Kubernetes在將其各個(gè)部分集成到一個(gè)易于管理的整體方面做得特別糟糕。典型Linux發(fā)行版也包含許多不同的軟件。但是用戶(hù)能夠以集中、簡(jiǎn)化的方式安裝和管理它們。Kubernetes架構(gòu)并非如此。
4. Kubernetes不會(huì)自動(dòng)地保證高可用性
使用Kubernetes的最常被提及的原因之一是，它以一種神奇的方式管理應(yīng)用程序，保證它們永遠(yuǎn)不會(huì)失敗，即使部分基礎(chǔ)設(shè)施出現(xiàn)故障。
確實(shí)，Kubernetes架構(gòu)可以做出明智的自動(dòng)決策，以決定將工作負(fù)載放置在集群中的位置。但是，Kubernetes并不是實(shí)現(xiàn)高可用性的靈丹妙藥。例如，它將在只有一個(gè)主節(jié)點(diǎn)的生產(chǎn)環(huán)境中運(yùn)行，這是關(guān)閉整個(gè)集群的方法(如果主要服務(wù)器出現(xiàn)故障，則整個(gè)集群將基本上停止運(yùn)行)。
Kubernetes也不能自動(dòng)保證在集群中運(yùn)行的不同工作負(fù)載之間正確分配資源。要進(jìn)行設(shè)置，用戶(hù)需要人工設(shè)置資源配額。
5.很難人工控制Kubernetes
盡管Kubernetes需要大量的人工干預(yù)才能提供高可用性，但是如果確實(shí)要這樣做，它會(huì)使人工控制變得相當(dāng)困難。
可以肯定的是，有一些方法可以修改Kubernetes執(zhí)行的探測(cè)時(shí)間，以確定容器是否正常運(yùn)行，或者強(qiáng)制工作負(fù)載在集群中的特定服務(wù)器上運(yùn)行。但是，Kubernetes架構(gòu)的設(shè)計(jì)并不期望管理員會(huì)進(jìn)行這些人工更改。
如上所述，Kubernetes首先是針對(duì)Web規(guī)模的部署，這是有道理的。如果用戶(hù)有數(shù)千臺(tái)服務(wù)器和數(shù)百個(gè)工作負(fù)載，將不會(huì)人工配置許多東西。但是如果是一家規(guī)模較小的公司，并且想要更好地控制集群中工作負(fù)載的結(jié)構(gòu)方式，那么采用Kubernetes很難做到這一點(diǎn)。
6. Kubernetes監(jiān)視和性能優(yōu)化面臨挑戰(zhàn)
Kubernetes試圖在保持工作負(fù)載正常運(yùn)行方面做得很好(盡管如上所述，其能力取決于諸如用戶(hù)設(shè)置的管理者數(shù)量以及如何組織資源分配等因素)。
但是Kubernetes架構(gòu)并不能幫助用戶(hù)監(jiān)視工作負(fù)載或確保它們表現(xiàn)最佳。它不會(huì)在出現(xiàn)問(wèn)題時(shí)向用戶(hù)發(fā)出警報(bào)，而且從集群中收集監(jiān)視數(shù)據(jù)也不太容易。Kubernetes發(fā)行版隨附的大多數(shù)監(jiān)視儀表板也無(wú)法提供對(duì)環(huán)境的深入可見(jiàn)性。采用第三方工具可以使用戶(hù)獲得可見(jiàn)性，但是如果要運(yùn)行Kubernetes，則必須設(shè)置、學(xué)習(xí)和管理這些工具。
同樣，Kubernetes也不擅長(zhǎng)幫助用戶(hù)優(yōu)化成本。它不會(huì)通知用戶(hù)集群中的服務(wù)器是否僅以20%的容量使用，這可能意味著用戶(hù)在過(guò)度配置的基礎(chǔ)設(shè)施方面浪費(fèi)了資金。同樣，第三方工具可以幫助用戶(hù)應(yīng)對(duì)諸如此類(lèi)的挑戰(zhàn)，但它們會(huì)增加復(fù)雜性。
7. Kubernetes將所有內(nèi)容簡(jiǎn)化為代碼
在Kubernetes中，完成幾乎所有任務(wù)都需要用戶(hù)編寫(xiě)代碼。通常情況下，其代碼采用YAML文件的形式，然后必須在Kubernetes命令行上應(yīng)用它們。
許多人會(huì)把Kubernetes架構(gòu)的所有代碼要求作為功能而不是錯(cuò)誤。然而，雖然使用單一方法和工具(即YAML文件)可以管理整個(gè)平臺(tái)，但確實(shí)希望Kubernetes能為需要它們的人提供其他選擇。
有時(shí)候，用戶(hù)不想編寫(xiě)一個(gè)很長(zhǎng)的YAML文件(或從GitHub中提取一個(gè)文件，然后人工調(diào)整其中的隨機(jī)部分以適合其環(huán)境)來(lái)部署簡(jiǎn)單的工作負(fù)載。用戶(hù)希望按下一個(gè)按鈕或運(yùn)行一個(gè)簡(jiǎn)單的命令(這指的是不需要十幾個(gè)參數(shù)的kubectl命令，其中許多參數(shù)都配置有必須復(fù)制和粘貼的數(shù)據(jù)串)。需要在Kubernetes中做一些簡(jiǎn)單的事情。但是這種情況很少發(fā)生。
8. Kubernetes希望控制一切
Kubernetes的最后一個(gè)問(wèn)題是，它的設(shè)計(jì)并不能很好地與其他類(lèi)型的系統(tǒng)配合。它希望成為用戶(hù)用來(lái)部署和管理應(yīng)用程序的唯一平臺(tái)。
如果用戶(hù)的所有工作負(fù)載都是容器化的，并且可以由Kubernetes進(jìn)行協(xié)調(diào)，這是一個(gè)很好的結(jié)果。但是，如果用戶(hù)擁有無(wú)法作為容器運(yùn)行的原有應(yīng)用程序怎么辦?或者，如果想在Kubernetes集群上運(yùn)行一部分工作負(fù)載，而又有一部分在外部運(yùn)行呢?Kubernetes不提供執(zhí)行這些操作的原生功能。其設(shè)計(jì)的前提是希望一直在容器中運(yùn)行所有內(nèi)容。
結(jié)論
Kubernetes其實(shí)是編排大型容器化應(yīng)用程序的強(qiáng)大工具。 Kubernetes有很多適合的用例。
但是Kubernetes架構(gòu)也有一些缺點(diǎn)?？傮w而言，如果用戶(hù)要管理原有的工作負(fù)載或部署規(guī)模不足以證明Kubernetes帶來(lái)的所有復(fù)雜性，那么就不是一個(gè)很好的解決方案。為了證明它的全部?jī)r(jià)值，Kubernetes應(yīng)該解決這些問(wèn)題，以便它可以完全匹配其在IT生態(tài)系統(tǒng)某些領(lǐng)域中享有的聲譽(yù)。
