10G ネットワーク上の Kubernetes の CNI パフォーマンス評価 (2020 年 XNUMX 月)

TL; DR： Kube-Router と Kube-OVN を除き、すべての CNI が正常に動作します。自動 MTU 検出を除けば、Calico が最適です。

過去のチェック記事の更新 (2018 и 2019）、テスト時点では、1.19 年 18.04 月時点で CNI が更新された Ubuntu 2020 上で Kubernetes XNUMX を使用しています。

指標の説明に入る前に...

2019 年 XNUMX 月以降の新機能は何ですか?

• 独自のクラスターでテスト可能: ツールを使用して独自のクラスターでテストを実行できます。 Kubernetes ネットワーク ベンチマーク: KNB
• 新しいメンバーが登場しました
  • アントレア VMware Tanzu より
  • キューブ-OVN alauda.ioより
• 新しいシナリオ: 現在のチェックでは「Pod-to-Pod」ネットワーク パフォーマンス テストが実行されますが、実際の条件に近いテストを実行する新しい「Pod-to-Service」スクリプトが追加されました。 実際には、API を備えたポッドは、ポッドの IP アドレスを通じてではなく、サービスとしてベースと連携します (もちろん、両方のシナリオで TCP と UDP の両方をチェックします)。
• リソース消費: 各テストには独自のリソース比較が含まれるようになりました。
• アプリケーション テストの削除: コミュニティおよび CNI メンテナとの有益なコラボレーションにより、CNI の起動遅延 (Pod の最初の数秒) による TCP 経由の iperf 結果とcurl 結果との間にギャップがあることが判明したため、HTTP、FTP、および SCP テストは行わなくなりました。実際の状況では一般的ではありません)。
• オープンソース: すべてのテスト ソース (スクリプト、yml 設定、元の「生」データ) が利用可能 ここで

リファレンステストプロトコル

プロトコルが詳しく説明されています ここでこの記事はデフォルトのカーネルを使用した Ubuntu 18.04 に関するものであることに注意してください。

評価用の CNI の選択

このテストは、XNUMX つの yaml ファイルで構成された CNI を比較することを目的としています (したがって、VPP などのスクリプトによってインストールされたすべての CNI は除外されます)。

比較のために選択した CNI:

• アントレア v.0.9.1
• キャリコ v3.16
• Canal v3.16 (Flannel ネットワーク + Calico ネットワーク ポリシー)
• 繊毛 1.8.2
• フランネル 0.12.0
• Kube ルーターの最新情報 (2020–08–25)
• ウィーブネット 2.7.0

CNI の MTU の構成

まず、自動 MTU 検出が TCP パフォーマンスに与える影響を確認します。

TCP パフォーマンスに対する MTU の影響

UDP を使用すると、さらに大きなギャップが見つかります。

UDP パフォーマンスに対する MTU の影響

テストで明らかになったパフォーマンスへの多大な影響を考慮して、私たちはすべての CNI メンテナーに希望の手紙を送りたいと思います。自動 MTU 検出を CNI に追加してください。 子猫、ユニコーン、そして最もかわいい子猫、小さなデボップさえも救うことができます。

ただし、自動 MTU 検出をサポートせずに CNI を使用する必要がある場合は、手動で設定してパフォーマンスを向上させることができます。 これは Calico、Canal、WeaveNet に適用されることに注意してください。

随伴する CNI への私の小さなお願いです...

CNI テスト: 生データ

このセクションでは、CNI と正しい MTU (自動的に決定または手動で設定) を比較します。 ここでの主な目的は、生データをグラフで表示することです。

色の凡例:

• グレー - サンプル (つまり、裸の鉄)
• 緑 - 9500 Mbpsを超える帯域幅
• 黄色 - 帯域幅が 9000 Mbps を超える
• オレンジ - 8000 Mbps を超える帯域幅
• 赤 - 帯域幅が 8000 Mbps 未満
• 青 - ニュートラル (帯域幅とは無関係)

無負荷時のリソース消費量

まず、クラスターが「スリープ」しているときのリソース消費量を確認します。

無負荷時のリソース消費量

ポッド間

このシナリオは、クライアント ポッドが IP アドレスを使用してサーバー ポッドに直接接続することを前提としています。

ポッド間のシナリオ

TCP

ポッド間の TCP 結果とそれに対応するリソース消費量:

UDP

ポッド間の UDP 結果とそれに対応するリソース消費:

ポッドからサービスへ

このセクションは実際のユースケースに関連しており、クライアント Pod は ClusterIP サービス経由でサーバー Pod に接続します。

ポッドからサービスへのスクリプト

TCP

ポッドからサービスへの TCP 結果とそれに対応するリソース消費:

UDP

ポッドからサービスへの UDP 結果とそれに対応するリソース消費:

ネットワークポリシーのサポート

上記の中で唯一政治を支持していないのはフランネルです。 他のすべては、インバウンドとアウトバウンドを含むネットワーク ポリシーを正しく実装します。 よくやった！

CNI暗号化

チェックされた CNI の中には、Pod 間のネットワーク交換を暗号化できるものが含まれます。

• IPsec を使用したアントレア
• ワイヤーガードを使用したキャリコ
• IPsecを使用したCilium
• IPsec を使用した WeaveNet

スループット

残っている CNI が少なくなったので、すべてのシナリオを XNUMX つのグラフにまとめてみましょう。

資源の消費

このセクションでは、TCP および UDP で Pod 間の通信を処理するときに使用されるリソースを評価します。 追加情報が提供されないため、ポッドからサービスへのグラフを描画しても意味がありません。

すべてを一緒に入れて

すべてのグラフを繰り返してみます。ここでは少し主観を導入し、実際の値を「非常に速い」、「低い」などの言葉に置き換えます。

結論と私の結論

結果について私自身の解釈を伝えているため、これは少し主観的です。

新しい CNI が登場し、Antrea のパフォーマンスが良く、自動 MTU 検出、暗号化、簡単なインストールなど、初期のバージョンでも多くの機能が実装されていることを嬉しく思います。

パフォーマンスを比較すると、Kube-OVN と Kube-Router を除くすべての CNI が良好に動作します。 Kube-Router も MTU を検出できませんでした。ドキュメントのどこにも MTU を構成する方法が見つかりませんでした (ここで このトピックに関するリクエストは受け付け中です)。

リソース消費の点では、Cilium は依然として他のものよりも多くの RAM を使用しますが、メーカーは明らかに大規模なクラスターをターゲットにしており、これは明らかに XNUMX ノード クラスターでのテストと同じではありません。 Kube-OVN も CPU と RAM リソースを大量に消費しますが、Open vSwitch に基づいた若い CNI です (Antrea と同様、パフォーマンスが高く、消費量が少なくなります)。

Flannel を除く全員がネットワーク ポリシーを持っています。 目標は蒸したカブよりも単純で、軽いほど良いため、彼は決して彼らをサポートしない可能性が非常に高いです。

また、何よりも暗号化のパフォーマンスが素晴らしいです。 Calico は最も古い CNI の 9000 つですが、暗号化が追加されたのはほんの数週間前です。 彼らは IPsec の代わりにワイヤーガードを選択しました。簡単に言えば、それは非常に素晴らしく機能し、テストのこの部分では他の CNI を完全に上回りました。 もちろん、暗号化によりリソースの消費量は増加しますが、達成されるスループットにはそれだけの価値があります (Calico は、XNUMX 位の Cilium と比較して暗号化テストで XNUMX 倍の向上を示しました)。 さらに、Calico をクラスターにデプロイした後はいつでもワイヤーガードを有効にすることができ、必要に応じて短期間または永久に無効にすることもできます。 すごく便利なんですけどね！ Calico は現在 MTU を自動検出しないことに注意してください (この機能は将来のバージョンで予定されています)。そのため、ネットワークがジャンボ フレーム (MTU XNUMX) をサポートしている場合は、必ず MTU を設定してください。

とりわけ、Cilium はクラスター ノード間 (ポッド間だけでなく) のトラフィックを暗号化できることに注意してください。これはパブリック クラスター ノードにとって非常に重要になる可能性があります。

結論として、次の使用例をお勧めします。

• 非常に小さなクラスターには CNI が必要、またはセキュリティは必要ありません： と連携 フランネル、最も軽量で最も安定した CNI (彼はまた、ホモ・クベルナウトゥスまたはホモ・コンタイトルスによって発明された伝説によると、最古の人物の一人でもあります。）。 最も独創的なプロジェクトにも興味があるかもしれません k3s、 チェック！
• 通常のクラスターには CNI が必要: サラサ - 任意ですが、必要に応じて MTU を設定することを忘れないでください。 簡単かつ自然にネットワーク ポリシーを操作したり、暗号化をオンまたはオフにしたりすることができます。
• (非常に) 大規模なクラスターには CNI が必要: そうですね、このテストでは大規模なクラスターの動作は示されていません。喜んでテストを実施したいのですが、10Gbps 接続を備えたサーバーが数百台もありません。 したがって、最良の選択肢は、少なくとも Calico と Cilium を使用して、変更したテストをノード上で実行することです。

出所： habr.com