我們的行業(yè)在過去十年中取得了令人難以置信的進步，這在一定程度上要歸功于 Docker、Docker Compose 和 Kubernetes 等技術(shù)。然而，我們?nèi)栽谘芯咳绾卧谖覀兯幍亩鄻踊h(huán)境中進行開發(fā)。

容器化在開發(fā)和運維掀起了一場風(fēng)暴。在過去，部署是高度依賴于特定技術(shù)的，通常需要對每個項目進行大量不可重復(fù)的工程工作。

你是否部署到 vps?你是否在分發(fā)虛擬機鏡像?靜態(tài)可執(zhí)行文件?需要特定解釋器的腳本? 根據(jù)你對這些問題的回答，你可能已經(jīng)使用了 Capistrano、Puppet、shell 腳本、Ansible、deb 或 rpm 包、cloud-init 腳本、專有云技術(shù)、upstart、systemd、init 等很多技術(shù)。

在部署階段，系統(tǒng)管理和開發(fā)之間的界限就變得模糊了，DevOps 的原則就誕生了。隨著 DevOps 開始成熟，業(yè)界發(fā)展出了應(yīng)用開發(fā)的最佳實踐，比如 12 因素應(yīng)用程序方法論，但許多實現(xiàn)細節(jié)仍然是依賴于特定技術(shù)的。

挑戰(zhàn)剖析

回歸現(xiàn)象看本質(zhì)，隨著業(yè)務(wù)復(fù)雜度的提高，單體應(yīng)用越來越龐大，對資源形成挑戰(zhàn)劇增：

挑戰(zhàn)一、資源利用率低

煙囪系統(tǒng)是指一種由相互關(guān)聯(lián)的元素緊密結(jié)合在一起的集合，其中單個元素?zé)o法區(qū)分、升級或重構(gòu)。

很多企業(yè)的IT系統(tǒng)都是煙囪式，這種模式有很多弊端，如：

• 重復(fù)建設(shè)運維
• 交互成本高昂
• 難以持續(xù)運營
• 業(yè)務(wù)靈活性差

挑戰(zhàn)二、應(yīng)用架構(gòu)擴展性差

單體架構(gòu)在規(guī)模比較小的情況下工作情況良好，隨著系統(tǒng)規(guī)模的擴大，暴露出來的問題也越來越多，主要有以下幾點：

• 復(fù)雜性漸增;
• 技術(shù)創(chuàng)新受阻;
• 按需伸縮變難;
• 部署效率下降。

挑戰(zhàn)三、開發(fā)周期長

龐大代碼基線、組件耦合大、責(zé)任不清楚，牽一發(fā)而動全身。

部署慢、擴容慢：部署過程不可重復(fù)、出錯率高;不支持自動彈性伸縮。

升級難：固定時間窗、集中大規(guī)模人力中斷服務(wù)升級。

在敏捷開發(fā)中，軟件項目的構(gòu)建被切分成多個子項目，各個子項目的成果都經(jīng)過測試，具備集成和可運行的特征。

換言之，就是把一個大項目分為多個相互聯(lián)系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態(tài)。

IT架構(gòu)演進

為了解決傳統(tǒng)應(yīng)用升級緩慢、架構(gòu)臃腫、不能快速迭代、故障不能快速定位、問題無法快速解決等問題，云原生這一概念橫空出世。

云原生可以改進應(yīng)用開發(fā)的效率，改變企業(yè)的組織結(jié)構(gòu)，甚至?xí)谖幕瘜用嫔现苯佑绊懸粋€公司的決策。另外，云原生也很好地解釋了云上運行的應(yīng)用應(yīng)該具備什么樣的架構(gòu)特性——敏捷、可靠、彈性、可擴展、故障可恢復(fù)。

行業(yè)場景

假設(shè)你是一家新能源汽車商解決方案架構(gòu)師，貴公司為全球各地的客戶提供汽車跟蹤解決方案。我們可以使用容器化的實例來快速部署到新的客戶區(qū)域，并按需縮放資源來滿足客戶需求。我們希望使用容器業(yè)務(wù)流程平臺，以便輕松地開發(fā)、部署和管理容器化的應(yīng)用程序。

假設(shè)你是一家大型服裝品牌零售擔(dān)任CIO，你決定將所有服務(wù)移動到Azure Kubernetes服務(wù)中。哪些組件會對每月Azure費用產(chǎn)生影響?只需考慮群集使用的虛擬機實例、存儲和網(wǎng)絡(luò)資源付費。

假設(shè)你是一家大型跨國研發(fā)制造行業(yè)CTO，我們都須知智能制造行業(yè)大量調(diào)用需要持久化存儲。你將使用AKS的哪些功能?對于需要持久性存儲的容器，AKS支持靜態(tài)和動態(tài)存儲卷。

假設(shè)你就職于一家監(jiān)視道路狀況的交通出行公司擔(dān)任研發(fā)架構(gòu)師，開發(fā)人員團隊需要與AKS群集中的其他組件進行端到端測試。該團隊希望在不復(fù)制或模擬依賴關(guān)系的情況下進行測試。他們應(yīng)該選擇哪些服務(wù)?借助Azure Dev Spaces，無需復(fù)制或模擬依賴關(guān)系，即可獨立開發(fā)代碼并與其他組件進行端到端測試。

需求拓展

就拿上述新能源汽車商業(yè)務(wù)場景深入展開詳述，假定業(yè)務(wù)場景解決方案包含三個主要應(yīng)用程序：

• 一個主程序網(wǎng)站，其中包括有關(guān)要跟蹤的車輛的地圖和信息;
• 一種數(shù)據(jù)處理服務(wù)，用于收集和處理從所跟蹤車輛發(fā)送的信息;
• 一個MSSQL數(shù)據(jù)庫，用于存儲從網(wǎng)站捕獲的跟蹤信息和用戶信息。

傳統(tǒng)思路

通過橫向擴展解決方案滿足客戶需求。為每個應(yīng)用程序部署新的虛擬機(VM)，然后將應(yīng)用程序部署到 VM 中。

但這樣做的話，必須確保是否已為每個應(yīng)用程序安裝和配置適當(dāng)?shù)牟僮飨到y(tǒng) (OS) 版本和依賴項。

還必須確保安裝和升級的是應(yīng)用程序的適當(dāng)版本。如果存在錯誤，則必須確保你能夠以影響最小的方式回滾。

AKS思路

優(yōu)勢：

• AKS環(huán)境啟用了自動更新、自愈和輕松縮放等功能;
• Kubernetes群集主機由Azure免費管理;
• 由你管理群集中的代理節(jié)點，且只需為節(jié)點在其上運行的VM付費;
• 可以在Azure門戶中創(chuàng)建群集，也可以使用Azure CLI 創(chuàng)建群集;
• 創(chuàng)建群集時，可以使用資源管理器模板自動創(chuàng)建群集;
• 利用這些模板，可以指定高級網(wǎng)絡(luò)、Azure Active Directory (AD) 集成和監(jiān)視等功能;
• 與自定義Kubernetes群集相比，利用AKS，可以享受開放源代碼Kubernetes的優(yōu)勢，不存在復(fù)雜性或運營開銷。

第一步：創(chuàng)建 AKS 群集

創(chuàng)建 AKS 群集時，有兩個選項可供選擇。

可以使用 Azure 門戶或 Azure CLI。

這兩個選項都必須配置有關(guān)群集的基本信息。

例如：

• Kubernetes 群集名稱;
• 要安裝的 Kubernetes 版本;
• 用于使主節(jié)點可公開訪問的 DNS 前綴;
• 初始節(jié)點池大小;
• 初始節(jié)點池大小默認為兩個節(jié)點，但建議在生產(chǎn)環(huán)境中至少使用三個節(jié)點。

除非另行指定，否則創(chuàng)建工作流會使用默認配置創(chuàng)建 Kubernetes 群集，以用于縮放、身份驗證、網(wǎng)絡(luò)和監(jiān)視。

創(chuàng)建 AKS 群集通常需要幾分鐘時間。完成后，可以更改任何默認 AKS 群集屬性。

可通過 Azure 門戶或從命令行訪問和管理群集。

第二步：開發(fā)工作負載并將其部署到 AKS

AKS 支持 Docker 映像格式，使用任何開發(fā)環(huán)境來創(chuàng)建工作負載、將工作負載打包為容器以及將容器部署為 Kubernetes Pod。

此處使用標(biāo)準(zhǔn) Kubernetes 命令行工具或 Azure CLI 來管理部署。

對標(biāo)準(zhǔn)Kubernetes工具的支持可確保你無需更改當(dāng)前工作流，即可支持將現(xiàn)有Kubernetes遷移到 AKS。

AKS還支持所有常用開發(fā)和管理工具，例如Helm、Draft以及適用于Visual Studio Code 的 Kubernetes 擴展和 Visual Studio Kubernetes Tools。

資源監(jiān)視-Azure Monitor

Azure Monitor 是一項用于收集、分析和響應(yīng)來自云和本地環(huán)境的遙測數(shù)據(jù)的服務(wù)。

IT運營、DevOps和開發(fā)人員團隊使用Azure Monitor來最大限度地提高應(yīng)用程序和服務(wù)的可用性和性能。

Azure Monitor 的主要特性包括：

Azure Monitor 可以從應(yīng)用程序、基礎(chǔ)結(jié)構(gòu)、Azure 平臺和集成的任何自定義源收集堆棧中所有層的性能和可用性遙測數(shù)據(jù)。

• 用于數(shù)值時序值的 Azure Monitor 指標(biāo)和用于存儲日志數(shù)據(jù)的 Azure Monitor 日志;
• 系統(tǒng)會自動針對 Azure 資源收集和存儲 Azure Monitor 指標(biāo);
• 對 Azure 資源進行監(jiān)視和故障排除。可用見解包括VM見解、應(yīng)用程序見解和容器見解;
• 通過工作簿和儀表板對數(shù)據(jù)進行可視化，并且可以通過自定義圖表和分析來分析數(shù)據(jù);
• Azure Monitor 自帶可視化監(jiān)視數(shù)據(jù)的功能，并且可以使用其他 Azure 服務(wù)將這些數(shù)據(jù)發(fā)布給不同的受眾。允許將不同類型的數(shù)據(jù)合并到 Azure 門戶的單個窗格中。

監(jiān)視選項

指標(biāo)-描述系統(tǒng)某些方面在特定時間點的情況的數(shù)值。

日志-收集用于分析的日志數(shù)據(jù)。

可視化效果-將不同類型的數(shù)據(jù)合并到Azure 門戶的單個窗格中。用于數(shù)據(jù)分析和在門戶中創(chuàng)建豐富的可視化報表。

• 指標(biāo)-用于描述系統(tǒng)某些方面在特定時間點的情況。是輕型數(shù)據(jù)，可以支持近實時方案。
• 日志-使用查詢來分析 Azure Monitor 收集的日志數(shù)據(jù)，快速檢索、合并和分析所收集的數(shù)據(jù)。
• 可視化效果-以 Azure 儀表板和工作簿的形式提供了兩種主要的可視化效果。可以利用這兩個功能向管理人員或其他相關(guān)方提供可視化報表，從而實現(xiàn)輕松使用所監(jiān)視的數(shù)據(jù)。

關(guān)于Azure Dev Spaces

價值點：

• 最大程度減少每位團隊成員的本地開發(fā)計算機設(shè)置;
• 使用 Visual Studio 或 Visual Studio Code 直接快速執(zhí)行循環(huán)訪問和調(diào)試代碼;
• 生成 Docker 和 Kubernetes 配置即代碼資產(chǎn)，供開發(fā)到生產(chǎn)使用;
• 獨立開發(fā)代碼，并與其他組件一起進行集成測試，而無需復(fù)制或模擬依賴關(guān)系。

部署中心:

可以使用配置后的此 DevOps 管道為 AKS Kubernetes 群集設(shè)置(CI)和(CD)管道。

利用 Azure DevOps Projects，便可以執(zhí)行以下操作：

• 自動創(chuàng)建 Azure 資源，例如 AKS 群集;
• 創(chuàng)建用于監(jiān)視 AKS 群集的 Azure Application Insights 資源;
• 啟用適用于容器的 Azure Monitor 以監(jiān)視 AKS 群集上的容器工作負載的性能;
• 添加更豐富的 DevOps 功能。例如，可在部署之前添加審批，預(yù)配其他 Azure 資源，運行腳本或升級工作負載。

補充何時使用 Azure Kubernetes 服務(wù)

創(chuàng)建群集或進行以下部署后，都可以配置上述所有功能。