👩🏻‍🌾 💃🏽 😮 Kubernetesネットワークパフォーマンスの比較 👨‍👨‍👧‍👦 🏤 🚱

Kubernetesでは、クラスター内の各コンテナーに一意のルーティング可能なIPが必要です。 KubernetesはIPアドレス自体を割り当てないため、このタスクはサードパーティのソリューションに任されています。

この調査の目標は、最小のレイテンシ、最高のスループット、および最低の構成コストでソリューションを見つけることです。負荷は遅延に依存するため、十分にアクティブなネットワーク負荷での高パーセンタイルの遅延を測定します。特に、最大負荷の30〜50％程度のパフォーマンスに焦点を当てました。これは、混雑していないシステムの典型的な状況を最もよく反映しているためです。

オプション

`--net=host`

を`--net=host`

Docker

模範的なインストール。他のすべてのオプションは彼女と比較されました。

オプション--net=host

は、コンテナがホストマシンのIPアドレスを継承することを意味します。ネットワークのコンテナ化はありません。

先験的なネットワークコンテナ化の欠如は、実装の存在よりも優れたパフォーマンスを提供します。このため、このインストールを参照として使用しました。

フランネル

Flannelは、 CoreOSプロジェクトでサポートされている仮想ネットワークソリューションです。十分にテストされ、生産の準備ができているため、実装のコストは最小限です。

フランネルマシンをクラスターに追加すると、フランネルは次の3つのことを行います。

etcdを使用してサブネットを新しいマシンに割り当てます。
マシン上に仮想ブリッジインターフェイスを作成します（ docker0 bridge

）。
パケット転送バックエンドを構成します。
- aws-vpc
  
  -Amazon AWSインスタンステーブルにマシンサブネットを登録するこのテーブルのエントリの数は50に制限されています。 aws-vpc
  
  でaws-vpc
  
  を使用する場合、クラスター内に50台を超えるマシンをaws-vpc
  
  ことはできません。さらに、このバックエンドはAmazon AWSでのみ機能します。
- host-gw
  
  リモートマシンのIPアドレスを介してサブネットへのIPルートを作成します。 flannelを実行しているホスト間の直接L2接続が必要です。
- vxlan
  
  仮想VXLANインターフェイスを作成します。

flannelはブリッジインターフェイスを使用してパケットを転送するため、各パケットが1つのコンテナから別のコンテナに送信されると、2つのネットワークスタックを通過します。

IPvlan

IPvlanはLinuxカーネルのドライバーで、ブリッジインターフェイスを必要とせずに一意のIPアドレスを持つ仮想インターフェイスを作成できます。

IPvlanを使用してコンテナにIPアドレスを割り当てるには、次が必要です。

ネットワークインターフェイスなしでコンテナを作成します。
標準のネットワーク名前空間にipvlanインターフェイスを作成します。
インターフェイスをコンテナのネットワーク名前空間に移動します。

IPvlanは比較的新しいソリューションであるため、このプロセスを自動化するための既製のツールはありません。したがって、多くのマシンおよびコンテナでのIPvlanの展開はより複雑になり、つまり実装コストが高くなります。ただし、IPvlanはブリッジインターフェイスを必要とせず、パケットをNICから仮想インターフェイスに直接転送するため、フランネルよりも優れたパフォーマンスが期待されていました。

負荷テストスクリプト

各オプションについて、次の手順を完了しました。

2つの物理マシンでネットワークをセットアップします。
1台のマシンのコンテナーでtcpkaliを開始し、一定の速度で要求を送信するようにセットアップしました。
別のマシンのコンテナでnginxを起動し、固定サイズのファイルで応答するように設定しました。
システムメトリックとtcpkaliの結果を削除しました。

このテストは、毎秒50,000から450,000のリクエスト（RPS）の異なるリクエスト数で実行しました。

各リクエストに対して、nginxは固定サイズの静的ファイルで応答しました：350バイト（100バイトのコンテンツと250バイトのヘッダー）または4キロバイト。

結果

IPvlanは、最小のレイテンシと最高の最大スループットを示しています。 host-gw

およびaws-vpc

を備えたFlannelは、closeインジケータを使用してそれに追従しますが、 host-gw

は最大負荷下でパフォーマンスが向上しました。
vxlan

を使用したフランネルは、すべてのテストで最悪の結果を示しました。ただし、例外的に悪いパーセンタイル99.999はバグが原因であると思われます。
4 KBの応答の結果は350バイトの場合と似ていますが、2つの顕著な違いがあります。
- 4キロバイトの応答では10ギガビットNICを完全にロードするのに約27万RPSしかかからなかったため、最大RPSははるかに低くなります。
- 帯域幅の制限に近づくと、IPvlanは--net=host
  
  に非常に近くなります。

現在の選択は、 host-gw

フランネルです。依存関係はほとんどなく（特に、AWSやLinuxカーネルの新しいバージョンを必要としません）、IPvlanと比較して簡単にインストールでき、十分なパフォーマンスを提供します。 IPvlanはフォールバックです。ある時点でflannelがIPvlanサポートを取得したら、このオプションに進みます。

aws-vpc

はhost-gw

よりもわずかに優れていましたが、50台のマシンの制限とAmazon AWSへの緊密なバインドの事実が決定的な要因でした。

50,000 RPS、350バイト

1秒あたり50,000件のリクエストで、すべての候補者が許容できるパフォーマンスを示しました。すでに主な傾向に気づくことができます。IPvlanが最良の結果を示し、 host-gw

とaws-vpc

がそれにvxlan

最悪です。

150,000 RPS、350バイト

150,000 RPS（最大RPSの約30％）での遅延パーセンタイル、ミリ秒

IPvlanはhost-gw

およびaws-vpc

よりもわずかに優れていますが、最悪のパーセンタイルは99.99です。 host-gw

パフォーマンスはaws-vpc

よりもわずかに優れています。

250,000 RPS、350バイト

このような負荷は生産で一般的であると想定されているため、結果は特に重要です。

250,000 RPSのパーセンタイル遅延（最大RPSの約50％）、ミリ秒

IPvlanのパフォーマンスは再び向上していますが、 aws-vpc

最高パーセンタイルは99.99と99.999です。 host-gw

、パーセンタイル95および99でaws-vpc

よりも優れています。

350,000 RPS、350バイト

ほとんどの場合、遅延は250,000 RPS（350バイト）の結果に近いですが、99.5パーセンタイルの後に急速に増加します。これは、最大RPSに近づくことを意味します。

450,000 RPS、350バイト

興味深いことに、 host-gw

はaws-vpc

よりもはるかに優れたパフォーマンスを示します。

500,000 RPS、350バイト

負荷が500,000 RPSの場合、IPvlanのみが動作し、-- --net=host

を超え--net=host

が、遅延が非常に大きいため、遅延の影響を受けやすいアプリケーションでは許容できないとは言えません。

50,000 RPS、4キロバイト

大規模なクエリ結果（以前にテストされた350バイトに対して4キロバイト）は、ネットワーク負荷を大きくしますが、リーダーボードは実質的に変化しません。

50,000 RPSのパーセンタイル遅延（最大RPSの約20％）、ミリ秒

150,000 RPS、4キロバイト

host-gw

99.999パーセンタイルは驚くほど貧弱ですが、小さいパーセンタイルでも良い結果を示しています。

150,000 RPSでの遅延パーセンタイル（最大RPSの約60％）、ms

250,000 RPS、4キロバイト

これは、大きな応答（4 Kb）での最大RPSです。 aws-vpc

、小さな応答（350バイト）の場合とは異なり、 host-gw

よりaws-vpc

大幅に優れていhost-gw

。

Vxlan

は再びスケジュールから除外されました。

テスト環境

基本

この記事をよりよく理解し、テスト環境を再現するには、高性能の基本を理解する必要があります。

これらの記事には、このトピックに関する有用な情報が含まれています。

CloudFlareから毎秒100万パケットを受信する方法。
CloudFlareの10Gbpsイーサネットで低遅延を実現する方法。
LinuxカーネルのドキュメントのLinux Networking Stackでのスケーリング。

車

CentOS 7を搭載したAmazon AWS EC2でc4.8xlargeの 2つのインスタンスを使用しました。
両方のマシンで拡張ネットワーキングが有効になっています。
各マシンは2つのプロセッサを備えたNUMAであり、各プロセッサには9つのコアがあり、各コアには2つのスレッド（ハイパースレッド）があり、各マシンで36スレッドの効果的な起動を保証します。
各マシンには、10Gbps（NIC）ネットワークカードと60 GBのRAMがあります。
拡張ネットワークとIPvlanをサポートするために、Intel ixgbevfドライバーを備えたLinux 4.3.0カーネルをインストールしました。

構成

最新のNICは、複数の割り込み要求ライン（ IRQ ）を介してReceive Side Scaling（RSS）を使用します。 EC2は仮想化環境でそのような行を2つだけ提供するため、RSSとReceive Packet Steering（RPS）を使用していくつかの構成をテストし、Linuxカーネルのドキュメントで一部推奨されている次の設定に到達しました。

IRQ 2つのNUMAノードのそれぞれの最初のコアは、NICから割り込みを受信するように構成されています。 CPUをNUMA lscpu

にlscpu

、 lscpu

使用されます。
```
 $ lscpu | grep NUMA NUMA node(s): 2 NUMA node0 CPU(s): 0-8,18-26 NUMA node1 CPU(s): 9-17,27-35
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     
```
この設定は、 0

と9

を/proc/irq/<num>/smp_affinity_list

に書き込むことで行われます/proc/irq/<num>/smp_affinity_list

番号はgrep eth0 /proc/interrupts

から取得grep eth0 /proc/interrupts

ます。
```
 $ echo 0 > /proc/irq/265/smp_affinity_list $ echo 9 > /proc/irq/266/smp_affinity_list
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     
```
パケットステアリング（RPS）を受信します。 RPSのいくつかの組み合わせがテストされています。遅延を減らすために、CPU番号1〜8および10〜17のみを使用して、IRQ処理からプロセッサをアンロードしました。 IRQのsmp_affinity

とは異なり、 rps_cpus

sysfsファイルにrps_cpus

後置記号rps_cpus

ないため、ビットマスクを使用して、RPSがトラフィックを転送できるCPUをリストします（詳細については、 Linuxカーネルのドキュメント：RPS Configurationを参照してください） 。
```
 $ echo "00000000,0003fdfe" > /sys/class/net/eth0/queues/rx-0/rps_cpus $ echo "00000000,0003fdfe" > /sys/class/net/eth0/queues/rx-1/rps_cpus
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     
```

パケットステアリング（XPS）を送信します。すべてのNUMA 0プロセッサー（ハイパースレッディング、つまり0-8、18-26のCPU番号を含む）はtx-0に構成され、NUMA 1プロセッサー（9-17、27-37）はtx-1に構成されました（詳細Linuxカーネルのドキュメントを参照してください：XPS Configuration ） ：

 $ echo "00000000,07fc01ff" > /sys/class/net/eth0/queues/tx-0/xps_cpus $ echo "0000000f,f803fe00" > /sys/class/net/eth0/queues/tx-1/xps_cpus

フローステアリング（RFS）を受信します。私たちは6万の永続的な接続を使用する予定でしたが、公式の文書では、この数を2のべき乗に丸めることを推奨しています。

 $ echo 65536 > /proc/sys/net/core/rps_sock_flow_entries $ echo 32768 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt $ echo 32768 > /sys/class/net/eth0/queues/rx-1/rps_flow_cnt

Nginx Nginxは、それぞれ独自のCPU（0〜17）を備えた18のワークフローを使用しました。これはworker_cpu_affinity

を使用して設定されます：

 workers 18; worker_cpu_affinity 1 10 100 1000 10000 ...;

Tcpkali 。 Tcpkaliには、特定のCPUへのバインドのサポートが組み込まれていません。 RFSを使用するために、タスクセットでtcpkaliを実行し、まれなスレッドの再割り当てのためにスケジューラーをセットアップしました。

 $ echo 10000000 > /proc/sys/kernel/sched_migration_cost_ns $ taskset -ac 0-17 tcpkali --threads 18 ...

この構成により、割り込みの負荷をプロセッサコア全体に均等に分散し、他のテスト済み構成と同じ遅延を維持しながらスループットを向上させることができました。

カーネル0および9は、ネットワークインターフェイス割り込み（NIC）のみを処理し、パケットを処理しませんが、最も忙しいままです：

また、付属のネットワーク遅延プロファイルでRed Hatから調整されたものを使用しました。

nf_conntrackの影響を最小限に抑えるために、NOTRACK ルールが追加されました。

sysctl構成は、多数のTCP接続をサポートするように構成されました。

 fs.file-max = 1024000 net.ipv4.ip_local_port_range = "2000 65535" net.ipv4.tcp_max_tw_buckets = 2000000 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_slow_start_after_idle = 0 net.ipv4.tcp_low_latency = 1

翻訳者から ： Machine Zone、Incの同僚のテストに感謝します！ それは私たちを助けたので、他の人と共有したかったのです。

PS記事「 Container Networking Interface（CNI）-Network Interface and Standard for Linux Containers 」にも興味があるかもしれません。

Kubernetesネットワークパフォーマンスの比較