先週、CNCF（Cloud Native Computing Foundation）は、第10回オープンソースプロジェクトであるCNI（Container Networking Interface）の採用を発表しました。 そのタスクは、Linuxコンテナのネットワークインターフェイスの標準化された管理とネットワーク機能の柔軟な拡張に必要なすべてを提供することです。 CNCFは、コンテナ化されたアプリケーションを実稼働環境で積極的に配布することでこのようなプロジェクトの必要性を説明し、「Kubernetesが開発者が数千台のマシンで大量のコンテナを起動できるように、これらのコンテナには大規模なネットワーク管理（および実装フレームワーク）が必要である」と主張しています。
CNIはどのようにして生まれ、何を提供しますか？
CNIの背景
Container Network Interface（CNI）プロジェクトは、rktコンテナエンジン（最近ではcontainerdとともにCNCFにも転送されました）、NoSQLリポジトリetcd、Kubernetesおよびその他のオープンソースコンテナ関連プロジェクトで知られているCoreOSで始まりました。およびDevOps。 CNIの最初の詳細なデモは2015年の終わりに行われました（ 10月のビデオ 、11月のプレゼンテーションを参照）。 当初から、このプロジェクトは「Linuxコンテナのネットワークインターフェイスを構成するための標準案」として位置付けられており、もちろん、最初にrktで使用を開始しました。 CNIの最初の「サードパーティユーザー」はProject Calico、Weaveworks、Kubernetesがすぐに参加しました。
KubernetesプラットフォームでのCNI適応は、一見の価値があります。 Linuxコンテナのネットワーク構成を標準化する必要性は、その時点（2015年）で明らかであり、ますます重要になったため、CNIだけがそのようなプロジェクトではありませんでした。 競合製品である同じ2015年に導入されたDockerのContainer Network Model（CNM）は、同じ問題を解決し、libcontainerおよびDocker Engineのネットワークコードから成長したライブラリであるlibnetworkの形式で参照実装を取得しました。 そして、CNIとCNMの対立における重要なステップは、Kubernetesによる選択でした。 「 Kubernetesがlibnetworkを使用しないのはなぜですか？」 「 （2016年1月）、開発者はソリューションを説明するすべての技術的およびその他の理由を詳細に説明します。 主なポイント（多くの技術的なポイントに加えて）は次のとおりです。
CNIは哲学的な観点からKubernetesに近いです。 それはCNMよりもはるかに単純で、デーモンを必要とせず、そのクロスプラットフォームは少なくとももっともらしい（CoreOS rktコンテナーランタイムがサポートしています） [...そしてKubernetesは異なるコンテナー実装をサポートすることを目指しています- perev。 ] 。 クロスプラットフォームであるということは、異なるランタイム環境（つまり、Docker、Rocket、Hyper）で等しく機能するネットワーク構成を使用できることを意味します。 このアプローチは、1つのことをうまく行うというUNIXの哲学に従っています。
どうやら、これはまさに（Kubernetesの選択だけでなく、既存の実装に関する技術専門家のサードパーティの見解でもある）CNIの将来とCNCFでの採用を事前に決定したものです。 比較のために、他の競合するCoreOSおよびDocker製品：rktおよびconatinerdコンテナーランタイムが同時にファンドに受け入れられましたが、これはCNI / CNMでは発生しませんでした。
Calicoプロジェクトは2016年3月にコンテナネットワークを調査します
2016年9月現在のCNIとCNMの追加の比較は、 The New Stackに関する英語の記事にも記載されています。
CNIデバイス
CNIの作成者は、可能な限り最小の仕様を作成しました。その目的は、コンテナー実行可能環境とプラグインの間の簡単なレイヤーになることです。 必要なネットワーク機能はすべてプラグインで実装され、その相互作用はJSON形式のスキームによって決定されます。
CNIは3つの部分で構成されています。
1.コンテナのランタイムとネットワークプラグインの間のAPIを定義する仕様 （ GitHubを参照 ）：必要なサポートされる操作（ネットワークへのコンテナの追加とそこからの削除）、パラメータのリスト、ネットワーク構成の形式とそのリスト（JSONに保存）、および既知の構造（IPアドレス、ルート、DNSサーバー）。
CNIのネットワーク構成の例：
{ "cniVersion": "0.3.1", "name": "dbnet", "type": "bridge", "bridge": "cni0", "ipam": { "type": "host-local", "subnet": "10.1.0.0/16", "gateway": "10.1.0.1" }, "dns": { "nameservers": [ "10.1.0.1" ] } }
2.さまざまな状況にネットワーク構成を提供し、CNI仕様への準拠の例として役立つ公式プラグイン 。 containernetworking / pluginsで利用可能で、4つのカテゴリに分かれています：メイン（ループバック、ブリッジ、ptp、vlan、ipvlan、macvlan）、ipam（dhcp、ホストローカル）、meta（フランネル、チューニング）、サンプル。 すべてGoで書かれています。 （サードパーティのプラグインについては、記事の次のセクションを参照してください。）
3.コンテナ実行可能ファイルで便利に使用できるように、CNI仕様（Go言語でも）の実装を提供するライブラリ （ libcni ）。
利用可能なすべてのコード（および仕様）は、無料のApache License v2.0で公開されています。
高速トライCNI
コンテナなしでCNIにタッチできます。 これを行うには、プロジェクトリポジトリ（およびオプションで必要なプラグイン）から
./build.sh
ダウンロードし、。/
./build.sh
からそれらを
./build.sh
（またはバイナリアセンブリを既にダウンロード）してから、プラグイン実行可能ファイル（たとえば、。
./bin/bridge
）を使用します）、環境変数
CNI_*
、およびネットワーク構成を通じて機能するために必要な引数を渡す
CNI_*
を介してJSONデータで直接（CNI仕様で提供）。
このような実験の詳細については、 この記事を参照してください 。著者は、次のようなことをしています（Ubuntuのホスト上で）。
$ cat > mybridge.conf <<"EOF" { "cniVersion": "0.2.0", "name": "mybridge", "type": "bridge", "bridge": "cni_bridge0", "isGateway": true, "ipMasq": true, "ipam": { "type": "host-local", "subnet": "10.15.20.0/24", "routes": [ { "dst": "0.0.0.0/0" }, { "dst": "1.1.1.1/32", "gw":"10.15.20.1"} ] } } EOF $ sudo ip netns add 1234567890 $ sudo CNI_COMMAND=ADD CNI_CONTAINERID=1234567890 \ CNI_NETNS=/var/run/netns/1234567890 CNI_IFNAME=eth12 \ CNI_PATH=`pwd` ./bridge <mybridge.conf $ ifconfig cni_bridge0 Link encap:Ethernet HWaddr 0a:58:0a:0f:14:01 inet addr:10.15.20.1 Bcast:0.0.0.0 Mask:255.255.255.0 inet6 addr: fe80::3cd5:6cff:fef9:9066/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:536 (536.0 B) TX bytes:648 (648.0 B) …
CNIおよびネットワークプラグインのクイックスタートのその他の例は、 READMEプロジェクトにあります （「CNIの使用方法」セクション）。
CNIのサードパーティプラグイン
もちろん、CNIの主な価値の1つは、Linuxコンテナのさまざまな最新ソリューションのサポートを提供するサードパーティのプラグインです。 それらの中には：
- Project Calico （オーケストレーションツールおよびクラウドプラットフォームと統合されたL3仮想ネットワーク）;
- Weave （マルチホストDockerインストール用のシンプルなネットワーク）;
- Contiv Netplugin （ポリシー/ ACL / QoS、およびマルチホストクラスターインストールのコンテナーのその他の機能）;
- フランネル （CoreOSのコンテナーのネットワークファクトリー）;
- SR-IOV 、 Cilium （BPF / XDP）、 Multus （IntelのKubernetes用マルチプラグイン）、 VMware NSXなど...
残念ながら、それらのカタログや絶えず更新されたリストはありませんが、これは、CNIの現在の分布の一般的な考えにとって十分なはずです。
プロジェクトの成熟度の追加指標は、コンテナの既存の実行可能環境への統合：rktおよびKurma、およびコンテナを操作するプラットフォーム：Kubernetes、OpenShift、Cloud Foundry、Mesosです。
おわりに
CNIの現在の状況により、プロジェクトの「大きな見通し」だけでなく、その実用的な適用性の具体的な現実についても話すことができます。 CNCFでの受け入れは、業界によって公式に認められており、さらなる発展を保証します。 そしてこれは、少なくともCNIについて学ぶ時間であることを意味します。CNIについては遅かれ早かれ会わなければならないでしょう。
PS
ブログもご覧ください。