10 Gbps ネットワーク上の Kubernetes ネットワーク プラグイン (CNI) ベンチマーク結果 (更新: 2019 年 XNUMX 月)

これは私のアップデートです 以前のベンチマーク、1.14 年 2019 月の時点で最新の CNI バージョンを備えた Kubernetes XNUMX 上で実行されるようになりました。

まず最初に、Cilium チームに感謝したいと思います。彼らは、メトリクス監視スクリプトのチェックと修正を手伝ってくれました。

2018年XNUMX月からの変更点

それ以降の変更点は次のとおりです (興味がある場合は)。

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

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

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

Calico では、最高のパフォーマンスを得るために最大パケット サイズ (MTU) を手動で構成する必要があります。 Calico には、CNI をインストールするための XNUMX つのオプションが用意されているため、別個の ETCD リポジトリなしでインストールできます。

• Kubernetes API に状態をデータ ストアとして保存します (クラスター サイズ < 50 ノード)。
• K8S API (クラスター サイズ > 50 ノード) の負荷を軽減するために、Typha プロキシを使用してデータ ストアとして Kubernetes API に状態を保存します。

Calico がサポートを発表 アプリケーションレベルのポリシー アプリケーションレベルのセキュリティを実現するために Istio 上に構築されます。

Cilium が暗号化をサポートするようになりました。 Cilium は、IPSec トンネルによる暗号化を提供し、暗号化された WeaveNet ネットワークの代替手段を提供します。 ただし、暗号化を有効にすると、WeaveNet は Cilium よりも高速になります。

Cilium は、ETCD オペレーターが組み込まれているため、導入が簡単になりました。

Cilium チームは、メモリ消費量と CPU コストを削減することで CNI の重量をある程度削減しようとしましたが、競合他社は依然として軽量です。

ベンチマークのコンテキスト

このベンチマークは、10 Gb Supermicro スイッチを備えた 9000 台の非仮想化 Supermicro サーバー上で実行されます。 サーバーはパッシブ DAC SFP+ ケーブルを介してスイッチに直接接続され、ジャンボ フレーム (MTU XNUMX) を使用して同じ VLAN 上に構成されます。

Kubernetes 1.14.0 は、Docker 18.04 (このリリースのデフォルトの Docker バージョン) を備えた Ubuntu 18.09.2 LTS にインストールされています。

再現性を向上させるために、常に最初のノードにマスターを構成し、ベンチマークのサーバー部分を XNUMX 番目のサーバーに配置し、クライアント部分を XNUMX 番目のサーバーに配置することにしました。 これを行うには、Kubernetes デプロイメントで NodeSelector を使用します。

次のスケールでベンチマーク結果を説明します。

ベンチマークの CNI の選択

これは、セクションのリストにある CNI のみのベンチマークです。 kubeadm を使用した XNUMX つのマスタークラスターの作成について Kubernetes の公式ドキュメントを参照してください。 9 つの CNI のうち、6 つだけを取り上げます。インストールが難しいものや、ドキュメントに従って設定しないと機能しないものは除外されます (Romana、Contiv-VPP、および JuniperContrail/TungstenFabric)。

次の CNI を比較します。

• キャリコ v3.6
• Canal v3.6 (基本的にネットワーク用の Flannel + ファイアウォールとしての Calico)
• 繊毛 1.4.2
• フランネル 0.11.0
• Kubeルーター0.2.5
• ウィーブネット 2.5.1

インストール

CNI のインストールが簡単であればあるほど、第一印象は良くなります。 ベンチマークのすべての CNI は、インストールが非常に簡単です (XNUMX つまたは XNUMX つのコマンドで)。

前述したように、サーバーとスイッチはジャンボ フレームを有効にして構成されています (MTU を 9000 に設定しました)。 CNI がアダプターの構成に基づいて MTU を自動的に決定できれば幸いです。 しかし、これを管理できるのはシリウムとフランネルだけでした。 残りの CNI は GitHub 上で自動 MTU 検出を追加するリクエストを行っていますが、Calico、Canal、および Kube-router の ConfigMap を変更するか、WeaveNet の環境変数を渡すことにより、手動で構成します。

MTU が正しくない場合、どのような問題が発生しますか? この図は、デフォルトの MTU とジャンボ フレームが有効になっている WeaveNet の違いを示しています。

MTU はスループットにどのような影響を与えますか?

MTU がパフォーマンスにとっていかに重要であるかを見てきました。次に、CNI が MTU をどのように自動的に決定するかを見てみましょう。

CNI は MTU を自動的に検出します

グラフは、最適なパフォーマンスを得るには、Calico、Canal、Kube-router、および WeaveNet の MTU を構成する必要があることを示しています。 Cilium と Flannel は、設定を行わなくても、MTU 自体を正しく決定できました。

セキュリティ

CNI のセキュリティを、送信データの暗号化機能と Kubernetes ネットワーク ポリシーの実装 (ドキュメントではなく実際のテストに基づく) の XNUMX つの側面で比較します。

データを暗号化する CNI は、Cilium と WeaveNet の XNUMX つだけです。 暗号化 ウィーブネット 暗号化パスワードを CNI 環境変数として設定することで有効になります。 で ドキュメンテーション WeaveNet では複雑な方法で説明されていますが、すべてが簡単に行われます。 暗号化 繊毛 コマンド、Kubernetes シークレットの作成、および daemonSet の変更によって構成されます (WeaveNet よりも少し複雑ですが、Cilium には段階的な手順があります) 説明書).

ネットワーク政策の導入に関しては、彼らは成功した Calico、Canal、Cilium、WeaveNetここで、イングレス ルールとエグレス ルールを構成できます。 のために Kubeルーター Ingress のみのルールがあり、 フランネル ネットワーク ポリシーはまったくありません。

全体的な結果は次のとおりです。

安全性能ベンチマーク結果

Производительность

このベンチマークは、各テストの少なくとも 3 回の実行にわたる平均スループットを示します。 TCP と UDP (iperfXNUMX を使用)、HTTP (Nginx とcurl を使用) または FTP (vsftpd とcurl を使用) などの実際のアプリケーションのパフォーマンスをテストし、最後に SCP ベースの暗号化 (クライアントとサーバーの OpenSSH を使用) を使用してアプリケーションのパフォーマンスをテストします。

すべてのテストで、ベア メタル ベンチマーク (緑の線) を実行し、CNI のパフォーマンスとネイティブ ネットワークのパフォーマンスを比較しました。 ここでは同じスケールをカラーで使用します。

• 黄色 = 非常に良い
• オレンジ＝良い
• 青 = まあまあ
• 赤 = 悪い

正しく構成されていない CNI は採用されず、正しい MTU を持つ CNI の結果のみが表示されます。 (注: 暗号化を有効にすると、Cilium は MTU を正しく計算しないため、バージョン 8900 では MTU を手動で 1.4 に下げる必要があります。次のバージョン 1.5 では、これが自動的に行われます。)

結果は次のとおりです。

TCP パフォーマンス

すべての CNI は TCP ベンチマークで良好なパフォーマンスを示しました。 暗号化にはコストがかかるため、暗号化を備えた CNI は大幅に遅れています。

UDPのパフォーマンス

ここでも、すべての CNI は順調に進んでいます。 暗号化を使用した CNI もほぼ同じ結果を示しました。 Cilium は競合製品に少し遅れをとっていますが、ベアメタルのわずか 2,3% なので、悪くない結果です。 MTU を自身で正しく決定したのは Cilium と Flannel だけであり、これらは追加の構成を行わない結果であることを忘れないでください。

実際のアプリケーションではどうなるでしょうか? ご覧のとおり、HTTP の全体的なパフォーマンスは TCP よりもわずかに低くなります。 TCP で HTTP を使用する場合でも、HTTP ベンチマークに影響を与えるスロースタートを回避するために、TCP ベンチマークで iperf3 を構成しました。 ここではみんなよく頑張りました。 Kube-router には明らかな利点がありますが、WeaveNet のパフォーマンスは良くなく、ベアメタルよりも約 20% 悪かったです。 暗号化を備えた Cilium と WeaveNet は本当に残念に思えます。

もう 10 つの TCP ベースのプロトコルである FTP では、結果は異なります。 Flannel と Kube-router は機能しますが、Calico、Canal、Cilium は少し遅れており、ベアメタルよりも約 17% 遅くなります。 WeaveNet は 40% も遅れていますが、暗号化された WeaveNet は暗号化された Cilium より XNUMX% 進んでいます。

SCP を使用すると、SSH 暗号化にどれくらいのコストがかかるかをすぐに確認できます。 ほぼすべての CNI は好調ですが、WeaveNet は再び遅れをとっています。 暗号化を使用する Cilium と WeaveNet は、二重暗号化 (SSH + CNI) により最悪であることが予想されます。

結果をまとめた表は次のとおりです。

資源の消費

次に、高負荷時（TCP 転送時、10 Gbps）で CNI がどのようにリソースを消費するかを比較してみましょう。 パフォーマンス テストでは、CNI とベアメタル (緑の線) を比較します。 リソース消費については、CNI を含まない純粋な Kubernetes (紫色の線) を表示し、CNI が消費する追加リソースの数を確認してみましょう。

記憶から始めましょう。 以下は、転送中のノードの RAM (バッファーとキャッシュを除く) の平均値 (MB 単位) です。

メモリ消費量

Flannel と Kube-router は優れた結果を示しました (わずか 50 MB)。 Calico と Canal はそれぞれ 70 です。WeaveNet は明らかに他のものより多く消費します - 130 MB、Cilium は 400 MB も使用します。
次に、CPU 時間の消費量を確認してみましょう。 注目すべき: この図はパーセンテージではなく、ppm で示しています。つまり、「裸の鉄」の 38 ppm は 3,8% です。 結果は次のとおりです。

CPU消費量

Calico、Canal、Flannel、および Kube-router は非常に CPU 効率が高く、CNI を使用しない Kubernetes よりわずか 2% 高いだけです。 WeaveNet はさらに 5% の差で大きく遅れをとっており、Cilium が 7% で続きます。

リソース消費の概要は次のとおりです。

結果

すべての結果を含む表:

一般的なベンチマーク結果

まとめ

最後の部分では、結果に対する私の主観的な意見を述べます。 このベンチマークは、非常に小規模なクラスター (3 ノード) 上の単一接続のスループットのみをテストすることに注意してください。 大規模なクラスター (ノード数 50 未満) や並列接続には適用されません。

シナリオに応じて、次の CNI を使用することをお勧めします。

• クラスター内にありますか リソースが少ないノード (数 GB の RAM、複数のコア) セキュリティ機能は必要ありません - を選択してください フランネル。 これは、最もコスト効率の高い CNI の 64 つです。 また、さまざまなアーキテクチャ (amd64、arm、armXNUMX など) と互換性があります。 さらに、これは MTU を自動的に決定できる XNUMX つの CNI (もう XNUMX つは Cilium) のうちの XNUMX つであるため、何も設定する必要はありません。 Kube-router も適していますが、標準ではないため、MTU を手動で構成する必要があります。
• 必要に応じて ネットワークを暗号化する 安全のために、取ってください ウィーブネット。 ジャンボ フレームを使用している場合は、忘れずに MTU サイズを指定し、環境変数でパスワードを指定して暗号化を有効にしてください。 ただし、パフォーマンスのことは忘れたほうがよいでしょう。それは暗号化のコストです。
• のために 通常の使用 советую サラサ。 この CNI は、さまざまな Kubernetes デプロイメント ツール (Kops、Kubespray、Rancher など) で広く使用されています。 WeaveNet と同様に、ジャンボ フレームを使用する場合は、必ず ConfigMap で MTU を設定してください。 これは、リソース消費、パフォーマンス、セキュリティの点で効率的な多機能ツールです。

そして最後に、開発状況に従うことをお勧めします。 繊毛。 この CNI には、製品 (機能、リソースの節約、パフォーマンス、セキュリティ、クラスタリングなど) に熱心に取り組んでいる非常に活発なチームがあり、非常に興味深い計画を持っています。

CNI 選択のビジュアル図

出所： habr.com