Advanced Container Networking Services に関する AKS ネットワークの問題を診断して解決する

このガイドでは、Advanced Container Networking Services (ACNS) を使用したAzure Kubernetes Service (AKS)での実際のネットワークの問題の診断と解決について説明します。 各プレイブックは、症状 (DNS エラー、パケット ドロップ、トラフィックの不均衡、L7 エラー) から始まり、最初に確認するシグナルを示し、ログにドリルダウンするタイミングを示します。

このガイドは、機能ではなくタスクに関して整理されています。 メンタル モデルを 1 回読み、症状に一致するプレイブックに直接ジャンプします。

このガイドが解決に役立つ内容

• ポッドでの DNS 解決エラー (NXDOMAIN、SERVFAIL、応答がありません)。
• 正しく構成されていないネットワーク ポリシー、接続の追跡、または接続の低下によって発生するパケットのドロップ。
• ポッドまたは名前空間間のトラフィックの不均衡 (ホット ポッド、不均等な負荷分散)。
• L7 アプリケーション エラー (HTTP 4xx/5xx、gRPC エラー、Kafka ドロップ)。
• クラスター全体のネットワーク正常性 の監視と容量計画。
• 対象となるメトリックとログの収集による監視コスト制御。

メンタル モデル: メトリック、ログ、フィルター処理がどのように連携するか

ACNS は 3 つのシグナルを提供します。 それぞれが異なる質問に答えます。

より詳細な機能リファレンスについては、 コンテナー ネットワーク メトリック、 コンテナー ネットワーク ログ、および メトリック フィルターの構成に関する記事を参照してください。

標準のトラブルシューティング フロー

ネットワーク インシデントには、次のループを使用します。

1. メトリック ダッシュボードから開始します。 異常を確認します。ドロップ数の急増、エラー、TCP リセット、または DNS エラー。 影響を受けるノード、名前空間、またはワークロードを特定します。
2. 保存されたログに移行します。 手順 1 の名前空間と時間枠で ContainerNetworkLogs テーブルをフィルター処理します。 ログには、判定、ドロップ理由、ソース/宛先ワークロード、メトリックに含まれない L7 状態コードが示されます。
3. オンデマンド ログを使用してライブで再現します。 問題が断続的であるか、保存されているデータで既に修正されている場合は、Hubble CLI または Hubble UI を使用してそのワークロードのライブ フローをキャプチャします。
4. 修正プログラムを検証します。 同じメトリック パネルを再確認し、同じ KQL クエリを再実行します。 異常はなくなりました。
5. コレクションをチューニングします。 インシデント中に過剰に収集した場合は、 ContainerNetworkLog CRD を絞り込むか、 ContainerNetworkMetric フィルターを適用して、今後必要なものだけをキャプチャします。

標準ダッシュボードを一目で見る

Container Network Observability を設定して、一度だけこれを行います。 各プレイブックの随所で参照します。

プレイブック 1: DNS 解決エラーを診断する

症状。 ポッドは、サービス名の解決中に DNS_PROBE_FINISHED_NXDOMAIN、 SERVFAIL などのエラーを記録したり、ハングしたりすることがあります。

目標。 障害がアップストリーム (CoreDNS または外部リゾルバー)、ポリシードリブン (FQDN 拒否)、ワークロード固有のいずれであるかを特定します。

手順 1: DNS メトリックの異常を確認する

DNS (クラスター) ダッシュボードを開きます。 要求ボリューム、応答ボリューム、または 要求不足応答 %の急激な変化を探します。 概要パネルには、最も一般的なクエリ、最も一般的な応答コード、および最も多くのエラーを生成するノードが表示されます。

検索対象: エラー応答の継続的な増加、成功した応答の低下、またはエラー数を支配する単一ノード。 異常のタイムスタンプをメモします。

手順 2: 最も騒々しいポッドを識別する

同じダッシュボードを下にスクロールして、すべての名前空間の DNS エラーによってポッドをランク付けするパネルに移動します。 上位のエントリが最初の候補です。

決定ポイント。

• エラーが CoreDNS ポッドに集中している場合は、選択されている kube-system / coredns ダッシュボードに移動します。CoreDNS 自体またはそのアップストリーム リゾルバーが問題です。
• エラーがアプリケーション ワークロードに集中している場合、そのワークロードは不適切なクエリを生成しているか、FQDN ポリシーによって拒否されています。

手順 3: 影響を受けるワークロードの詳細を調べる

特定した ワークロードの DNS (ワークロード) ダッシュボードを開きます。

• DNS 要求/DNS 応答パネル。 Requests Missing Response % が高い場合、アップストリーム タイムアウトまたはクエリのオーバーロードを示します。

  

• 種類別の DNS エラー。 スパイクをコードに一致させます。

  • NXDOMAIN — アプリ構成のドメイン名が間違っているか古い。
  • SERVFAIL — アップストリーム リゾルバーの問題。
  • クエリ拒否 — FQDN ポリシーまたは DNS 構成の不一致。

  

• 返された DNS 応答 IP。 成功した解決率を確認します。 通常、低下は CoreDNS がアップストリームに到達できないことを意味します。急激な急増は、クエリの嵐を示している可能性があります。

• DNS 応答テーブル。 これを使用して、"A records fail but AAAA records succeed" のようなパターンを特定します。これは通常、IPv4 のみの環境で正しく構成されていないスタックを指しています。

  

手順 4: 保存されているログを確認する

Log Analytics ワークスペースでこの KQL クエリを実行して、DNS エラー パターンを表示します。 集計された行は Verdict、名前空間、ワークロード、および Layer7.dns.rcodeを保持するため、このクエリは既定の (集計された) ContainerNetworkLogs テーブルに対して機能します。

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| extend L4 = parse_json(Layer4), L7 = parse_json(Layer7)
| where L4.UDP.destination_port == 53
| where Reply == true
| extend SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name),
         DnsRcode    = tostring(L7.dns.rcode)
| where DnsRcode != "NOERROR"
| summarize ResponseCount = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SourceNamespace, SrcWorkload, DestinationNamespace, DstWorkload, DnsRcode, Verdict
| order by ResponseCount desc

<start-time>と<end-time>を、2026-04-30T15:00:00Z形式のタイムスタンプに置き換えます。

結果を確認する内容:

• 評決。 DROPPED は、FQDN またはネットワーク ポリシーによってクエリがブロックされていることを意味します。 FORWARDED 非NOERRORDnsRcode (たとえば、 NXDOMAIN、 SERVFAIL) は、アップストリーム リゾルバーがエラーを返したことを意味します。
• 移行元/移行先のワークロード。 トラフィックが予想される CoreDNS ワークロードに送信されていることを確認します。
• DnsRcode。 DNS 応答コードは、エラー モードを一目で識別します。

Azure ポータルのAKS クラスター>Insights>Networking>Flow Logsで同じフローを視覚化することもできます。

手順 5: 問題が断続的な場合はライブで再現する

スパイクが既に過ぎ、格納されたログにキャプチャできない場合は、オンデマンドで Hubble CLI を 使用します。

hubble observe --namespace <ns> --port 53 --type l7 --follow

手順 6: 修正プログラムを検証する

FQDN ポリシーの更新、アプリケーション構成の修正、または CoreDNS のスケーリングが完了したら、 DNS (ワークロード) ダッシュボードを再度開きます。 エラー率は 1 ~ 2 分以内に低下します。 KQL クエリを同じ時間枠で再実行し、失敗したクエリがなくなったことを確認します。

プレイブック 2: パケット ドロップを調査する

症状。 サービスは相互に到達できません。 プローブは失敗します。 接続がタイムアウトしています。破棄カウンターはダッシュボードに表示されます。

目標。 ドロップの原因が、ネットワーク ポリシー、接続追跡の枯渇、アップストリーム接続の問題のいずれであるか、およびどのワークロードが原因であるかを特定します。

手順 1: 名前空間レベルでドロップを見つける

ポッド フロー (名前空間) を開きます。 ヒートマップにより、発信および受信ドロップ率が最も高い名前空間とポッドが表示されます。

明るいセルは、ドロップ 率が高いことを示します。 名前空間と時間枠をメモします。

手順 2: 影響を受ける作業負荷を詳細に調査する

ドロップ (ワークロード) を開き、特定したワークロードを選択します。

• ワークロード スナップショット には、最大/最小の送信ドロップがパケット数/秒で表示されます。重要度を測定するために使用します。

  

• 理由別のトラフィックのドロップが最も重要なパネルです。 その理由は、修正する内容を示しています。

  • ポリシーが拒否されました 。 NetworkPolicy または CiliumNetworkPolicy がトラフィックをブロックしています。
  • CT: マップの挿入に失敗しました — 接続追跡テーブルがいっぱいです。ノードをスケーリングするか、接続のチャーンを減らします。
  • サポートされていない L3 プロトコル/無効なパケット — アプリケーションまたはプロキシが形式の正しくないトラフィックを送信しています。

  

• 受信/送信ドロップのヒートマップ。 トラフィックを失っている特定のポッド ペアを識別します。

  

• ソース ポッド別の積み上げ合計ドロップ数。 最初に確認するレプリカを把握できるように、違反者をランク付けします。

  

手順 3: 保存されたログ内の削除されたフローを確認する

ドロップされたトラフィックの正確な送信元と宛先のワークロードを見つけます。 Verdict、 DropReason、名前空間、ワークロードはすべて集計キーに含まれるため、このクエリは集計データに対して機能します。

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where Verdict == "DROPPED"
| extend SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name)
| summarize DropCount = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SourceNamespace, SrcWorkload, DestinationNamespace, DstWorkload, DropReason, bin(TimeGenerated, 5m)
| order by TimeGenerated desc, DropCount desc

特定した名前空間を 1 つに絞り込みます:

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where Verdict == "DROPPED"
| where SourceNamespace == "<namespace-name>"
| extend SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name)
| summarize DropCount = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SrcWorkload, DestinationNamespace, DstWorkload, DropReason, TrafficDirection
| order by DropCount desc

Azure ポータルの Flow Logs ダッシュボードには、ブロックされたパスを強調表示するサービス依存関係グラフなど、同じデータが視覚的に表示されます。

手順 4: ポリシーとのクロスチェック

ソース ポッドと宛先ポッドがわかったら、次のようにします。

kubectl get netpol,cnp -A
kubectl describe cnp -n <namespace> <policy-name>

失敗したフローをイングレス/エグレス ルールと照合します。 最も一般的な原因は、正当なパスの許可ルールを含まないまま追加されたデフォルト拒否ポリシーです。

手順 5: 修正プログラムを検証する

ポリシーを調整した後、 Dropped Traffic by Reason グラフは ポリシー拒否の場合はフラットになります。 KQL クエリを再実行します。 DROPPED 、そのソースと宛先のペアの判定が表示されなくなります。

プレイブック 3: トラフィックの不均衡とホット ポッドを見つける

症状。 デプロイのいくつかのポッドで CPU またはネットワークが飽和しているのに対し、他のポッドはアイドル状態です。 TCP リセットが上昇します。 待機時間レポートはユーザーから取得されます (待機時間自体は ACNS メトリックでは表示されません。 Mental モデルのメモを参照してください)。

目標。 どのポッドが不均衡なトラフィックを運んでいるか、リセットがオーバーロードまたは正しく構成されていない負荷分散を示しているかどうかを特定します。

手順 1: ポッド レベルのトラフィックを比較する

ポッド フロー (ワークロード) を開きます。 ワークロード スナップショットは、送信/受信トラフィックとドロップを要約します。

[トレース タイプ別トラフィック] パネルには、時間の経過に伴うトラフィックの傾向が表示されます。 多くの場合、発信ボリュームと受信ボリュームの間の広いギャップは、ダウンストリームのボトルネックを指しています。

手順 2: ヒートマップを使用してホット ポッドをスポットする

ポッド レベルのヒートマップにより、不均衡が明らかになります。 1 つのポッド (たとえば、 default/tcp-client-0) が、レプリカよりもはるかに暗いセルを持つ発信ヒートマップと着信ヒートマップの両方に表示される場合、トラフィックはそこに集中します。

一般的な原因:

• サービス sessionAffinity: ClientIP クライアントを 1 つのポッドにピン留めします。
• 固定 DNS 解決を使用したヘッドレス サービス。
• 外部ロードバランサーがカーディナリティの低いフィールドでハッシュを行う。

手順 3: TCP リセットを飽和信号として使用する

TCP リセット メトリック パネルを開きます。

• ソース ポッドごとの送信 TCP RST のヒートマップ。 また、RTS を生成するホット ソース ポッドが過負荷になり、アプリケーションは積極的に接続を閉じています。

  

• 宛先ポッド別の受信 TCP RST のヒートマップ。 多くのソースから RST を受信するポッドは、通常、新しい接続を迅速に受け入れることができないことを意味します（バックログが満杯、リスナーが遅い）。

  

• ソース/宛先ごとの積み上げ合計RST。 時間の経過に伴う傾向は、リセットがインシデントか新しい安定状態かを示します。

手順 4: ログで確認する

フローボリュームの合計で最も負荷の高いワークロードを特定します。 基になるフローではなく、集計された行のみをカウントする count()ではなく、集計されたフローカウント列を使用します。

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| extend SrcWorkload = tostring(SourceWorkloads[0].name)
| summarize TotalFlows = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SourceNamespace, SrcWorkload
| top 10 by TotalFlows desc

手順 5: 修正プログラムを検証する

ワークロードのスケーリング、サービスの再調整、またはアフィニティ ルールの修正後、ヒートマップは、より多くのポッド間で均等に明るくなり、TCP RST レートが低下します。

プレイブック 4: クラスター全体のネットワーク正常性を監視する

これは、フリート ビューが必要な場合に使用します。例えば、容量計画、通話中のダッシュボード、または多くのクラスターでの迅速な正常性チェックなどです。

Kubernetes/Networking/Clusters を開きます。

監視するシグナルとその意味:

このダッシュボードの内容が間違っている場合は、一致するプレイブック (DNS の場合はプレイブック 1、ドロップの場合はプレイブック 2、ホット ポッドの場合はプレイブック 3) にジャンプします。

プレイブック 5: アプリケーション 層 (L7) エラーを診断する

症状。 HTTP 4xx/5xx エラー率が上昇します。 gRPC 呼び出しは失敗します。 Kafka コンシューマーのラグ。 L7 ポリシーの適用が有効で、L7 ルールを含むCiliumNetworkPolicyがある Cilium クラスターで使用できます。「レイヤー 7 ポリシーの構成」を参照してください。

目標。 L7 エラーが、正しく構成されていないクライアント、サーバー側の障害、または拒否されたフローから発生しているかどうかを特定します。

手順 1: L7 ダッシュボードを開く

1 つのサービスには Kubernetes/Networking/ L7 (ワークロード) を使用し、テナント全体には L7 (名前空間) を使用します。

手順 2: 破棄された HTTP トラフィックと転送された HTTP トラフィックを分離する

判定パネルは、HTTP トラフィックを転送されたフローとドロップされたフローに分割します。 HTTP のドロップが急増している場合、通常、CiliumNetworkPolicy によって L7 で要求が拒否されていることが多いことを示しています (たとえば、パスやメソッドのブロック)。

手順 3: 時間の経過と同時に状態コードを追跡する

状態コード パネルには、エラーがクライアント側かサーバー側かを示します。 4xx の急増は、不適切な入力、期限切れのトークン、または拒否されたパスを指しています。 バックエンドの障害時に 5xx ポイントの急増。

手順 4: 問題のあるポッドを見つける

4xx ヒートマップは、最も失敗した要求を生成しているソース ポッドを示しています。 1 つのポッドが明るく光るということは、通常、クライアントの再試行ループがスタックしているか、レプリカが正しく構成されていないことを意味します。

ドロップされたリクエストのヒートマップと共に、HTTP リクエストのボリュームごとの上位ソースポッドのスクリーンショット。

手順 5: KQL で確認する

状態コード別に分類された HTTP トラフィックをプルします。 Layer7.http.code は集計キーの一部であるため、これは集計された行に対して機能します。

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| extend L7 = parse_json(Layer7)
| where isnotnull(L7.http)
| extend StatusCode  = tostring(L7.http.code),
         SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name)
| where StatusCode startswith "4" or StatusCode startswith "5"
| summarize ErrorFlows = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount),
            UniqueCodes = dcount(StatusCode)
    by SrcWorkload, DstWorkload, StatusCode
| order by ErrorFlows desc

gRPC と Kafka の場合、 Layer7 はプロトコル固有のペイロードを保持しますが、集計キーは http.code と dns.rcode のみです。 Verdictとワークロード ID をフィルター処理し、gRPC メソッドまたは Kafka トピックが必要な場合はオンデマンド ログを使用します。

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where FlowType == "L7"
| extend SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name)
| where Verdict == "DROPPED"
| summarize DroppedFlows = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SrcWorkload, DstWorkload
| order by DroppedFlows desc

L7 RCA 中に注目する内容

• トラフィックの量と形状。 ヒートマップを使用して不均衡を見つける。多くの場合、1 つのホット レプリカでエラー率が説明されます。
• 状態コードの傾向。 4xx と 5xx は、調査をクライアント側またはサーバー側に絞り込みます。
• 評決。削除 L7 フローは、L7 ポリシーが要求を拒否することを意味します。ポリシーを読み取り、意図を確認します。

機能の詳細分析 (状況に応じて何を使用するかの判断)

プレイブックがわかったら、このセクションをクイック リファレンスとして使用します。

コンテナー ネットワーク メトリック

• 使用対象: 異常検出、ダッシュボード、アラート、容量計画。
• スキップの理由: どのポッドか、どのパスか、どの判定かといった、ID が必要な根本原因。
• 粒度: すべてのデータ プレーンのノード レベル。Linux 上のポッド レベル。
• コスト重視のワークロード: Cilium クラスターに メトリック フィルターを 適用して、関心のある名前空間、ラベル、メトリックの種類のみを保持します。 フィルター処理はスクレーピングの前に行われるため、不要なシリーズが Prometheus に到達することはありません。

コンテナー ネットワーク ログ (保存)

• 使用対象: 根本原因分析、履歴傾向、コンプライアンス/監査。

• データ プレーン:Cilium のみ。 保存されたログは、Cilium 以外のクラスターでは使用できません。

• 必須の手順: 必要なトラフィックを選択する ContainerNetworkLog CRD を定義します。 それなしでは、ログは収集されません。 コンテナー ネットワーク ログの設定を参照してください。

• ログが格納される場所: 既定では、Cilium はフロー レコードを各ノード (50 MB 回転バッファー) 上の /var/log/acns/hubble/events.log に書き込みます。 そこから、次の 2 つのストレージ パスがあります。

  • Azure Log Analytics (マネージド、推奨) - Container Insights は、KQL クエリと組み込みのAzure ポータル ダッシュボードのContainerNetworkLogs テーブルにログを発送します。
  • 独自のコレクター — OpenTelemetry と互換性のあるエージェント (Splunk、Datadog、Elastic、任意の OTel コレクター) をホストのログ パスに向けて設定し、Log Analytics の代わりに、またはそれを併用して、既存の監視スタックへフローを転送します。

• コスト管理: フロー ログの集約では、30秒間のウィンドウ内で同様のフローがまとめられるため、ボリュームを低下させながらもパターンが保持されます。 最良の結果を得るには、狭い includeFilters と組み合わせます。

• 可視化:フローログ - アナリティクス ティアのダッシュボードまたはフローログ - ベーシック ティアのダッシュボードを使用し、Azure>Insights>Containers>Networkingで確認します。

  

  

コンテナー ネットワーク ログ (オンデマンド)

• 使用対象: ライブ インシデント、断続的な問題、収集構成を変更しないアドホック調査。

• データ プレーン:Cilium のみ。

• ツール： ターミナルフィルタリング用の Hubble CLI。視覚的なサービス間マップ用の Hubble UI。

• 永続的ストレージなし、追加コストなし、ACNS を有効にした以外のセットアップはありません。

  

メトリックのフィルター処理 (Cilium クラスター)

ContainerNetworkMetric CRD を適用して、ノードごとにエクスポートする Hubble メトリックを制御します。 いくつかの重要な名前空間で広範な可観測性を必要とするが、それらのすべてに対して高カーディナリティ フロー シリーズの料金を支払いたくない場合に便利です。

一般的なパターン:

• DNS を保持し、メトリックをクラスター全体にドロップする。フロー メトリックを運用環境の名前空間に制限します。
• フロー メトリックから、 kube-system などの大量のシステム名前空間を除外します。
• テナントごとの名前空間を独自のフィルター ブロックにスコープします。

完全な CRD の例については、「 コンテナー ネットワーク メトリックのフィルター処理の構成」を参照してください。

ベスト プラクティス

• 開始範囲を広くし、狭くします。 数日間の広範なログ/メトリックを有効にし、実際に使用するものを確認してから、 ContainerNetworkLog と ContainerNetworkMetric フィルターを強化します。
• メトリックとログの時間枠を揃えておきます。 インシデントを調査する場合は、ダッシュボードと KQL クエリ全体で同じ開始時刻/終了時刻を使用して、シグナルが正確に関連付けられるようにします。
• 事前に構築されたダッシュボードを使用します。 最も一般的な質問について説明します。 カスタム パネルは通常、最初のトリアージを過ぎた後にのみ必要です。
• 必要に応 ContainerNetworkLogs 階層化します。 コスト重視のワークロードの Basic レベルに切り替えます。一致する Basic レベルのダッシュボードを使用します。 Log Analytics テーブル プランの詳細をご覧ください。
• 集計されたログとオンデマンド ログを補完として扱います。 集計されたログは傾向とパターンの検出に適していますが、フローごとの詳細はスキップされます。 詳細な検査にはオンデマンド (Hubble) を使用します。
• 問題が発生したのと同じパネルで修正プログラムを検証します。 変更後に同じパネルがフラットになった場合は、実際の修正があります。

よくある落とし穴

• ContainerNetworkLog CRD のことを忘れないようにする。 クラスターでコンテナー ネットワーク ログを有効にしても、トラフィックを選択する CRD を少なくとも 1 つ適用するまで、何も収集されません。
• 保存されたログをすでに発生したインシデントに使用しようとしています。 インシデントの前にログが有効になっていない場合、またはキャプチャされたフィルターの外側に落ちた場合は、次の発生のためにオンデマンドの Hubble フローに切り替えます。
• Cilium クラスター上の L7 ダッシュボードが空です。 L7 メトリックには、クラスターでの--acns-advanced-networkpolicies L7と、L7 規則を使用したCiliumNetworkPolicyの両方が必要です。 CCNP は L7 ルールをサポートしていません。 L7 ポリシーの適用を参照してください。
• Cilium の DNS メトリックが空です。 DNS の可視化には、CiliumNetworkPolicy に dns を設定する必要があります (通常は、toFQDNs と併用します)。 FQDN/DNS プロキシは ノード ローカル DNS または AKS ローカル DNS と互換性がありません — いずれかを実行すると、DNS プロキシングとそれに伴うメトリックが無効になります。 FQDN フィルタリングの制限事項を参照してください。
• matchPattern: "*" は、すべての DNS をブロックします。 単独のワイルドカードはサポートされていません。 *.example.comやapp*.example.comなどの先頭ワイルドカード パターンを使用します。 FQDN フィルタリング ポリシーの適用を参照してください。

Azure の監視に含まれるネットワーク監視機能

AKS クラスターで Prometheus についての Azure Monitor マネージド サービスを有効にすると、基本的なノード ネットワーク監視メトリックは、既定で networkobservabilityRetina ターゲットを介し収集されます。 これにより、次が提供されます。

• 基本的ノード レベルのネットワーク メトリック: ノード レベルでの基本的ネットワーク トラフィックの可視性
• 既定の Prometheus ターゲット: Azure Monitor によって自動的にスクレイピングされたネットワーク監視メトリック
• Azure Monitor の統合: Azure Monitor とのシームレスな統合では、メトリックが自動的に収集され、Grafana で視覚化されます
• 追加のセットアップは必要なし: Azure Monitor マネージドの Prometheus が構成されていれば自動的に有効になります
• Microsoft サポート: Azure Monitor と AKS の一部としてサポートされます

注: これには、AKS クラスターで Prometheus 用の Azure Monitor マネージド サービスを有効にする必要があり、関連コストが発生する場合があります。

使用開始: Azure portal または CLI を介し、AKS クラスターで Prometheus の Azure Monitor マネージド サービスを有効にします。 ネットワーク監視メトリックは自動的に収集され、Azure Managed Grafana での視覚化に使用できます。

Retina OSS を使用したネットワークの監視

アドバンスト コンテナー ネットワークサービス (ACNS) は、包括的なネットワーク監視機能を提供する有料オファリングですが、Microsoft では、重要なネットワーク監視機能を提供するオープン ソースのネットワーク監視プラットフォームである、Retina OSS を使用したネットワーク監視もサポートしています。

Retina OSS はオープンソースの監視プラットフォームで、retina.sh および GitHub で利用が可能です。 共有サービスには次のものが含まれています。

• eBPF ベースのネットワーク可観測性: eBPF テクノロジを使用して、最小限のオーバーヘッドで分析情報を収集します
• Kubernetes コンテキストを使用した詳細なトラフィック分析: 完全な Kubernetes 統合を使用した、ネットワーク トラフィック フローの包括的なキャプチャと分析
• 高度なメトリック収集: レイヤー 4 のメトリック、DNS メトリック、および分散パケット キャプチャ機能
• プラグインベースの拡張性: プラグイン アーキテクチャを使用して機能をカスタマイズおよび拡張します
• Prometheus 互換のメトリック: 構成可能なメトリック モードを含む Prometheus 形式で、包括的なネットワーク メトリックをエクスポートします
• 分散パケット キャプチャ: 詳細なトラブルシューティングを行う複数のノードにわたるオンデマンド パケット キャプチャ
• プラットフォームと CNI への依存なし: 任意の Kubernetes クラスター (AKS、Arc 対応、オンプレミス)、任意の OS (Linux/Windows)、および任意の CNI で動作します
• コミュニティサポート: コミュニティ主導のサポートとコントリビューションがあるオープンソース
• セルフマネージド: デプロイと構成を完全に制御します
• Hubble 統合: Cilium の Hubble と統合して、追加のネットワーク分析情報を獲得します

使用開始: 公式の Retina リポジトリから、Helm チャートまたは Kubernetes マニフェストを使用して、Retina OSS をデプロイします。 Prometheus と Grafana を設定してメトリックを視覚化し、Kubernetes コンテキストを使用して詳細なトラフィック分析を構成し、高度なトラブルシューティングのための分散パケット キャプチャを有効にし、特定のユース ケースに対しては、プラグイン ベースのアーキテクチャを使用して機能をカスタマイズします。

ネットワーク監視機能の比較

詳細情報

アドバンスト コンテナー ネットワーク サービス (ACNS)

• プラットフォームの概要:AKS 用の Advanced Container Networking Services とは
• 可観測性を設定する:コンテナー ネットワークの可観測性を設定する
• コンテナー ネットワーク メトリック:コンテナー ネットワーク メトリックの概要
• コンテナー ネットワーク ログ:コンテナー ネットワーク ログの概要 と コンテナー ネットワーク ログの設定
• メトリックのフィルター処理 (Cilium):コンテナー ネットワーク メトリックのフィルター処理を構成する

AI 駆動型診断

• Container Network Insights エージェント (プレビュー):エージェントの概要と設定
• AKS MCP サーバー:AKS モデル コンテキスト プロトコル サーバー

コンテナネットワークセキュリティ（Cilium）

• FQDN フィルタリング:概念 と FQDN フィルタリング ポリシーの適用
• レイヤー 7 ポリシー:概念 と L7 ポリシーの適用
• 相互 TLS (Cilium):概念と相互 TLS の構成
• 転送中の暗号化:WireGuard 暗号化の概念

データ プレーンとプラットフォーム

• Cilium によって駆動される Azure CNI:Cilium によって駆動される Azure CNI を構成する
• eBPF ホスト・ルーティング・パフォーマンス:eBPF ホスト・ルーティングを使用したコンテナー・ネットワーク・パフォーマンス
• Log Analytics テーブル プラン:データ使用量に基づいてテーブル プランを選択します

オープン ソース ツール

• Retina:retina.sh および Microsoft Retina GitHub リポジトリ
• Hubble (Cilium プロジェクト):Hubble のドキュメント