共計(jì) 2345 個(gè)字符，預(yù)計(jì)需要花費(fèi) 6 分鐘才能閱讀完成。

本篇內(nèi)容主要講解“Kubernetes 能做什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓丸趣 TV 小編來帶大家學(xué)習(xí)“Kubernetes 能做什么”吧!

Kubernetes 會(huì)做什么？

Kubernetes 是用于容器化應(yīng)用程序的編排工具。它負(fù)責(zé)：

部署鏡像和容器

管理容器和集群的擴(kuò)展

容器和集群的資源管理

服務(wù)的流量管理

當(dāng)你的應(yīng)用程序由運(yùn)行在不同容器中的多個(gè)服務(wù)組成時(shí)，Kubernetes 確實(shí)會(huì)帶來很多好處。對于具有靜態(tài)用戶群的單體應(yīng)用，這可能超出了必要。

構(gòu)建，測試并將應(yīng)用程序交付到容器倉庫的任務(wù)不是 Kubernetes 的一部分，這些使用 CI/CD 工具就可以完成工作。除了 CI/CD 流水線，Kubernetes 還可以幫助你將應(yīng)用部署到生產(chǎn)環(huán)境中而不會(huì)造成服務(wù)停機(jī)。

改善單體應(yīng)用

大多數(shù)應(yīng)用程序都是以單體形式開始的–將整個(gè)應(yīng)用程序放在一個(gè)地方，可以快速輕松地進(jìn)行和部署更改。但是，如果你的應(yīng)用程序發(fā)展壯大，你需要很快找到擴(kuò)大規(guī)模的方法。

這是否意味著該是 Kubernetes 的時(shí)候了？可能不是。

通常，擴(kuò)展更多地是關(guān)于應(yīng)用程序的內(nèi)部，而不是高級架構(gòu)和工具。例如，你可以通過使用支持相似性標(biāo)簽的負(fù)載均衡器部署多個(gè)實(shí)例來擴(kuò)展整體。

擴(kuò)展應(yīng)用程序時(shí)要考慮的第一步是測試驅(qū)動(dòng)開發(fā)（TDD），它可以確保軟件質(zhì)量并防止隨著應(yīng)用程序的增長而出現(xiàn)問題。盡管較小的模塊或服務(wù)更易于測試，但模塊化也意味著對 mocking 需求增加，并且需要額外的工具來配置和維護(hù)。良好的測試可以使你輕松自信地構(gòu)建和擴(kuò)展應(yīng)用程序。

當(dāng)你開始擴(kuò)展整體時(shí)，Chef 和 Ansible 等配置管理工具會(huì)派上用場。你可以使用它們來自動(dòng)配置新服務(wù)器，以確保它們準(zhǔn)備好運(yùn)行你的應(yīng)用程序。你甚至可以更進(jìn)一步，并使用 Terraform 之類的工具來幫助配置新的服務(wù)器 VM，這樣你就不必手動(dòng)創(chuàng)建它們。

當(dāng)應(yīng)用程序的其他部分成為瓶頸（例如數(shù)據(jù)庫）時(shí)，你也可以擴(kuò)展這些部分。例如，如果數(shù)據(jù)庫成為瓶頸，則可以將經(jīng)常訪問的數(shù)據(jù)移至高性能內(nèi)存數(shù)據(jù)存儲（如 Redis）中，以減少數(shù)據(jù)庫的負(fù)載。

無論你使用哪種配置管理和配置工具，都必須有一個(gè)良好的 CI/CD 流水線。第一次部署應(yīng)用程序時(shí)，你可能已通過 FTP 將 zip 文件復(fù)制到服務(wù)器，但是這種方法無法擴(kuò)展。簡化的 CI/CD 流水線可確保自動(dòng)構(gòu)建，測試和部署你的應(yīng)用程序，而無需你或你的團(tuán)隊(duì)進(jìn)行任何額外的工作。

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

在開發(fā)新應(yīng)用程序時(shí)，請專注于開發(fā)最佳應(yīng)用程序。像 Kubernetes 這樣的復(fù)雜工具可能是管理應(yīng)用程序基礎(chǔ)結(jié)構(gòu)的正確解決方案。

增強(qiáng)單體應(yīng)用

隨著應(yīng)用程序的不斷增長，你可能最終將無法繼續(xù)添加功能到單體應(yīng)用中。這通常是因?yàn)樵搼?yīng)用，接近單個(gè)開發(fā)團(tuán)隊(duì)可以從事的工作的極限。

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

即使引入微服務(wù)，你可能也不需要或不想從 Kubernetes 開始。Kubernetes 擅長運(yùn)行和擴(kuò)展相關(guān)服務(wù)和微服務(wù)容器的 Pod。但是，采用 Kubernetes 的某些方面很容易被忽略，例如，Kubernetes 沒有用于保護(hù) Pod，節(jié)點(diǎn)和集群的強(qiáng)大內(nèi)置工具，并且在多云環(huán)境中部署 Kubernetes 集群會(huì)增加很多復(fù)雜性。

從像 Azure Service Fabric 和 AWS Fargate 這樣的單云平臺開始，可以更輕松地啟動(dòng)和擴(kuò)展服務(wù)，而不必強(qiáng)迫你進(jìn)行 Kubernetes 集群的管理。

另一個(gè)選擇是完全避免具有維護(hù)開銷的服務(wù)，并選擇功能即服務(wù)（FaaS），例如 AWS Lambda 或 Azure Functions。FaaS 是一種在向應(yīng)用程序添加服務(wù)時(shí)最大程度地減少潛在基礎(chǔ)架構(gòu)開銷的好方法。此外，如果你最終需要使用 Kubernetes 編排的集群，則可以使用 FaaS 功能進(jìn)行增強(qiáng)。

不再使用單體應(yīng)用

現(xiàn)在，想象你的單體應(yīng)用已經(jīng)增長得如此之快，以至于你不能采用單體應(yīng)用方式，開始需要遷移到微服務(wù)架構(gòu)。

慢慢地，你擁有了各種各樣的服務(wù)，其中許多服務(wù)需要彼此通信。你需要確保相互依賴的服務(wù)始終處于正常運(yùn)行狀態(tài)并且彼此可見。

此外，你有時(shí)還需要考慮跨多個(gè)可用性區(qū)域（甚至可能跨多個(gè)云供應(yīng)商）運(yùn)行。

在這一點(diǎn)上，你可能需要像 Kubernetes 這樣的協(xié)調(diào)器。它使你可以輕松定義相關(guān)服務(wù)的模塊（Pods），并可以自動(dòng)縮放應(yīng)用實(shí)例并在服務(wù)之間進(jìn)行負(fù)載均衡。

為了使 Kubernetes 發(fā)揮作用，組織需要：

操作幾個(gè)或幾十個(gè)虛擬機(jī)

分配人員進(jìn)行 Kubernetes 專門的配置和維護(hù)

使大部分同類服務(wù)部署自動(dòng)化

與云（或托管）提供商無關(guān)

此外，Kubernetes 內(nèi)置了對高可用性（Amazon RDS Multi-AZ）部署的支持，這使得提高應(yīng)用程序的可靠性和可用性變得更加容易。

當(dāng)然，這確實(shí)帶來了開銷：需要時(shí)間和工程資源來創(chuàng)建和管理集群，定義 Pod 以及創(chuàng)建適合部署到 Kubernetes 的容器化應(yīng)用程序。但是，如果你的應(yīng)用足夠大，可以從 Kubernetes 中受益，那么管理開銷是值得的。

到此，相信大家對“Kubernetes 能做什么”有了更深的了解，不妨來實(shí)際操作一番吧！這里是丸趣 TV 網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！