原文發表于kubernetes中文社區，為作者原創翻譯 ，原文地址
更多kubernetes文章，請多關注kubernetes中文社區
目錄
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作為編排工具，
譯文鏈接：https://thenewstack.io/do-i-really-need-kubernetes/
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/190774.html
標籤：其他