# Pod単位ネットワークトラフィック計測 ## 定義 Pod単位ネットワークトラフィック計測は、KubernetesクラスタのPodごとにネットワーク送受信量を記録し、通信相手の種類や方向別にメトリクスとして出力する計装方式である。クラスタ内の帯域占有を引き起こしたPodを特定するには、Node単位やPod全体の合算ではなく、Podと通信相手の対応を残す必要がある。Preferred Networksの記事では、Pod・Service・クラスタ外の3分類、Ingress/Egressの2方向、eBPF Mapによるカーネル内集約を組み合わせている。([[@2024__Preferred Networks__eBPFを用いてPod ごとのインターネットトラフィック量を計測するツールの開発]]) ## 設計パターン ### 通信相手の適切な集約粒度 個別の通信相手やIPアドレスをすべてキーにすると、Mapのエントリ数とメトリクスのカーディナリティが増える。記事の実装は、原因特定に必要な粒度をPod・Service・クラスタ外に限定し、通信相手の詳細な列挙を避ける。これは「何を計測するか」を先に定め、不要な観測データを生成しない設計である。 ### CNIを差し込み点として使う Chained CNI PluginはPod生成時に呼び出され、ネットワークネームスペースとインターフェイス名を受け取る。これを利用してPodのインターフェイスへTCのeBPFプログラムをアタッチする。CNIの接続性実装そのものを変更せず、計装を後段のPluginとして追加できる点が特徴である。 ### カーネル内集約とユーザー空間出力の分離 パケットごとのイベントをユーザー空間へ転送する代わりに、eBPFプログラムがPodごとのMapへバイト数を加算する。ユーザー空間のDaemonSetはPinningされたMapを周期的に読み出し、OpenTelemetryまたはPrometheus形式で出力する。高頻度のパケット処理と、長寿命のメトリクス公開を分離する構成である。 ### IngressとEgressの両方向計測 XDPは受信側の早期フックとして有効だが、記事の要件である送受信両方向の計測にはTCを用いる。Ingress用とEgress用に別の`BPF_MAP_TYPE_PERCPU_ARRAY`を用意し、キーをPod・Service・Otherに対応させる。per-CPU配列によってCPU間の更新競合を避け、パケットサイズを直接加算できる。 ## 横断的知見 - **カーネル内集約の設計原則が、通信グラフ構築とPodの帯域原因特定で共通する**: [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]]は、`sock_sendmsg`/`sock_recvmsg`をeBPFで計装し、カーネル内のバイトカウンタを閾値超過時だけユーザー空間へ転送するKernelAggで、重み付きコンテナ通信グラフを構築した。一方、本ソースはパケット処理時にPod・Service・クラスタ外へ集約し、DaemonSetが周期的にMapを読む。前者はソケット単位、後者はPodインターフェイス単位という計測点の違いはあるが、高頻度イベントをカーネル内で小さな集約値へ変換してから転送する構造は共通する。([[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]], [[@2024__Preferred Networks__eBPFを用いてPod ごとのインターネットトラフィック量を計測するツールの開発]]) - **「接続を発見する計測」と「帯域占有を帰属する計測」は補完関係にある**: [[ネットワーク依存性発見]]がサービス間の依存関係や通信グラフを構築するのに対し、本ソースはPodごとの方向別バイト数を出力し、特定テナントによるクラスタ外帯域の占有を原因Podへ帰属する。接続先の構造を知る計測と、転送量の大きさを知る計測は異なるため、両方を組み合わせると「誰と通信しているか」と「どれだけ帯域を使っているか」を同時に扱える。([[@2022__IPSJ JIP__Low Overhead TCP-UDP Socket-based Tracing for Discovering Network Services Dependencies]], [[@2024__Preferred Networks__eBPFを用いてPod ごとのインターネットトラフィック量を計測するツールの開発]]) - **Node NATは観測点を上流へ移すほどPod帰属情報を失わせる**: 上流ルーターではインターネットアクセス量を測れるが、NodeでNATされた後は送信元Nodeまでしか復元できない。本ソースはPodのネットワークインターフェイスへ計装を置くことで、NAT前のPod識別子と外部通信量を対応づける。これはネットワーク監視で「実際のトラフィックパス」を見る[[@2026__NSDI__Harp - Improving VPC Network Availability via Efficient Failure Detection and Rerouting in Tencent Cloud|Harp]]や、ネットワーク層とホスト層を融合する[[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks|INTFusion]]とは異なるが、観測点をどこに置くかが得られる属性を決めるという共通の設計問題を示す。([[@2024__Preferred Networks__eBPFを用いてPod ごとのインターネットトラフィック量を計測するツールの開発]], [[@2026__NSDI__Harp - Improving VPC Network Availability via Efficient Failure Detection and Rerouting in Tencent Cloud]], [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]]) - **CNI非依存性は完全な実装非依存ではなく、標準的なアタッチ点への依存である**: 本ソースは特定CNI Pluginの機能に依存せず、Chained CNI Pluginという標準の呼び出し機構とPodインターフェイスを利用する。一方、[[Container Network Interface (CNI)]]が整理するCiliumのeBPF datapathは、CNI自体が転送・フィルタリングを担う方式である。本ソースの計装は既存datapathを置き換えずに観測を追加するため、CNI選択の自由度を保ちやすいが、TCフック、ネットワークネームスペース、`/sys/fs/bpf`のマウントといったLinux実装条件には依存する。([[@2024__Preferred Networks__eBPFを用いてPod ごとのインターネットトラフィック量を計測するツールの開発]], [[@2021__TNSM__Assessing Container Network Interface Plugins - Functionality, Performance, and Scalability]]) - **帯域占有の原因特定は、コンテナ配置最適化とは異なる向きの利用である**: [[コンテナ配置最適化]]は通信量からPod・コンテナを近接配置してネットワークコストを下げるが、本ソースは同じような粒度の通信量を外部帯域の公平な共有と原因特定に使う。つまり、Pod単位のバイト数は「配置を変えるための重み付きグラフ」と「現在のテナント間競合を診断するメトリクス」の両方に転用できる。([[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]], [[@2024__Preferred Networks__eBPFを用いてPod ごとのインターネットトラフィック量を計測するツールの開発]]) - **粒度の削減は、精度の削減ではなく原因帰属に必要な情報の選択である**: cAdvisorのPod全体合算は通信相手の分類を失い、上流ルーターの計測はPod識別子を失う。本ソースは個別IPを保持せずに3分類へまとめることで、帯域占有の原因Podを特定する目的を満たす。[[eBPF]]・[[eBPFマップ]]が示す「情報を最上流で絞る」設計原則を、Kubernetesのメトリクスカーディナリティ削減と原因帰属へ具体化した例である。([[@2024__Preferred Networks__eBPFを用いてPod ごとのインターネットトラフィック量を計測するツールの開発]]) ## 未解決の問い - IPv4以外のIPv6トラフィック、カプセル化、フラグメント化、オフロード済みパケットを同じ分類方式で正確に集計できるか。 - PodごとのMapを多数のPodへ作成したとき、Map数、Pinningされた疑似ファイル数、DaemonSetの周期読み出しコストがどのように増えるか。 - Podの終了・再作成、Namespaceの削除、Node再起動時に、PinningされたMapを確実に回収し、Pod名の再利用による古い値の混入を防げるか。 - `BPF_MAP_TYPE_PERCPU_ARRAY`の各CPU値をユーザー空間で合算する際、読み出しの途中に更新された値をどの程度の一貫性で扱うべきか。 - TCの既存プログラムやCNI datapathと共存する際、フック順序、再アタッチ、ネットワークネームスペースのライフサイクルをどう保証するか。 - PrometheusのラベルにPod UIDやPod名を付けることによる系列チャーンを、Podの短命性が高いクラスタでどう抑えるか。[[Prometheusシリーズチャーン]]や[[マテリアライズドメトリクス]]との接続を調べる必要がある。 - Pod・Service・クラスタ外という3分類だけで、外部サービス別のコスト配賦、許可されていない通信の検知、ネットワークポリシー違反の調査まで対応できるか。 - 本ソースの計測値を、[[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks|INTFusion]]のネットワーク層テレメトリや[[ネットワーク依存性発見]]のサービスグラフと統合し、Pod・経路・通信相手の3階層を同一の時系列で照合できるか。 ## 関連 - ソース: [[@2024__Preferred Networks__eBPFを用いてPod ごとのインターネットトラフィック量を計測するツールの開発]] / [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]] / [[@2022__IPSJ JIP__Low Overhead TCP-UDP Socket-based Tracing for Discovering Network Services Dependencies]] - 概念: [[eBPF]] / [[eBPFマップ]] / [[Container Network Interface (CNI)]] / [[ネットワーク監視]] / [[ネットワーク依存性発見]] / [[コンテナ配置最適化]] / [[Prometheusシリーズチャーン]] - エンティティ: [[Kubernetes]] / [[Preferred Networks]] / [[OpenTelemetry]] / [[Prometheus]] / [[Cilium]] ## 出典 - [[@2024__Preferred Networks__eBPFを用いてPod ごとのインターネットトラフィック量を計測するツールの開発]] — Pod・Service・クラスタ外の3分類、TC/eBPF Map、Chained CNI Plugin、Pinning、OpenTelemetry/Prometheus出力、検証結果。 - [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]] — eBPFによるカーネル内バイト集約と重み付きコンテナ通信グラフ。 - [[@2022__IPSJ JIP__Low Overhead TCP-UDP Socket-based Tracing for Discovering Network Services Dependencies]] — サービス依存関係発見のためのカーネル内フロー集約。 - [[@2021__TNSM__Assessing Container Network Interface Plugins - Functionality, Performance, and Scalability]] — CNIの分類とCilium eBPF datapath。 - [[@2026__NSDI__Harp - Improving VPC Network Availability via Efficient Failure Detection and Rerouting in Tencent Cloud]] — 実トラフィック経路を利用するインバンドネットワーク監視。 - [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]] — ネットワーク層とホスト層テレメトリの融合。