很多情況下，應(yīng)用程序現(xiàn)代化的路徑是這樣的：首先，將應(yīng)用重構(gòu)為微服務(wù)；接下來，將每個服務(wù)容器化；最后，將其部署在Kubernetes上。Kubernetes是一種開源的編排引擎，已經(jīng)成為運行容器化應(yīng)用的一種事實標準平臺。

問題是，并非所有的現(xiàn)代化都遵循這種路徑。很多情況下，Kubernetes并不是現(xiàn)代軟件部署之旅的一部分。

盡管Kubernetes是一項優(yōu)秀的技術(shù)，但它遠不是適合所有應(yīng)用部署的最佳解決方案。即使你的應(yīng)用使用容器作為微服務(wù)運行，Kubernetes也不一定是部署這些應(yīng)用的最佳方式，還有其他更簡單的解決方案（例如Amazon ECS或者Lambda）可以用于運行容器。而且，如果你的應(yīng)用根本不是一組微服務(wù)，那么Kubernetes顯然也不是運行這些應(yīng)用的一個好方式。

那么，哪些類型的應(yīng)用實際上可以通過Kubernetes運行呢？應(yīng)用具備哪些功能要求或者架構(gòu)特征的情況下特別適合采用K8（Kubernetes追隨者有時候?qū)υ撈脚_的叫法）呢，或者反過來，更適合采用替代性的托管解決方案呢？

本文通過介紹使用Kubernetes部署應(yīng)用之前應(yīng)該具備的五個關(guān)鍵因素來回答這些問題。我們還將研究Kubernetes工作負載的“反模式”，即團隊在選擇是否用K8來運行給定工作負載時經(jīng)常犯的一些錯誤。

如何判斷你的應(yīng)用是否適合Kubernetes？

在評估應(yīng)用是否適合通過Kubernetes進行部署的時候，請考慮Kuberbetes與以下每個特征的匹配程度。

1、你的應(yīng)用是作為小型的、簡潔的、獨立的可擴展服務(wù)運行的

當應(yīng)用作為一組小型的、簡潔的服務(wù)運行的時候，它就非常適合Kubernetes。主要原因是Kubernetes可以獨立地動態(tài)擴展每個服務(wù)，反過來意味著你的應(yīng)用可以最有效地利用可用的托管資源。

相反，作為“單體”運行的應(yīng)用（也就是說整個應(yīng)用是作為單一服務(wù)運行的）并不能從Kubernetes中受益。選擇在K8上運行單體應(yīng)用，就意味著與選擇更簡單的部署模型（例如在獨立虛擬機上運行該應(yīng)用）相比，你將面臨更多的復(fù)雜性，而且也不會獲得很多好處，因為單體應(yīng)用是無法進行細粒度或者動態(tài)擴展的。

2、你的應(yīng)用是與硬件無關(guān)的

不需要特定硬件配置的應(yīng)用可以很好地運行在Kubernetes上，因為你可以使用K8s設(shè)置服務(wù)器集群并在這些集群之間部署應(yīng)用。Kubernetes會決定在集群中放置每個應(yīng)用的位置，并根據(jù)需要為應(yīng)用分配資源?；蛘?，你可以（通常應(yīng)該可以）定義Kubernetes在部署時應(yīng)該分配給每個應(yīng)用的資源最小值。

另一方面，如果你的應(yīng)用需要嚴格的CPU或者內(nèi)存分配（或者需要訪問專用硬件設(shè)備例如GPU），那么通常把應(yīng)用直接部署在虛擬機要比K8s集群更有意義。

3、你的應(yīng)用是眾多應(yīng)用之一，而且這些應(yīng)用可以在共享基礎(chǔ)設(shè)施上共存

Kubernetes允許你使用稱為命名空間的功能把工作負載彼此分割，命名空間本質(zhì)上是你可以在單個服務(wù)器集群中進行定義的虛擬邊界。但是，Kubernetes并不提供在專用虛擬機或者是物理服務(wù)器上運行每個應(yīng)用所獲得的“硬”應(yīng)用隔離。

這意味著，如果你有大量可以共享服務(wù)器集群的工作負載，而且每個工作負載都運行著自己的虛擬環(huán)境，那么Kubernetes非常適合，而如果你需要工作負載之間有堅如磐石的隔離，那么K8就不是那么好了。如果你只有少量的工作負載，這也沒有多大意義，在這種情況下，設(shè)置和管理Kubernetes的難度要超過它能帶來的價值。

4、你的應(yīng)用運行多個服務(wù)，有些是內(nèi)部的，有些是外部的

通常，現(xiàn)代應(yīng)用中只有一些微服務(wù)需要是外部的，意味著可以連接到應(yīng)用外部（但仍在公司網(wǎng)絡(luò)內(nèi)部）的資源，而其他服務(wù)（例如在應(yīng)用前端和后端數(shù)據(jù)庫之間內(nèi)部移動數(shù)據(jù)的服務(wù)）則不需要連接到應(yīng)用或者是托管這些應(yīng)用的服務(wù)器集群外部。

Kubernetes是此類應(yīng)用的絕佳解決方案，因為Kubernetes讓你能夠以細粒度的方式定義哪些服務(wù)將面向公司網(wǎng)絡(luò)，哪些服務(wù)僅限內(nèi)部，而且真正重要的是，它讓你可以保存企業(yè)網(wǎng)絡(luò)IP地址，這一點很重要，因為IP地址在企業(yè)環(huán)境中通常是有限供應(yīng)的。

5、你的應(yīng)用需要自定義DNS設(shè)置

Kubernetes讓管理員可以很好地控制網(wǎng)絡(luò)名稱的解析方式，這對于那些需要自定義域名設(shè)置（而不是使用通用DNS服務(wù)器）將IP地址映射到主機或服務(wù)名稱的應(yīng)用來說非常有用。

大多數(shù)傳統(tǒng)應(yīng)用并不需要特殊的DNS設(shè)置。但是在手動設(shè)置DNS配置的企業(yè)環(huán)境中，或者對于具有大量需要特殊DNS設(shè)置的內(nèi)部服務(wù)應(yīng)用來說，Kubernetes是很有用處的，因為Kubernetes提供了對DNS一定程度的控制和靈活性，而這在其他類型托管環(huán)境中是不具備的。

在什么情況下你絕不應(yīng)該使用Kubernetes

為了在是否使用Kubernetes的決策過程中多考慮一些背景信息，讓我們來看一下什么時候我們不走K8路線的一個例子。

當你有一個單體應(yīng)用的時候，你決定把它放到Docker容器中。盡管從技術(shù)角度來看，Kubernetes能夠運行你的容器化單體，但選擇在Kubernetes上部署這類應(yīng)用會讓你面臨很多挑戰(zhàn)，而且?guī)缀醪粫砣魏魏锰帯?/p>

你的應(yīng)用將無法有效地消耗主機資源，因為Kubernetes無法對應(yīng)用的不同部分進行單獨的擴展。這個應(yīng)用作為一個整體，只能整體地橫向或者是縱向擴展。

你的容器化單體也可能需要在不同的交付階段（例如開發(fā)、測試和生產(chǎn)）進行不同的配置，這意味著你將無法享受到容器在一致性配置方面帶來的好處，例如由于配置錯誤導(dǎo)致的故障幾率會降低。

最糟糕的是，你最終也許不得不把安全配置數(shù)據(jù)（例如訪問憑證）拷貝到你的單體容器映像中，這無形中增加了敏感信息落入壞人之手的風險。

底線是，雖然從技術(shù)上講沒有什么能夠阻止你在Kubernetes以容器的形式運行單體應(yīng)用，但這么做絕對不是一個好主意。這是在Kubernetes上獲取應(yīng)用的一種方式，但客觀上來說這是一種糟糕的方式。

最后，我要強調(diào)的是，我并不是反對Kubernetes。Kubernetes確實可以提供很多東西，特別是對于那些以離散微服務(wù)的方式運行的應(yīng)用，這些應(yīng)用可以在共享集群上運行良好，并且需要特殊的網(wǎng)絡(luò)配置。

但對于其他應(yīng)用來說，很可能存在一種替代性的部署解決方案，它的設(shè)置和管理都要比Kubernetes更簡單，同時還能提供更高的性能、可擴展性和成本節(jié)約優(yōu)勢。在你僅僅因為其他人都這么做而加入Kubernetes潮流之前，重要的是退后一步，想想哪種部署策略最適合你特定的應(yīng)用，而不是最流行的那種。