AKS クラスターのブルーグリーンデプロイ

Azure Kubernetes Service (AKS)

Azure Application Gateway

Azure Container Registry

Azure Front Door

Azure DNS

この記事では、現在のバージョンの実行を続けながら、Azure Kubernetes Service (AKS) クラスターの新しいバージョンをテストするブルーグリーンデプロイ戦略の実装に関するガイダンスを提供します。新しいバージョンが検証されると、ルーティング変更によってユーザートラフィックが切り替わります。この方法でデプロイすると、AKS クラスターへのアップグレードを含む変更を行うときの可用性が向上します。この記事では、Azure マネージドサービスとネイティブ Kubernetes 機能を使用する AKS のブルーグリーンデプロイの設計と実装について説明します。

アーキテクチャ

このセクションでは、AKS クラスターのブルーグリーンデプロイのアーキテクチャについて説明します。次の 2 つのケースがあります。

アプリケーションと API は一般向けです。
アプリケーションと API はプライベート向けです。

また、ここでは説明していないハイブリッドケースもあります。ここでは、一般向けアプリケーションとプライベート向けアプリケーションと API がクラスター内に混在しています。

次の図は、一般向けのケースのアーキテクチャを示しています。

このアーキテクチャの Visio ファイルをダウンロードします。

Azure Front Door と Azure DNS には、青と緑のクラスター間でトラフィックを切り替えるルーティングメカニズムが用意されています。詳細については、「Azure Front Door を使用したブルーグリーンデプロイ」をご覧ください。 Azure Front Door を使用すると、重さに基づいて完全なスイッチまたはより制御されたスイッチを実装できます。この手法は、Azure 環境で最も信頼性が高く効率的です。独自の DNS とロードバランサーを使用する場合は、安全で信頼性の高いスイッチを提供するように構成されていることを確認する必要があります。

Azure Application Gateway は、パブリックエンドポイント専用のフロントエンドを提供します。

この図は、プライベート向けのケースを対象にしています。

このアーキテクチャの Visio ファイルをダウンロードします。

この場合、1 つの Azure DNS インスタンスによって、青と緑のクラスター間のトラフィックの切り替えが実装されます。これは、 A と CNAME のレコードを使用して行われます。詳細については、「T3: トラフィックを緑色のクラスターに切り替える」セクションをご覧ください。

Application Gateway は、プライベートエンドポイント専用のフロントエンドを提供します。

ワークフロー

ブルーグリーンデプロイでは、クラスターの現在のバージョンを新しいバージョンに更新するための 5 つの段階があります。この説明では、青いクラスターが現在のバージョンであり、緑のクラスターが新しいクラスターです。

以下のステージがあります。

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 を指します。これは、バックエンドプールとして青色のクラスターのプライベート IP またはパブリック IP を持ちます。
- aks-green.contoso.com は、グリーンクラスターのプライベート IP またはパブリック IP をバックエンドプールとして持つアプリケーションゲートウェイのプライベート IP またはパブリック IP を指します。

T0: 青いクラスターがオンになっている

初期ステージ T0 は、青いクラスターがライブであるということです。このステージでは、クラスターの新しいバージョンをデプロイ用に準備します。

T1 ステージのトリガー条件は、新しいバージョンのクラスター (緑のクラスター) のリリースです。

T1: 緑のクラスターをデプロイする

このステージでは、新しい緑のクラスターのデプロイが開始されます。青いクラスターはオンのままで、ライブトラフィックは引き続きルーティングされます。

T2 ステージに移行するトリガーは、プラットフォームレベルでの緑色の AKS クラスターの検証です。この検証では、Azure Monitor メトリックと CLI コマンドを使用して、デプロイの正常性を確認します。詳細については、「Monitor を使用た Azure Kubernetes Service (AKS) のモニタリング」と「AKS データ参照」をご覧くださいださい。

AKS 監視は、次の図に示すように、異なるレベルに分割できます。

クラスターの正常性は、レベル 1 とレベル 2、およびレベル 3 の一部で評価されます。レベル 1 の場合、次に示すように、Monitor のネイティブマルチクラスタービューを使用して正常性を検証できます。

レベル 2 で、Kubernetes API サーバーと Kubelet が正しく動作することを確認します。 Kubelet ブックは、モニターで使用できます。具体的には、ノードの主要な動作統計情報を示すブックの 2 つのグリッドです。

ノードグリッドによる概要では、ノードごとの割合および傾向による、合計操作数、合計エラー数、および成功した操作数を要約します。
操作の種類別の概要グリッドには、操作の種類ごとに、操作の数、エラー、成功した操作の割合と傾向が表示されます。

レベル 3 は、omsagent、kube-proxy など、AKS で既定でデプロイされる Kubernetes オブジェクトとアプリケーション専用です。この検査では、[モニター] の [分析情報] ビューを使用して、AKS デプロイの状態を確認できます。

別の方法として、「Container Insights によるデプロイ & HPA メトリック」に記載されている専用ブックを使用できます。次に例を示します。

検証が成功したら、T2 ステージに移行できます。

T2: 青と緑のクラスターの間で Kubernetes の状態を同期する

この段階では、 アプリケーション、 オペレーター、 Kubernetes リソース はまだ緑のクラスターにデプロイされていません。または、AKS クラスターがプロビジョニングされるときに、少なくともそれらのすべてが適用およびデプロイされるわけではありません。このステージの最終的な目標は、同期の最後に、緑のクラスターが青いクラスターと下位互換性を持つということです。その場合は、緑のクラスターにトラフィックを切り替える前に、新しいクラスターの状態を検証できます。

クラスター間で Kubernetes 状態を同期するには、さまざまな方法があります。

継続的インテグレーションと継続的デリバリー (CI/CD) による再デプロイメント。通常は、アプリの通常のデプロイに使用されるのと同じ CI/CD パイプラインを使用するだけで十分です。これを行うための一般的なツールは、GitHub Actions、Azure DevOps、Jenkins です。
Flux や ArgoCD など、Cloud Native Computing Foundation (CNCF) Web サイトでレベルを上げたソリューションを使用した GitOps。
Kubernetes の構成とリソースをデータストアに格納するカスタマイズされたソリューション。通常、これらのソリューションは、メタデータ定義から始まり、生成された Kubernetes マニフェストを Azure Cosmos DB などのデータストアに格納する Kubernetes マニフェストジェネレーターに基づいています。これらは通常、使用中のアプリケーション記述フレームワークに基づくカスタムソリューションです。

次の図は、Kubernetes 状態を同期するプロセスを示しています。

通常、同期中に、新しいバージョンのアプリケーションのデプロイは、ライブクラスターでは許可されません。この期間は同期から始まり、緑のクラスターへの切り替えが完了すると終了します。 Kubernetes でデプロイを無効にする方法は異なる場合があります。考えられる 2 つの解決策。

デプロイパイプラインを無効にします。
デプロイを実行する Kubernetes サービスアカウントを無効にします。

Open Policy Agent (OPA) を使用して、サービスアカウントの無効化を自動化できます。 AKS ネイティブ機能はまだプレビュー段階であるため、この機能を使用することはできません。

同期期間は、複数のクラスターで Kubernetes 状態を管理する高度なメカニズムを使用して回避できます。

同期が完了したら、クラスターとアプリケーションの検証が必要です。これには次のものが含まれます

クラスターの正常性を検証するための監視プラットフォームとログプラットフォームのチェック。「T1: 緑のクラスターをデプロイする」ステージで行うことを検討できます。
現在使用されているツールチェーンに基づくアプリケーションの機能テスト。

また、ロードテストセッションを実行して、グリーンクラスターアプリケーションのパフォーマンスとパフォーマンスベースラインを比較することをお勧めします。任意のツールまたは Azure Load Testing を使用できます。

通常、緑色のクラスターは、外部ユーザーには表示されない内部 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 を指します。

カナリアリリースの部分スイッチなどの代替の切り替え手法は、Azure Front Door や Traffic Manager などの追加の Azure サービスでできます。 Azure Front Door レベルでのブルーグリーンのトラフィックスイッチの実装については、「Azure Front Door を使用したブルーグリーンデプロイ」を参照してください。

この例で説明したように、ネットワークの観点からは、この手法は 4 つのホスト名の定義に基づいています。

公式に公開されているホスト名: エンドユーザーとコンシューマーによって使用される公式パブリックホスト名。
クラスターホスト名: クラスターでホストされているワークロードのコンシューマーによって使用される公式のホスト名。
青いクラスターホスト名: 青いクラスターの専用ホスト名。
緑のクラスターホスト名: 緑のクラスターの専用ホスト名。

クラスターホスト名は、イングレストラフィックを管理するためにアプリケーションゲートウェイレベルで構成されるホスト名です。ホスト名は、トランスポート層セキュリティ (TLS) を適切に管理するために、AKS イングレス構成の一部でもあります。このホストは、ライブトランザクションと要求にのみ使用されます。

Azure Front Door がデプロイの一部でもある場合は、公式のクラスターホスト名のみを管理するため、スイッチの影響を受けません。これにより、アプリケーションユーザーに適切な抽象化が提供されます。 DNS CNAME レコードは常に Azure Front Door を指しているため、スイッチの影響を受けません。

青と緑のクラスターホスト名は、主にクラスターのテストと検証に使用されます。これらの目的のために、ホスト名は専用エンドポイントを使用してアプリケーションゲートウェイレベルで公開され、TLS を適切に管理するために AKS イングレスコントローラーレベルでも公開されます。

この段階では、検証はインフラストラクチャとアプリの監視メトリックに基づいており、利用可能な場合は公式の SLO と SLA に基づいています。検証に成功した場合は、最終ステージに移行して青いクラスターを破棄します。

T4: 青いクラスターを破棄する

トラフィックを正常に切り替えると、最終的なステージに進み、ライブトラフィックで緑のクラスターが期待どおりに動作するように検証と監視が行われます。検証と監視は、プラットフォームレベルとアプリケーションレベルの両方をカバーします。

この検証が完了すると、青いクラスターを破棄できます。破棄は、コストを削減し、Azure が提供する弾力性、特に AKS を適切に使用するために強くお勧めするステップです。

青いクラスターが破棄された後の状況を次に示します。

コンポーネント

Application Gateway は、Web アプリケーションに対するトラフィックを管理できる Web トラフィック (OSI レイヤー 7) ロードバランサーです。このソリューションでは、AKS クラスターにアクセスするための HTTP トラフィックのゲートウェイとして使用されます。
Azure Kubernetes Service (AKS) は、コンテナ化されたアプリケーションをデプロイして管理するために使用できるマネージド Kubernetes サービスです。このアプリケーションプラットフォームはこのパターンのメインコンポーネントです。
Azure Container Registry は、コンテナーイメージと関連するアーティファクトの格納と管理に使用されるマネージドサービスです。このソリューションでは、コンテナーイメージとアーティファクト (Helm チャートなど) を AKS クラスターに格納して配布するために使用します。
Azure Monitor は、クラウド環境とオンプレミス環境からの監視データを収集し、分析して、対応するための監視ソリューションです。青緑色のデプロイを実行するために必要な主要な監視機能が提供されます。 AKS との統合と、ステージ切り替えの管理に使用できるログ記録、監視、アラート機能を提供する機能があるため、このアーキテクチャで使用されています。
Azure Key Vault はシークレット管理、キー管理、証明書管理に関する問題の解決に役立ちます。このソリューションのプラットフォームレベルとアプリケーションレベルで必要なシークレットと証明書を格納および管理するために使用されます。
Azure Front Door はグローバルロードバランサーでありアプリケーションエンドポイント管理システムでもあります。このソリューションでは、AKS でホストされている HTTP アプリケーションのパブリックエンドポイントとして使用されます。このソリューションでは、青と緑のアプリケーションゲートウェイ間のトラフィックスイッチを管理する重要な責任があります。
Azure DNS は、DNS ドメインのホスティングサービスであり、Microsoft Azure インフラストラクチャを使用した名前解決を提供します。青と緑のクラスターのソリューションで使用されるホスト名を管理し、トラフィックスイッチ (特にプライベートエンドポイント) で重要な役割を果たします。

代替

より多くの制御を提供できるトラフィックスイッチを実装するための代替手法があります。たとえば、次の 1 つ以上に基づくトラフィックルールを使用して、部分スイッチを行うことができます。
- 受信トラフィックの割合
- HTTP ヘッダー
- Cookie
変更によって引き起こされる問題からより大きな保護を提供するもう 1 つの代替手段は、リングベースのデプロイを持つことです。青と緑のクラスターだけでなく、リングと呼ばれるクラスターを増やすこともできます。各リングは、新しいバージョンの AKS にアクセスできるユーザーの数に対して十分な大きさです。ここで説明するブルーグリーンデプロイについては、リングを削除して適切なコストの最適化と制御を行うことができます。
Application Gateway の代わりに、NGINX と HAProxy を使用できます。
Container Registry の代わりに、Harbor を使用することもできます。
状況によっては、Azure Front Door と Azure DNS ではなく、異なる負荷分散サービスと DNS サービスを使用してトラフィックスイッチを実行できます。
このソリューションは、標準のイングレスコントローラー Kubernetes API をベースにしています。ソリューションが Gateway API の恩恵を受ける場合は Application Gateway for Containers を使用します。これは、負荷分散を管理し、Application Gateway とポッド間のイグレストラフィック管理を処理するのに役立ちます。 Application Gateway for Containers はアプリケーションゲートウェイの設定を制御します。

シナリオの詳細

ソリューションの主なベネフィットは次のとおりです。

デプロイ中のダウンタイムを最小限に抑えました。
計画されたロールバック戦略。
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 プラットフォームだけでなく、プラットフォームにデプロイされているワークロードやアプリにも、自動化、監視、検証など、実装のすべての側面を適用することに依存します。これを行うと、ブルーグリーンデプロイの最大のベネフィットを得ることができます。
提案されたソリューションでは、パブリックとプライベートの各シナリオごとに 2 つの Application Gateway があるため、合計 4 つになります。この決定は、ゲートウェイの構成ミスによるダウンタイムを回避するために、Azure Application Gateway レベルで青い緑色のデプロイを適用するためのものです。この決定の主な欠点は、4 つの Application Gateway インスタンスがあるためにコストがかかる点です。これらは、WAF ポリシーやスケーリング構成など、Application Gateway の構成に関連する変更がある期間にのみ並列で実行されます。さらにコストを最適化するために、各シナリオごとに 1 つの Application Gateway を選択できます。つまり、Application Gateway は合計で 2 つになります。そのため、Azure Front Door ではなく、青/緑のロジックをアプリケーションゲートウェイに移動する必要があります。 Azure Front Door が命令型に制御されるのではなく、Application Gateway が制御されます。

信頼性

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。詳細については、「信頼性の重要な要素の概要」を参照してください。

ブルーグリーンデプロイは、AKS プラットフォームとワークロードの可用性に直接的かつ肯定的的な影響を与えます。特に、AKS プラットフォームの変更のデプロイ中の可用性が向上します。ユーザーセッションが適切に管理されている場合、ダウンタイムはほとんどありません。
ブルーグリーンデプロイでは、新しいクラスターバージョンで問題が発生した場合に、既定で以前のバージョンの AKS クラスターにロールバックするオプションがあるため、デプロイ中の信頼性を確保できます。

コスト最適化

コストの最適化とは、不要な費用を削減し、操作効率を向上させる方法を検討することです。詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

ブルーグリーンデプロイは、クラウドによって提供されるネイティブな弾力性により、Azure で広く採用されています。これにより、運用とリソース消費の期間中にコストを最適化できます。節約のほとんどは、新しいバージョンのクラスターを正常にデプロイした後に、不要になったクラスターを削除することでもたらされます。
新しいバージョンをデプロイする場合、同じサブネット内で青と緑の両方のクラスターをホストし、引き続き同じコストベースラインを保持するのが一般的です。リソースとサービスへのすべてのネットワーク接続とアクセスは、2 つのクラスターで同じであり、すべての Azure サービスとリソースは同じままです。

オペレーショナルエクセレンス

オペレーショナルエクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。詳細については、「オペレーショナルエクセレンスの重要な要素の概要」を参照してください。

ブルーグリーンデプロイは、適切に実装されることで、自動化、継続的デリバリー、回復性のあるデプロイを提供します。
継続的デリバリーの重要な側面の 1 つは、プラットフォームとワークロードの変更の増分を反復的に提供することです。 AKS のブルーグリーンデプロイを使用すると、コントロールされた安全な方法でプラットフォームレベルで継続的デリバリーを実現できます。
以前のクラスターにロールバックするオプションが含まれているため、回復性はブルーグリーンデプロイの基本です。
ブルーグリーンデプロイは、ビジネス継続性戦略に関連する労力を削減するための適切なレベルの自動化を提供します。
プラットフォームとアプリを監視することは、実装を成功させるために重要です。プラットフォームでは、ネイティブの Azure 監視機能を使用できます。アプリの場合は、監視を設計して実装する必要があります。

このシナリオのデプロイ

このガイドで説明されているブルーグリーンデプロイの実装例については、 AKS ランディングゾーンアクセラレータに関するページを参照してください。

この参照実装は、Application Gateway と Application Gateway イングレスコントローラー (AGIC) に基づいています。各クラスターには独自のアプリケーションゲートウェイがあり、トラフィックスイッチは DNS 経由 (特に CNAME 構成経由) で行われます。

重要

ミッションクリティカルなワークロードの場合は、このガイドで説明されているブルー/グリーンデプロイと、デプロイの自動化および継続的な検証を組み合わせて、ダウンタイムなしのデプロイを実現することが重要です。詳細とガイダンスについては、ミッションクリティカルな設計手法に関するページを参照してください。

リージョンに関する考慮事項

青と緑のクラスターは、リージョンを分離するか、同じリージョンにデプロイできます。設計と操作の原則は、この選択の影響を受けません。ただし、次のような特定の型の追加のネットワーク構成は影響を受ける可能性があります。

AKS とアプリケーションゲートウェイ用の専用仮想ネットワークとサブネット。
Monitor、Container Registry、Key Vault などのバッキングサービスとの接続。
アプリケーションゲートウェイの Azure Front Door の可視性。

同じリージョンにデプロイするための前提条件があります。

仮想ネットワークとサブネットは、2 つのクラスターをホストするようにサイズを設定する必要があります。
Azure サブスクリプションは、2 つのクラスターに十分な容量を提供する必要があります。

イングレスコントローラーと外部ロードバランサーのデプロイ

イングレスコントローラーと外部ロードバランサーのデプロイには、さまざまな方法があります。

このガイドで説明されているアーキテクチャのリファレンス実装のように、専用の外部ロードバランサーを備えた 1 つのイングレスコントローラーを使用できます。 AGIC は、Application Gateway L7 ロードバランサーを使用して、クラウドソフトウェアをインターネットに公開できるようにする Kubernetes アプリケーションです。特定のシナリオでは、アプリケーションエンドポイントに加えて、AKS クラスターに管理エンドポイントがあります。管理者エンドポイントは、アプリケーションで操作タスクを実行したり、構成マップ、シークレット、ネットワークポリシー、マニフェストの更新などの構成タスクを実行したりするためのものです。
同じクラスターまたは複数のクラスターにデプロイされた複数のイングレスコントローラーを提供する 1 つの外部ロードバランサーを使用できます。この方法については、参照実装では説明されません。このシナリオでは、パブリック向けエンドポイントとプライベートエンドポイント向けに個別のアプリケーションゲートウェイを用意することをお勧めします。
このガイドに示されている、結果として得られるアーキテクチャは、NGINX ベースや Envoy ベースのものなどの AKS クラスターの一部としてデプロイされる標準のイングレスコントローラーに基づいています。参照実装では AGIC を使用します。これは、アプリケーションゲートウェイと AKS ポッドの間に直接接続があることを意味しますが、これはブルーグリーンアーキテクチャ全体には影響しません。

共同作成者

この記事は、Microsoft によって保守されています。当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

ヴィンチェンツォモッラ |SAO インキュベーションアーキテクト

その他の共同作成者:

オスカープラアルバレス | ドメインソリューションアーキテクト

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次の方法で共有

AKS クラスターのブルーグリーンデプロイ