AKS 叢集的藍綠部署

Azure Kubernetes Service (AKS)

Azure 應用程式閘道

Azure Container Registry

Azure Front Door

Azure DNS

本文提供實作藍綠部署策略的指引，以測試新版的 Azure Kubernetes Service （AKS）叢集，同時繼續執行目前的版本。驗證新版本之後，路由變更會將使用者流量切換至該版本。如此一來，在進行變更，包括升級至 AKS 叢集時，部署會增加可用性。本文說明使用 Azure 受控服務和原生 Kubernetes 功能的 AKS 藍綠色部署設計和實作。

架構

本節說明 AKS 叢集藍綠色部署的架構。有兩種情況：

應用程式和 API 是公開的。
應用程式和 API 是私人面向的。

這裡也未討論混合式案例，其中混合式和私人面向應用程式和叢集中的 API。

下圖顯示公開案例的架構：

下載此架構的 Visio 檔案。

Azure Front Door 和 Azure DNS 提供路由機制，可在藍色和綠色叢集之間切換流量。如需詳細資訊，請參閱使用 Azure Front Door 進行藍綠部署。藉由使用 Azure Front Door，您可以實作以權數為基礎的完整交換器或更受控制的交換器。這項技術是 Azure 環境中最可靠且最有效率的技術。如果您想要使用自己的 DNS 和負載平衡器，您必須確定它們已設定為提供安全且可靠的交換器。

Azure 應用程式閘道提供專用於公用端點的前端。

此圖表適用於私用案例：

下載此架構的 Visio 檔案。

在此情況下，單一 Azure DNS 實例會實作藍叢集與綠色叢集之間的流量切換。這是使用 A 和 CNAME 記錄來完成。如需詳細資訊，請參閱 T3：將流量切換至綠色叢集。

應用程式閘道提供專用於私人端點的前端。

工作流程

在藍綠部署中，有五個階段會將目前版本的叢集更新為新版本。在我們的描述中，藍色叢集是目前的版本，而綠色叢集是新的叢集。

這些階段包括：

T0：藍色叢集已開啟。
T1：部署綠色叢集。
T2：同步處理藍色和綠色叢集之間的 Kubernetes 狀態。
T3：將流量切換至綠色叢集。
T4：終結藍色叢集。

新版本上線后，它會成為藍色叢集，以供接下來進行任何變更或更新。

藍色和綠色叢集會同時執行，但只會在有限的時間內執行，以優化成本和作業工作。

轉換觸發程式

從階段轉換到階段的觸發程式可以自動化。直到達到此目的，部分或全部都是手動的。觸發程式與下列項目相關：

特定的工作負載計量、服務等級目標（SLO）和服務等級協定（SLA）： 這些主要用於 T3 階段，在切換流量之前先驗證 AKS 叢集的整體狀態。
Azure 平臺計量： 這些計量可用來評估工作負載和 AKS 叢集的狀態和健康情況。這些轉換用於所有轉換中。

叢集的網路可探索性

您可以透過下列方式為叢集提供網路探索能力：

具有指向叢集的 DNS 記錄。例如：
- aks-blue.contoso.com 指向藍色叢集的私人或公用IP。
- aks-green.contoso.com 指向綠色叢集的私人或公用IP。
然後，您可以直接使用這些主機名，或在位於每個叢集前的應用程式閘道後端集區組態中。
具有指向應用程式閘道的 DNS 記錄。例如：
- aks-blue.contoso.com 指向應用程式閘道的私人或公用IP，其具有藍色叢集的私人或公用IP作為後端集區。
- aks-green.contoso.com 會指向應用程式閘道的私人或公用IP，其具有綠色叢集的私人或公用IP作為後端集區。

T0：藍色叢集開啟

初始階段 T0 是藍色叢集是即時的。此階段會準備新版的叢集以進行部署。

T1 階段的觸發條件是發行新版本的叢集，即綠色叢集。

T1：部署綠色叢集

此階段會開始部署新的綠色叢集。藍色叢集會維持開啟狀態，且即時流量仍會路由傳送至該叢集。

進入 T2 階段的觸發程式是平臺層級綠色 AKS 叢集的驗證。驗證會使用 Azure 監視器計量和 CLI 命令來檢查部署的健康情況。如需詳細資訊，請參閱使用監視和監視 AKS 數據參考監視 Azure Kubernetes Service （AKS）。

AKS 監視可以分割成不同的層級，如下圖所示：

叢集的健康情況會在層級 1 和 2 上評估，以及部分層級 3。針對層級 1，您可以使用監視器中的原生多重叢集檢視來驗證健康情況，如下所示：

在層級 2 中，請確定 Kubernetes API 伺服器和 Kubelet 可正常運作。您可以在監視器中使用 Kubelet 活頁簿，特別是顯示節點主要作業統計資料之活頁簿的兩個方格：

依節點方格的概觀摘要說明每個節點的總作業、總錯誤和成功作業百分比和趨勢。
依作業類型方格提供的每個作業類型、作業數目、錯誤數目，以及依百分比和趨勢成功作業的概觀。

層級 3 專用於預設在 AKS 中部署的 Kubernetes 物件和應用程式，例如 omsagent、kube-proxy 等等。針對這項檢查，您可以使用監視的深入解析檢視來檢查 AKS 部署的狀態：

或者，您可以使用容器深入解析部署和 HPA 計量中記載的專用活頁簿。以下是範例：

驗證成功之後，您可以轉換至 T2 階段。

T2：同步處理藍綠叢集之間的 Kubernetes 狀態

在這個階段， 應用程式、 操作員和 Kubernetes 資源尚未部署在綠色叢集中，或者至少並非所有資源 都適用，並在布建 AKS 叢集時部署。此階段的最終目標是，在同步處理結束時，綠色叢集與藍色叢集回溯相容。如果是，在將流量切換至綠色叢集之前，可以先驗證新叢集的狀態。

有各種方式可在叢集之間同步 Kubernetes 狀態：

透過持續整合和持續傳遞重新部署（CI/CD）。通常，使用用於應用程式一般部署的相同 CI/CD 管線就已足夠。執行這項操作的常見工具包括：GitHub Actions、Azure DevOps 和 Jenkins。
GitOps，其解決方案會在 Cloud Native Computing Foundation （CNCF）網站上推廣，例如 Flux 和 ArgoCD。
自定義的解決方案，會將 Kubernetes 組態和資源儲存在數據存放區中。這些解決方案通常是以從元數據定義開始的 Kubernetes 指令清單產生器為基礎，然後將產生的 Kubernetes 指令清單儲存在 Azure Cosmos DB 等數據存放區中。這些通常是以使用中應用程式描述架構為基礎的自定義解決方案。

下圖顯示同步處理 Kubernetes 狀態的程式：

通常，在同步處理期間，即時叢集中不允許部署新版本的應用程式。這段時間從同步開始，並在切換至綠色叢集完成時完成。停用 Kubernetes 中部署的方式可能會有所不同。兩個可能的解決方案如下：

停用部署管線。
停用執行部署的 Kubernetes 服務帳戶。

您可以使用開放式原則代理程式（OPA）將服務帳戶的停用自動化。目前還無法使用 AKS 原生功能，因為它們仍處於預覽狀態。

您可以使用管理多個叢集中 Kubernetes 狀態的進階機制來避免同步處理期間。

同步處理完成時，需要叢集和應用程式的驗證。這包括：

檢查監視和記錄平臺，以驗證叢集的健康情況。您可以考慮在 T1：部署綠色叢集階段中執行的動作。
根據目前使用的工具鏈，對應用程式進行功能測試。

建議您也執行負載測試會話，以比較綠色叢集應用程式的效能與效能基準。您可以使用慣用的工具或 Azure 負載測試。

通常，綠色叢集會在應用程式網關或外部負載平衡器上公開，而外部使用者看不到的內部URL。

驗證新叢集時，您可以繼續進行下一個階段，將流量切換至新的叢集。

T3：將流量切換至綠色叢集

同步完成且綠色叢集在平臺和應用層級驗證之後，即可升級為主要叢集，並開始接收即時流量。交換器會在網路層級執行。工作負載通常是無狀態的。不過，如果工作負載為具狀態，則必須實作額外的解決方案，以在交換器期間維護狀態和快取。

以下是在套用參數之後顯示目標狀態的圖表：

本文所述的技術會實作完整交換器：100% 的流量會路由傳送至新的叢集。這是因為路由會套用在 DNS 層級，並具有 A 更新為指向綠色叢集的或 CNAME 記錄指派，而且每個叢集都有應用程式網關。

以下是切換私人面向端點的設定範例。建議的解決方案會使用 A 記錄進行切換。從 DNS 和 IP 對應的觀點來看，切換之前的情況如下：

A 記錄 aks.priv.contoso.com 會指向藍色應用程式閘道的私人IP。
A 記錄 aks-blue.priv.contoso.com 會指向藍色應用程式閘道的私人IP。
A 記錄 aks-green.priv.contoso.com 會指向綠色應用程式閘道的私人IP。

參數會重新設定為下列專案：

A 記錄 aks.priv.contoso.com 會指向綠色應用程式閘道的私人IP。
A 記錄 aks-blue.priv.contoso.com 會指向藍色應用程式閘道的私人IP。
A 記錄 aks-green.priv.contoso.com 會指向綠色應用程式閘道的私人IP。

叢集的使用者會在存留時間（TTL）和記錄的 DNS 傳播之後看到切換。

針對公開的端點，建議的方法會使用 Azure Front Door 和 Azure DNS。以下是切換前的組態：

CNAME 記錄 official-aks.contoso.com 會指向自動產生的 Azure Front Door 網域記錄。如需詳細資訊，請參閱教學課程：將自訂網域新增到您的 Front Door。
A 記錄 aks.contoso.com 會指向藍色應用程式閘道的公用IP。
Azure Front Door 原始設定會指向 aks.contoso.com 主機名。如需設定後端集區的詳細資訊，請參閱 Azure Front Door 中的來源和原始群組。
- A 記錄 aks-blue.contoso.com 會指向藍色應用程式閘道的公用IP。
- A 記錄 aks-green.contoso.com 會指向綠色應用程式閘道的公用IP。

參數會重新設定為下列專案：

CNAME 記錄 official-aks.contoso.com 會指向自動產生的 Azure Front Door 網域記錄。
A 記錄 aks.contoso.com 指向綠色應用程式閘道的公用IP。
Azure Front Door 原始設定會指向 aks.contoso.com 主機名。
- A 記錄 aks-blue.contoso.com 指向藍色應用程式閘道的公用IP。
- A 記錄 aks-green.contoso.com 指向綠色應用程式閘道的公用IP。

其他切換技術，例如 Canary 版本的部分交換器，可以搭配其他 Azure 服務，例如 Azure Front Door 或流量管理員。如需在 Azure Front Door 層級實作藍綠流量交換器，請參閱使用 Azure Front Door 進行藍綠部署。

如範例所述，從網路的觀點來看，這項技術是以四個主機名的定義為基礎：

官方公開的主機名： 使用者和取用者所使用的官方公用主機名。
叢集主機名： 裝載於叢集中之工作負載取用者所使用的官方主機名。
藍色叢集主機名： 藍色叢集的專用主機名。
綠色叢集主機名： 綠色叢集的專用主機名。

叢集主機名是在應用程式閘道層級設定，以管理輸入流量。主機名也是 AKS 輸入設定的一部分，以便正確管理傳輸層安全性（TLS）。此主機僅用於即時交易和要求。

如果 Azure Front Door 也是部署的一部分，則不會受到交換器的影響，因為它只會管理官方叢集主機名。它為應用程式使用者提供適當的抽象概念。它們不會受到交換器的影響，因為 DNS CNAME 記錄一律指向 Azure Front Door。

藍色和綠色叢集主機名主要用於測試和驗證叢集。為了達到這些目的，主機名會在應用程式閘道層級公開並具有專用端點，而且也會在 AKS 輸入控制器層級公開，以正確管理 TLS。

在這個階段，驗證是以基礎結構和應用程式監視計量，以及正式 SLO 和 SLA 為基礎，如果有的話。如果驗證成功，請轉換至最後階段以終結藍色叢集。

T4：終結藍色叢集

切換流量會成功將我們帶到最後階段，其中仍會發生驗證和監視，以確保綠色叢集能如預期般使用即時流量。驗證和監視涵蓋平臺和應用層級。

完成此驗證之後，可以終結藍色叢集。解構是強烈建議使用的步驟，以降低成本，並適當地使用 Azure 所提供的彈性，特別是 AKS。

以下是藍色叢集終結之後的情況：

元件

應用程式閘道是 Web 流量（OSI 第 7 層）負載平衡器，可讓您管理 Web 應用程式的流量。在此解決方案中，它會作為 HTTP 流量存取 AKS 叢集的閘道。
Azure Kubernetes Service （AKS）是受控 Kubernetes 服務，可用來部署和管理容器化應用程式。此應用程式平臺是此模式的主要元件。
Azure Container Registry 是一項受控服務，可用來儲存和管理容器映射和相關成品。在此解決方案中，用來在 AKS 叢集中儲存和散發容器映像和成品，例如 Helm 圖表。
Azure 監視器是一種監視解決方案，可用來收集、分析及回應來自雲端和內部部署環境的監視數據。它提供執行藍色綠色部署所需的核心監視功能。由於它與 AKS 整合，以及其提供記錄、監視和警示功能的功能，可用來管理階段轉換，因此會用於此架構。
Azure 金鑰保存庫可協助解決下列問題：秘密管理、金鑰管理和憑證管理;它可用來儲存和管理此解決方案的 platfomr 和應用層級所需的秘密和憑證。
Azure Front Door 是全域負載平衡器和應用程式端點管理系統。此解決方案會作為裝載在 AKS 上的 HTTP 應用程式的公用端點。在此解決方案中，它必須負責管理藍色和綠色應用程式閘道之間的流量交換器。
Azure DNS 是 DNS 網域的裝載服務，可使用 Microsoft Azure 基礎結構來提供名稱解析。它會管理用於藍色和綠色叢集之解決方案中的主機名，並在流量交換器中扮演重要角色，尤其是私人端點。

替代項目

實作流量交換器有替代技術，可提供更多控制。例如，您可以使用以下列一或多個為基礎的流量規則來執行部分切換：
- 連入流量的百分比
- HTTP 標頭
- Cookie
另一個提供更大保護的替代方式，可防範變更所造成的問題，就是進行通道式部署。與其說是藍色和綠色叢集，不如說是藍色和綠色叢集，而是可以有更多的叢集，稱為環形。每個通道都足夠大，足以存取新版本 AKS 的用戶數目。至於此處所述的藍綠部署，可以移除通道，以取得適當的成本優化和控制。
應用程式閘道的可能替代方案是 NGINX 和 HAProxy。
容器登錄的可能替代方案是 Harbor。
在某些情況下，您可以使用不同的負載平衡和 DNS 服務來執行流量交換器，而不是 Azure Front Door 和 Azure DNS。
此解決方案是以標準輸入控制器 Kubernetes API 為基礎。如果您的解決方案會受益於閘道 API，則請針對容器使用應用程式閘道。它可協助管理負載平衡，並處理應用程式閘道與 Pod 之間的輸入流量管理。容器應用程式閘道會控制應用程式閘道的設定。

案例詳細資料

解決方案的主要優點包括：

在部署期間將停機時間降至最低。
計劃復原策略。
改善 AKS 變更和升級發行和部署期間的控制和作業。
測試執行災害復原（DR）程式的需求。

這些文章將討論藍綠部署的主要原則和基本層面：

從自動化和 CI/CD 的觀點來看，解決方案可以透過多種方式實作。我們建議：

適用於 IaC 的 Bicep 或 Terraform 。
適用於 CI/CD 的 Azure Pipelines 或 GitHub Actions 。

潛在使用案例

藍綠部署可讓您對叢集進行變更，而不會影響執行中的應用程式和工作負載。變更的範例包括：

作業變更
啟用新的 AKS 功能
叢集中共用資源的變更
更新 Kubernetes 版本
修改 Kubernetes 資源和物件，例如輸入閘道、服務網格、操作員、網路原則等等
復原至仍在部署的舊版 AKS 叢集，而不會影響叢集中執行的工作負載

考量

這些考量能實作 Azure Well-Architected Framework 的要素，其為一組指導原則，可以用來改善工作負載的品質。如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework (部分機器翻譯)。

藍綠部署可以完全自動化，例如零接觸部署。初始實作通常會有手動觸發程式來啟動階段。一路上，以及適當的成熟度和監視功能，可以自動化觸發程式。這表示有自動化測試和特定計量、SLA 和 SLO 來自動化觸發程式。
請務必擁有藍綠色叢集的專用主機名，以及在叢集前面的網關和負載平衡器上具有專用的端點組態。這對於改善新叢集部署的可靠性與有效性至關重要。如此一來，部署的驗證就會與標準生產叢集的相同架構和組態一起發生。
請考慮 AKS 叢集是多個由不同業務單位管理之應用程式的共用資源的情況。在這種情況下，AKS 平臺本身通常是由負責叢集整體作業和生命週期的專用小組所管理，而且叢集中有用於系統管理員和作業用途的端點。我們建議這些端點在 AKS 叢集中有專用的輸入控制器，以適當區隔考慮和可靠性。
藍綠色部署適用於實作及測試 AKS 和相關工作負載的商務持續性和災害復原（BC/DR）解決方案。特別是，它提供管理多個叢集的基本結構，包括叢集分散於多個區域的情況。
藍綠部署的成功，取決於將實作的所有層面套用，例如自動化、監視和驗證，不僅套用至 AKS 平臺，也套用至部署在平臺上的工作負載和應用程式。這樣做可協助您獲得藍綠部署的最大好處。
在建議的解決方案中，每個案例都有兩個應用程式閘道公用和私用，因此總共有四個。此決策是在 Azure 應用程式閘道層級套用藍色綠色部署，以避免閘道設定錯誤所造成的停機時間。此決策的主要缺點是成本，因為有四個應用程式閘道實例。它們只會在應用程式閘道設定的相關變更期間平行執行，例如 WAF 原則或調整設定。如需進一步的成本優化，您可以為每個案例選擇單一應用程式閘道，這表示總共有兩個應用程式閘道。這需要您將藍色/綠色邏輯移至應用程式閘道，而不是 Azure Front Door。因此，應用程式閘道不是必須控制 Azure Front Door。

可靠性

可靠性可確保您的應用程式可以符合您對客戶的承諾。如需詳細資訊，請參閱可靠性要素的概觀 (部分機器翻譯)。

藍綠部署對 AKS 平臺和工作負載的可用性有直接且正面的影響。特別是，它會在 AKS 平台變更的部署期間增加可用性。如果用戶會話管理良好，則停機時間很小。
藍綠色部署提供部署期間可靠性的涵蓋範圍，因為如果新叢集中發生問題，可以選擇回復至舊版的AKS 叢集。

成本最佳化

成本優化是考慮如何減少不必要的費用，並改善營運效率。如需詳細資訊，請參閱成本最佳化要素的概觀。

Azure 中廣泛採用藍綠部署，因為雲端提供的原生彈性。這可讓您在作業和資源耗用量方面將成本優化。大部分節省的結果，都是在成功部署新版本叢集之後，移除不再需要的叢集。
部署新版本時，通常會同時裝載相同子網中的藍色和綠色叢集，以繼續具有相同的成本基準。這兩個叢集的所有網路連線和存取權都相同，所有 Azure 服務和資源都保持不變。

卓越營運

卓越營運涵蓋部署應用程式並使其持續在生產環境中執行的作業流程。如需詳細資訊，請參閱卓越營運要素的概觀 (部分機器翻譯)。

藍綠部署已正確實作，可提供自動化、持續傳遞和彈性部署。
持續傳遞的其中一個關鍵層面是反覆傳遞平臺和工作負載變更的增量。透過 AKS 的藍綠部署，您可以透過受控且安全的方式，在平臺層級實現持續傳遞。
復原是藍綠部署的基礎，因為它包含復原至上一個叢集的選項。
藍綠部署提供適當的自動化層級，以減少與商務持續性策略相關的工作。
監視平臺和應用程式對於成功實作至關重要。針對平臺，您可以使用原生 Azure 監視功能。針對應用程式，必須設計和實作監視。

部署此案例

如需本指南中所述之藍綠部署的實作範例，請參閱 AKS 登陸區域加速器。

此參考實作是以應用程式閘道和應用程式閘道輸入控制器（AGIC）為基礎。每個叢集都有自己的應用程式閘道，而且流量交換器是透過 DNS 完成的，特別是透過 CNAME 組態來完成。

重要

對於任務關鍵性工作負載，請務必結合本指南中所述的藍色/綠色部署與部署自動化和持續驗證，以達到零停機時間部署。如需詳細資訊和指引，請參閱任務關鍵性設計方法。

區域考量

您可以將藍色和綠色叢集部署到不同的區域或相同的區域。設計與操作原則不會受到這個選擇的影響。不過，某些類型的其他網路設定可能會受到影響，例如：

AKS 和應用程式閘道的專用虛擬網路和子網。
與監視、Container Registry 和金鑰保存庫等備份服務連線。
應用程式閘道的 Azure Front Door 可見度。

部署至相同區域的必要條件如下：

虛擬網路和子網的大小必須設定為裝載兩個叢集。
Azure 訂用帳戶必須為這兩個叢集提供足夠的容量。

部署輸入控制器和外部負載平衡器

部署輸入控制器和外部負載平衡器的方法有不同：

您可以使用專用外部負載平衡器的單一輸入控制器，例如本指南中所述架構的參考實作。 AGIC 是 Kubernetes 應用程式，可讓您使用應用程式閘道 L7 負載平衡器將雲端軟體公開至因特網。在某些情況下，除了應用程式端點之外，AKS 叢集中還有系統管理員端點。系統管理端點適用於在應用程式上執行作業工作，或用於更新設定對應、秘密、網路原則和指令清單等設定工作。
您可以有單一外部負載平衡器，提供部署在相同叢集或多個叢集上的多個輸入控制器。參考實作中未涵蓋此方法。在此案例中，我們建議您針對公開端點和私人端點，有個別的應用程式網關。
本指南所提議和描述的結果架構是以部署為 AKS 叢集一部分的標準輸入控制器為基礎，例如 NGINX 和 Envoy 型的輸入控制器。在參考實作中，我們使用 AGIC，這表示應用程式閘道與 AKS Pod 之間有直接連線，但這不會影響整體藍綠色架構。

參與者

本文由 Microsoft 維護。原始投稿人如下。

主要作者：

Vincenzo Morra |SAO Incubation Architect

其他投稿人：

奧斯卡·普拉·阿爾瓦雷斯 |網域解決方案架構師

若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。

共用方式為

AKS 叢集的藍綠部署

架構