我真的需要Kubernetes嗎？

如果你關注技術新聞，那麼Kubernetes似乎無處不在。它已經變得非常流行。實際上，如果不使用Kubernetes，開發人員和DevOps團隊可能會覺得他們的應用程式開發流水線已經過時了。

Kubernetes是用于容器化應用程式的編排工具。從Docker容器開始，Kubernetes可以控制雲應用程式和微服務的資源配置設定和流量管理。

這樣，Kubernetes簡化了面向服務的應用程式基礎結構的許多方面。除了持續內建和持續部署（CI/CD），Kubernetes還提供了擴充這些應用程式的基礎設施，而無需付出大量的工作。

使用Kubernetes來管理雲和混合雲環境有很多令人興奮的事情。但是很多團隊經常追趕熱點并過早地遷移到Kubernetes，常常會造成會大量時間，金錢浪費，和開發人員的挫敗感。

在本文中，我們将嘗試并幫助你回答以下問題：我真的需要Kubernetes？

Kubernetes會做什麼？

Kubernetes是用于容器化應用程式的編排工具。它負責：

• 部署鏡像和容器
• 管理容器和叢集的擴充
• 容器和叢集的資源管理
• 服務的流量管理

當你的應用程式由運作在不同容器中的多個服務組成時，Kubernetes确實會帶來很多好處。對于具有靜态使用者群的單體應用，這可能超出了必要。

建構，測試并将應用程式傳遞到容器倉庫的任務不是Kubernetes的一部分，這些使用CI/CD工具就可以完成工作。除了CI/CD流水線，Kubernetes還可以幫助你将應用部署到生産環境中而不會造成服務停機。

改善單體應用

大多數應用程式都是以單體形式開始的--将整個應用程式放在一個地方，可以快速輕松地進行和部署更改。但是，如果你的應用程式發展壯大，你需要很快找到擴大規模的方法。

這是否意味着該是Kubernetes的時候了？可能不是。

通常，擴充更多地是關于應用程式的内部，而不是進階架構和工具。例如，你可以通過使用支援相似性标簽的負載均衡器部署多個執行個體來擴充整體。

擴充應用程式時要考慮的第一步是測試驅動開發（TDD），它可以確定軟體品質并防止随着應用程式的增長而出現問題。盡管較小的子產品或服務更易于測試，但子產品化也意味着對mocking需求增加，并且需要額外的工具來配置和維護。良好的測試可以使你輕松自信地建構和擴充應用程式。

當你開始擴充整體時，Chef和Ansible等配置管理工具會派上用場。你可以使用它們來自動配置新伺服器，以確定它們準備好運作你的應用程式。你甚至可以更進一步，并使用Terraform之類的工具來幫助配置新的伺服器VM，這樣你就不必手動建立它們。

當應用程式的其他部分成為瓶頸（例如資料庫）時，你也可以擴充這些部分。例如，如果資料庫成為瓶頸，則可以将經常通路的資料移至高性能記憶體資料存儲（如Redis）中，以減少資料庫的負載。

無論你使用哪種配置管理和配置工具，都必須有一個良好的CI/CD流水線。第一次部署應用程式時，你可能已認證FTP将zip檔案複制到伺服器，但是這種方法無法擴充。簡化的CI/CD流水線可確定自動建構，測試和部署你的應用程式，而無需你或你的團隊進行任何額外的工作。

你甚至可以使用AWS Elastic Beanstalk，Google App Engine或Azure App Service等雲服務自動縮放單體應用。與Kubernetes相比，所有這些都帶來了更少的管理開銷，并且它們都可以與CI/CD工具很好地協同工作。

在開發新應用程式時，請專注于開發最佳應用程式。像Kubernetes這樣的複雜工具可能是管理應用程式基礎結構的正确解決方案。

增強單體應用

随着應用程式的不斷增長，你可能最終将無法繼續添加功能到單體應用中。這通常是因為該應用，接近單個開發團隊可以從事的工作的極限。

在這一點上，許多團隊選擇拆分單體應用并完全遷移到微服務中。盡管這是一個頗受歡迎的決定，但它既不是必需的決定，也不是靈丹妙藥。組織，可以考慮從添加單體應用的功能服務開始，而不是整體替換單體應用。這些支援服務中的某些實際上可能就是微服務-是以，你可以在合理的情況下使用小型服務而受益，同時仍可利用單體應用的好處。

即使引入微服務，你可能也不需要或不想從Kubernetes開始。Kubernetes擅長運作和擴充相關服務和微服務容器的Pod。但是，采用Kubernetes的某些方面很容易被忽略，例如，Kubernetes沒有用于保護Pod，節點和叢集的強大内置工具，并且在多雲環境中部署Kubernetes叢集會增加很多複雜性。

從像Azure Service Fabric和AWS Fargate這樣的單雲平台開始，可以更輕松地啟動和擴充服務，而不必強迫你進行Kubernetes叢集的管理。

另一個選擇是完全避免具有維護開銷的服務，并選擇功能即服務（FaaS），例如AWS Lambda或Azure Functions。FaaS是一種在向應用程式添加服務時最大程度地減少潛在基礎架構開銷的好方法。此外，如果你最終需要使用Kubernetes編排的叢集，則可以使用FaaS功能進行增強。

不再使用單體應用

現在，想象你的單體應用已經增長得如此之快，以至于你不能采用單體應用方式，開始需要遷移到微服務架構。

慢慢地，你擁有了各種各樣的服務，其中許多服務需要彼此通信。你需要確定互相依賴的服務始終處于正常運作狀态并且彼此可見。

此外，你有時還需要考慮跨多個可用性區域（甚至可能跨多個雲供應商）運作。

在這一點上，你可能需要像Kubernetes這樣的協調器。它使你可以輕松定義相關服務的子產品（Pods），并可以自動縮放應用執行個體并在服務之間進行負載均衡。

為了使Kubernetes發揮作用，組織需要：

• 操作幾個或幾十個虛拟機
• 配置設定人員進行Kubernetes專門的配置和維護
• 使大部分同類服務部署自動化
• 與雲（或托管）提供商無關

此外，Kubernetes内置了對高可用性（Amazon RDS Multi-AZ）部署的支援，這使得提高應用程式的可靠性和可用性變得更加容易。

當然，這确實帶來了開銷：需要時間和工程資源來建立和管理叢集，定義Pod以及建立适合部署到Kubernetes的容器化應用程式。但是，如果你的應用足夠大，可以從Kubernetes中受益，那麼管理開銷是值得的。

結論

Kubernetes功能強大，但這并不意味着它是每個團隊和每個應用程式的正确選擇。與任何技術一樣，它可以解決某些問題。如果你沒有遇到Kubernetes想要解決的問題，那就麻煩多了。

首先，建議使用簡單可用工具将應用程式快速釋出。當你的應用程式達到其部署和擴充成為自身運轉的一部分時，就有必要開始考慮編排，并且自然而然地将Kubernetes作為編排工具。