Azure Monitor とクラウド ネイティブ ツールを使用して Kubernetes クラスターを監視する

Azure Monitor での Kubernetes 監視では、Kubernetes 環境とその上で実行されるワークロードの完全な監視を提供するために使用される Azure Monitor サービスについて説明します。 この記事では、これらのサービスを利用して、それらを管理する一般的なロールに基づいて Kubernetes 環境のさまざまなレイヤーを監視する方法のベスト プラクティスについて説明します。

インフラストラクチャ レイヤーからアプリケーションまで、一般的な Kubernetes 環境の共通モデルを次に示します。 各レイヤーには、異なるサービスで対処され、通常は組織内のさまざまなロールによって管理される個別の監視要件があります。

Kubernetes 環境のさまざまなレイヤーと、それに依存するアプリケーションに対する責任は、通常、複数のロールによって対処されます。 組織内のサイズによっては、これらのロールは、異なるユーザーやチームによって実行される場合があります。 次の表では、さまざまなロールについて説明しますが、以下のセクションでは、それぞれが通常発生する監視シナリオを示します。

ネットワーク エンジニア

ネットワーク エンジニアは、ワークロードとクラスターのイングレス/エグレスとの間のトラフィックを担当します。 ネットワーク トラフィックを分析し、脅威分析を実行します。

監視レベル 1 - ネットワーク

ネットワークを監視するための一般的なシナリオを次に示します。

• Network Watcher を使用してフロー ログを作成し、クラスターによって使用されるネットワーク セキュリティ グループを通過する IP トラフィックに関する情報をログに記録し、トラフィック分析を使用してこのデータに関する分析情報を提供します。 コンテナー ログとコントロール プレーン ログに使用するトラフィック分析には、同じ Log Analytics ワークスペースを使用します。
• トラフィック分析を使用して、クラスターで使用される予期しないポートとの間でトラフィックが流れているかどうか、および公開すべきでないパブリック IP 経由でトラフィックが流れているかどうかを判断します。 この情報を使用して、ネットワーク ルールを変更する必要があるかどうかを判断します。
• AKS クラスターの場合は、AKS のネットワーク監視機能アドオン (プレビュー) を使用して、クラスター内のサービス (東西のトラフィック) 間のアクセスを監視します。

プラットフォーム エンジニア

プラットフォーム エンジニア (クラスター管理者とも呼ばれます) は、Kubernetes クラスター自体を担当します。 開発者が使用するプラットフォームをプロビジョニングして維持します。 クラスターとそのコンポーネントの正常性を把握し、検出された問題をトラブルシューティングできるようにする必要があります。 また、クラスターを運用するためのコストを把握し、さまざまなチームにコストを割り当てることができるようにすることも必要です。

大規模な組織には、プラットフォーム エンジニアに似ているものの、複数のクラスターを担当するフリート アーキテクトがいる場合もあります。 環境全体を視覚化することが必要であり、大規模な管理タスクを実行する必要があります。 次に示すガイダンスには大規模な推奨事項が含まれています。 マルチクラスターおよび大規模なシナリオ用のフリート リソースの作成について詳しくは、「Azure Kubernetes Fleet Manager とは?」をご覧ください。

プラットフォーム エンジニアの監視を構成する

以下のセクションでは、 コンテナー レベルの Azure サービスを使用して Kubernetes 環境を監視する手順を示します。 機能と統合のオプションは、特定の要件を満たすためにこの構成を変更する必要がある場所を決定するのに役立ちます。 Managed Prometheus とコンテナー のログ記録のオンボードは、「 Kubernetes クラスターの監視を有効にする」で説明されているのと同じエクスペリエンスの一部になります。 以下のセクションでは、それぞれのオンボードと構成のオプションをすべて考慮できるように、それぞれについて個別に説明します。

Prometheus メトリックのスクレイピングを有効にする

Prometheus の Azure Monitor マネージド サービスによる Prometheus メトリックの作成時または既存のクラスターへの追加時に、クラスターからの Prometheus メトリックのスクレイピングを有効にします。 詳細については、「 Prometheus メトリックを有効にする 」を参照してください。

AKS クラスターに使用する Prometheus 環境が既にある場合は、Prometheus の Azure Monitor マネージド サービスを有効にしてから、リモート書き込みを使用して既存の Prometheus 環境にデータを送信します。 リモート書き込みを使用して、既存のセルフマネージド Prometheus 環境から Prometheus 用の Azure Monitor マネージド サービスにデータを送信することもできます。

既定で収集されるメトリックとその収集頻度に関する詳細については、「Azure Monitor での既定の Prometheus メトリック構成」を参照してください。 構成をカスタマイズする場合は、「Prometheus の Azure Monitor マネージド サービスで Prometheus メトリックのスクレイピングをカスタマイズする」を参照してください。

Prometheus データの分析で Grafana を有効にする

データ ソースとして Prometheus データを使用できるようにするために、Managed Grafana のインスタンスを作成し、Azure Monitor ワークスペースにリンクします。 Azure Monitor の Prometheus 用マネージド サービスをデータ ソースとして追加して、この構成を手動で実行することもできます。 Kubernetes クラスターの監視には、Container insights ビューと同様の情報を表すダッシュボードなど、さまざまな事前構築済みダッシュボードを使用できます。

既存の Grafana 環境がある場合は、引き続き使用して、Prometheus の Azure Monitor マネージド サービスをデータ ソースとして追加できます。 Azure Monitor データ ソースを Grafana に追加して、Container insights で収集されたデータをカスタム Grafana ダッシュボードで使用することもできます。 Container insights のビューとレポートを使用するのではなく、Grafana ダッシュボードに重点を置く場合は、この構成を実行します。

コンテナー ログの収集を有効にする

Kubernetes クラスターのコンテナー ログの収集を有効にすると、Azure Monitor は、Kusto クエリ言語 (KQL) を使用して分析できる Azure Monitor の Log Analytics ワークスペースに stdout/stderr とインフラストラクチャ ログを送信する、コンテナー化されたバージョンの Azure Monitor エージェントをデプロイします。

Kubernetes クラスターをオンボードするための前提条件と構成オプションについては、「 AKS クラスターの監視を有効にする 」を参照してください。 Azure Policy を使用してオンボードし、すべてのクラスターが一貫した構成を維持するようにします。

クラスターに対してコンテナー ログが有効になったら、次のアクションを実行してインストールを最適化します。

• 不定期のトラブルシューティングにのみログを使用する場合は、この表を基本ログとして構成することを検討してください。
• 収集されるデータの量を減らして、Container Insights のデータ インジェストのコストを削減するには、Container Insights でのコスト最適化設定の有効化に関する記事で説明されているコスト プリセットを使います。 多くのメトリック値は Prometheus と同じなので、ログとイベントのみを収集するように Container Insights を構成して、メトリックの収集を無効にします。

ログ収集用の既存のソリューションがある場合は、そのツールのガイダンスに従うか、Azure Monitor でログ収集を有効にし、 Log Analytics ワークスペースのデータ エクスポート機能 を使用して Azure Event Hubs にデータを送信し、別のシステムに転送します。

AKS クラスターのコントロール プレーン ログを収集する

AKS コントロール プレーン コンポーネントのログは、リソース ログとして Azure に実装されます。 AKS リソース ログを Log Analytics ワークスペースに送信するには、各 AKS クラスターの診断設定を作成します。 Azure Policy を使用して、複数のクラスター間で一貫した構成を確保します。

リソース ログをワークスペースに送信するにはコストがかかるため、使うログ カテゴリのみを収集する必要があります。 AKS で使用できるカテゴリの説明については、「リソース ログ」を参照してください。 最初は最小限の数のカテゴリを収集することから始め、ニーズの増加と関連するコストの理解に応じて、診断設定を変更して追加のカテゴリを収集します。 コンプライアンス上の理由で情報を保持する必要がある場合は、Azure Storage アカウントにログを送信してコストを削減できます。 ログ データの取り込みと保持のコストの詳細については、Azure Monitor Logs の料金の詳細に関する記事を参照してください。

最初に有効にするリソース ログがわからない場合は、最も一般的な顧客の要件に基づく次の推奨事項を使用します。 必要に応じて、後で他のカテゴリを有効にできます。

ログ収集用の既存のソリューションがある場合は、そのツールのガイダンスに従うか、Azure Monitor でログ収集を有効にし、 Log Analytics ワークスペースのデータ エクスポート機能 を使用して Azure イベント ハブにデータを送信し、別のシステムに転送します。

AKS クラスターのアクティビティ ログを収集する

AKS クラスターに対する構成の変更は、アクティビティ ログに格納されます。 診断設定を作成して、このデータを Log Analytics ワークスペースに送信し、他の監視データと一緒に分析します。 このデータ収集にはコストはかからず、Log Analytics を使用してデータを分析またはアラートできます。

モニター レベル 2 - クラスター レベルのコンポーネント

クラスター レベルには、次のコンポーネントが含まれます。

クラスター レベルのコンポーネントを監視するための一般的なシナリオを次に示します。

Azure Portal

• Azure portal の統合監視ダッシュボードを使用して、CPU とメモリの使用率など、クラスター内のノードのパフォーマンスを確認します。
• [ノード] ビューを使って、各ノードの正常性と、そこで実行されているポッドの正常性とパフォーマンスを確認します。 ノードの正常性とパフォーマンスの分析の詳細については、 Azure portal での Kubernetes クラスターのパフォーマンスの分析に関するページを参照してください。
• [レポート] では、[Node Monitoring] (ノードの監視) ブックを使って、ディスク容量、ディスク IO、GPU 使用率を分析します。 これらのワークブックの詳細については、「ノード監視ワークブック」を参照してください。
• [監視] で [ワークブック] を選び、次に [Subnet IP Usage] (サブネット IP の使用状況) を選択し、選択した時間範囲における各ノードの IP 割り当てと配置を確認します。

Grafana ダッシュボード

• Kubelet 用 Managed Grafana の事前構築済みダッシュボードを使用して、それぞれの正常性とパフォーマンスを確認します。
• や node_disk_io_time_seconds_total などのディスクに関連する windows_logical_disk_free_bytesを含む Grafana ダッシュボードを使用して、アタッチされたストレージを監視します。
• Prometheus に格納されているデータに基づいてノードのパフォーマンスと正常性を視覚化する複数の Kubernetes ダッシュボードを使用できます。

Log Analytics

• Log Analytics ワークスペースのクエリ ダイアログで [コンテナー] カテゴリを選択して、Container Insights によって設定された ContainerImageInventory テーブルからデータを取得する イメージ インベントリ ログ クエリなどのクラスター向けの事前構築済みのログ クエリにアクセスします。

トラブルシューティング

• トラブルシューティングのシナリオでは、メンテナンスまたは即時ログ収集のためにノードに直接アクセスする必要がある場合があります。 セキュリティのため、AKS ノードはインターネットに公開されませんが、kubectl debug コマンドを使って AKS ノードに SSH 接続できます。 このプロセスの詳細については、「メンテナンスまたはトラブルシューティングのために SSH を使用して Azure Kubernetes Service (AKS) クラスター ノードに接続する」を参照してください。

コスト分析

• Kubernetes のコストを把握するためのオープンソースでベンダーニュートラルの CNCF サンドボックス プロジェクトである OpenCost を構成して、クラスター コストの分析をサポートします。 詳細なコスト計算データを Azure Storage にエクスポートします。
• OpenCost のデータを使用して、組織内のさまざまなチームによるクラスターの相対的な使用状況を内訳化し、コストをチームに割り当てることができるようにします。
• OpenCost のデータを使用して、多数の小型ノードではなく、より少ない大型ノードを使用して、ワークロードを高密度にパックすることで、クラスターがそのノードの完全な容量を使用していることを確認します。

監視レベル 3 - マネージド Kubernetes コンポーネント

マネージド Kubernetes レベルには、次のコンポーネントが含まれます。

マネージド Kubernetes コンポーネントを監視するための一般的なシナリオを次に示します。

Azure Portal

• メトリック ス エクスプローラーを使用して、クラスターの Inflight Requests カウンターを表示します。
• Kubelet ワークブックを使用して、各kubeletのヘルスとパフォーマンスを確認します。

グラファナ

• Kubelet 用 Managed Grafana の事前構築済みダッシュボードを使用して、それぞれの kubelet の正常性とパフォーマンスを確認します。
• API サーバーの完全なパフォーマンスを表示するには、Kubernetes API サーバーなどのダッシュボードを使用します。 これには、要求の待機時間や作業キューの処理時間などの値が含まれます。

Log Analytics

• リソース ログを含むログ クエリを使用して、AKS コンポーネントによって生成されたコントロール プレーン ログを分析します。

• AKS の構成アクティビティは、アクティビティ ログに記録されます。 アクティビティ ログを Log Analytics ワークスペースに送信する場合は、Log Analytics を使用して分析できます。 たとえば、次のサンプル クエリを使用することで、すべての AKS クラスターで正常にアップグレードされたことを示すレコードを返すことができます。

  AzureActivity
  | where CategoryValue == "Administrative"
  | where OperationNameValue == "MICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS/WRITE"
  | extend properties=parse_json(Properties_d) 
  | where properties.message == "Upgrade Succeeded"
  | order by TimeGenerated desc
  

トラブルシューティング

• トラブルシューティングのシナリオでは、「Azure Kubernetes Service (AKS) クラスター ノードから kubelet ログを取得する」で説明されているプロセスを使用して、kubelet ログにアクセスできます。

監視レベル 4 - Kubernetes オブジェクトとワークロード

Kubernetes オブジェクトとワークロード レベルには、次のコンポーネントが含まれます。

Kubernetes オブジェクトとワークロードを監視するための一般的なシナリオを次に示します。

Azure Portal

• [ノード] ビューと [コントローラー] ビューを使って、それらで実行中のポッドの正常性とパフォーマンスを確認し、それらのコンテナーの正常性とパフォーマンスにドリルダウンします。
• [コンテナー] ビューを使って、コンテナーの正常性とパフォーマンスを確認します。 コンテナーの正常性とパフォーマンスの分析の詳細については、「 Container Insights を使用した Kubernetes クラスター データの分析」を参照してください。
• デプロイ ブックを使用して、デプロイ メトリックを表示します。 詳細については、「Container insights によるデプロイと HPA メトリック」を参照してください。

Grafana ダッシュボード

• ノードおよびポッド 用 Managed Grafana の事前構築済みダッシュボードを使用して、正常性とパフォーマンスを表示します。
• Prometheus に格納されているデータに基づいてノードのパフォーマンスと正常性を視覚化する複数の Kubernetes ダッシュボードを使用できます。

ライブ データ

• トラブルシューティングのシナリオでは、コンテナーの分析情報はライブ AKS コンテナー ログ (stdout または stderror)、イベント、ポッド メトリックにアクセスできます。 この機能の詳細については、「Kubernetes ログ、イベント、およびポッド メトリックをリアルタイムで表示する方法」を参照してください。

プラットフォーム エンジニアに対するアラート

Azure Monitor のアラートでは、監視データの興味深いデータやパターンを事前に通知します。 これにより、ユーザーが気付く前に、管理者が問題を識別して対処できます。 アラート用の既存の ITSM ソリューション がある場合は、Azure Monitor と統合できます。 ワークスペース データをエクスポートして、Log Analytics ワークスペースから現在のアラート ソリューションをサポートする別の場所にデータを送信することもできます。

アラートの種類

次の表では、上述のサービスで収集されたデータに基づいて作成できるさまざまな種類のカスタム アラート ルールについて説明します。

推奨アラート

まず、Kubernetes クラスターの最も一般的なアラート条件を含む、Container insights のメトリック アラート ルール (プレビュー) で推奨される Prometheus アラートのセットから始めます。 追加のアラート条件を特定すると、後でさらにアラート ルールを追加できます。

Developer

開発者は、アプリケーションの開発に加えて、クラスター上で実行されているアプリケーションを維持します。 また、アプリケーションのパフォーマンスや失敗などのアプリケーション固有のトラフィックを担当し、会社で定義された SLA に従ってアプリケーションの信頼性を維持します。

監視レベル 5 - アプリケーション

Azure Monitor OpenTelemetry Distro を実装して Application Insights エクスペリエンスを有効にし、サンプリングを構成してコストを制御します。

Application Insights のエクスペリエンス

• 概要ダッシュボードで、アプリケーションの正常性とパフォーマンスをひとめで確認できます。
• アプリケーションのアクティビティとパフォーマンスに関するリアルタイムの分析情報を得るための ライブ メトリック を表示します。
• 障害、パフォーマンス、トランザクションを調査して、アプリケーションの 正常性と効率を診断します。
• アプリケーション のアーキテクチャとコンポーネントの相互作用の視覚的な概要については、アプリケーション マップを使用します。
• アプリケーションの可用性を監視するための 標準テスト を作成します。

アプリケーション ログ

• Container insights は、stdout/stderr ログを Log Analytics ワークスペースに送信します。 さまざまなログの説明については、リソース ログを参照し、それぞれが送信される表の一覧については、Kubernetes Services を参照してください。

サービス メッシュ

• AKS クラスターの場合は、マイクロサービス アーキテクチャを監視できる Istio ベースのサービス メッシュ アドオンをデプロイします。 Istio は、既存の分散アプリケーションに透過的にレイヤー化するオープンソース サービス メッシュです。 アドオンは、AKS 用 Istio のデプロイと管理をサポートします。

関連項目

• Kubernetes クラスターの監視を有効にして、クラスターで Managed Prometheus とログ収集を有効にする方法を参照してください。