次の方法で共有

Kubernetes クラスターの監視を有効にする

  • [アーティクル]

この記事では、Azure Monitor の次の機能を使って Kubernetes クラスターの完全な監視を有効にする方法について説明します。

Azure portal を使うと、すべての機能を同時に有効にできます。 Azure CLI、Azure Resource Manager テンプレート、Terraform、または Azure Policy を使って、それらを個別に有効にすることもできます。 この記事では、これらの各方法について説明します。

重要

Kubernetes クラスターでは大量のログ データが生成されるため、収集するログを選択しないと、大幅なコストが発生する可能性があります。 クラスターの監視を有効にする前に、次の記事を参照して、環境がコストに合わせて最適化されていること、およびログ収集を必要なデータのみに制限していることを確認してください。

サポートされているクラスター

この記事では、次の種類のクラスターに関するオンボードのガイダンスを提供します。 各種類のプロセスの違いについては、関連するセクションで説明します。

前提条件

アクセス許可

  • オンボードのためには、クラスターに対する少なくとも共同作成者アクセス権が必要です。
  • 監視が有効になった後でデータを表示するには、監視閲覧者または監視共同作成者が必要です。

Managed Prometheus の前提条件

  • クラスターではマネージド ID 認証を使用する必要があります。
  • AKS クラスターと Azure Monitor ワークスペースのサブスクリプションには、次のリソース プロバイダーが登録されている必要があります。
    • Microsoft.ContainerService
    • Microsoft.Insights
    • Microsoft.AlertsManagement
    • Microsoft.Monitor
  • Grafana ワークスペース サブスクリプションのサブスクリプションには、次のリソース プロバイダーが登録されている必要があります。
    • Microsoft.Dashboard

Arc 対応 Kubernetes クラスターの前提条件

Note

Managed Prometheus Arc 対応 Kubernetes 拡張機能 (プレビュー) では、次の構成はサポートされていません。

  • Azure Red Hat OpenShift (ARO) を含む Red Hat Openshift のディストリビューション
  • Windows ノード

ワークスペース

次の表では、Managed Prometheus とコンテナーの分析情報をサポートするために必要なワークスペースについて説明します。 オンボード プロセスの一部として各ワークスペースを作成しても、既存のワークスペースを使ってもかまいません。 作成するワークスペースの数と配置場所については、「Log Analytics ワークスペース アーキテクチャを設計する」をご覧ください。

機能 ワークスペース メモ
マネージド Prometheus Azure Monitor ワークスペース アドオンが Azure Monitor ワークスペースにデータを送信できるようにするには、Contributor のアクセス許可があれば十分です。 Azure Managed Grafana でメトリックを表示するために Azure Monitor ワークスペースをリンクするには、Owner レベルのアクセス許可が必要になります。 これが必要である理由は、オンボード ステップを実行するユーザーが、メトリックのクエリを実行するために Azure Monitor ワークスペースで Azure Managed Grafana システム ID Monitoring Reader ロールを付与できる必要があるためです。
Container insights Log Analytics ワークスペース AKS クラスターを、同じ Microsoft Entra テナント内の別の Azure サブスクリプションの Log Analytics ワークスペースに接続できますが、Azure CLI または Azure Resource Manager テンプレートを使用する必要があります。 現在、Azure portal ではこの構成を実行できません。

既存の AKS クラスターを別のサブスクリプションの Log Analytics ワークスペースに接続している場合は、Microsoft.ContainerService リソース プロバイダーを、Log Analytics ワークスペースと共にサブスクリプションに登録する必要があります。 詳細については、「リソース プロバイダーを登録する」 を参照してください。

既定のワークスペースに使用する、サポートされているマッピング ペアの一覧については、コンテナー分析情報でサポートされているリージョンのマッピングに関するページを参照してください。
マネージド Grafana Azure Managed Grafana ワークスペース Grafana ワークスペースを Azure Monitor ワークスペースにリンクして、クラスターから収集された Prometheus メトリックを Grafana ダッシュボードで使用できるようにします。

Prometheus と Grafana を有効にする

次のいずれかの方法を使って、クラスターからの Prometheus メトリックのスクレイピングを有効にし、Managed Grafana でメトリックを視覚化できるようにします。 Azure Monitor ワークスペースと Azure Managed Grafana ワークスペースを接続するためのオプションについては、Grafana ワークスペースのリンクに関する記事をご覧ください。

Note

プライベートにリンクされた単一の Azure Monitor リソースがある場合、AKS クラスターと Azure Monitor ワークスペースが異なるリージョンにある場合、Prometheus の有効化は機能しません。 Prometheus アドオンに必要な構成は、プライベート リンク制約のため、リージョン間では使用できません。 これを解決するには、AKS クラスターの場所に新しい DCE を作成し、同じ AKS クラスター リージョンに新しい DCRA (関連付け) を作成します。 新しい DCE を AKS クラスターに関連付け、新しい関連付け (DCRA) に configurationAccessEndpoint という名前を付けます。 データ インジェストに Private Link を使用するように Azure Monitor ワークスペースに関連付けられている DCE を構成する方法の詳細については、Azure Monitor での Kubernetes の監視用プライベート リンクの有効化に関するページを参照してください。

CLI を使用して有効にする

次のコマンドで既存の Azure Monitor ワークスペースを指定しないと、リソース グループの既定のワークスペースが使われます。 クラスターのリージョンに既定のワークスペースがまだ存在しない場合は、DefaultAzureMonitorWorkspace-<mapped_region> という形式の名前を持つワークスペースが、DefaultRG-<cluster_region> という名前のリソース グループに作成されます。

前提条件

  • Az CLI バージョン 2.49.0 以降が必要です。
  • az extension remove --name aks-preview コマンドを使って、aks-preview 拡張機能を AKS クラスターからアンインストールする必要があります。
  • az extension add --name k8s-extension コマンドを使って、k8s-extension 拡張機能をインストールする必要があります。
  • k8s-extension バージョン 1.4.1 以降が必要です。

AKS クラスター

az aks create または az aks update (新規クラスターの作成か、既存クラスターの更新かに応じて) で -enable-azure-monitor-metrics オプションを使って、Prometheus メトリックをスクレイピングするメトリック アドオンをインストールします。

サンプル コマンド

### Use default Azure Monitor workspace
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group>

### Use existing Azure Monitor workspace
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group> --azure-monitor-workspace-resource-id <workspace-name-resource-id>

### Use an existing Azure Monitor workspace and link with an existing Grafana workspace
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group> --azure-monitor-workspace-resource-id <azure-monitor-workspace-name-resource-id> --grafana-resource-id  <grafana-workspace-name-resource-id>

### Use optional parameters
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group> --ksm-metric-labels-allow-list "namespaces=[k8s-label-1,k8s-label-n]" --ksm-metric-annotations-allow-list "pods=[k8s-annotation-1,k8s-annotation-n]"

Arc 対応クラスター (プレビュー)

### Use default Azure Monitor workspace
az k8s-extension create --name azuremonitor-metrics --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers.Metrics

## Use existing Azure Monitor workspace
az k8s-extension create --name azuremonitor-metrics --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers.Metrics --configuration-settings azure-monitor-workspace-resource-id=<workspace-name-resource-id>

### Use an existing Azure Monitor workspace and link with an existing Grafana workspace
az k8s-extension create --name azuremonitor-metrics --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers.Metrics --configuration-settings azure-monitor-workspace-resource-id=<workspace-name-resource-id> grafana-resource-id=<grafana-workspace-name-resource-id>

### Use optional parameters
az k8s-extension create --name azuremonitor-metrics --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers.Metrics --configuration-settings azure-monitor-workspace-resource-id=<workspace-name-resource-id> grafana-resource-id=<grafana-workspace-name-resource-id> AzureMonitorMetrics.KubeStateMetrics.MetricAnnotationsAllowList="pods=[k8s-annotation-1,k8s-annotation-n]" AzureMonitorMetrics.KubeStateMetrics.MetricLabelsAllowlist "namespaces=[k8s-label-1,k8s-label-n]"

どのコマンドでも、次の省略可能なパラメーターを使用できます。

  • AKS: --ksm-metric-annotations-allow-list
    Arc: --AzureMonitorMetrics.KubeStateMetrics.MetricAnnotationsAllowList
    リソースの kube_resource_annotations メトリックで使用される Kubernetes 注釈キーのコンマ区切りリスト。 たとえば、kube_pod_annotations はポッド リソースの注釈メトリックです。 既定では、このメトリックには名前と名前空間のラベルのみが含まれます。 注釈をさらに含めるには、複数形のリソース名と、それらを許可する Kubernetes 注釈キーの一覧を指定します。 リソースごとに 1 つの * を指定して任意の注釈を許可できますが、これはパフォーマンスに重大な影響を及ぼします。 たとえば、pods=[kubernetes.io/team,...],namespaces=[kubernetes.io/team],... のようにします。
  • AKS: --ksm-metric-labels-allow-list
    Arc: --AzureMonitorMetrics.KubeStateMetrics.MetricLabelsAllowlist
    リソースの kube_resource_labels メトリック kube_resource_labels メトリックで使用されるその他の Kubernetes ラベル キーのコンマ区切りリスト。 たとえば、kube_pod_labels はポッド リソースのラベル メトリックです。 既定では、このメトリックには名前と名前空間のラベルのみが含まれます。 さらに多くのラベルを含めるには、複数形のリソース名のリストと、それらに対して許可する Kubernetes ラベル キーを指定します。リソースごとに 1 つの * を指定して任意のラベルを許可できますが、これはパフォーマンスに重大な影響を及ぼします。 たとえば、pods=[app],namespaces=[k8s-label-1,k8s-label-n,...],... のようにします。
  • AKS: --enable-windows-recording-rules Windows ダッシュボードの適切な機能に必要な記録ルール グループを有効にできます。

コンテナー分析情報を有効にする

次のいずれかの方法を使って、クラスターでコンテナーの分析情報を有効にします。 これが完了したら、コンテナーの分析情報のためのエージェント データ収集の構成に関する記事を参照して、必要以上のデータが収集されないように構成を確実にカスタマイズします。

AKS クラスターと Arc 対応クラスターの監視を有効にするには、次のいずれかのコマンドを使います。 既存の Log Analytics ワークスペースを指定しないと、リソース グループの既定のワークスペースが使われます。 クラスターのリージョンに既定のワークスペースがまだ存在していない場合は、DefaultWorkspace-<GUID>-<Region> という形式の名前で作成されます。

前提条件

  • Azure CLI バージョン 2.43.0 以降
  • CLI バージョン 2.49.0 以降では、マネージド ID 認証が既定です。
  • Azure k8s-extension バージョン 1.3.7 以降
  • マネージド ID 認証は、k8s-extension バージョン 1.43.0 以降の既定値です。
  • マネージド ID 認証は、ARO (Azure Red Hat Openshift) または Windows ノードを使する Arc 対応 Kubernetes クラスターではサポートされていません。 レガシ認証を使ってください。
  • CLI バージョン 2.54.0 以降の場合、ログ スキーマは ConfigMap を使って ContainerLogV2 に構成されます。

Note

クラスターに対して ContainerLogV2 スキーマを有効にするには、クラスターのデータ収集規則 (DCR) または ConfigMap を使用してください。 両方の設定が有効になっている場合、ConfigMap が優先されます。 Stdout ログと stderr ログは、DCR と ConfigMap の両方が明示的に off に設定されている場合にのみ ContainerLog テーブルに取り込まれます。

AKS クラスター

### Use default Log Analytics workspace
az aks enable-addons --addon monitoring --name <cluster-name> --resource-group <cluster-resource-group-name>

### Use existing Log Analytics workspace
az aks enable-addons --addon monitoring --name <cluster-name> --resource-group <cluster-resource-group-name> --workspace-resource-id <workspace-resource-id>

### Use legacy authentication
az aks enable-addons --addon monitoring --name <cluster-name> --resource-group <cluster-resource-group-name> --workspace-resource-id <workspace-resource-id> --enable-msi-auth-for-monitoring false

例

az aks enable-addons --addon monitoring --name "my-cluster" --resource-group "my-resource-group" --workspace-resource-id "/subscriptions/my-subscription/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace"

Arc 対応クラスター

### Use default Log Analytics workspace
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers

### Use existing Log Analytics workspace
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings logAnalyticsWorkspaceResourceID=<workspace-resource-id>

### Use managed identity authentication (default as k8s-extension version 1.43.0)
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.useAADAuth=true

### Use advanced configuration settings
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings  amalogs.resources.daemonset.limits.cpu=150m amalogs.resources.daemonset.limits.memory=600Mi amalogs.resources.deployment.limits.cpu=1 amalogs.resources.deployment.limits.memory=750Mi

### With custom mount path for container stdout & stderr logs
### Custom mount path not required for Azure Stack Edge version > 2318. Custom mount path must be /home/data/docker for Azure Stack Edge cluster with version <= 2318
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.logsettings.custommountpath=<customMountPath>

使用できる構成設定については、Helm チャートのリソース要求と制限のセクションをご覧ください。

例

az k8s-extension create --name azuremonitor-containers --cluster-name "my-cluster" --resource-group "my-resource-group" --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings logAnalyticsWorkspaceResourceID="/subscriptions/my-subscription/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace"

転送プロキシを使用する Arc 対応クラスター

クラスターが転送プロキシで構成されている場合、プロキシ設定が拡張機能に自動的に適用されます。 AMPLS + プロキシを使用するクラスターの場合、プロキシ構成は無視する必要があります。 構成設定 amalogs.ignoreExtensionProxySettings=trueを使用して拡張機能をオンボードします。

az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.ignoreExtensionProxySettings=true

ARO、OpenShift または Windows ノードを使用する Arc 対応クラスター

マネージド ID 認証は、ARO (Azure Red Hat OpenShift)、OpenShift または Windows ノードを使用する Arc 対応 Kubernetes クラスターではサポートされていません。 次の例に示すように、amalogs.useAADAuth=false を指定してレガシ認証を使います。

az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.useAADAuth=false

拡張機能のインスタンスを削除する

次のコマンドでは、拡張機能インスタンスのみが削除され、Log Analytics ワークスペースは削除されません。 Log Analytics リソース内のデータはそのまま残ります。

az k8s-extension delete --name azuremonitor-containers --cluster-type connectedClusters --cluster-name <cluster-name> --resource-group <resource-group>

Azure portal で完全な監視を有効にする

新しい AKS クラスター (Prometheus、Container insights、Grafana)

Azure portal で新しい AKS クラスターを作成するときに、[監視] タブで Prometheus、Container insights、Grafana を有効にできます。[コンテナー ログを有効にする]、[Prometheus メトリックを有効にする]、[Grafana を有効にする] チェック ボックスをオンにします。

新しい AKS クラスターの [監視] タブのスクリーンショット。

既存のクラスター (Prometheus、Container insights、Grafana)

  1. Azure portal でお使いの AKS クラスターに移動します。
  2. サービス メニューの [監視] で、[分析情報]>[監視の構成] を選びます。
  3. Container insights は既に有効です。 [Prometheus メトリックを有効にする] と [Grafana を有効にする] のチェック ボックスをオンにします。 既存の Azure Monitor ワークスペースと Grafana ワークスペースがある場合は、それらが選ばれます。
  4. 別のワークスペースを選ぶか、新しいものを作成する場合は、[詳細設定] を選びます。 [コストの事前設定] 設定を使用すると、既定のコレクションの詳細を変更して、監視コストを削減できます。 詳細については、「Container Insights でコストの最適化設定を有効にする」を参照してください。
  5. [構成] をクリックします。

既存のクラスター (Prometheus のみ)

  1. Azure portal でお使いの AKS クラスターに移動します。
  2. サービス メニューの [監視] で、[分析情報]>[監視の構成] を選びます。
  3. [Prometheus メトリックを有効にする] チェック ボックスをオンにします。
  4. 別のワークスペースを選ぶか、新しいものを作成する場合は、[詳細設定] を選びます。 [コストの事前設定] 設定を使用すると、既定のコレクションの詳細を変更して、監視コストを削減できます。
  5. [構成] をクリックします。

Windows メトリック収集を有効にする (プレビュー)

Note

windows-exporter-daemonset.yaml には CPU/メモリの制限がないため、Windows ノードを過剰にプロビジョニングする可能性があります
詳細については、「リソース予約」を参照してください

ワークロードをデプロイするときに、コンテナーにリソースのメモリと CPU の制限を設定します。 これもまた NodeAllocatable から減算され、クラスター全体のスケジューラが、どのノードにどのポッドを配置するかを決定するのに役立ちます。 制限なしでポッドをスケジュールすると、Windows ノードが過剰にプロビジョニングされる可能性があり、極端な場合はノードが異常になる原因となる可能性があります。

マネージド Prometheus アドオン コンテナー (prometheus_collector) のバージョン 6.4.0-main-02-22-2023-3ee44b9e の時点で、AKS クラスターに対して Windows メトリックの収集が有効になっています。 Azure Monitor メトリック アドオンにオンボードすると、Windows DaemonSet ポッドがノード プールで実行を開始できるようになります。 Windows Server 2019 と Windows Server 2022 の両方がサポートされています。 これらの手順に従って、ポッドが Windows ノード プールからメトリックを収集できるようにします。

  1. Windows-exporter-daemonset YAML ファイルをデプロイすることで、Windows メトリックにアクセスするために、AKS ノードに windows-exporter を手動でインストールします。 次のコレクターを有効にします。

    • [defaults]
    • container
    • memory
    • process
    • cpu_info

    その他のコレクターについては、「Windows メトリックの Prometheus エクスポーター」を参照してください。

    windows-exporter-daemonset YAML ファイルをデプロイします。 ノードにテイントが適用されている場合は、適切な容認を適用する必要があることに注意してください。

        kubectl apply -f windows-exporter-daemonset.yaml

  2. クラスターに ama-metrics-settings-configmap を適用します。 ブール値 windowsexporter と windowskubeproxy を true に設定します。 詳しくは、「メトリック アドオン設定の configmap」をご覧ください。

  3. すぐに利用できるダッシュボードに必要な記録ルールを有効にします。

    • CLI を使用してオンボードする場合は、オプション --enable-windows-recording-rules を含めます。
    • ARM テンプレート、Bicep、Azure Policy を使用したオンボードの場合は、パラメーター ファイルで enableWindowsRecordingRules を true に設定します。
    • クラスターが既にオンボードされている場合、この ARM テンプレートとこのパラメーター ファイルを使用してルール グループを作成します。 これにより、必要なレコーディング規則が追加されます。クラスターでの ARM 操作ではないため、クラスターの現在の監視状態には影響しません。

デプロイの検証

エージェントが正しくデプロイされていることを確認するには、kubectl コマンド ライン ツールを使います。

マネージド Prometheus

DaemonSet が Linux ノード プールに正しくデプロイされたことを確認する

kubectl get ds ama-metrics-node --namespace=kube-system

ポッドの数は、クラスター上の Linux ノードの数と同じである必要があります。 出力は次の例のようになります。

User@aksuser:~$ kubectl get ds ama-metrics-node --namespace=kube-system
NAME               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
ama-metrics-node   1         1         1       1            1           <none>          10h

Windows ノードが正しくデプロイされたことを確認する

kubectl get ds ama-metrics-win-node --namespace=kube-system

ポッドの数は、クラスター上の Windows ノードの数と同じである必要があります。 出力は次の例のようになります。

User@aksuser:~$ kubectl get ds ama-metrics-node --namespace=kube-system
NAME                   DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
ama-metrics-win-node   3         3         3       3            3           <none>          10h

Prometheus 用に 2 つのレプリカセットがデプロイされたことを確認する

kubectl get rs --namespace=kube-system

出力は次の例のようになります。

User@aksuser:~$kubectl get rs --namespace=kube-system
NAME                            DESIRED   CURRENT   READY   AGE
ama-metrics-5c974985b8          1         1         1       11h
ama-metrics-ksm-5fcf8dffcd      1         1         1       11h

Container insights

DaemonSet が Linux ノード プールに正しくデプロイされたことを確認する

kubectl get ds ama-logs --namespace=kube-system

ポッドの数は、クラスター上の Linux ノードの数と同じである必要があります。 出力は次の例のようになります。

User@aksuser:~$ kubectl get ds ama-logs --namespace=kube-system
NAME       DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
ama-logs   2         2         2         2            2           <none>          1d

Windows ノードが正しくデプロイされたことを確認する

kubectl get ds ama-logs-windows --namespace=kube-system

ポッドの数は、クラスター上の Windows ノードの数と同じである必要があります。 出力は次の例のようになります。

User@aksuser:~$ kubectl get ds ama-logs-windows --namespace=kube-system
NAME                   DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR     AGE
ama-logs-windows           2         2         2         2            2       <none>            1d

コンテナーの分析情報ソリューションのデプロイを確認する

kubectl get deployment ama-logs-rs --namespace=kube-system

出力は次の例のようになります。

User@aksuser:~$ kubectl get deployment ama-logs-rs --namespace=kube-system
NAME          READY   UP-TO-DATE   AVAILABLE   AGE
ama-logs-rs   1/1     1            1           24d

CLI を使って構成を表示する

ソリューションが有効になっているかどうか、Log Analytics ワークスペースのリソース ID、クラスターについての概要情報を確認するには、aks show コマンドを使います。

az aks show --resource-group <resourceGroupofAKSCluster> --name <nameofAksCluster>

コマンドは、ソリューションに関する JSON 形式の情報を返します。 addonProfiles セクションには、次の例のように omsagent に関する情報を含める必要があります。

"addonProfiles": {
    "omsagent": {
        "config": {
            "logAnalyticsWorkspaceResourceID": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/microsoft.operationalinsights/workspaces/my-workspace",
            "useAADAuth": "true"
        },
        "enabled": true,
        "identity": null
    },
}

プロビジョニングされるリソース

監視を有効にすると、サブスクリプションに次のリソースが作成されます。

リソース名 リソースの種類 リソース グループ リージョン/場所 [説明]
MSCI-<aksclusterregion>-<clustername> データ収集ルール クラスターと同じ Log Analytics ワークスペースと同じ このデータ収集ルールは、Azure Monitor エージェントによるログ収集に関するもので、Log Analytics ワークスペースを収集先として使い、AKS クラスター リソースに関連付けられています。
MSPROM-<aksclusterregion>-<clustername> データ収集ルール クラスターと同じ Azure Monitor ワークスペースと同じ このデータ収集ルールは、メトリック アドオンによる prometheus メトリック収集用であり、宛先として選択された Azure モニター ワークスペースがあり、AKS クラスター リソースにも関連付けられています
MSPROM-<aksclusterregion>-<clustername> データ収集エンドポイント クラスターと同じ Azure Monitor ワークスペースと同じ このデータ収集エンドポイントは、メトリック アドオンから Prometheus メトリックを取り込むために、上記のデータ収集ルールによって使用されます

新しい Azure Monitor ワークスペースを作成すると、その一部として次の追加リソースが作成されます

リソース名 リソースの種類 リソース グループ リージョン/場所 [説明]
<azuremonitor-workspace-name> データ収集ルール MA_<azuremonitor-workspace-name>_<azuremonitor-workspace-region>_managed Azure Monitor ワークスペースと同じ OSS Prometheus サーバーを使って Azure Monitor ワークスペースにリモート書き込みを行うときに作成される DCR。
<azuremonitor-workspace-name> データ収集エンドポイント MA_<azuremonitor-workspace-name>_<azuremonitor-workspace-region>_managed Azure Monitor ワークスペースと同じ OSS Prometheus サーバーを使って Azure Monitor ワークスペースにリモート書き込みを行うときに作成される DCE。

Windows クラスターと Linux クラスターの違い

Windows Server クラスターの監視を Linux クラスターの場合と比較すると、主に次のような相違点があります。

  • Windows にはメモリ RSS メトリックがありません。 そのため、Windows のノードとコンテナーでは利用できません。 ワーキング セット メトリックは使用できます。
  • Windows ノードではディスク ストレージ容量の情報を使用できません。
  • ポッド環境のみが監視され、Docker 環境は対象外です。
  • プレビュー リリースでは、最大 30 の Windows Server コンテナーがサポートされます。 この制限は、Linux コンテナーには適用されません。

注意

Windows Server 2022 オペレーティング システム用 Container insights のサポートはプレビュー中です。

コンテナー化された Linux エージェント (replicaset ポッド) を使用すると、クラスター内の Kubelet のセキュリティで保護されたポート (10250) 上のすべての Windows ノードに API 呼び出しを行い、ノードとコンテナーのパフォーマンス関連のメトリックが収集されます。 Windows ノードとコンテナーのパフォーマンス関連のメトリックの収集が機能するためには、インバウンドとアウトバウンドの両方で、クラスターの仮想ネットワークの Kubelet で保護されたポート (:10250) が開かれている必要があります。

Windows ノードを持つ Kubernetes クラスターがある場合は、クラスターの仮想ネットワークのインバウンドとアウトバウンドの両方で、Kubelet で保護されたポート (:10250) が開かれていることを確認し、ネットワーク セキュリティ グループとネットワーク ポリシーを構成してください。

次のステップ

  • ソリューションのオンボードを試みた際に問題が発生した場合は、トラブルシューティング ガイドを確認してください。
  • AKS クラスターと実行中のワークロードの正常性とリソース使用率を収集するための監視を有効にしたうえで、Container insights を使用する方法について学習します。