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