このアーキテクチャでは、アクティブ/アクティブの高可用性の構成で複数のリージョンにわたって Azure Kubernetes Service (AKS) クラスターの複数のインスタンスを実行する方法を詳しく示しています。
このアーキテクチャは、Microsoft が推奨する AKS インフラストラクチャの開始点である AKS ベースライン アーキテクチャに基づいています。 AKS ベースラインでは、Microsoft Entra ワークロード ID、イングレスとエグレスの制限、リソース制限、その他のセキュリティで保護された AKS インフラストラクチャ構成などのインフラストラクチャ機能が詳しく示されています。 これらのインフラストラクチャの詳細については、このドキュメントでは取り上げません。 複数リージョンのコンテンツに進む前に、AKS ベースラインについて理解を深めておくことをお勧めします。
Architecture
このアーキテクチャの Visio ファイルをダウンロードします。
コンポーネント
この複数リージョンの AKS アーキテクチャでは、多くのコンポーネントと Azure サービスが使用されています。 このマルチクラスター アーキテクチャに固有のコンポーネントのみをこちらに一覧します。 他のものについては、「AKS ベースライン アーキテクチャ」を参照してください。
- リージョン AKS クラスター: 複数の AKS クラスターをそれぞれ別の Azure リージョンにデプロイします。 通常の運用中は、ネットワーク トラフィックはすべてのリージョン間でルーティングされます。 1 つのリージョンが使用できなくなった場合、トラフィックは、要求を発行したユーザーに最も近いリージョンにルーティングされます。
- リージョン バブスポーク ネットワーク: リージョン バブスポーク ネットワーク ペアを各リージョン AKS インスタンスにデプロイします。 Azure Firewall Manager ポリシーは、すべてのリージョンでファイアウォール ポリシーを管理するために使用されます。
- Regional Key Vault: Azure Key Vault が各リージョンでプロビジョニングされます。 Key Vault は、機密性の高い値と AKS クラスター固有のキーを格納し、そのリージョンにあるサービスをサポートするために使用します。
- 複数ログワークスペース: Regional Log Analytics ワークスペースは、リージョンのネットワーク メトリックと診断ログを格納するために使用します。 また、共有 Log Analytics インスタンスは、すべての AKS インスタンスのメトリックと診断ログを格納するために使用されます。
- Global Azure Front Door プロファイル: Azure Front Door は、トラフィックの負荷を分散し、各 AKS クラスターの前に配置されているリージョン Azure Application Gateway インスタンスにルーティングするために使用します。 Azure Front Door では、レイヤー 7 のグローバル ルーティングが可能であり、これらはどちらもこのアーキテクチャに必要です。
- 共通コンテナー レジストリ: ワークロードのコンテナー イメージは、マネージド コンテナー レジストリに格納されます。 このアーキテクチャでは、クラスター内のすべての Kubernetes インスタンスに対して 1 つの Azure Container Registry が使用されます。 Azure Container Registry の geo レプリケーションにより、選択した Azure リージョンへのイメージのレプリケートが可能になり、リージョンで障害が発生した場合でも、イメージへの継続的なアクセスを提供することができます。
デザイン パターン
このアーキテクチャでは、2 つのクラウド設計パターンが使用されています。
- ジオード (地理的ノード)、どのリージョンでも任意のリクエストを処理できます。
- デプロイ スタンプ、アプリケーションまたはアプリケーション コンポーネントの複数の独立したコピーが、デプロイメント テンプレートなどの単一のソースからデプロイされます。
ジオード パターンに関する考慮事項
各 AKS クラスターをデプロイするリージョンを選ぶ場合は、ワークロード コンシューマーまたは顧客に近いリージョンを検討してください。 また、リージョン間レプリケーションを使用することも検討してください。 リージョン間レプリケーションにより、ディザスター リカバリー保護のために、他の Azure リージョンとの間で同じアプリケーションとデータが非同期にレプリケートされます。 クラスターが 2 つのリージョンを超えてスケーリングする場合は、AKS クラスター各ペアのリージョン間レプリケーションを引き続き計画します。
ゾーンの障害によるイシューを防止するため、AKS ノード プール内のノードは、各リージョン内で複数の可用性ゾーンに分散されます。 可用性ゾーンは、限られた一連のリージョンでサポートされており、リージョンのクラスター配置に影響します。 サポートされているリージョンの一覧を含め、AKS と可用性ゾーンについて詳しくは、AKS 可用性ゾーン をご覧ください。
デプロイ スタンプに関する考慮事項
マルチリージョン AKS ソリューションを管理する場合は、複数のリージョンに複数の AKS クラスターをデプロイします。 これらのクラスターのそれぞれが 1 つのスタンプとして見なされます。 リージョン障害が起こった場合、またはクラスターにキャパシティまたはリージョン プレゼンスを追加する必要がある場合は、新しいスタンプ インスタンスの作成が必要になる場合があります。 デプロイ スタンプを作成および管理するプロセスを選択する際には、次の点を考慮することが重要です。
- 一般化された構成を使用できるスタンプ定義向けの適切なテクノロジをを選択します。 たとえば、Bicep を使用して、コードとしてインフラストラクチャを定義できます。
- 変数やパラメーター ファイルなどのデプロイ入力メカニズムを使用して、インスタンス固有の値を指定します。
- 柔軟かつ反復可能なべき等のデプロイを可能にするデプロイ ツールを選択します。
- アクティブ/アクティブ スタンプ構成では、各スタンプ間でトラフィックがどのように分散されるかを検討します。 このアーキテクチャでは、グローバルな負荷分散に Azure Front Door が使用されています。
- キャパシティや費用を考慮して、スタンプは、コレクションに追加・削除されます。
- スタンプのコレクションを 1 つの単位として表示または監視する方法を考慮します。
これらの各項目については、以降のセクションで具体的なガイダンスとともに詳しく説明します。
フリート管理
このソリューションを使うと、すべてのクラスターを統合フリートの一部として扱う高度なオーケストレーターを含めることなく、マルチクラスターとマルチリージョンのトポロジを表すことができます。 クラスター数が増えたら、Azure Kubernetes Fleet Manager にメンバーを登録し、参加しているクラスターの大規模管理を強化することを検討してください。 ここで紹介するインフラストラクチャのアーキテクチャは、Fleet Manager に登録しても根本的には変わりませんが、運用開始後や同様のアクティビティには、複数クラスターを同時にターゲットにできるコントロール プレーンのベネフィットがあります。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
クラスターのデプロイとブートストラップ
可用性が高く地理的に分散した構成で複数の Kubernetes クラスターをデプロイする場合は、各 Kubernetes クラスターの合計を結合ユニットとして見なす必要があります。 各 Kubernetes インスタンスが可能な限り同一になるように、デプロイと構成を自動化するコード駆動型の戦略を策定することができます。 その他 Kubernetes クラスターの追加や削除を含む規模調整の戦略を検討します。 設計、デプロイ、構成計画では、可用性ゾーンの停止、リージョンの障害、およびその他の一般的なシナリオを考慮する必要があります。
クラスター定義
Azure Kubernetes Service クラスターをデプロイするためのオプションは多数あります。 Azure Portal、Azure CLI、Azure PowerShell モジュールはすべて、個別または非結合の AKS クラスターをデプロイする適切なオプションです。 ただし、これらの方法を使用すると、密結合された多数の AKS クラスターを操作する場合に課題が生じる場合があります。 たとえば、Azure Portal を使用すると、ステップの欠落や構成オプションを使用できないことが原因で、構成ミスが発生する可能性があります。 ポータルを使用した多数のクラスターのデプロイと構成は、1 人以上のエンジニアが集中して行う必要がある時間がかかるプロセスです。 Azure CLI または Azure PowerShell を使用する場合は、コマンドライン ツールを使用して、反復可能で自動化されたプロセスを構築できます。 ただし、べき等、デプロイ エラーの制御、障害復旧などの責任は、スクリプトとその作成者にあります。
複数の AKS インスタンスで作業をする場合は、Bicep、Azure Resource Manager テンプレートまたは Terraform などの Infrastructure as Code ソリューションを検討することが推奨されます。 コード ソリューションとしてのインフラストラクチャにより、自動化された、スケーラブルなべき等のデプロイ ソリューションが提供されます。 たとえば、ソリューションの共有サービス用に 1 つの Bicep ファイルを使用し、AKS クラスターやその他のリージョン サービス用に別の Bicep ファイルを使用できます。 コードとしてのインフラストラクチャを使用する場合、ネットワーク、承認、診断などの一般化された構成でデプロイ スタンプを定義できます。 デプロイ パラメータ ファイルは、リージョン固有値で指定できます。 この構成では、1 つのテンプレートを使用して、ほぼ同一のスタンプを任意のリージョンにデプロイできます。
コード資産としてインフラストラクチャを開発および保守するコストは、高額になる可能性があります。 Infrastructure as Code を定義するオーバーヘッドが、非常に小さい (たとえば 2 または 3) 場合や、AKS インスタンスの数が変わらない場合など、利点を上回る場合があります。 このような場合は、コマンドライン ツールや Azure Portal を使用した手動のアプローチなど、より命令的なアプローチを使用できます。
クラスター デプロイ
クラスター スタンプの定義後は、各スタンプ インスタンスや複数のスタンプ インスタンスをデプロイするためのたくさんのオプションが用意されます。 GitHub Actions や Azure Pipelines などの最新の継続的インテグレーション テクノロジを使用することをお勧めします。 継続的インテグレーション ベースのデプロイ ソリューションのベネフィットは次のとおりです。
- コードを使用してスタンプを追加および削除できるようにするコードベースのデプロイ
- 統合されたテスト機能
- 統合環境とステージング機能
- 統合シークレット管理ソリューション
- アプリケーション コードとデプロイ スクリプトとテンプレートの両方に対するソース管理との統合
- デプロイ履歴とログ
- アクセス制御と監査機能を使用して、誰がどのような条件で変更できるかを制御します。
グローバル クラスターに対して新しいスタンプが追加または削除されたら、デプロイ パイプラインを更新して整合性を保つ必要があります。 1 つの方法は、GitHub Actions のワークフロー内の個別のステップとして各リージョンへのリソースのデプロイをそれぞれ行うことです。 この構成は、各クラスター インスタンスがデプロイ パイプライン内で明確に定義されているという点で単純です。 この構成には、デプロイに対してクラスターを追加および削除する管理オーバーヘッドが含まれます。
もう 1 つのオプションは、ビジネス ロジックを作成して、目的の場所の一覧またはその他の表示データ ポイントに基づいてクラスターを作成することです。 たとえば、デプロイ パイプラインには目的のリージョンの一覧を含めることができます。パイプライン内のステップは、この一覧をループし、一覧内の各リージョンにクラスターをデプロイできます。 この構成の欠点は、デプロイの一般化が複雑であり、各クラスター スタンプがデプロイ パイプラインで明示的に詳細化されていないことです。 明らかな利点は、目的のリージョンの一覧を単純に更新することで、パイプラインに対するクラスター スタンプの追加または削除ができるようになることです。
また、デプロイ パイプラインからクラスター スタンプを削除しても、スタンプのリソースが停止されるわけではありません。 デプロイ ソリューションと構成によっては、AKS インスタンスとその他 Azure リソースを停止させるための追加の手順を実行する必要があります。 デプロイ スタック を使用して、リソースが必要亡くなった場合のクリーンアップなどを含む Azure リソースの完全なライフサイクル管理の有効化を検討します。
クラスター ブートストラップ
各 Kubernetes インスタンスまたはスタンプがデプロイ後、イングレス コントローラー、ID ソリューション、ワークロード コンポーネントなどのクラスター コンポーネントをデプロイして構成する必要があります。 また、クラスター全体にセキュリティ、アクセス、ガバナンスの各ポリシーを適用することも検討する必要があります。
デプロイと同様に、これらの構成では、複数の Kubernetes インスタンスにわたる手動での管理が困難になる場合があります。 代わりに、大規模な構成とポリシーについて、次のオプションを検討してください。
GitOps
Kubernetes コンポーネントを手動で構成する代わりに、自動化された方法で Kubernetes クラスターに構成を適用することをお勧めします。これらの構成はソース リポジトリにチェックインされるためです。 このプロセスは GitOps と呼ばれることが多く、Kubernetes の人気の GitOps ソリューションには、Flux や Argo CD などがあります。 たとえば、AKS 用 Flux 拡張機能を使用すると、クラスターのデプロイ直後にクラスターを自動的にブートストラップできます。
GitOps の詳細については、AKS ベースライン参照アーキテクチャに関するページを参照してください。 GitOps ベースのアプローチを構成に採用することで、特別な作業なしで各 Kubernetes インスタンスが同様に構成されます。 フリートのサイズが大きくなると、合理化された構成プロセスがさらに重要になります。
Azure Policy
複数の Kubernetes インスタンスが追加されるに従って、ポリシー駆動型のガバナンス、コンプライアンス、および構成のベネフィットが増します。 ポリシー (具体的には Azure Policy) を使用すると、一元化されたスケーラブルな方法がクラスター制御に提供されます。 AKS ポリシーの利点については、AKS ベースライン参照アーキテクチャに関するページを参照してください。
Azure Policy は、AKS クラスターの作成時に有効にしておく必要があります。 コンプライアンス違反の状況が表示されるように、イニシアチブは監査モードで割り当てておく必要もあります。 さらに、組み込みのイニシアチブに含まれていないポリシーを設定することもできます。 これらのポリシーは、 拒否 モードで設定されます。 たとえば、承認されたコンテナー イメージのみがクラスターで実行されるようにするポリシーが設定されています。 独自のカスタム イニシアティブの作成を検討してください。 また、ワークロードに適用可能なポリシーを 1 つの割り当てに結合してください。
ポリシー スコープは、各ポリシーとポリシー イニシアティブのターゲットを指します。 Bicep を使用して、各 AKS クラスターがデプロイされるリソース グループにポリシーを割り当てることができます。 グローバル クラスターの占有領域が増えると、多くの重複するポリシーが発生します。 ポリシーのスコープを、Azure サブスクリプションまたは Azure 管理グループに設定することもできます。 この方法により、サブスクリプションのスコープ内のすべての AKS クラスター、または管理グループの下にあるすべてのサブスクリプションに対して、1 つのポリシー セットを適用できます。
複数の AKS クラスターのポリシーを設計する場合は、次の点を考慮してください。
- すべての AKS インスタンスにグローバルに適用する必要があるポリシーを、管理グループまたはサブスクリプションに適用します。
- 各リージョン クラスターを、リソース グループに適用されるリージョン固有のポリシーを許可する独自のリソース グループに配置します。
ポリシー管理戦略の確立に役立つ資料については、「クラウド導入フレームワーク リソース編成」を参照してください。
ワークロードのデプロイ
AKS インスタンスの構成に加えて、各リージョン インスタンスまたはスタンプにデプロイされたワークロードを考慮してください。 デプロイ ソリューションまたはパイプラインには、各リージョン スタンプに対応する構成が必要です。 グローバル クラスターにスタンプが追加されるにつれ、デプロイ プロセスを拡張するか、新しいリージョン インスタンスに対処できる柔軟性を設定する必要があります。
ワークロードのデプロイを計画する場合は、次の項目を考慮してください。
- 1 つのデプロイ構成を複数のクラスター スタンプで使用できるように、Helm Chart などを使用してデプロイを一般化します。
- すべてのクラスター スタンプにワークロードをデプロイするように構成された 1 つの継続的デプロイ パイプラインを使用します。
- デプロイ パラメーターとしてスタンプ固有のインスタンスの詳細を指定します。
- アプリケーション全体の監視のためにアプリケーション診断ログと分散トレースを構成する方法を検討します。
可用性とフェールオーバー
複数リージョンの Kubernetes アーキテクチャを選択する重要な動機は、サービスの可用性です。 つまり、あるリージョンでサービスまたはサービス コンポーネントが使用できなくなった場合、そのサービスのインスタンスが継続して利用可能なリージョンにトラフィックをルーティングする必要があります。 複数リージョンのアーキテクチャには、さまざまな障害点が含まれています。 このセクションでは、これらの潜在的な障害点についてそれぞれ説明します。
アプリケーション Pod 障害
Kubernetes デプロイ オブジェクトは、Pod の複数のレプリカを管理する ReplicaSet を作成します。 1 つの Pod が利用できない場合は、トラフィックは残っているものの間でルーティングされます。 Kubernetes ReplicaSet は、指定された数のレプリカを稼働状態に維持しようとします。 1 つのインスタンスが停止した場合は、新しいインスタンスが自動作成されるはずです。 最後に、liveness probe を使用して、Pod で実行されているアプリケーションまたはプロセスの状態を確認します。 サービスが応答していない場合、liveness probe によってポッドが削除され、ReplicaSet によって新しいインスタンスが強制的に作成されます。
詳細については、Kubernetes の ReplicaSet に関するページをご覧ください。
データセンターのハードウェア障害
局所的な障害が発生する場合があります。 たとえば、Azure サーバーの 1 台のラックで電源が使用できなくなる場合が挙げられます。 AKS ノードが単一障害点にならないように、Azure Availability Zones を使用します。 可用性ゾーンを使用することで、1 つの 可用性ゾーン内の AKS ノードが、別の可用性ゾーンで定義したノードから物理的に分離されます。
詳細については、AKS と Azure 可用性ゾーンに関するページをご覧ください。
Azure リージョンの障害
リージョン全体が使用できなくなると、クラスター内のポッドは要求を処理できなくなります。 この場合、Azure Front Door は、すべてのトラフックを残りの正常なリージョンにルーティングします。 正常なリージョン内の Kubernetes クラスターと Pod は引き続き要求を処理します。
この状況では、残りのクラスターへのリクエストとトラフィックの増加を補うように注意してください。 次の点を考慮してください。
- リージョンのフェールオーバーによるトラフィックの急激な増加を吸収するために、ネットワークとコンピューティングのリソースを適切なサイズに設定します。 たとえば、Azure CNI を使用する場合は、トラフィックのスパイク中にすべての Pod IP アドレスをサポートするのに十分な大きさのサブネットがあることを確認します。
- ポッドの水平オートスケーラーを使用して、ポッド レプリカ数を増やし、リージョンの需要の増加を補います。
- AKS クラスター オートスケーラーを使用して、Kubernetes インスタンス ノード数を増やし、増加したリージョンの需要を補います。
詳細については、「ポッドの水平オートスケーラー」と AKS クラスター オートスケーラーに関するページを参照してください。
ネットワーク トポロジ
AKS ベースライン参照アーキテクチャと同様に、このアーキテクチャではハブスポーク ネットワーク トポロジが使用されます。 AKS ベースライン参照アーキテクチャで指定されている考慮事項に加えて、次のベスト プラクティスを考慮してください。
- 仮想ネットワークのハブスポーク セットを、各リージョンの AKS インスタンスに実装します。 各リージョン内で、各スポークをハブ仮想ネットワークにピアリングします。
- すべての送信トラフィックを、各リージョン ハブ ネットワークにある Azure Firewall インスタンスを経由してルーティングします。 Azure Firewall Manager ポリシーを利用して、すべてのリージョンでファイアウォール ポリシーを管理します。
- AKS ベースライン参照アーキテクチャに記載されている IP サイズに従い、別のリージョンとリージョン障害が発生し、残りのリージョンへのトラフィックが大幅に増加した場合に備えて、ノードと Pod の両方の規模操作でより多くの IP アドレスを許可します。
トラフィック管理
AKS ベースライン参照アーキテクチャを使用すると、ワークロード トラフィックは、Azure Application Gateway インスタンスに直接ルーティングされてから、バックエンドのロード バランサーおよび AKS イングレス リソースに転送されます。 複数のクラスターを利用する場合、クライアント要求は Azure Front Door インスタンスを介してルーティングされ、Azure Application Gateway インスタンスにルーティングされます。
この図の Visio ファイルをダウンロードします。
ユーザーがドメイン名 (例:
https://contoso-web-a1bc2de3fh4ij5kl.z01.azurefd.net) に要求を送信し、これが Azure Front Door プロファイルに解決されます。 この要求は、Azure Front Door のすべてのサブドメインに対して発行されたワイルドカード証明書 (*.azurefd.net) を使用して暗号化されます。 Azure Front Door により、Web Application Firewall ポリシーに対して要求が検証され、(正常性と待機時間に基づいて) 最速の要求元が選択され、パブリック DNS を使用して元の IP アドレス (Azure Application Gateway インスタンス) が解決されます。Azure Front Door により、リージョン スタンプのエントリ ポイントとして機能する、選択された適切な Application Gateway インスタンスに要求が転送されます。 トラフィックはインターネット経由で流れます。 Azure Front Door では、要求元へのトラフィックが確実に暗号化されます。
Application Gateway インスタンスが Front Door インスタンスからのトラフィックのみを受け入れるようにする方法を検討します。 1 つの方法は、Application Gateway を含むサブネットでネットワーク セキュリティ グループを使用することです。 規則を使用すると、Source、Port、Destination などのプロパティに基づいて、受信 (または送信) トラフィックをフィルター処理できます。 Source プロパティを使用すると、Azure リソースの IP アドレスを示す組み込みのサービス タグを設定できます。 この抽象化により、規則の構成と保守、および IP アドレスの追跡が容易になります。 さらに、要求元に送信する前に Azure Front Door が要求に追加する
X-Azure-FDIDヘッダーを使用して、Application Gateway インスタンスのみが、Front Door インスタンスからのトラフィックを許可するよう検討します。 Front Door ヘッダーの詳細については、「Azure Front Door での HTTP ヘッダー プロトコルのサポート」を参照してください。
共有リソースに関する考慮事項
このシナリオの焦点は、複数 Azure リージョンで複数 Kubernetes インスタンスを分散させることにありますが、すべてのリージョンでいくつかのリソースを共有することも理にかなっています。 1 つの方法は、すべての共有リソースを 1 つの Bicep ファイルでデプロイし、その後、各リージョンの固有のリソース (スタンプ) を別の Bicep ファイルでデプロイすることです。 このセクションでは、これらの共有リソースと、複数の AKS インスタンス間でそれらを使用する際の考慮事項についてそれぞれ説明します。
Container Registry
このアーキテクチャでは、Azure Container Registry を使用して、コンテナー イメージ サービスを提供します。 クラスターは、レジストリからコンテナー イメージをプルします。 複数リージョンのクラスター デプロイで Azure Container Registry を使用する場合は、次の点を考慮してください。
ご利用可能な地域
AKS クラスターがデプロイされている各リージョンにコンテナー レジストリを配置します。 この方法により、低遅延ネットワーク運用が許可され、高速で信頼性の高いイメージ レイヤ転送が可能になります。 また、リージョン サービスが利用できない場合に可用性を提供するための複数のイメージ サービス エンドポイントを維持していることも意味します。 Azure Container Registry の geo レプリケーション機能を使用すると、複数リージョンに自動的にレプリケートされる 1 つの コンテナー レジストリを管理できます。
1 つのレジストリを作成し、クラスターが配置される各 Azure リージョンに、そのレプリカが作成されるようにすることを検討してください。 Azure Container Registry レプリケーションの詳細については、「Azure Container Registry の geo レプリケーション」を参照してください。
Azure Portal 内からの複数の Azure Container Registry レプリカを示す画像。
クラスターへのアクセス
各 AKS クラスターでは、コンテナー イメージ レイヤーをプルできるように、コンテナー レジストリにアクセスする必要があります。 Azure Container Registry へのアクセスを確立する方法は複数あります。 このアーキテクチャでは、クラスターごとにマネージド ID が作成され、コンテナー レジストリで AcrPull ロールが付与されます。 Azure Container Registry アクセスに対してマネージド ID を使用する場合の推奨事項については、「AKS ベースライン参照アーキテクチャ」を参照してください。
この構成は、新しいスタンプがデプロイされるたびに新しい AKS インスタンスにアクセス権が付与されるように、クラスター スタンプ Bicep ファイルで定義されています。 コンテナー レジストリは共有リソースであるため、デプロイにコンテナー レジストリのリソース ID がパラメーターとして含まれるようにします。
Azure Monitor
Azure Monitor Container Insights 機能は、クラスターとコンテナー ワークロードのパフォーマンスと正常性を、監視および把握するのにお勧めのツールです。 Container Insights では、ログ データを格納する Log Analytics ワークスペースと、数値の時系列データを格納する Azure Monitor メトリック の両方が使用されます。 Prometheus メトリックも Container Insights で収集され、データは Azure Monitor Prometheus 用マネージド サービスまたはAzure Monitor ログのいずれかに送信できます。 詳細については、AKS ベースライン参照アーキテクチャに関するページを参照してください。
AKS クラスター診断設定を構成して、AKS コントロール プレーン コンポーネントからリソース ログを収集および分析し、Log Analytics ワークスペースに転送することもできます。
マルチリージョン アーキテクチャ用の監視ソリューションを設計する場合は、各スタンプ間の結合を考慮することが重要です。 1 つの Log Analytics ワークスペースをデプロイし、各 Kubernetes クラスターで共有されるようにすることもできます。 他の共有リソースと同様に、リージョン スタンプを定義して、単一の共通共有 Log Analytics ワークスペースに関する情報を使用して、各リージョン クラスターにその共有ワークスペースを接続します。 各リージョン クラスターがその単一の Log Analytics ワークスペースに診断ログを出力する場合は、データとリソース メトリックを使用すると、複数リージョン ソリューション全体の実行方法を理解するのに役立つレポートとダッシュボードをより簡単に作成できます。
Azure Front Door
Azure Front Door は、各 AKS クラスターへのトラフィックの負荷分散とルーティングに使用されます。 Azure Front Door では、レイヤ 7 のグローバル ルーティングも有効になります。 これらの機能がこのシナリオに必要です。
クラスター構成
各リージョン AKS インスタンスが追加されると、Kubernetes クラスターと共にデプロイされた Application Gateway を Azure Front Door の要求元として登録し、ルーティングに使用できるようにする必要があります。 この操作では、コード資産としてのインフラストラクチャを更新する必要があります。 または、この操作をデプロイ構成から切り離して、Azure CLI などのツールを使用して管理することもできます。
証明書
Azure Front Door では、開発環境やテスト環境でも、自己署名証明書を使用した要求元はサポートされていません。 HTTPS トラフィックを有効にするには、証明機関 (CA) によって署名された TLS/SSL 証明書を作成する必要があります。 Front Door でサポートされているその他の CA について詳しくは、Azure Front Door でカスタム HTTPS を有効にする許可された証明機関をご覧ください。
テスト環境や非運用クラスターでは、Certbot を使用して、アプリケーション ゲートウェイごとに Let's Encrypt Authority X3 証明書を作成することを検討するとよいでしょう。
運用クラスターを計画する場合は、組織が推奨している方法を使用して TLS 証明書を調達します。
クラスターのアクセスと ID
「AKS ベースライン参照アーキテクチャ」で説明されているように、クラスターには ID プロバイダーとして Microsoft Entra ID の使用が推奨されます。 そうすると、Microsoft Entra グループをクラスター リソースへのアクセスを制御するために使用できます。
複数のクラスターを管理する場合は、アクセス スキーマを決定する必要があります。 次のオプションがあります。
- メンバーが、クラスター内のすべての Kubernetes インスタンスのすべてのオブジェクトにアクセスできる、グローバル クラスター全体のアクセス グループを作成します。 このオプションでは、最小限の管理ニーズが生じますが、グループ メンバー全員に対して大きな特権が付与されます。
- Kubernetes インスタンスごとに個別のアクセス グループを作成します。これは、個々のクラスター インスタンス内のオブジェクトへのアクセスを許可するために使用されます。 このオプションを使用すると、管理オーバーヘッドが増えますが、よりきめ細かいクラスター アクセスが可能になります。
- Kubernetes オブジェクトの種類と名前空間のきめ細かいアクセス制御を定義し、その結果を Microsoft Entra グループ構造に関連付けます。 このオプションを使用すると、管理オーバーヘッドが大幅に増加しますが、各クラスターだけでなく、各クラスター内にある名前空間と Kubernetes API にもきめ細かいアクセスが可能になります。
管理アクセス用には、各リージョンに Microsoft Entra グループを作成することを検討してください。 各グループに、そのリージョン内の対応するクラスター スタンプへのフル アクセス許可を付与します。 これにより、各グループのメンバーに、対応するクラスターへの管理アクセス許可が付与されます。
Microsoft Entra ID を使用した AKS クラスター アクセスの管理の詳細については、「AKS の Microsoft Entra 統合」を参照してください。
データ、状態、キャッシュ
グローバルに分散された AKS クラスター一式を使用する場合は、クラスター全体で実行される可能性があるアプリケーションやプロセス、その他のワークロードのアーキテクチャについて考慮してください。 状態ベースのワークロードがクラスター全体に分散されている場合、状態ストアにアクセスする必要がありますか? 障害が原因でクラスター内の別の場所にプロセスが再作成された場合、ワークロードまたはプロセスは、依存する状態ストアまたはキャッシュ ソリューションに引き続きアクセスできますか? 状態はさまざまな方法で格納できますが、単一の Kubernetes クラスターでも管理するのは複雑です。 複数の Kubernetes クラスターを追加すると、複雑さが増します。 リージョンへのアクセスと複雑さの懸念があるため、グローバルに分散された状態ストア サービスを使用するアプリケーションを設計することを検討してください。
このアーキテクチャの設計には、状態に関する構成は考慮されていません。 複数の AKS クラスターで単一のロジカル アプリケーションを実行する場合は、ワークロードを設計して、Azure Cosmos DB などのグローバルに分散された Data Service を使用することを検討します。 Azure Cosmos DB は、グローバルに分散されたデータベース システムです。これにより、データベースのローカル レプリカからのデータの読み取りと書き込みが可能になり、ユーザーの代わりに Cosmos DB サービスが geo レプリケーションを管理できるようになります。 詳細については、Azure Cosmos DB に関するページを参照してください。
ワークロードがキャッシュ ソリューションを使用している場合、キャッシュ サービスを設計して、フェイルオーバーイベント中でも機能し続けるようにします。 そのためには、ワークロード自体がキャッシュ関連のフェールオーバーに対して回復性があること、およびキャッシュ ソリューションがすべてのリージョン AKS インスタンスに存在することを確認します。
コストの最適化
Azure 料金計算ツールを使用して、アーキテクチャで使用するサービスのコストを見積もります。 その他のベスト プラクティスは、「Microsoft Azure Well-Architected Framework」のコストの最適化セクションと、コストの最適化に関する記事の具体的なコスト最適化構成オプションで説明されています。
Kubernetes 固有のコンストラクトによる詳細なクラスター インフラストラクチャ コストの割り当てに対して、 AKS コスト分析 を有効にすることを検討してください。
次のステップ
- AKS 可用性ゾーン
- Azure Kubernetes Fleet Manager
- Azure Container Registry の geo レプリケーション
- Azure のペアになっているリージョン