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

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

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

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

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

如何判斷你的應用是否適合Kubernetes？

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

1、你的應用是作為小型的、簡潔的、獨立的可擴展服務運行的

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

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

2、你的應用是與硬件無關的

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

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

3、你的應用是眾多應用之一，而且這些應用可以在共享基礎設施上共存

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

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

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

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

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

5、你的應用需要自定義DNS設置

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

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

在什么情況下你絕不應該使用Kubernetes

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

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

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

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

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

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

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

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