Kubernetes クラスター内のすべてのポッド、サービス、およびノードは、接続の開始、パケットの転送または削除、DNS クエリの解決または失敗などのネットワーク アクティビティを常に生成しています。 アクティビティを理解することは、デバッグ、容量計画、サービスの正常な維持に不可欠です。 ただし、ほとんどの監視設定は、次の 2 つの方法で不足しています。
- 十分な可視性がありません。 ノード レベルの集計では、何かが間違っているが、 どこにあるかは示されません。 ソースと宛先のコンテキストを含むポッド レベルの内訳がない場合、失敗したワークロードを分離することは推測を意味します。
- 大規模なデータが多すぎます。 数百のマイクロサービスを実行するクラスターでは、ノードごとに数千のメトリック時系列を生成できます。 すべてを収集すると、ストレージ コストが高くなり、ダッシュボードの速度が低下します。
Azure Kubernetes Service (AKS) の Advanced Container Networking Services におけるコンテナーネットワークメトリックは、両方の課題に対処します。 この機能は、Linux および Windows で、サポートされている Cilium データ プレーンと非 Cilium データ プレーン全体で、ノード レベルとポッド レベルでネットワーク メトリックを収集します。
Cilium クラスターでは、ソース レベルのフィルター処理をさらに進めることができます。これにより、データがノードから離れる 前 に収集される名前空間、ワークロード、メトリックの種類を正確に選択できます。
コンテナーメトリクスのフィルタリングは、可観測性データのインジェスト前制御です。 使用可能なすべてのメトリックを収集し、後でダッシュボードまたはクエリでフィルター処理する代わりに、ソースで収集する内容を定義します。 これにより、関心のあるワークロードの価値の高いメトリックが保持され、低価値またはノイズの多い時系列の取り込みが回避されます。
その結果、サポートされている任意のデータ プレーンでの実用的なネットワーク可観測性が得られます。Cilium でのオプションのコスト効率の高いフィルター処理が可能です。
コンテナー ネットワーク メトリックを使用すると、トラブルシューティングと計画のためのワークロード レベルの詳細な可視性が得られますが、Cilium のソース レベルのフィルター処理は、ビジネスクリティカルなワークロードに比例した監視コストを維持するのに役立ちます。
収集とフィルター処理の概要
次の表を使用して、広範なコレクションが使用できる場所と、きめ細かいフィルター処理が使用できる場所をすばやく理解します。
| 能力 | Cilium クラスター | Cilium 以外のクラスター |
|---|---|---|
| ノード レベルのメトリック収集 | ✅ | ✅ |
| ポッド レベルのメトリック収集 | ✅ (Linux) | ✅ (Linux) |
| 名前空間、ポッド ラベル、メトリックの種類によるソース レベルのフィルター処理 | ✅ | ❌ |
| インジェスト前のフィルター処理によるコスト管理 | ✅ | ❌ |
Important
2025 年 11 月 30 日から、Azure Kubernetes Service (AKS) は、Azure Linux 2.0 のセキュリティ更新プログラムをサポートまたは提供しなくなりました。 Azure Linux 2.0 ノード イメージは、 202512.06.0 リリースでフリーズします。 2026 年 3 月 31 日以降、ノード イメージは削除され、ノード プールをスケーリングできなくなります。 ノード プールをサポートされている Kubernetes バージョンにアップグレードするか、osSku AzureLinux3 に移行して、サポートされている Azure Linux バージョンに移行します。 詳細については、 廃止に関する GitHub の問題 と Azure 更新プログラムの提供終了に関するお知らせを参照してください。 お知らせや更新情報を常に把握するには、 AKS のリリース ノートに従ってください。
主な利点
ノードレベルとポッドレベルの細分性。 インフラストラクチャの正常性のために、ノード レベルでトラフィック量、ドロップ レート、接続状態を追跡します。 ソースラベルと宛先ラベルを持つ個々のポッドにドリルダウンして、問題の原因となっている正確なワークロードを特定します。
迅速なトラブルシューティング。 サービスがパケットまたは DNS クエリのドロップを開始すると、ポッド レベルのメトリックを使用すると、問題を時間ではなく、特定のポッド、名前空間、またはプロトコルに秒単位で分離できます。
柔軟な視覚化。 Azure Managed Prometheus にメトリックを格納し、Azure Managed Grafana (フル マネージド) で視覚化するか、独自の Prometheus と Grafana インフラストラクチャを使用します。
スケーラブルな設計。 パイプラインは、包括的なカバレッジと管理可能なデータ ボリュームのいずれかを選択する必要なく、数百のノードと数千のポッドを持つ大規模で動的なクラスターを処理します。
ターゲットされた可観測性 (Cilium クラスター) Cilium クラスターでは、ソース レベルのフィルター処理を使用して、関心のある名前空間、ポッド ラベル、またはメトリックの種類を定義し、それらのみを収集できます。 コレクション後のトリミングは必要ありません。
メトリック インジェスト コストの削減 (Cilium クラスター)。 フィルター処理は各ノードのソースで行われるため、不要なメトリック時系列は、Prometheus バックエンドにスクレイピング、送信、または取り込まれることはありません。 実際に必要なメトリックに対してのみ支払います。 フィルター処理されていないコレクションによってノードごとに数千の時系列が生成される大規模なクラスターでは、ソース レベルのフィルター処理により、マネージド Prometheus のインジェストとストレージ コストAzure大幅に削減できます。
どのように機能するのか
各ノードのエージェント スタックは、図に示すようにデータ プレーンに依存します。
Linux Cilium ノード は、階層化された eBPF ベースのスタックを使用します。eBPF カーネル フックは生トラフィック データをキャプチャし、Cilium はそれを処理し、Hubble はそれを Prometheus 形式のメトリックとして公開します。 Hubble はノードとスクレーピング エンドポイントの間にあるため、ソース レベルのフィルター処理はこのレイヤーで実行されます。データがノードから離れる前にエクスポートされる名前空間、ポッド ラベル、メトリックの種類を選択します。
Linux 非Ciliumノードは、Microsoft Retina にフィードするeBPFカーネルフックを使用し、その上にフロー検査用のHubble層を保持します。 Microsoft Retina はメトリック収集を処理し、Prometheus 形式でノード レベルおよびポッド レベルのメトリックをエクスポートします。
すべてのパスから、メトリックは Prometheus 形式でスクレイピングされ、Azure Managed Prometheus または独自の Prometheus バックエンドに取り込まれた後、Azure Managed Grafanaまたは独自の Grafana スタックで視覚化されます。
開始するには、 コンテナー ネットワーク メトリックを設定してから、Cilium クラスターの コンテナー ネットワーク メトリック のフィルター処理を構成 します。
コンテナー ネットワーク メトリックを使用するタイミング
コンテナー ネットワーク メトリックは、未加工のテレメトリではなく、集中して実用的なネットワーク データを必要とするチーム向けに設計されています。 一般的なシナリオは次のとおりです。
- 特定のワークロードのデバッグ。 ポッド レベルのメトリックを使用して、特定のサービスのパケット ドロップ、TCP リセット、または DNS エラーを分離します。 Cilium クラスターでは、フィルター処理によってコレクションをその名前空間またはポッド ラベルのみに絞り込み、クラスター全体のノイズをカットできます。
- マルチテナント クラスターの監視。 各チームが独自のトラフィック パターンを可視化できるように、名前空間ごとのネットワーク正常性を追跡します。 Cilium クラスターでは、スコープフィルター処理によってコレクションがテナント固有の名前空間に制限されます。
- 容量計画。 ノードごとの転送および削除されたバイト数を追跡して、飽和リンクまたは不均衡なワークロードの配置を識別します。
- DNS 正常性の監視。 DNS クエリの失敗と遅い解決時間を特定し、問題がアプリケーションエラーに発展する前に対処します。
- 大規模な監視コストの削減。 大規模なクラスターでは、フィルター処理されていないコレクションによってノードごとに数千の時系列が生成される可能性があります。 Cilium クラスターでは、ソース レベルのフィルター処理により、インジェストの前に不要な系列が削除されるため、コストは選択したワークロードとメトリックの種類に合わせて調整されます。
収集する内容を選択する方法 (Cilium クラスター)
可視性とコストのバランスを取るために、このロールアウト モデルを使用します。
- 非運用名前空間の広範なコレクションから始めて、ベースラインを確立します。
- 重要な名前空間のパケット ドロップ、DNS、TCP 状態のメトリックを保持します。
- カーディナリティの高いフロー メトリックをビジネス クリティカルなワークロードのみにスコープします。
- Prometheus のインジェストの傾向を確認し、毎週フィルターを絞り込みます。
このアプローチは、時系列の増加と取り込みのコストを制御しながら、価値の高いメトリックを維持するのに役立ちます。
メトリック テーブルを確認する前に
次の点に留意してください。
- ノード レベルのメトリックは、サポートされている Cilium および Cilium 以外のデータ プレーンで使用できます。
- ポッド レベルのメトリックは、Linux で使用できます。
- ソース レベルのフィルター処理は、Cilium クラスターでのみ使用できます。
- Cilium クラスターでは、DNS メトリックには Cilium FQDN ネットワーク ポリシーが必要です。
メトリックリファレンス
ノード レベルのメトリック
ノード レベルのメトリックは、ノードごとのトラフィック統計情報 (転送および破棄されたパケット、バイト数、接続状態) を提供します。 これらのメトリックは Prometheus 形式で格納され、Grafana で視覚化できます。
次のメトリックがノードごとに集計されます。 すべてのメトリックには、次のラベルが含まれます。
cluster-
instance(ノード名)
Cilium データ プレーン クラスターの場合、ノード レベルのメトリックは Linux でのみ使用できます。 Cilium は、コンテナー ネットワーク メトリックで使用される次のメトリックを公開します。
| 指標名 | Description | 追加のラベル | Linux | Windows |
|---|---|---|---|---|
| cilium_forward_count_total | 転送されたパケット数の合計 | direction |
✅ | ❌ |
| cilium_forward_bytes_total | 転送されたバイト数の合計 | direction |
✅ | ❌ |
| cilium_drop_count_total | 破棄されたパケット数の合計 |
direction、reason |
✅ | ❌ |
| cilium_drop_bytes_total | 破棄されたバイト数の合計 |
direction、reason |
✅ | ❌ |
ポッド レベルのメトリクス (Hubble メトリクス)
ポッド レベルのメトリックにはソースポッドと宛先ポッドの情報が含まれているため、個々のワークロード レベルでネットワークの問題を特定できます。 これらのメトリックは、トラフィック量、ドロップされたパケット、TCP リセット、およびレイヤー 4/レイヤー 7 フローを対象とします。
DNS メトリック (クエリ数、応答コード、エラー) は、Cilium 以外のデータ プレーンで既定で収集されます。 Cilium データ プレーンでは、DNS メトリックには Cilium FQDN ネットワーク ポリシーが必要です。 また、Hubble CLI を使用して、リアルタイムで DNS のトラブルシューティングを行うこともできます。
次の表では、ポッドごとに集計されるメトリックについて説明します (ノード情報は保持されます)。
すべてのメトリックに次のラベルがあります。
clusterinstance(ノード名)sourceまたはdestination送信トラフィックの場合、
sourceラベルはソース ポッドの名前空間と名前を示します。着信トラフィックの場合、
destinationラベルは宛先ポッドの名前空間と名前を示します。
| 指標名 | Description | 追加のラベル | Linux | Windows |
|---|---|---|---|---|
| hubble_dns_queries_total | クエリ別の DNS 要求総数 |
source または destination、query、qtypes (クエリの種類) |
✅ | ❌ |
| hubble_dns_responses_total | クエリ/応答別の DNS 応答総数 |
source または destination、query、qtypes (クエリの種類)、rcode (リターン コード)、ips_returned (IP の数) |
✅ | ❌ |
| hubble_drop_total | 破棄されたパケット数の合計 |
source または destination、protocol、reason |
✅ | ❌ |
| hubble_tcp_flags_total | フラグ別の TCP パケット数の合計 |
source または destination、flag |
✅ | ❌ |
| hubble_flows_processed_total | 処理されたネットワーク フローの合計数 (レイヤー 4/レイヤー 7 トラフィック) |
source または destination、protocol、verdict、type、subtype |
✅ | ❌ |
Limitations
プラットフォームとデータ プレーン:
- ポッドレベルのメトリックを利用できるのは Linux 上のみです。
- Cilium データ プレーンがサポートされるのは Kubernetes バージョン 1.29 以降です。
- ソース レベルのメトリック のフィルター処理は、Cilium クラスターでのみ使用できます。
- メトリック ラベルには、Cilium クラスターと非 Cilium クラスターの間に微妙な違いがあります。
DNS メトリック:
- Cilium クラスターでは、DNS メトリックに Cilium FQDN ネットワーク ポリシーが必要です。または、リアルタイムの DNS トラブルシューティングに Hubble CLI を使用できます。
既知の問題:
- Hubble ノード エージェントがダウンすると、Hubble リレーがクラッシュし、Hubble CLI セッションが中断される可能性があります。
FIPS のサポート (Cilium 以外のデータ プレーンのみ):
- カーネルの制限により、Ubuntu 20.04 ノードでは FIPS を使用できません。 代わりに、Azure Linux ノード プールを使用してください。 この制限は、Cilium データ プレーンには適用されません。 更新プログラムについては、 AKS の問題トラッカーを参照してください。
| オペレーティング システム | FIPS のサポート |
|---|---|
| Azure Linux 3.0 | Yes |
| Azure Linux 2.0 | Yes |
| Ubuntu 20.04 | No |
スケール:
- Azure Monitor と Azure Managed Grafana の Prometheus のマネージド サービスでは、サービス固有のスケール制限が課されます。 詳細については、「Azure Monitor で大規模に Prometheus メトリックをスクレイピングする」を参照してください。
Pricing
Important
アドバンスト コンテナー ネットワークサービスは有料オファリングです。
価格の詳細については、「アドバンスト コンテナー ネットワークサービス - 価格」を参照してください。
関連コンテンツ
- コンテナー ネットワーク メトリックを設定する
- コンテナー ネットワーク メトリックのフィルター処理を構成する
- AKS 用の高度なコンテナー ネットワーク サービス
- 高度なコンテナネットワークサービスにおけるコンテナネットワーク監視
- 高度なコンテナネットワークサービスにおけるコンテナネットワークセキュリティ