Kubernetes の CNI は何を選ぶべきか – 設計思想と製品制約から現代的な選択肢を整理する

CNI 選定は機能一覧だけでは決められない

Kubernetes の CNI を選定する際、Cilium、Calico、OVN-Kubernetes、Antrea などの機能を一覧にして比較することがあります。一覧で整理すること自体に問題があるわけではありません。問題になるのは、対応機能の数を数え、その多寡によって CNI の優劣を決めようとすることです。

現在の CNI は、単に Pod へ IP アドレスを割り当て、ノード間でパケットを転送するだけのコンポーネントではありません。NetworkPolicy、Service の負荷分散、外部ネットワークとの経路交換、通信の可視化、暗号化、複数ネットワークなど、Kubernetes のネットワーク基盤をどこまで担当するかが製品ごとに異なります。

そのため、CNI の選定では、利用する Kubernetes 製品でどの CNI がサポートされているかを確認する段階と、選択可能な範囲の中でどのネットワークモデルを採用するかを決める段階を分ける必要があります。セルフホストの Kubernetes であれば設計思想から CNI を比較し、比較的自由に選択できます。一方、マネージド Kubernetes や特定の Kubernetes ディストリビューションでは、CNI が製品のネットワーク実装に組み込まれています。

段階	確認すること	判断の意味
第 1 段階	利用する Kubernetes 製品で、どの CNI がサポートされているか	ベンダーの責任分界、アップグレード、障害対応の範囲を確認する
第 2 段階	選択可能な範囲の中で、どのネットワークモデルを採用するか	要件に合うデータプレーン、経路制御、ポリシー、可視化を選ぶ

この場合、CNI の選定は純粋な技術比較ではなく、ベンダーのサポート範囲、アップグレード方式、障害時の責任分界を含む製品選定になります。

比較表が問題なのではなく、比較軸が問題になる

CNI を表で比較することには意味があります。ただし、表の目的を「高機能な製品を決めること」ではなく、「ネットワークモデルの違いを分類すること」に置く必要があります。主要な CNI を設計思想で分類すると、次のようになります。

CNI	中心となるネットワークモデル	主なデータプレーン
Cilium	eBPF によるネットワーク機能の統合	eBPF
Calico	IP ルーティングとネットワークポリシー	Linux ルーティング、BGP、eBPF
OVN-Kubernetes	論理スイッチと論理ルーターによる SDN	OVN、Open vSwitch
Antrea	Open vSwitch による Kubernetes ネットワーク	Open vSwitch
Kube-OVN	VPC と Subnet を中心とした仮想ネットワーク	OVN、Open vSwitch

この表は、機能数による順位付けではありません。たとえば、eBPF を利用できる CNI が、BGP を中心に構成する CNI より常に優れているわけではありません。既存の L3 ネットワークへ Pod の経路を広報したい環境と、Kubernetes 内部の Service 処理や通信可視化を eBPF へ統合したい環境では、適切なネットワークモデルが異なります。

CNI の比較で問うべきなのは、どの製品が最も多くの機能を持つかではなく、どの製品が要求するネットワークモデルを最も自然に実装できるかです。

CNI を選ぶ前に、そもそも選択できるかを確認する

CNI の設計思想を比較する前に、利用する Kubernetes 製品がどこまで CNI の変更を許容しているかを確認する必要があります。これは技術的にインストールできるかどうかだけの問題ではありません。ベンダーがサポートする構成であるか、アップグレード時に維持されるか、障害発生時に問い合わせ可能かという問題です。

Amazon EKS

Amazon EKS では、Amazon VPC CNI が標準のネットワークアドオンとして導入され、VPC の IP アドレスを Pod へ割り当てます。AWS のドキュメントでは、Amazon VPC CNI は各 EC2 ノードへ配置され、Pod へ VPC 内の IPv4 または IPv6 アドレスを割り当てると説明されています。また、互換性のある別の CNI は存在するものの、AWS インフラストラクチャ上で動作するノードに対して EKS がサポートする CNI は Amazon VPC CNI であると説明されています。参考: Amazon EKS Pod networking

したがって、EKS で Cilium や Calico が動作するという技術的事実だけを見て、Amazon VPC CNI と同列の選択肢として扱うことはできません。技術的に導入できることと、EKS がその構成全体をサポートすることは別です。代替 CNI を採用する場合は、コミュニティまたは別ベンダーからのサポートを確保するか、自組織で障害を解析できることが前提になります。

Google Kubernetes Engine

GKE Dataplane V2 は、GKE のネットワークデータプレーンとして提供される機能です。Google のドキュメントでは、新しい Autopilot クラスタでは一定バージョン以降 GKE Dataplane V2 が有効化され、Dataplane V2 では NetworkPolicy の強制が組み込まれるため、従来のように NetworkPolicy を別途有効化する扱いではないことが説明されています。参考: GKE Dataplane V2

GKE で Cilium 系の実装技術が使われているとしても、上流の Cilium をそのまま利用しているとは限りません。利用可能な機能、設定方法、バージョン、アップグレード時期は GKE の製品仕様によって管理されます。データプレーンの実装技術が同じであっても、運用上は GKE の製品機能として評価する必要があります。

Azure Kubernetes Service

AKS では、Azure CNI Powered by Cilium が提供されています。Microsoft のドキュメントでは、この構成は Azure CNI のコントロールプレーンと Cilium のデータプレーンを組み合わせ、高性能なネットワークとセキュリティを提供するものとして説明されています。AKS Automatic では Azure CNI Overlay powered by Cilium が標準の仮想ネットワークとして事前構成され、AKS Standard では構成を選択して作成できます。参考: Azure CNI Powered by Cilium

AKS 上で Cilium が使われていることと、セルフホスト環境で上流 Cilium を自由に構成することは同じではありません。Azure CNI との統合、対応する Kubernetes と Cilium のバージョン、サポートされる ConfigMap の変更範囲など、AKS 側の制約を含めて評価する必要があります。

OpenShift Container Platform

OpenShift Container Platform では、OVN-Kubernetes がクラスタネットワークの標準的な構成要素として組み込まれています。Red Hat のドキュメントでは、OVN-Kubernetes は OpenShift Container Platform のデフォルトネットワークプロバイダーであり、OVN と Open vSwitch を利用して Pod と Service の仮想ネットワークを実装すると説明されています。参考: OpenShift OVN-Kubernetes network plugin

OpenShift における CNI の判断は、クラスタ構築後に Cilium、Calico、OVN-Kubernetes を横並びにして選ぶ話ではありません。OpenShift を採用する時点で、OVN-Kubernetes を含む OpenShift のネットワークモデル、Operator によるライフサイクル管理、アップグレード、監視、Red Hat のサポート範囲をまとめて採用することになります。これは、技術的に別の CNI を動作させられるかという問題ではなく、製品としてサポートされる構成と責任分界の問題です。

技術的能力とサポート範囲は分けて評価する

CNI の上流プロジェクトが持つ機能と、Kubernetes 製品上で利用できる機能は同じとは限りません。ある CNI が上流では BGP、eBPF、暗号化、通信可視化に対応していても、マネージド Kubernetes 側では、設定可能なパラメーターが限定される、特定機能が公開されていない、CNI のバージョンを利用者が選べない、アップグレード時期をベンダーが管理する、上流のトラブルシューティング手順をそのまま適用できない、独自の IPAM やクラウドネットワークと統合されている、別の CNI へ変更するとベンダーサポート外になる、といった制約があり得ます。

これは技術的に優れた CNI を採用できないという話ではありません。CNI の能力が、製品のサポート境界によって包まれているということです。マネージド Kubernetes では、CNI 単体の優劣よりも、クラウドネットワークとの統合やベンダーサポートを含むシステム全体を評価する必要があります。

セルフホスト環境では設計思想から選択できる

セルフホストの Kubernetes や、CNI の選定を利用者に委ねるディストリビューションでは、ネットワークモデルから CNI を比較できます。ここで主要な選択肢になるのが、Cilium、Calico、OVN-Kubernetes、Antrea、Kube-OVN です。

Cilium – eBPF を共通のデータプレーンとして利用する

Cilium は、Linux カーネルの eBPF を使用して Pod 通信、NetworkPolicy、Service 負荷分散などを処理します。Cilium の eBPF 実装によって kube-proxy を置き換える構成も可能であり、Hubble を利用すると Cilium と eBPF が処理する通信フローを観測できます。参考: Cilium kube-proxy replacement / Hubble observability

Cilium の特徴は、ネットワーク機能を個別に追加するのではなく、eBPF を共通のデータプレーンとして統合していく点にあります。従来、Pod ネットワーク、Service 負荷分散、NetworkPolicy、通信可視化は、それぞれ異なる仕組みとして実装されることがありました。Cilium では、これらの処理を eBPF を中心としたデータプレーンへ統合します。

一方、障害解析では Linux のルーティングテーブルだけでなく、eBPF Program、eBPF Map、Cilium の Service 処理などを確認する必要があります。ネットワーク機能が統合されることと、内部構造が単純になることは同じではありません。機能を一つのデータプレーンへ集約すると、コンポーネント間の不整合は減らせる可能性がありますが、その代わりに運用担当者は eBPF と Cilium 固有の内部状態を理解する必要があります。

Calico – IP ルーティングとポリシーを中心に構成する

Calico は、IP ルーティングとネットワークポリシーを中心とした CNI です。Calico ノード間だけでなく、外部ルーターと BGP ピアを構成して Pod の経路を広報できます。オンプレミスでは、Pod を既存の L3 ネットワークから到達可能な IP エンドポイントとして扱う構成も可能です。参考: Calico BGP configuration

Calico は、VXLAN などを利用したオーバーレイ構成と、BGP や Linux ルーティングを利用する非オーバーレイ構成の両方を選択できます。また、従来の Linux データプレーンだけでなく eBPF データプレーンも提供しており、eBPF モードでは Calico が kube-proxy の機能を置き換えるため、Calico 公式ドキュメントでも kube-proxy を無効化する手順が示されています。参考: Calico eBPF data plane

したがって、「eBPF なら Cilium、BGP なら Calico」という単純な分類は正確ではありません。両者の差は対応技術の有無よりも、Cilium が eBPF を中心にネットワーク機能を統合するのに対し、Calico は IP ルーティングとポリシーを基礎に複数のデータプレーンを選択できる点にあります。既存ネットワークとの接続を経路制御として明確に管理したい場合は、Calico の設計思想が理解しやすいです。

OVN-Kubernetes – クラスタ内に論理ネットワークを構成する

OVN-Kubernetes は、OVN と Open vSwitch を使用して、Kubernetes 上に論理スイッチ、論理ルーター、ACL などのネットワーク機能を構成します。Cilium や Calico では Linux ホスト上のルーティングや eBPF を中心にデータプレーンを構成しますが、OVN-Kubernetes ではクラスタ全体に論理的な L2・L3 ネットワークを構成し、その論理ネットワークを各ノード上の Open vSwitch へ反映します。参考: OVN-Kubernetes architecture

アーキテクチャについては、古いバージョンの説明を現在の実装へそのまま適用しない注意が必要です。2026 年 7 月 15 日時点で公開されている上流ドキュメントでは、OVN-Kubernetes は Interconnect モードによる分散コントロールプレーンを使用し、デフォルトでは各ノードが個別の Zone になる構造として説明されています。過去の Central モードや、特定のディストリビューションに組み込まれた旧バージョンへ、この説明を無条件に当てはめるべきではありません。

OVN-Kubernetes は、個々の Linux ホストのルーティングだけを見るのではなく、クラスタ全体にどのような論理 L2・L3 ネットワークを構成するかという視点で評価する必要があります。

Antrea – Open vSwitch 上で通信とポリシーを処理する

Antrea は、Open vSwitch をデータプレーンとして利用し、Pod ネットワークと NetworkPolicy を実装します。OVN-Kubernetes と同じく Open vSwitch を利用しますが、両者のネットワークモデルは同一ではありません。OVN-Kubernetes は OVN による論理スイッチや論理ルーターを含む SDN を構成します。Antrea は、Kubernetes の Pod ネットワークとネットワークポリシーを Open vSwitch 上に実装する性格が強い製品です。

Antrea の特徴的な診断機能として Traceflow があります。Traceflow は、指定したパケットを Open vSwitch へ注入し、複数ノードにまたがる転送経路や、どの処理によってパケットが破棄されたかを追跡する機能です。単に機能名として Traceflow を挙げるのではなく、Open vSwitch 上の転送処理を Kubernetes リソースから追跡できることが、運用上の評価点になります。参考: Antrea Traceflow guide

Antrea は、Open vSwitch を利用しながら、OVN の論理ネットワーク全体を導入するのではなく、Kubernetes のネットワークとポリシーを比較的直接的に実装したい場合の選択肢です。

Kube-OVN – VPC と Subnet を Kubernetes リソースとして管理する

Kube-OVN も OVN と Open vSwitch を使用しますが、Subnet や VPC を中心にネットワークを管理する性格が強い CNI です。Kube-OVN 1.16 のドキュメントでは、Subnet をネットワークと IP 設定の基本単位として扱い、Namespace や Pod を Subnet へ割り当てます。参考: Kube-OVN Subnet

Kube-OVN は、Overlay ネットワーク、Underlay ネットワーク、VPC、Subnet、VLAN、固定 IP アドレス、EIP、SNAT、複数 NIC、Pod 単位の QoS などを提供します。QoS については、Pod 単位の最大帯域制限と、遅延やパケット損失を模擬する linux-netem に対応しています。現行ドキュメントでは、QoS は Pod 単位でのみサポートされ、Namespace 単位や Subnet 単位の QoS 制限はサポートされていないと説明されています。参考: Kube-OVN QoS

Kube-OVN は、Pod 間通信だけでなく、Kubernetes 上にクラウド基盤に近い仮想ネットワーク管理を持ち込みたい場合に適しています。たとえば、テナントごとに VPC を分離する、Subnet を Kubernetes リソースとして管理する、Pod や仮想マシンへ固定 IP アドレスを割り当てるといった要件です。一方、要求が標準的な Pod ネットワークと NetworkPolicy だけであれば、VPC や Subnet を含む管理モデルが過剰になる可能性があります。

主要 CNI の違いは対応機能の有無だけではない

各 CNI は、機能面では相互に重複しています。Cilium は BGP に対応しており、Calico も eBPF を利用できます。OVN-Kubernetes や Kube-OVN はいずれも OVN と Open vSwitch を使用します。そのため、個別機能の有無だけで分類すると、製品間の境界が曖昧になります。

CNI	機能が統合される中心
Cilium	eBPF を共通データプレーンとして機能を統合する
Calico	IP ルーティングとポリシーを基礎に構成する
OVN-Kubernetes	論理スイッチと論理ルーターをクラスタ全体に構成する
Antrea	Open vSwitch 上に Kubernetes の通信とポリシーを実装する
Kube-OVN	VPC と Subnet を中心に仮想ネットワークを管理する

たとえば、Cilium と Calico の双方が eBPF に対応していても、両者の設計思想が同じになるわけではありません。OVN-Kubernetes と Kube-OVN が同じ OVN を利用していても、Kubernetes 上で提供するネットワーク管理モデルは異なります。製品比較では、機能名だけでなく、どのモデルを中心として機能が統合されているかを見る必要があります。

Multus と SR-IOV を分けて考える理由

CNI の選定は、プライマリーネットワークだけを決めれば必ず完了するわけではありません。Pod へ複数のネットワークインターフェースを持たせる場合、クラスタ標準ネットワークと、ワークロード固有の追加ネットワークを分けて設計する必要があります。

Multus は複数の CNI を呼び出すメタプラグインであり、Pod へ複数のネットワークインターフェースを付与します。通常の eth0 をプライマリー CNI で構成し、追加インターフェースを macvlan、ipvlan、SR-IOV CNI などで構成できます。参考: Multus CNI

ネットワーク	担当するもの	主な例
プライマリー CNI	Kubernetes 標準ネットワーク	Cilium、Calico、OVN-Kubernetes
Multus 配下のセカンダリー CNI	ワークロード固有の追加ネットワーク	SR-IOV CNI、macvlan、ipvlan

この節がプライマリー CNI の比較に必要なのは、複数 NIC を利用する環境では、Cilium か Calico かという比較だけではネットワーク設計が完結しないためです。プライマリー CNI は、Kubernetes API、Service、クラスタ内部通信などの標準ネットワークを担当します。Multus を介した追加 CNI は、ワークロード固有のデータネットワークを担当します。

通信事業者向けの CNF や、高速なパケット処理を行うワークロードでは、管理ネットワークとデータネットワークを分離することがあります。その場合、プライマリー CNI は Kubernetes として必要な管理通信を提供し、SR-IOV CNI などが物理 NIC の VF を Pod へ割り当てます。Multus や SR-IOV CNI は、Cilium や Calico の代替ではありません。CNI 選定の問題を、プライマリーネットワークと追加ネットワークの二層へ分けるためのコンポーネントです。

Flannel は最小構成の補足的な選択肢になる

Flannel は、ノードごとにサブネットを割り当て、VXLAN などを利用してノード間に L3 ネットワークを構成する、単純なネットワークファブリックです。現在でも、小規模な検証環境や、Kubernetes ディストリビューションが標準で Flannel を組み込んでいる環境では合理的な選択肢です。参考: Flannel

たとえば、CNI 自体を評価するのではなく、Kubernetes の基本動作やアプリケーションのデプロイを確認するだけであれば、Flannel の単純さは利点になります。ただし、現代的な CNI 選定の中心的な論点は、Flannel が使用できるかどうかではありません。NetworkPolicy、Service 処理、経路制御、可視化などを含むネットワーク基盤を、どの設計思想で構成するかです。

Flannel が担う基本的な Pod 間通信は、Cilium、Calico、OVN-Kubernetes なども提供しています。その上で、各 CNI はポリシー、ルーティング、可視化、Service 処理などを統合しています。そのため Flannel は、主要な設計モデルを比較した後に、要件を最小限に限定する場合の補足的な選択肢として扱うのが妥当です。

CNI 選定では四つの順序を崩さない

CNI を選定する際は、製品とサポート境界、ネットワークモデル、追加ネットワーク、障害解析とライフサイクルの順に整理すると判断しやすくなります。

1. 製品とサポート境界を確認する

最初に、利用する Kubernetes 製品でサポートされる CNI を確認します。マネージド Kubernetes や OpenShift では、この時点で候補が大きく絞られます。技術的にインストール可能であることを、製品として採用可能であることと混同してはいけません。

• ベンダーがサポートする CNI
• サポート対象となる構成
• CNI のバージョン管理主体
• アップグレード方法
• 障害発生時の責任分界
• 代替 CNI を導入した場合のサポート範囲

2. ネットワークモデルを決める

選択余地がある場合は、要求するネットワークモデルを定義します。ここでも、製品の優劣ではなく、設計モデルの分類として整理します。

要求するモデル	主な候補
eBPF へネットワーク機能を統合する	Cilium
IP ルーティングと BGP を中心に構成する	Calico
論理スイッチと論理ルーターを構成する	OVN-Kubernetes
Open vSwitch 上で通信とポリシーを処理する	Antrea
VPC と Subnet を Kubernetes リソースとして管理する	Kube-OVN

ネットワークモデルを決める際には、Overlay か Underlay か、Pod CIDR を外部へ広報するか、BGP を利用するか、kube-proxy を利用するか、eBPF へ Service 処理を統合するか、論理 L2・L3 ネットワークを必要とするか、テナントごとの VPC や Subnet を必要とするか、NetworkPolicy をどの範囲まで利用するか、通信フローをどの粒度で可視化するかを整理します。

3. 追加ネットワークの有無を確認する

複数 NIC、SR-IOV、macvlan、物理ネットワークへの直接接続が必要であれば、プライマリー CNI とは別に Multus とセカンダリー CNI を設計します。このとき、標準ネットワークと追加ネットワークの責任を混在させないことが重要です。

ネットワーク	主な用途
プライマリーネットワーク	Kubernetes API、Service、監視、管理通信
セカンダリーネットワーク	データ通信、物理ネットワーク接続、高速パケット処理

IP アドレス管理についても、プライマリー CNI とセカンダリー CNI で別々に考える必要があります。

4. 障害解析とライフサイクルを確認する

最後に、運用担当者がどのレイヤーまで解析できるかを確認します。高機能な CNI を導入しても、障害時に内部状態を確認できなければ、ネットワーク基盤として運用できません。

データプレーン	主な解析対象
Linux ルーティング	Route、Neighbor、iptables、nftables
eBPF	eBPF Program、Map、Hook、CNI 固有状態
Open vSwitch	Bridge、Port、Flow、OpenFlow
OVN	Logical Switch、Logical Router、Northbound DB、Southbound DB、OVS Flow
SR-IOV	PF、VF、PCI、Device Plugin、Pod 内ドライバー

また、CNI は Kubernetes 本体と独立して更新できる場合がある一方、Kubernetes のバージョンや Linux カーネル、コンテナランタイムとの互換性にも影響されます。選定時には、導入時の機能だけでなく、Kubernetes との互換性、Linux カーネル要件、アップグレード経路、設定変更時の影響、切り戻し方法、バックアップ対象、障害解析手順、ベンダーまたはコミュニティのサポート期間も確認する必要があります。

まとめ

現代の CNI 選定では、最初から Cilium、Calico、OVN-Kubernetes などを横並びにして比較するべきではありません。最初に確認するべきなのは、利用する Kubernetes 製品でどこまで CNI を選択できるかです。EKS、GKE、AKS、OpenShift では、CNI がクラウドネットワーク、Operator、アップグレード、監視、サポートと統合されています。この場合、CNI の技術的能力だけでなく、ベンダーがどの構成を製品として維持するかが選定条件になります。

セルフホスト環境で選択余地がある場合には、各 CNI の設計思想から比較できます。Cilium は eBPF を共通のデータプレーンとしてネットワーク機能を統合し、Calico は IP ルーティングとネットワークポリシーを中心に構成します。OVN-Kubernetes は論理スイッチと論理ルーターによる SDN を構成し、Antrea は Open vSwitch 上に Kubernetes の通信とポリシーを実装します。Kube-OVN は VPC と Subnet を中心に仮想ネットワークを管理します。

さらに、複数 NIC や SR-IOV を利用する場合は、プライマリー CNI と Multus 配下の追加ネットワークを分離して設計します。Flannel も最小構成の選択肢として残っていますが、現代的な CNI 選定における中心的な比較対象ではありません。

CNI の選定で決めるものは、単なる Pod の転送方式ではありません。どのネットワークモデルを採用するか、どこまでを CNI の責任範囲にするか、どこまでをベンダーの製品仕様に委ねるかを定義した結果として、採用する CNI が決まります。

参考資料

• Amazon EKS – Assign IPs to Pods with the Amazon VPC CNI
• Google Cloud – Using GKE Dataplane V2
• Microsoft Learn – Azure CNI Powered by Cilium
• Red Hat Documentation – OVN-Kubernetes network plugin
• Cilium – kube-proxy replacement
• Cilium – Hubble observability
• Calico – BGP configuration
• Calico – eBPF data plane
• OVN-Kubernetes architecture
• Antrea Traceflow guide
• Kube-OVN Subnet
• Kube-OVN QoS
• Multus CNI
• Flannel