これは、 以前のベンチマークの更新で、2019年4月の現在のCNIバージョンでKubernetes 1.14で動作します。
まず、私はCiliumチームに感謝します：メトリックモニタリングスクリプトのチェックと修正を支援してくれました。
2018年11月以降の変更点
以下に変更点を示します（興味がある場合）：
Flannelは、CNIの最速かつ最も簡単なインターフェイスのままですが、ネットワークポリシーと暗号化はまだサポートしていません。
Romanaはサポートされなくなったため、ベンチマークから削除しました。
WeaveNetがIngressおよびEgressのネットワークポリシーをサポートするようになりました！ しかし、生産性は低下しました。
Calicoでは、パフォーマンスを向上させるために、最大パケットサイズ（MTU）を手動で構成する必要があります。 Calicoは2つのCNIインストールオプションを提供しているため、個別のETCDリポジトリなしで実行できます。
- データストアとしてのKubernetes APIの状態ストレージ（クラスターサイズ<50ノード）。
- Kybernetes APIの状態ストレージを、Typhaプロキシを備えたデータストアとして使用して、K8S API（クラスターサイズ> 50ノード）からの負荷を軽減します。
Calicoは、 アプリケーションレベルのセキュリティのために、Istioに加えてアプリケーションレベルのポリシーサポートを発表します 。
Ciliumは暗号化をサポートするようになりました！ Ciliumは、IPSecトンネルで暗号化を提供し、暗号化されたWeaveNetネットワークの代替手段を提供します。 ただし、WeaveNetは暗号化が有効になっているCiliumよりも高速です。
組み込みのETCDオペレーターのおかげで、Ciliumの展開が容易になりました。
Ciliumチームは、CNIの重量を抑え、メモリ消費とCPUコストを削減しようとしましたが、競合他社はまだ軽いです。
ベンチマークコンテキスト
ベンチマークは、10 Gb Supermicroスイッチを備えた3つの非仮想化Supermicroサーバーで実行されます。 サーバーはパッシブDAC SFP +ケーブルを介してスイッチに直接接続され、ジャンボフレーム（MTU 9000）と同じVLANで構成されます。
Kubernetes 1.14.0は、Docker 18.09.2（このリリースのDockerのデフォルトバージョン）を使用してUbuntu 18.04 LTSにインストールされます。
再現性を向上させるため、最初のノードで常にマスターを構成し、ベンチマークのサーバー部分を2番目のサーバーに配置し、クライアント部分を3番目のサーバーに配置することにしました。 このため、KubernetesデプロイメントでNodeSelectorを使用します。
ベンチマーク結果は、そのようなスケールで説明されます。
ベンチマークにCNIを選択する
これは、Kubernetesの公式ドキュメントのkubeadmで1つのマスタークラスターを作成するセクションのリストにあるCNI専用のベンチマークです。 CNI 9から6つだけを取得します。インストールが困難なもの、および/またはドキュメント構成なしでは機能しないもの（Romana、Contiv-VPP、およびJuniperContrail / TungstenFabric）は除外します。
以下のCNIを比較します。
- 三毛猫v3.6
- Canal v3.6（基本的にネットワーキング用のフランネル+ファイアウォールとしてのCalico）
- 繊毛1.4.2
- フランネル0.11.0
- キューブルーター0.2.5
- WeaveNet 2.5.1
設置
CNIのインストールが簡単であればあるほど、第一印象は良くなります。 ベンチマークのすべてのCNIは、インストールが非常に簡単です（1つまたは2つのチームで）。
前述したように、サーバーとスイッチはジャンボフレームがアクティブに構成されています（MTU 9000をインストールしました）。 CNIがアダプタ設定に基づいてMTUを自動的に決定してくれたら幸いです。 ただし、これを処理したのは繊毛とフランネルのみです。 残りのCNIにはGitHubで自動MTU検出を追加する要求がありますが、Calico、Canal、およびKube-routerのConfigMapを変更するか、WeaveNetの環境変数を渡すことにより、手動で構成します。
間違ったMTUの問題は何ですか？ 次の図は、デフォルトのMTUとジャンボフレームが有効になっているWeaveNetの違いを示しています。
MTUが帯域幅に与える影響
MTUがパフォーマンスにとってどれほど重要であるかを理解し、CNIがどのようにそれを自動的に検出するかを見てみましょう。
CNIはMTUを自動的に検出します
このグラフは、最適なパフォーマンスを得るために、Calico、Canal、Kube-router、およびWeaveNetのMTUを構成する必要があることを示しています。 繊毛とフランネル自体は、設定なしでMTUを正しく決定することができました。
安全性
CNIセキュリティを2つの側面で比較します。送信されたデータを暗号化する機能とKubernetesネットワークポリシーの実装です（ドキュメントではなく、実際のテストに従って）。
データを暗号化するのは、CiliumとWeaveNetの2つのCNIのみです。 WeaveNet暗号化は 、暗号化パスワードをCNI環境変数として設定することにより有効になります。 これについて説明したWeaveNetのドキュメントは複雑ですが、すべてが簡単に行われます。 Cilium暗号化は 、コマンド、Kubernetesシークレットの作成、daemonSetの変更（WeaveNetよりも少し複雑ですが、Ciliumには段階的な手順があります）によって構成されます。
ネットワークポリシーの実装に関しては、 Calico、Canal、Cilium、およびWeaveNetがここで成功しました。ここで、IngressおよびEgressルールを構成できます。 Kube-routerの場合、 Ingress専用のルールがありますが、 Flannelにはネットワークポリシーがまったくありません。
一般的な結果は次のとおりです。
セキュリティ機能のベンチマーク結果
性能
このベンチマークは、各テストの少なくとも3回の実行の平均スループットを示しています。 TCPとUDP（iperf3を使用）、実際のアプリケーション、たとえばHTTP（Nginxとcurlを使用）またはFTP（vsftpdとcurlを使用）、および最後にSCPベースの暗号化を使用するアプリケーション（クライアントとサーバーを使用）のパフォーマンスをテストしますOpenSSH）。
すべてのテストで、ベアメタルベンチマーク（緑色の線）を作成して、CNIパフォーマンスとネイティブネットワークパフォーマンスを比較しました。 ここでは、同じスケールを使用していますが、色は次のとおりです。
- 黄色=非常に良い
- オレンジ=良好
- 青=まあまあ
- 赤=悪い
不適切に構成されたCNIは使用せず、正しいMTUを持つCNIの結果のみを表示します。 （注：暗号化が有効になっている場合、CiliumはMTUを正しく考慮しないため、バージョン1.4では手動でMTUを8900に減らす必要があります。次のバージョン1.5では、これは自動的に行われます。）
結果は次のとおりです。
TCPパフォーマンス
すべてのCNIは、TCPベンチマークで良好に機能しました。 暗号化は高価なので、暗号化されたCNIははるかに遅れています。
UDPパフォーマンス
ここでも、すべてのCNIが順調です。 暗号化されたCNIはほぼ同じ結果を示しました。 繊毛は競合他社にやや遅れていますが、ベアメタルのわずか2.3％であるため、結果は悪くありません。 CiliumとFlannel自体がMTUを正しく決定したことを忘れないでください。これらは、追加の構成を行わない場合の結果です。
実際のアプリケーションはどうですか？ ご覧のとおり、HTTPの場合、全体的なパフォーマンスはTCPの場合よりもわずかに低くなります。 TCPでHTTPを使用する場合でも、TCPベンチマークでは、遅い起動を避けるためにiperf3を構成しました。これはHTTPベンチマークに影響します。 ここですべてがうまくいった。 Kube-routerには明らかな利点があり、WeaveNetはうまく機能しませんでした。ベアメタルよりも約20％劣っています。 暗号化機能を備えたCiliumとWeaveNetは非常に悲しそうです。
別のTCPベースのプロトコルであるFTPでは、結果は異なります。 フランネルとキューブルーターは対処しますが、Calico、Canal、Ciliumはわずかに遅れ、ベアメタルよりも約10％遅くなります。 WeaveNetは17％に対応できませんが、暗号化されたWeaveNetは暗号化されたCiliumよりも40％進んでいます。
SCPを使用すると、SSH暗号化のコストをすぐに確認できます。 ほぼすべてのCNIがこれを実行し、WeaveNetは再び遅れをとっています。 暗号化を使用したCiliumおよびWeaveNetは、二重暗号化（SSH + CNI）により、最悪の事態になると予想されます。
結果を要約表に示します。
リソース消費
ここで、CNIが高負荷下でリソースを消費する方法を比較してみましょう（TCP、10 Gb / sでの伝送中）。 パフォーマンステストでは、CNIとベアメタル（緑の線）を比較します。 リソースを消費するために、CNIなしの純粋なKubernetes（紫色の線）を表示し、CNIが消費する追加リソースの数を確認します。
記憶から始めましょう。 転送中のノードのRAM（バッファおよびキャッシュなし）の平均値（MB単位）は次のとおりです。
メモリ消費
FlannelとKube-routerは優れた結果を示しました-わずか50 MB。 CalicoとCanalにはそれぞれ70があります。WeaveNetは明らかに130 MB以上を消費し、Ciliumは400を使用します。
次に、CPU消費を確認しましょう。 注目すべきは、図では、パーセンテージではなく、1ミルあたり、つまり「裸鉄」の38 ppm-これは3.8％です。 結果は次のとおりです。
CPU消費
Calico、Canal、Flannel、およびKube-routerはCPUを非常に効率的に使用します。CNIなしのKubernetesよりも2％だけ多くなります。 WeaveNetは5％余分に遅れており、Cilium-7％がそれに続きます。
リソース消費の概要は次のとおりです。
まとめ
すべての結果を含む表：
一般的なベンチマーク結果
おわりに
最後の部分では、結果に対する主観的な意見を述べます。 このベンチマークは、非常に小さなクラスター（3ノード）での1つの接続のスループットのみをテストすることに注意してください。 大規模なクラスター（<50ノード）または並列接続には適用されません。
シナリオに応じて、次のCNIを使用することをお勧めします。
- クラスター内に少量のリソース （数GBのRAM、いくつかのコア）を備えたノードがあり、セキュリティ機能は必要ありません-Flannelを選択します。 これは最も経済的なCNIの1つです。 また、さまざまなアーキテクチャ（amd64、arm、arm64など）と互換性があります。 さらに、これは2つのうちの1つ（2つ目はCilium）CNIであり、MTUを自動的に決定できるため、何も構成する必要はありません。 Kube-routerも適していますが、標準ではないため、MTUを手動で構成する必要があります。
- セキュリティのためにネットワークを暗号化する必要がある場合は、 WeaveNetを使用してください 。 ジャンボフレームを使用している場合は、MTUのサイズを指定することを忘れないでください。環境変数を使用してパスワードを指定することにより、暗号化をアクティブにします。 ただし、パフォーマンスは忘れてください。これは暗号化料金です。
- 通常の使用には、 Calico をお勧めします。 このCNIは、さまざまなKubernetes展開ツール（Kops、Kubespray、Rancherなど）で広く使用されています。 WeaveNetと同様に、ジャンボフレームを使用する場合は、ConfigMapでMTUを構成することを忘れないでください。 これは、リソース消費、生産性、およびセキュリティの点で効果的な多機能ツールです。
最後に、 Ciliumの開発をフォローすることをお勧めします。 このCNIには、その製品（機能、リソースの節約、生産性、セキュリティ、クラスターの分散など）に多く取り組む非常に活発なチームがあり、非常に興味深い計画があります。
CNI選択のための視覚図