我們的行業在過去十年中取得了令人難以置信的進步，這在一定程度上要歸功于 Docker、Docker Compose 和 Kubernetes 等技術。然而，我們仍在研究如何在我們所處的多樣化環境中進行開發。

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

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

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

挑戰剖析

回歸現象看本質，隨著業務復雜度的提高，單體應用越來越龐大，對資源形成挑戰劇增：

挑戰一、資源利用率低

煙囪系統是指一種由相互關聯的元素緊密結合在一起的集合，其中單個元素無法區分、升級或重構。

很多企業的IT系統都是煙囪式，這種模式有很多弊端，如：

• 重復建設運維
• 交互成本高昂
• 難以持續運營
• 業務靈活性差

挑戰二、應用架構擴展性差

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

• 復雜性漸增;
• 技術創新受阻;
• 按需伸縮變難;
• 部署效率下降。

挑戰三、開發周期長

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

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

升級難：固定時間窗、集中大規模人力中斷服務升級。

在敏捷開發中，軟件項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特征。

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

IT架構演進

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

云原生可以改進應用開發的效率，改變企業的組織結構，甚至會在文化層面上直接影響一個公司的決策。另外，云原生也很好地解釋了云上運行的應用應該具備什么樣的架構特性——敏捷、可靠、彈性、可擴展、故障可恢復。

行業場景

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

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

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

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

需求拓展

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

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

傳統思路

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

但這樣做的話，必須確保是否已為每個應用程序安裝和配置適當的操作系統 (OS) 版本和依賴項。

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

AKS思路

優勢：

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

第一步：創建 AKS 群集

創建 AKS 群集時，有兩個選項可供選擇。

可以使用 Azure 門戶或 Azure CLI。

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

例如：

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

除非另行指定，否則創建工作流會使用默認配置創建 Kubernetes 群集，以用于縮放、身份驗證、網絡和監視。

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

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

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

AKS 支持 Docker 映像格式，使用任何開發環境來創建工作負載、將工作負載打包為容器以及將容器部署為 Kubernetes Pod。

此處使用標準 Kubernetes 命令行工具或 Azure CLI 來管理部署。

對標準Kubernetes工具的支持可確保你無需更改當前工作流，即可支持將現有Kubernetes遷移到 AKS。

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

資源監視-Azure Monitor

Azure Monitor 是一項用于收集、分析和響應來自云和本地環境的遙測數據的服務。

IT運營、DevOps和開發人員團隊使用Azure Monitor來最大限度地提高應用程序和服務的可用性和性能。

Azure Monitor 的主要特性包括：

Azure Monitor 可以從應用程序、基礎結構、Azure 平臺和集成的任何自定義源收集堆棧中所有層的性能和可用性遙測數據。

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

監視選項

指標-描述系統某些方面在特定時間點的情況的數值。

日志-收集用于分析的日志數據。

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

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

關于Azure Dev Spaces

價值點：

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

部署中心:

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

利用 Azure DevOps Projects，便可以執行以下操作：

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

補充何時使用 Azure Kubernetes 服務

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