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

Azure Arc

Azure Kubernetes Service (AKS)

Azure Monitor

Azure Policy

Azure ロールベースのアクセス制御

この参照アーキテクチャでは、Azure Arc が Kubernetes クラスターの管理と構成を、顧客のデータセンター、エッジの場所、および複数のクラウド環境にわたって拡張する方法について説明します。

アーキテクチャ

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

Workflow

次のワークフローは、上記のダイアグラムに対応しています。

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

コンポーネント

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

シナリオの詳細

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

考えられるユースケース

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

オンプレミスの Kubernetes クラスターと AKS でホストされるクラスターのインベントリ、グループ化、タグ付けを管理する。
Azure Monitor を使用して、ハイブリッド環境全体で Kubernetes クラスターを監視する。
Azure Policy を使用して、ハイブリッド環境間で Kubernetes クラスターのポリシーをデプロイおよび適用します。
Azure Policy を使用して GitOps のデプロイと適用に役立つ。
Azure Machine Learning ワークフローのトレーニングとデプロイにより、オンプレミスのグラフィックス処理装置 (GPU) への投資を最大化します。
Prometheus および Managed Grafana 用の Azure Monitor マネージドサービスを使用して、Kubernetes ワークロードを監視および視覚化します。

推奨事項

次の推奨事項は、ほとんどのシナリオに適用できます。これらの推奨事項には、オーバーライドする特定の要件がない限り、従ってください。

クラスター登録

アクティブな CNCF Kubernetes クラスターはどれも登録できます。 Azure Arc 対応 Kubernetes エージェントをデプロイするには、クラスターにアクセスするための kubeconfig ファイルとクラスターのクラスター管理者ロールが必要です。 Azure CLI を使用してクラスター登録タスクを実行します。 az loginコマンドとaz connectedk8s connect コマンドに使用するユーザーまたはサービスプリンシパルには、Microsoft.Kubernetes/connectedClusters リソースの種類に対する読み取りと書き込みのアクセス許可が必要です。 Kubernetes クラスター - Azure Arc のオンボードロールにはこれらのアクセス許可があり、ユーザープリンシパルまたはサービスプリンシパルに対するロールの割り当てに使用できます。 connectedk8s拡張機能を使用するクラスターをオンボードするには、Helm 3 が必要です。 Azure Arc 対応 Kubernetes CLI 拡張機能をインストールするには、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は、他の Azure Arc エージェントからメトリックを収集して、これらのエージェントが最適に実行されるようにします。
deployment.apps/cluster-metadata-operatorは、クラスターのバージョン、ノード数、Azure Arc エージェントのバージョンなど、クラスターメタデータを収集します。
deployment.apps/resource-sync-agentは、前述のクラスターメタデータを Azure に同期します。
deployment.apps/clusteridentityoperatorは、他のエージェントが Azure と通信するために使用するマネージドサービス ID 証明書を保持します。
deployment.apps/flux-logs-agentは、ソース管理構成の一部としてデプロイされた flux オペレーターからログを収集します。
deployment.apps/extension-managerは、拡張機能 Helm チャートのライフサイクルをインストールして管理します。
deployment.apps/kube-aad-proxyは、AKS クラスター接続機能を介してクラスターに送信された要求の認証を処理します。
deployment.apps/clusterconnect-agentは、クラスター接続機能がクラスターの API サーバーへのアクセスを提供できるようにするリバースプロキシエージェントです。これは、クラスターでクラスター接続機能が有効な場合にのみデプロイされるオプションコンポーネントです。
deployment.apps/guardは、Microsoft Entra ロールベースのアクセス制御 (RBAC) に使用される認証および承認 Webhook サーバーです。これは、クラスターで Azure RBAC が有効になっている場合にのみデプロイされるオプションのコンポーネントです。
deployment.apps/extension-events-collectorは、拡張機能のライフサイクル管理に関連するログを収集します。これらのログは、作成、アップグレード、削除などの各操作に対応するイベントに集計されます。
deployment.apps/logcollectorはプラットフォームのテレメトリを収集して、プラットフォームの運用上の正常性を確保します。

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

Azure Monitor コンテナー分析情報を使用してクラスターを監視する

コンテナーの監視は非常に重要です。 Azure Monitor コンテナーの分析情報は、AKS および AKS エンジンクラスターの堅牢な監視機能を提供します。 Azure の外部でホストされている Azure Arc 対応 Kubernetes クラスターを監視するように Azure Monitor コンテナー分析情報を構成することもできます。この構成では、Azure、オンプレミス、および Microsoft 以外のクラウド環境で Kubernetes クラスターを包括的に監視できます。

Azure Monitor コンテナーの分析情報は、コントローラー、ノード、コンテナーからメモリとプロセッサのメトリックを収集することで、パフォーマンスを可視化します。これらのメトリックは、Metrics API を介して Kubernetes で使用できます。コンテナーのログも収集されます。 Kubernetes クラスターからの監視を有効にすると、コンテナー化されたバージョンの Log Analytics エージェントによってメトリックとログが自動的に収集されます。メトリックはメトリックストアに書き込まれ、ログデータは Log Analytics ワークスペースに関連付けられたログストアに書き込まれます。詳細については、 Kubernetes 監視用の Azure Monitor 機能に関するページを参照してください。

PowerShell スクリプトまたは Bash スクリプトを使用して、Kubernetes の 1 つ以上のデプロイに対して Azure Monitor コンテナー分析情報を有効にすることができます。

詳細については、「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 のパラメーターも設定します。割り当てが作成されると、Azure Policy エンジンはスコープ内のすべての connectedCluster または managedCluster リソースを識別し、各リソースに fluxConfiguration を適用します。

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

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

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

GitOps は、デプロイや名前空間などの Kubernetes 構成の目的の状態をソースリポジトリで定義する方法です。このリポジトリには、Git または Helm リポジトリ、バケット、または Azure Blob Storage を指定できます。このプロセスの後に、オペレーターを使用して、これらの構成をクラスターにポーリングしてプルベースでデプロイします。

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

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

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

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

詳細については、「 Flux v2 で GitOps を使用してアプリケーションをデプロイする」を参照してください。

Machine Learning を実行する

Machine Learning では、機械学習プロセスのコンピューティングターゲットとして AKS (または Azure Arc 対応 Kubernetes) クラスターを選択できます。この機能を使用すると、独自のセルフホステッド (またはマルチクラウド) インフラストラクチャで機械学習モデルをトレーニングまたはデプロイできます。このアプローチを使用すると、GPU に対するオンプレミスの投資と、Machine Learning がクラウドで提供する管理の容易さを組み合わせることができます。

マネージド Prometheus と Grafana を使用して Kubernetes ワークロードを監視する

Azure Monitor には、Prometheus と Grafana の両方のデプロイ用のマネージドサービスが用意されているため、これらの一般的な Kubernetes 監視ツールを利用できます。このマネージドサービスを使用すると、デプロイを自分で管理および更新する必要なく、これらのツールを使用できます。 Prometheus のメトリックを分析するには、 PromQL でメトリックスエクスプローラーを使用します。

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

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

エンドポイント (DNS)	説明
`https://management.azure.com:443`	エージェントが Azure に接続し、クラスターを登録するために必要です。
`https://[region].dp.kubernetesconfiguration.azure.com:443`	エージェントが状態をプッシュし、構成情報をフェッチするためのデータプレーンエンドポイント。[region] は、AKS インスタンスをホストする Azure リージョンを表します。
`https://docker.io:443`	コンテナーイメージをプルするために必要です。
$	GitOps リポジトリの例は、GitHub でホストされています。構成エージェントには、指定した Git エンドポイントへの接続が必要です。
`https://login.microsoftonline.com:443`、`https://<region>.login.microsoft.com`、`login.windows.net`	Azure Resource Manager トークンをフェッチし、更新するために必要です。
`https://mcr.microsoft.com:443` `https://*.data.mcr.microsoft.com:443`	Azure Arc エージェント用のコンテナーイメージをプルするために必要です。

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

考慮事項

これらの考慮事項では、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

[信頼性]

信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。詳細については、「信頼性設計レビューチェックリスト」を参照してください。

ほとんどのシナリオでは、インストールスクリプトの作成時に選択する場所は、オンプレミスのリソースに地理的に最も近い Azure リージョンである必要があります。残りのデータは、指定したリージョンを含む Azure geography 内に格納されます。データ所在地の要件がある場合、この詳細はリージョンの選択に影響する可能性があります。マシンが接続されている Azure リージョンが障害の影響を受ける場合、その障害は接続されているマシンには影響しませんが、Azure を使用した管理操作を完了できない可能性があります。地理的に冗長なサービスを提供する複数の場所がある場合は、各場所のマシンを別の Azure リージョンに接続します。この方法では、リージョンの停止が発生した場合の回復性が向上します。詳細については、「 Azure Arc 対応 Kubernetes でサポートされているリージョン」を参照してください。
ソリューション内のサービスが、Azure Arc がデプロイされているリージョンでサポートされていることを確認する必要があります。

セキュリティ

セキュリティは、意図的な攻撃や貴重なデータとシステムの誤用に対する保証を提供します。詳細については、「セキュリティ設計レビューチェックリスト」を参照してください。

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

コストの最適化

コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。詳細については、「コストの最適化設計レビューチェックリスト」を参照してください。

コストに関する一般的な考慮事項については、「コスト最適化の設計原則」を参照してください。

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

オペレーショナルエクセレンスは、アプリケーションをデプロイし、運用環境で実行し続ける運用プロセスを対象としています。詳細については、「オペレーショナルエクセレンス設計レビューチェックリスト」を参照してください。

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

共同作成者

Microsoft では、この記事を保持しています。次の共同作成者がこの記事を書きました。

プリンシパル作成者:

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

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ

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