Kubernetes クラスター向けの Azure Arc ハイブリッド管理とデプロイ

このリファレンス アーキテクチャは、Azure Arc によって、顧客データ センター、エッジの場所、複数のクラウド環境にわたって Kubernetes クラスターの管理と構成を拡張する方法を示しています。

アーキテクチャ

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

ワークフロー

アーキテクチャ*は、次のアスペクト*で構成されています:

• Azure Arc 対応 Kubernetes。 Azure Arc 対応 Kubernetes を使用して、Azure の内部または外部で Kubernetes クラスターを接続し、構成します。 Kubernetes クラスターを Azure Arc に接続すると、Azure Resource Manager ID とマネージド ID が割り当てられます。
• Azure Kubernetes Service 。 Azure で Kubernetes クラスターをホスティングして、Kubernetes クラスターの管理の複雑さと運用のオーバーヘッドを削減します。
• オンプレミスの Kubernetes クラスター 。 オンプレミスまたはサードパーティのクラウド環境でホスティングされている Cloud Native Computing Foundation (CNCF) 認定 Kubernetes クラスターを接続します。
• Azure Policy 。 Arc 対応 Kubernetes クラスターのポリシーをデプロイし、管理します。
• Azure Monitor。 Arc 対応 Kubernetes クラスターを観察および監視します。

Components

• Azure Arc は Azure プラットフォームを拡張するブリッジであり、データセンター、エッジ、マルチクラウド環境で実行できるアプリケーションとサービスを構築できるようにします。
• Azure Kubernetes Service (AKS) は、Kubernetes クラスターをデプロイおよびスケーリングするためのマネージド サービスです。
• Azure Policy を使用すると、一貫したリソース ガバナンスによって、大規模なリアルタイム クラウド コンプライアンスを実現できます。
• Azure Monitor を使用すると、アプリケーション、インフラストラクチャ、ネットワークのエンド ツー エンド監視を実現できます。

シナリオの詳細

Azure Arc を使用すると、Microsoft Azure の外部でホスティングされている Kubernetes クラスターを登録できます。 それにより、Azure ツールを使用して、Azure Kubernetes Service (AKS) でホスティングされているクラスターと共にこれらのクラスターを管理できます。

考えられるユース ケース

このアーキテクチャの一般的な用途は次のとおりです。

• オンプレミスの Kubernetes クラスターおよびインベントリ、グループ化、タグ付けのために AKS でホスティングされているクラスターを管理する。
• Azure Monitor を使用して、ハイブリッド環境全体で Kubernetes クラスターを監視する。
• Azure Policy を使用して、ハイブリッド環境全体に Kubernetes クラスターのポリシーをデプロイし、適用する。
• Azure Policy を使用して GitOps をデプロイし、適用する。

Recommendations

以下のセクションでは、ほとんどのシナリオに適用される推奨事項を示します。 Microsoft では、優先すべき要件がない限り、これらに従うことをお勧めします。

クラスター登録

アクティブな CNCF Kubernetes クラスターはどれも登録できます。 クラスターにアクセスするための kubeconfig ファイル と、Arc 対応 Kubernetes エージェントをデプロイするためのクラスターでのクラスター管理者ロールが必要です。 Azure コマンドライン インターフェイス (Azure CLI) を使用して、クラスター登録タスクを実行します。 az login および az connectedk8s connect コマンドで使用するユーザーまたはサービス プリンシパルには、Microsoft.Kubernetes/connectedClusters のリソースの種類に対する読み取りおよび書き込みアクセス許可が必要です。 Kubernetes クラスター - Azure Arc のオンボード ロールにはこれらのアクセス許可があり、ユーザー プリンシパルまたはサービス プリンシパルに対するロールの割り当てに使用できます。 connectedk8s 拡張機能を使用するクラスターのオンボードには、Helm 3 が必要です。 Azure Arc 対応の Kubernetes コマンド ライン インターフェイス拡張機能をインストールするには、Azure CLI バージョン 2.3 以降が必要です。

Kubernetes 用 Azure Arc エージェント

Azure Arc 対応 Kubernetes は、azure-arc 名前空間にデプロイされたクラスターで実行されるいくつかのエージェント ("オペレーター" とも呼ばれます) で構成されています。

• deployment.apps/config-agent: クラスターで適用されるソース管理構成リソース用の接続されたクラスターを監視し、コンプライアンスの状態を更新します。
• deployment.apps/controller-manager: Azure Arc コンポーネント間の相互作用を調整する、オペレーターのオペレーターです。
• deployment.apps/metrics-agent: 他の Arc エージェントからメトリックを収集して、これらのエージェントのパフォーマンスが最適であることを確認します。
• deployment.apps/cluster-metadata-operator: クラスター メタデータ、クラスターのバージョン、ノード数、Azure Arc エージェントのバージョンを収集します。
• deployment.apps/resource-sync-agent: 前述のクラスター メタデータを Azure に同期します。
• deployment.apps/clusteridentityoperator: 他のエージェントが Azure との通信に使用するマネージド サービス ID (MSI) 証明書を保持します。
• deployment.apps/flux-logs-agent: ソース管理構成の一部としてデプロイされる Flux オペレーターからログを収集します。
• deployment.apps/extension-manager. 拡張 Helm チャートをインストールし、そのライフサイクルを管理します。
• deployment.apps/kube-azure-ad-proxy. クラスター接続を使用してクラスターに送信される要求の認証に使用されます。
• deployment.apps/clusterconnect-agent. クラスターの apiserver へのアクセスを提供するクラスター接続機能を有効にするリバース プロキシ エージェント。 これは、クラスターでクラスター接続機能が有効な場合にのみデプロイされるオプション コンポーネントです。
• deployment.apps/guard. Microsoft Entra ロールベースのアクセス制御 (RBAC) に使用される認証および認可の Webhook サーバー。 これは、クラスターで azure-rbac 機能が有効な場合にのみデプロイされるオプション コンポーネントです。

詳細については、「Azure Arc 対応の Kubernetes クラスターを接続する」を参照してください。

Azure Monitor Container Insights を使用してクラスターを監視する

コンテナーの監視は非常に重要です。 Azure Monitor Container Insights は、AKS および AKS エンジン クラスターに対する充実した監視エクスペリエンスを提供します。 Azure の外部でホストされている Azure Arc 対応 Kubernetes クラスターを監視するように Azure Monitor Container Insights を構成することもできます。 これを行うことで、Azure、オンプレミス、サードパーティのクラウド環境にわたって、Kubernetes クラスターを包括的に監視できます。

Azure Monitor Container Insights では、Metrics アプリケーション プログラミング インターフェイス (API) を使用して、Kubernetes で使用可能なコントローラー、ノード、コンテナー、メトリックからメモリ メトリックやプロセッサ メトリックを収集することでパフォーマンスを可視化できます。 コンテナーのログも収集されます。 Kubernetes クラスターから監視を有効にすると、コンテナー化されたバージョンの Log Analytics エージェントを使用してメトリックとログが自動的に収集されます。 メトリックはメトリック ストアに書き込まれ、ログ データは Log Analytics ワークスペースに関連付けられたログ ストアに書き込まれます。 Azure Monitor Container Insights の詳細については、Azure Monitor Container Insights の概要に関するページをご覧ください。

PowerShell スクリプトまたは Bash スクリプトを使用して、Kubernetes の 1 つ以上のデプロイに対して Azure Monitor Container Insights を有効にすることができます。

Arc 対応 Kubernetes クラスターの監視を有効にするには、「Azure Arc 対応 Kubernetes クラスターの監視を有効にする」をご覧ください

Azure Policy を使用して GitOps ベースのアプリケーションのデプロイを有効にする

Azure Policy を使用して、GitOps 対応 Microsoft.Kubernetes/connectedclusters リソースまたは Microsoft.ContainerService/managedClusters リソースごとに特定の Microsoft.KubernetesConfiguration/fluxConfigurations が適用されるようにします。 たとえば、1 つ以上のクラスターにベースライン構成を適用したり、特定のアプリケーションを複数のクラスターにデプロイしたりできます。 Azure Policy を使用するには、[Azure Arc 対応 Kubernetes の Azure Policy 組み込み定義] で定義を選択し、ポリシー割り当てを作成します。

ポリシー割り当てを作成するときに、スコープを Azure リソース グループまたはサブスクリプションに設定します。 また、作成される fluxConfiguration のパラメーターも設定します。 割り当てが作成されると、Policy エンジンによって、スコープ内にあるすべての connectedCluster または managedCluster リソースが特定され、それぞれに fluxConfiguration が適用されます。

クラスターごとに複数のソース リポジトリを使用する場合 (たとえば、中央の IT またはクラスター オペレーター用に 1 つのリポジトリを使用し、アプリケーション チーム用に他のリポジトリを使用する場合)、これを有効にするには、複数のポリシー割り当てを使用し、異なるソース リポジトリを使用するように各ポリシー割り当てを構成します。

詳細については、「Flux v2 構成と Azure Policy を使用して、アプリケーションを一貫して大規模にデプロイする」を参照してください。

GitOps を使用してアプリケーションをデプロイする

GitOps は、ソース リポジトリ (Git または Helm リポジトリ、バケット、Azure Blob Storage など) の Kubernetes 構成 (デプロイ、名前空間など) の望ましい状態を宣言する方法です。 その後で、オペレーターを使用してこれらの構成をポーリングし、クラスターへのプルベースのデプロイを実行します。

クラスターと 1 つ以上のソース リポジトリ間の接続は、microsoft.flux 拡張機能をクラスターにデプロイすると有効になります。 fluxConfiguration リソースのプロパティは、Kubernetes リソースがソース リポジトリからクラスターへとフローする場所と方法を表します。 fluxConfiguration データは、保存時に暗号化されて Azure Cosmos DB データベースに保存されるので、データの機密性が確保されます。

クラスターで実行される flux-config エージェントは、Azure Arc 対応 Kubernetes リソースの新規または更新された fluxConfiguration 拡張機能リソースの監視、ソース リポジトリからのアプリケーションのデプロイ、fluxConfiguration に加えられた更新プログラムの伝達を担います。 同じ Azure Arc 対応 Kubernetes クラスター上で namespace スコープを使用して複数の fluxConfiguration リソースを作成し、マルチテナントを実現することもできます。

ソース リポジトリには、Namespace、ConfigMap、Deployment、DaemonSet などの有効な Kubernetes リソースを含めることができます。 また、アプリケーションをデプロイするための Helm グラフを含めることもできます。 ソース リポジトリの一般的なシナリオとして、組織のベースライン構成の定義があります。これには、一般的なロールベースのアクセス制御 (RBAC) ロールとバインド、監視エージェント、ログ エージェント、クラスター全体のサービスが含まれる場合があります。

異種環境にデプロイされる、クラスターの大規模なコレクションを管理することもできます。 たとえば、組織のベースライン構成を定義するリポジトリを 1 つ用意し、それを複数の Kubernetes クラスターに同時に適用できます。 複数のソース リポジトリからクラスターにアプリケーションをデプロイすることもできます。

詳細については、GitOps with Flux v2 を使ってアプリケーションをデプロイする方法に関するページを参照してください。

トポロジ、ネットワーク、ルーティング

Azure Arc エージェントが機能するには、次のプロトコル、ポート、送信 URL が必要です。

Azure Arc サービス全体の URL の完全なリストについては、「Azure Arc ネットワークの要件」を参照してください。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

[信頼性]

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

• ほとんどの場合、インストール スクリプトを作成するときに選択する場所は、オンプレミスのリソースに地理的に最も近い Azure リージョンにする必要があります。 残りのデータは、指定したリージョンを含む Azure 地域内に保存されます。データ所在地の要件がある場合、この事実はリージョンの選択にも影響する可能性があります。 マシンが接続されている Azure リージョンが障害の影響を受ける場合、その障害は接続されているマシンには影響しませんが、Azure を使用した管理操作を完了できない可能性があります。 リージョンの障害が発生した場合の回復性を確保するために、地理的に冗長なサービスを提供する複数の場所がある場合は、各場所のマシンを別の Azure リージョンに接続することをお勧めします。 利用可能なリージョンについては、Azure Arc 対応 Kubernetes の「サポートされているリージョン」をご覧ください。
• 「アーキテクチャ」セクションで参照されているサービスが、Azure Arc のデプロイ先のリージョンでサポートされていることを確認する必要があります。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。

• Azure RBAC を使用して、Microsoft Entra ID を使用する Azure 環境とオンプレミス環境にわたって Azure Arc 対応 Kubernetes へのアクセスを管理できます。 詳細については、「Kubernetes 認可に Azure RBAC を使用する」を参照してください。
• Microsoft では、Kubernetes クラスターを Azure Arc にオンボードするための限定された権限を持つサービス プリンシパルを使用することをお勧めします。この方法は、Azure Pipelines や GitHub Actions などの CI/CD パイプラインで役立ちます。 詳細については、「Azure Arc 対応オンボード サービス プリンシパルの作成」を参照してください。
• サービス プリンシパルの管理を簡素化するために、AKS でマネージド ID を使用できます。 ただし、クラスターはマネージド ID を使用して作成する必要があり、既存のクラスター (Azure クラスターとオンプレミス クラスターを含む) はマネージド ID に移行できません。 詳細については、「Azure Kubernetes Service でマネージド ID を使用する」を参照してください。

コスト最適化

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

コストに関する一般的な考慮事項については、Microsoft Azure Well-Architected Framework の「コスト最適化の原則」をご覧ください。

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

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

• Azure Arc 対応 Kubernetes クラスターを構成する前に、Azure Resource Manager のサブスクリプションの制限とリソース グループの制限を確認して、クラスターの数を計画してください。
• オープンソースのパッケージ化ツールである Helm を使用して、Kubernetes アプリケーションをインストールし、そのライフ サイクルを管理します。 APT や Yum などの Linux パッケージ マネージャーと同様に、Helm を使用して、構成済みの Kubernetes リソースのパッケージである Kubernetes "チャート" を管理します。

共同作成者

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

プリンシパル作成者:

• Pieter de Bruin | シニア プログラム マネージャー

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

次のステップ

• Azure Arc のドキュメント
• Azure Arc 対応 Kubernetes のドキュメント
• Azure Kubernetes Service のドキュメント
• Azure Policy のドキュメント
• Azure Monitor のドキュメント
• Azure Arc 対応 Kubernetes クラスターを接続する

関連リソース

関連するハイブリッド ガイダンス:

• ハイブリッド アーキテクチャの設計
• Azure ハイブリッド オプション
• ハイブリッド アプリの設計上の考慮事項

関連アーキテクチャ

• AKS on Azure Stack HCI のベースライン アーキテクチャ
• AKS on Azure Stack HCI のネットワーク アーキテクチャ
• Azure Arc を使用して、オンプレミス環境とマルチクラウド環境での SQL Server インスタンスの管理を最適化する
• Azure Monitor を使用した企業の監視