CNI（シーエヌアイ）

2025年11月6日

CNI（シーエヌアイ）

英語表記: CNI (Container Network Interface)

概要

CNI（Container Network Interface）は、コンテナオーケストレーションシステム、特にKubernetesにおいて、コンテナランタイムとネットワークプロバイダ（ネットワーク実装）を連携させるための標準規格（インターフェース）です。この標準規格があるおかげで、Kubernetesは特定のネットワーク技術に依存することなく、様々なベンダーのネットワークソリューション（プラグイン）を柔軟に利用できるようになります。CNIは、Kubernetesアーキテクチャの中でも特に「ストレージ/ネットワーク」という基盤部分において、各PodがユニークなIPアドレスを持ち、互いに通信できるというKubernetesのネットワークモデルを実現するための、まさに心臓部となる仕組みなのです。

詳細解説

目的と背景：なぜCNIが必要なのか

CNIが誕生した最大の目的は、コンテナランタイム（DockerやCRI-Oなど）とネットワーク実装（Calico, Flannel, Ciliumなど）の間で、共通の「会話のルール」を提供することです。Kubernetesのような大規模なオーケストレーションシステムでは、無数のコンテナが起動・停止を繰り返します。これらのコンテナ（KubernetesではPod単位）が互いに、あるいは外部と通信するためには、ネットワークの構成、IPアドレスの割り当て、ルーティングの設定といった複雑な作業を迅速かつ正確に行う必要があります。

CNI規格が存在しない場合、Kubernetesは特定のネットワーク技術に固定されてしまい、ネットワークの要件が変わるたびにシステム全体を大きく改修する必要が出てきます。CNIは、このネットワーク設定のプロセスを抽象化し、標準化することで、利用者が自由にネットワークソリューションを選択できる柔軟性を提供しています。これは、技術の進化が速いコンテナの世界において、非常に重要な役割を果たしていると言えるでしょう。

CNIの動作原理（Kubernetesとの連携）

Kubernetes環境において、CNIは主にノード上で動作するコンポーネントであるKubeletによって利用されます。この仕組みは、私たちが現在学んでいる「Kubernetes アーキテクチャ」の「ストレージ/ネットワーク」という文脈において、非常に重要です。

Podの起動要求: ユーザーがPodのデプロイを要求すると、Kubernetesのコントロールプレーン（Masterノード）がこれを承認し、Workerノード上のKubeletにPodの起動を指示します。
CNIの呼び出し: Kubeletは、コンテナランタイムを介してPodを起動する直前、ノードにインストールされているCNIプラグインを呼び出します。
IPアドレスの割り当て: CNIプラグインは、Pod内のコンテナにネットワーク接続を提供するために、以下の主要なタスクを実行します。
- Podに一意のIPアドレスを割り当てます。
- Podのネットワーク名前空間（ネットワークを分離する仕組み）に、仮想ネットワークインターフェース（Vethペアなど）を接続します。
- ノード内のルーティングテーブルやファイアウォール（iptablesなど）を設定し、他のPodや外部ネットワークとの通信経路を確保します。
通信の実現: これらの設定が完了することで、Kubernetesの標準的なネットワークモデル、すなわち「すべてのPodは、NATなしで他のすべてのPodと通信できる」という状態が実現されます。

このように、CNIはKubernetesのネットワーク層を「裏で支える縁の下の力持ち」であり、Kubernetesが複雑なネットワーク要件に対応できる秘密兵器なのです。

主要なコンポーネント：CNIプラグイン

CNI規格に基づいて実装された具体的なネットワークソリューションを「CNIプラグイン」と呼びます。Kubernetesの導入時には、このプラグインを選択・導入することが必須です。

ブリッジング（Bridge）プラグイン: ノード内のPod間通信を可能にする基本的なプラグインです。
ルーティング（Routing）プラグイン: ノードをまたいだ通信を実現するために、BGPなどのルーティングプロトコルを使用したり、オーバーレイネットワーク（トンネリング）技術を使用したりします。
- 代表的な例: Flannel（シンプルで広く使われる）、Calico（高度なネットワークポリシー機能を持つ）、Cilium（eBPFを活用し高性能なネットワークを提供する）など。

利用者は、これらのプラグインの中から、セキュリティ要件、パフォーマンス要件、あるいはクラウド環境の制約に応じて最適なものを選択します。この選択の自由度こそが、CNI規格の最大のメリットと言えるでしょう。

具体例・活用シーン

1. 異なるネットワークポリシーの適用

Kubernetesのクラスターを運用する際、開発環境と本番環境でセキュリティ要件が異なることはよくあります。

例えば、開発環境ではPod間の通信を比較的自由に許可したいが、本番環境では「ウェブサーバーPodはデータベースPodにしかアクセスできない」といった厳格な制限を設けたいとします。

このとき、CNIプラグインとしてCalicoのようなネットワークポリシー機能に特化したものを選択することで、KubernetesのNetwork Policyリソースを最大限に活用できます。KubeletがPodを起動する際、Calicoプラグインが呼び出され、PodにIPを割り当てるだけでなく、事前に定義されたセキュリティルールを即座に適用します。これにより、インフラストラクチャのレベルで強固なセキュリティを実現できるのです。

2. 配管工のアナロジー

CNIの役割を理解するための具体的な比喩を考えてみましょう。

Kubernetesクラスター全体を巨大な「集合住宅（アパート）」だと想像してください。この集合住宅には、無数の「部屋」（Pod）があり、それぞれの部屋には「蛇口」（ネットワークインターフェース）が必要です。

Kubeletは、新しい住人（Pod）が引っ越してくるたびに作業を行う「現場監督」です。
CNI規格は、この集合住宅全体で使われる「配管の設計図」です。この設計図があるからこそ、どのネットワーク会社（プラグイン）がきても、同じルールで配管工事ができます。
CNIプラグインは、実際に配管作業を行う「専門の配管工」です。

現場監督（Kubelet）が「新しい部屋（Pod）ができたよ」と指示を出すと、配管工（CNIプラグイン）が設計図（CNI規格）に従って、部屋（Pod）に水道管（IPアドレス）を引き込み、他の部屋や外の街路（外部ネットワーク）とつながるように複雑な配管（ルーティング）を一瞬で完了させます。

この「配管工」の役割を標準化しているのがCNIであり、これにより、Kubernetesはネットワーク構成の詳細を知らなくても、ただ「Podを起動せよ」と命令するだけで済むわけです。

資格試験向けチェックポイント

CNIは、応用情報技術者試験や基本情報技術者試験の午後問題、あるいはITパスポートのテクノロジ系知識において、コンテナ技術やクラウド技術の文脈で出題される可能性があります。特にKubernetes関連の出題が増えているため、以下のポイントを押さえておきましょう。

定義の理解: CNIは「Container Network Interface」の略であり、コンテナランタイムとネットワーク実装（プラグイン）の間で標準的なインターフェースを提供する役割であることを正確に理解してください。特定のネットワーク技術ではない、という点が重要です。
Kubernetesとの関連: CNIは、Kubernetesのネットワークモデル（全てのPodがユニークなIPを持ち、ルーティング可能であること）を実現するために必須のコンポーネントです。KubernetesのPodネットワーキングに関する設問が出た場合、CNIは必ず関連付けて考える必要があります。
柔軟性の確保: CNIの最大のメリットは、ネットワークの実装を自由に選択できる「ベンダー非依存性」や「拡張性」にある、という点を覚えておきましょう。
動作主体: CNIプラグインを呼び出すのは、主にKubernetesのWorkerノード上で動作するKubeletである、というプロセスを理解しておくと、より深い知識として評価されます。
具体例: FlannelやCalicoといった具体的なCNIプラグインの名称が選択肢として登場することがあります。これらが「Kubernetesのネットワーク機能を実現するツール」であることを把握しておきましょう。