# Container Network Interface (CNI) ## 定義 Container Network Interface(CNI)は CoreOS が提案し Cloud Native Computing Foundation(CNCF)が標準化したコンテナネットワーキング仕様で、CHECK・ADD・DELETE・VERSION という単純なインタフェースでコンテナのネットワークへの追加・削除を行う。Kubernetes・Cloud Foundry・Mesos 等、複数のコンテナランタイムから利用可能な業界標準であり、Docker 専用の Container Network Model(CNM)とはこの汎用性の点で異なる。CNI プラグインは実行可能ファイルとして実装され、コンテナランタイムから呼び出されて IP Address Management(IPAM)・ネットワークインタフェース設定・route/iptables 設定・ネットワークポリシー適用を担う。(Source: [[@2021__TNSM__Assessing Container Network Interface Plugins - Functionality, Performance, and Scalability]]) ## 横断的知見 - **CNI の実装設計は「通信レイヤー(L2/L3/Hybrid)」×「転送方式(overlay/underlay)」の 2 軸で 4 クラスに整理できる**: [[@2021__TNSM__Assessing Container Network Interface Plugins - Functionality, Performance, and Scalability]] は Flannel・Weave・Cilium・Calico・Kube-router という代表的な CNI プラグインの実装を、Layer-3+Overlay(Calico・Cilium overlay)・Layer-3+Underlay(Calico・Cilium underlay)・Hybrid+Overlay(Flannel・Weave・Kube-router)・Hybrid+Underlay(Flannel・Kube-router)の 4 クラスに分類する。この分類軸は、CNI の性能・スケーラビリティを議論する際の共通の語彙になっており、他の CNI(Antrea・Multus 等)を評価する際にも同じ軸で位置づけられる可能性が高い。 - **eBPF ベースの CNI(Cilium)は intra-host で iptables/Netfilter 処理を完全に迂回でき、これが性能優位の直接的な原因になる**: Cilium は veth にアタッチした eBPF プログラム(XDP・TC ingress/egress フック)でパケット転送とフィルタリングを一体化するため、intra-host の iptables チェーン数は 0(他 CNI は 3 チェーン/5 ルール)。この「iptables 迂回」は [[eBPF]] 概念が繰り返し観察してきた「情報を最上流(カーネル)で絞る」設計指針の、ネットワーキング領域における具体例である。ただし inter-host では overlay 処理のための追加フックポイントが必要になり、eBPF オーバーヘッドが 189→236 CPP に増加する(それでも他 CNI の Netfilter オーバーヘッドより低い)。 - **ネットワークポリシーの粒度と性能はトレードオフの関係にある**: Calico のネットワークポリシー有効モード(Calico-wp)は既定で 17 の追加 iptables ルールを持ち、intra-host の Netfilter オーバーヘッドを 324 CPP(他 CNI の 1.35 倍)に押し上げる。inter-host では Calico-wp-ipip が 749 CPP という全 CNI 中最大の Netfilter オーバーヘッドを記録する。CNI 選定は「きめ細かいセキュリティポリシー」と「パケット転送性能」のトレードオフとして捉える必要がある。 - **NIC のトンネルオフロード対応が overlay CNI の実効性能を決定づける、見落とされやすいハードウェア要因である**: 同じ IP-in-IP overlay でも、トンネルオフロード非対応の NIC(Mellanox ConnectX-4 25Gb)ではスループットが対応 NIC(Intel X520-DA2 10Gb)比で大幅に低下する。CNI の性能比較をソフトウェア実装の差異だけで説明するのは不十分で、クラスタの NIC 世代・機能対応状況を合わせて評価する必要がある。 - **native routing(underlay)は overlay よりスケーラビリティに優れる**: inter-host スループット・HTTP 大規模並行接続・背景トラフィック負荷耐性のいずれにおいても、native IP routing ベースの CNI(Kube-router、Calico underlay モード)が overlay ベースの CNI より一貫して高性能を維持する。overlay のカプセル化/デカプセル化オーバーヘッドは、負荷が高まるほど無視できなくなる。 ## 未解決の問い - 本 concept は 2021 年時点(カーネル 4.15、TNSM 論文)の CNI 実装知見に基づく。その後の eBPF/XDP の進化(Cilium の cluster mesh・Kube-proxy replacement 等)や、Antrea・Multus といった他の CNI がこの 4 分類軸・性能トレードオフにどう当てはまるかは未検証。 - Kubernetes 自体のネットワークモデル要件(NAT なし Pod 間通信、host-to-Pod 到達性)を満たしつつ、eBPF ネイティブな intra-host 処理と native routing な inter-host 処理を組み合わせた「理想の CNI」([[@2021__TNSM__Assessing Container Network Interface Plugins - Functionality, Performance, and Scalability]] の提案)を実際に実装した CNI(Cilium の native routing モード等)は、この論文の実測値と一致する性能改善を示すか。 - Netfilter オーバーヘッドの根本原因である iptables のチェーン走査を eBPF ベースの iptables 実装([34], [[eBPF]] 参照)に置き換えた場合、ネットワークポリシーの表現力と性能の両立はどこまで達成できるか。 ## 関連 - ソース: [[@2021__TNSM__Assessing Container Network Interface Plugins - Functionality, Performance, and Scalability]] - 概念: [[eBPF]] / [[コンテナネットワーク分離]] - エンティティ: [[Shixiong Qi]] / [[Sameer G. Kulkarni]] / [[K. K. Ramakrishnan]] / [[University of California, Riverside]] / [[Indian Institute of Technology, Gandhinagar]] ## 出典 - [[@2021__TNSM__Assessing Container Network Interface Plugins - Functionality, Performance, and Scalability]](Flannel・Weave・Cilium・Calico(4 モード)・Kube-router のカーネルレベル CPU サイクル分解。4 分類のネットワークモデル、Netfilter/eBPF/トンネルオフロードのオーバーヘッド分析)