Geekly Articles each Day

10 GbpsネットワークでのKubernetes Network Plug-ins（CNI）ベンチマークの結果（更新：2019年4月）


これは、 以前のベンチマークの更新で、2019年4月の現在のCNIバージョンでKubernetes 1.14で動作します。


まず、私はCiliumチームに感謝します：メトリックモニタリングスクリプトのチェックと修正を支援してくれました。


2018年11月以降の変更点


以下に変更点を示します（興味がある場合）：


Flannelは、CNIの最速かつ最も簡単なインターフェイスのままですが、ネットワークポリシーと暗号化はまだサポートしていません。


Romanaはサポートされなくなったため、ベンチマークから削除しました。


WeaveNetがIngressおよびEgressのネットワークポリシーをサポートするようになりました！ しかし、生産性は低下しました。


Calicoでは、パフォーマンスを向上させるために、最大パケットサイズ（MTU）を手動で構成する必要があります。 Calicoは2つのCNIインストールオプションを提供しているため、個別のETCDリポジトリなしで実行できます。



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を比較します。



設置


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を使用することをお勧めします。



最後に、 Ciliumの開発をフォローすることをお勧めします。 このCNIには、その製品（機能、リソースの節約、生産性、セキュリティ、クラスターの分散など）に多く取り組む非常に活発なチームがあり、非常に興味深い計画があります。



CNI選択のための視覚図



Source: https://habr.com/ru/post/J448688/

More articles:


All Articles