如果你正在從頭開發(fā)一個(gè)新的項(xiàng)目，諸如一個(gè)新的 APP，服務(wù)或者網(wǎng)站，你主要的關(guān)注點(diǎn)通常不是如何在高可用的網(wǎng)絡(luò)中大規(guī)模的運(yùn)行它。相反，你可能會(huì)專注于為你的目標(biāo)客戶打造合適的產(chǎn)品或?qū)ふ疫m合市場(chǎng)的產(chǎn)品。如果你正在為一家初創(chuàng)公司創(chuàng)建一個(gè) MVP，你需要在大規(guī)模擴(kuò)展(scaling)之前完成這個(gè)最小可用產(chǎn)品，否則，你在為誰(shuí)擴(kuò)展?如果你是企業(yè)的開發(fā)人員，你希望確保的是當(dāng)前做的業(yè)務(wù)滿足期望和需求。規(guī)?；\(yùn)營(yíng)充其量只是明天的事情。

[[419835]]

因此，在選擇正確的技術(shù)集時(shí)，Kubernetes(通常與大型分布式系統(tǒng)相關(guān))現(xiàn)在可能不在你的關(guān)注范圍內(nèi)。畢竟，它帶來(lái)了很大一部分工作量：設(shè)置和操作集群、容器化你的應(yīng)用程序、定義服務(wù)、部署、負(fù)載平衡器等等。這在早期看起來(lái)可能有點(diǎn)矯枉過(guò)正，你可能認(rèn)為你的時(shí)間最好花在其他任務(wù)上，例如編寫實(shí)際應(yīng)用程序的前幾次迭代。

當(dāng)我們?cè)?2008 年開始構(gòu)建 Stack Overflow 時(shí)，我們沒得選擇。沒有 Docker(2013 年)，也沒有 Kubernetes(2014 年)。云計(jì)算還處于起步階段：Azure 剛剛推出(2008 年)，而 Amazon Web Services 大約成立兩年。我們構(gòu)建的東西是為特定硬件設(shè)計(jì)的，并對(duì)其做了很多假設(shè)。現(xiàn)在我們正在對(duì)我們的代碼庫(kù)進(jìn)行現(xiàn)代化改造并遷移到云端，我們必須投入大量工作才能使 Kubernetes 和容器正常工作。

經(jīng)歷了這個(gè)過(guò)程，我們獲得一個(gè)全新的視角。如果你今天正在構(gòu)建一個(gè)新應(yīng)用程序，那么仔細(xì)研究一下使其成為云原生并從一開始就使用 Kubernetes 可能是值得的。設(shè)置 Kubernetes 的工作量比你想象的要少。同時(shí)，它也比以后重構(gòu)你的應(yīng)用程序來(lái)支持容器化所需的工作量少。

以下有三個(gè)原因說(shuō)明為什么從一開始就在 Kubernetes 上構(gòu)建你的應(yīng)用程序不一定是一個(gè)壞主意。

托管的 Kubernetes 完成了繁重的工作

幾年前，當(dāng)我們?cè)?Stack Overflow 建立我們的第一個(gè)內(nèi)部 Kubernetes 集群時(shí)，我們花了將近一周的時(shí)間才能啟動(dòng)并運(yùn)行所有內(nèi)容：配置虛擬機(jī)、安裝、配置、配置、配置。 一旦集群?jiǎn)?dòng)，后面就是持續(xù)的維護(hù)工作。這個(gè)過(guò)程對(duì)我們最大的觸動(dòng)是 Kubernetes 對(duì)我們來(lái)說(shuō)太棒了——但我們希望其他人也能來(lái)使用它。

如今，Amazon 的 Elastic Kubernetes Service(EKS)、Microsoft 的 Azure Kubernetes Service(AKS)或 Google 的 Google Kubernetes Engine(GKE)等托管 Kubernetes 服務(wù)允許你在幾分鐘內(nèi)設(shè)置自己的集群。例如，在 AKS 中，你只需單擊門戶中的幾個(gè)按鈕并填寫幾個(gè)表單：

這很方便，但你可能不想在工作流結(jié)束時(shí)創(chuàng)建集群這種快捷方式。先完成這個(gè)向?qū)?wizard)，但不要點(diǎn)擊最后那個(gè)藍(lán)色的“創(chuàng)建”按鈕!相反，將你剛剛創(chuàng)建的配置下載為 ARM 模板并將其納入到你的源代碼控制系統(tǒng)。現(xiàn)在你擁有兩全其美的優(yōu)勢(shì)——易用性和基礎(chǔ)設(shè)施即代碼(IaC)!

一旦你在此處完成設(shè)置，那么對(duì)于規(guī)模化你的應(yīng)用程序，剩下的就沒有什么可做的了，除了向你的云提供商提供更多的寫檢查(write bigger checks)。任何額外的資源分配都很容易。規(guī)?；瘞?lái)的問題——容錯(cuò)、負(fù)載平衡、流量整形(traffic shaping)——已經(jīng)得到處理。 在任何時(shí)候，都不會(huì)出現(xiàn)你被成功淹沒的那一刻;你無(wú)需付出太多額外工作就可以使你的應(yīng)用程序面向未來(lái)。

你可以保持云無(wú)關(guān)(cloud agnostic)

如果你的項(xiàng)目成功了，那么在早期階段做出的技術(shù)決策很可能在未來(lái)數(shù)月或數(shù)年仍會(huì)產(chǎn)生影響。例如，Stack Overflow 最初是用 C# 編寫的。13 年后，它仍然是用 C# 編寫的，但它曾經(jīng)也是。偶爾有人建議我們用 Node.js 重寫它。但直到現(xiàn)在也沒有發(fā)生。

對(duì)云服務(wù)的依賴也是如此。你可以在基礎(chǔ)設(shè)施即服務(wù)(IaaS)產(chǎn)品(如 Amazon 的 EC2)之上構(gòu)建你的新應(yīng)用程序?；蛘?，你可能開始依賴平臺(tái)即服務(wù)(PaaS)產(chǎn)品，例如 Microsoft 的 Azure SQL。但是，你是否愿意在現(xiàn)階段對(duì)其背后的云提供商做出長(zhǎng)期承諾?如果你還不知道你的旅程會(huì)帶你去哪里，也許你更愿意保持云無(wú)關(guān)狀態(tài)一段時(shí)間。

讓我們回到基礎(chǔ)設(shè)施即代碼：將諸如 Terraform 之類的工具投入其中將幫助你在某種程度上保持與云無(wú)關(guān)。它提供了統(tǒng)一的工具包和配置語(yǔ)言(HCL)來(lái)跨不同的云和基礎(chǔ)架構(gòu)提供商管理你的資源。你的應(yīng)用程序不太可能真正與云無(wú)關(guān)，但是在這種情況下，你可以像切換家中的互聯(lián)網(wǎng)或電力供應(yīng)商一樣輕松地切換云提供商。

HashiCorp 論壇中有一個(gè)關(guān)于這個(gè)主題的很好的討論：Terraform 真的與云無(wú)關(guān)嗎?正如其中一位評(píng)論者指出的那樣：

“Kubernetes 集群是對(duì)計(jì)算資源進(jìn)行抽象的一個(gè)很好的例子：它在不同平臺(tái)上有許多托管和自我管理的實(shí)現(xiàn)，所有這些實(shí)現(xiàn)都提供了一個(gè)通用的 API 和一組通用的功能。”

這總結(jié)得很好!它仍然不是一個(gè)完美的抽象。例如，每個(gè)云提供商可能都有自己的自定義方式來(lái)實(shí)現(xiàn)公共負(fù)載均衡器和 Kubernetes 中的持久卷等內(nèi)容。公平地說(shuō)，如果你在 Kubernetes 上構(gòu)建應(yīng)用，你將在一定程度上保持云無(wú)關(guān)。

你可以輕松地啟動(dòng)新環(huán)境 - 隨心所欲!

Kubernetes 通常被視為管理生產(chǎn)基礎(chǔ)設(shè)施的一種方式。但是在 Stack Overflow，我們一直在使用它來(lái)動(dòng)態(tài)管理我們的測(cè)試環(huán)境。我們使用 Kubernetes 來(lái)托管我們所謂的 PR 環(huán)境。只需按一下按鈕，每個(gè)拉取請(qǐng)求都可以在隔離的測(cè)試環(huán)境中運(yùn)行：

當(dāng)我們說(shuō)“隔離環(huán)境”時(shí)，我們指的是一切：應(yīng)用程序本身(包含 PR 分支中更改的代碼)及其自己的 SQL Server、Redis、Elasticsearch 和額外的服務(wù)實(shí)例。所有這些都會(huì)在幾分鐘內(nèi)從頭開始啟動(dòng)，并在專用命名空間中的少數(shù)容器中運(yùn)行，同時(shí)只為你和任何對(duì)你的 PR 感興趣的人服務(wù)。

這不是我們發(fā)明的;其他組織一直在使用這個(gè)概念。這個(gè)想法是每個(gè)代碼更改都會(huì)通過(guò)拉取請(qǐng)求進(jìn)入像 Git 這樣的版本控制系統(tǒng)。其他開發(fā)人員會(huì)審查代碼，但代碼不能說(shuō)明一切。你希望看到代碼的運(yùn)行情況。通常，你必須在本地下載所有代碼，編譯并運(yùn)行它。這可能很簡(jiǎn)單，但是如果你正在運(yùn)行一個(gè)需要從多個(gè)倉(cāng)庫(kù)中提取代碼的大型應(yīng)用程序，或者微服務(wù)架構(gòu)，那么你可能會(huì)需要幾個(gè)小時(shí)的調(diào)試。

讓我們更理想一點(diǎn)說(shuō)，假設(shè)你已將一項(xiàng)新功能的所有提交(commits)壓縮為一個(gè)，并將其作為單個(gè) PR 提交。將這個(gè) PR 環(huán)境作為一個(gè)鏈接發(fā)送到銷售或營(yíng)銷部門那里，以便他們可以預(yù)覽實(shí)際運(yùn)行的功能。如果你的銷售團(tuán)隊(duì)想要演示具有特定功能或自定義構(gòu)建的應(yīng)用程序，那么直接給他們發(fā)送 PR 環(huán)境鏈接。你不必花時(shí)間指導(dǎo)技術(shù)水平較低的同事完成構(gòu)建過(guò)程。

達(dá)到這一點(diǎn)需要大量的基礎(chǔ)工作。首先，在 Windows Containers 中運(yùn)行經(jīng)典的 .NET Framework 并不是我們真正想要追求的途徑。理論上這是可能的——從 v1.19 開始，Kubernetes 就已經(jīng)提供了 Windows 支持——但 Docker/Kubernetes 生態(tài)系統(tǒng)實(shí)際上更以 Linux 為中心。幸運(yùn)的是，我們向 .NET Core 的遷移已經(jīng)在進(jìn)行中，所以我們決定押注 Linux 容器。

當(dāng)然，這也帶來(lái)了一系列挑戰(zhàn)。當(dāng)處理一個(gè)已有 10 多年歷史的代碼庫(kù)時(shí)，你可能會(huì)發(fā)現(xiàn)關(guān)于它運(yùn)行的基礎(chǔ)架構(gòu)的假設(shè)：硬編碼文件路徑(包括我們最喜歡的：正斜杠與反斜杠)、服務(wù) URL、配置等。但我們最終完成了這個(gè)工作，現(xiàn)在我們可以在自動(dòng)擴(kuò)展的 Kubernetes 集群上啟動(dòng)任意數(shù)量的 Stack Overflow、Stack Exchange 網(wǎng)絡(luò)和 Teams 產(chǎn)品的測(cè)試實(shí)例。

回顧 Stack Overflow 的早期，擁有這種工具可能就會(huì)是另一種局面。在構(gòu)建產(chǎn)品的早期階段，你通常希望盡可能快的構(gòu)建、衡量和學(xué)習(xí)相關(guān)知識(shí)。使用容器和 Kubernetes 將允許你為此構(gòu)建這樣的工具，并在你需要擴(kuò)展時(shí)為你提供面向未來(lái)的支持。

那么，你應(yīng)該從一開始就使用 Kubernetes 嗎?可能是!當(dāng)然，這仍然取決于你的特定項(xiàng)目、需求和優(yōu)先事項(xiàng)。

但是你是否一直在說(shuō)“我們不需要 Kubernetes，因?yàn)槲覀冞€沒有產(chǎn)品市場(chǎng)契合度”?仔細(xì)想想，也許你會(huì)發(fā)現(xiàn)自己在說(shuō)“我們需要 Kubernetes，因?yàn)槲覀冞€沒有適合市場(chǎng)的產(chǎn)品。”