為什么從第一天起就應該在 Kubernetes 上構建應用

如果你今天正在構建一個(gè)新應用程序，那么仔細研究一下使其成為云原生并從一開(kāi)始就使用 Kubernetes 可能是值得的。設置 Kubernetes 的工作量比你想象的要少。同時(shí)，它也比以后重構你的應用程序來(lái)支持容器化所需的工作量少。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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