アンダーレイにおけるマルチネットワーク ns の適用 - ヒント

みなさんこんにちは。私は次男です。前回の記事「​​Underlay でのマルチネットワーク ns の適用 - この記事​​」に続き、マルチネットワーク ns に基づくマスターレベルのアプリケーションである Underlay について説明します。前の記事では、マルチネットワーク ns の基本的な概念について説明しました。まだ読んでいない方は先に読んでみることをお勧めします。結局のところ、大学入試の作文問題には、「初心者は基礎から始めるべきだ」と書かれていました。基礎スキルがしっかりして初めてチェスのスキルは向上します。初心者の中には、驚くべき動きを追求することに熱心で、より一般的に使用される基本的な動きを無視する人もいます。基礎スキルは土台であり、優れたスキルは創造です。

1. マルチVMからマルチネットワークNSへ

マルチネットワーク ns の重要な役割を示すために、別の図を使用して比較を行い、元のマルチ VM からマルチネットワーク ns への進化がいかに必要であるかがわかるようにしたいと思います。図 1 では、物理マシン上に複数の VM が作成されています。 VMM は、CPU/メモリ/ディスク/ネットワーク カードなどのデバイスを VM に仮想化します。各 VM の OS 部分は net_device を作成します。これは、VM が所有するネットワーク カードをソフトウェア レベルで抽象化するために使用されるデータ構造です。ネットワーク カード自体は仮想的ですが、VM がそれを実際のネットワーク カードであると認識していれば十分です。実際、これらのネットワーク カードは、物理マシンの Open vSwitch に接続された単なるタップ デバイスです。 vSwitch は大まかに言えばブリッジとして理解できます。

図1: マルチVM

ECS に精通している人や、Alibaba Cloud や Tencent Cloud でクラウド サーバーを購入したことがある人は、通常、VM 上で実行されるアプリケーション (ワークロード) は 1 つだけ、またはごく少数だけであることを知っているはずです。ほとんどの場合、この VM 上の CPU/メモリ/ディスクなどのリソースはアイドル状態であり、複数のアプリケーションを分離するために複数のネットワーク ns テクノロジが使用されていることは言うまでもありません。個人であれ企業であれ、お金は空から降ってくるものではなく、コスト削減や効率化は永遠の目標です。より資源を節約する方法が出現すれば、誰もがそれに群がるでしょう。マルチネームスペースベースの Docker の出現は、クラウド コンピューティング市場にほぼ破壊的な変化をもたらしました。これはその良い例です。図2: 複数のネットワーク名前空間を持つ環境

『アントマン・アンド・ワスプ』を見ましたか？ピム博士は瞬時に建物全体をトロリーケースに収めました。かっこいいでしょう？図 1 の vSwitch を図 2 のブリッジのサイズに縮小するか、ブリッジの位置に配置すると、vSwitch に接続されている VM は、実際にはブリッジに接続されている複数のネットワーク NS に属する Pod に縮小されます。とてもハンサムですよね？図2に基づく:

• VTEPを追加して基本的なオーバーレイを構築する
• flanneld などの機能と以下のルーティング設定を追加することで、host-gw に変換されます。ワークノードはブリッジを実行し、各ブリッジはサブネットを形成します。すべてのワーク ノードのルーティング テーブルにレコードを追加します。サブネットにつながる「ネクスト ホップ」(例: 10.244.1.0/24) は、ブリッジを実行しているワーク ノードの IP アドレスです。つまり、この「ホスト」はコンテナ通信パスへの「ゲートウェイ」として機能します。ホストゲートウェイの名前はこれに由来しています。

かなり良さそうですね。ワークロードで使用されるリソースを VM 粒度から Pod 粒度に削減することで節約されるリソースは、実に非常に印象的です。私の経験によると、Web サーバーのような I/O ワークロードの場合、元の VM サイズが 2 コア + 4 GB メモリの場合、Pod サイズを 0.5 コア + 200 MB に削減できます (Pod 内にコンテナーが 1 つしかないと仮定)。しかし、何かが間違っているようです。図 2 では、ブリッジがサブネットを形成していますが、サブネット内の各ポッドがサブネット外のリソースにアクセスする場合、ネットワーク トラフィックはルート NS を経由する必要があるようです。図 1 の VM のように、ネットワーク トラフィックがそれぞれ独自の方向に自由に流れるようにしながら、図 2 に示すようなきめ細かいリソース仮想化および割り当て方法を維持することは可能でしょうか。

2. 下敷き

大衆の声こそが、コンテナ クラウド ベンダーが前進するための原動力です。さて、AWS ENI や、弾性ネットワーク カードを使用してアンダーレイを実装するその他のテクノロジーは、図 2 の欠点を完璧に解決します。図 2 に示されている欠点の根本的な原因は、すべての Pod が VM が所有するネットワーク カードを共有していることであるため、図 2 の各 Pod に個別のネットワーク カードを装備することはできるでしょうか。たとえば、図 3 に示すように、ブリッジを削除すると、各人にネットワーク カードが与えられます。傲慢な気持ちが出てきますよね？図3: ブリッジを廃止し、各ポッドにネットワークカードをインストールする

（1）新しいネットワークカードを追加する

このアイデアは非常に優れているように思えますが、前提条件として、VM 上に追加のネットワーク カードがあり、そのネットワーク カードを Pod に挿入できることが必要です。実際、VM に新しいネットワーク カードを追加することは、VMWare の vSphere などのツールを使用すると簡単に実行できます。たとえば、図 4 では、Brother はマウスを数回クリックするだけで、新しいネットワーク カードを VM に手動で追加しました。

図4: VMに新しいNICを手動で追加する

もちろん、API を通じてこのようなネットワーク カードの作成作業を自動的に完了することもできます。 AWS と Alibaba Cloud はどちらも、API を介して ECS インスタンスの Elastic Network Interface (ENI) の動的な作成をサポートしています。ただし、ECS インスタンスにバインドできる ENI の数には制限があります。たとえば、AWS は ECS インスタンスの構成に基づいて最大 15 個の ENI のみをバインドできます。 Alibaba Cloud にも同様の制限があります。エラスティック ネットワーク カードは、複数のクラウド サーバー間で移行できる独立した仮想ネットワーク カードであり、柔軟なサービスの拡張と移行を実現します。 ENI を作成して ECS インスタンスにバインドすることも、セカンダリ ENI を別途作成して ECS インスタンスにバインドすることもできます。 ENI には次の機能があります。

• ECS インスタンスで作成されたプライマリ NIC に加えて、ECS インスタンスは複数のセカンダリ NIC のバインドをサポートします。これらの補助ネットワーク カードと ECS インスタンスは、同じ VPC と同じアベイラビリティー ゾーンに属している必要があり、異なる仮想スイッチや異なるセキュリティ グループに属することもできます。
• 各 Elastic Network Card には、バインドされているインスタンスの仕様に応じて、複数のセカンダリ プライベート IP アドレスを割り当てることができます。
• あるインスタンスからセカンダリ ENI をアンバインドし、別のインスタンスに再バインドすると、ENI のプロパティは変更されず、ネットワーク トラフィックは新しいインスタンスに直接切り替えられます。
• ENIC はホットスワップ可能な操作をサポートしており、ECS インスタンス間で自由に移行できます。 ENIC にバインドされたインスタンスを切り替える場合、インスタンスを再起動する必要はないため、インスタンス上で実行されているサービスには影響しません。

（２）新しいネットワークカードをコンテナに挿入する

うーん...いいですね。新しいネットワーク カードを作成する方法があるようですが、それを Pod に挿入するにはどうすればよいでしょうか? Docker を例にして、新しく作成した eth10 という名前のネットワーク カードをコンテナーに挿入します。まずコンテナを起動します。このコンテナの PID が 2022 であるとします。

 ~ # docker run -itd --net none ubuntu : 16.04

ホスト環境で以下のコマンドを実行して、eth10 をコンテナに配置し、eth0 に名前を変更し、電源をオンにして、DHCP を有効にします。

 ~ # mkdir / var / run / netns
 ~ # ln - sf / proc / 2022 / ns / net / var / run / netns / 2022
 ~ # ip リンクセットdev eth10 netns 2022
 ~ # ip netns exec 2022 ip link set eth10 name eth0
 ~ # ip netns exec 2022 ip link eth0 を設定する
~ # ip netns exec 2022 dhclient eth0

一連の激しい操作の後、eth10 はホスト マシン上で表示されなくなりました。コンテナ内でこのコマンドを実行すると、追加のネットワーク カードがあることがわかります。

 ~ # ifconfig -a

実際、正確に言うと、上記の操作はコンテナのネットワーク ns に eth10 を挿入することです。 Pod は基本的に同じネットワーク NS を共有するコンテナのコレクションであるため、これらの操作を Pod に適用すると何が起こるかは想像がつくでしょう。

図 2 と 3 を並べ替えてみましょう。図 5 は私たちが夢見ていたもので、図 1 と 2 の利点を組み合わせた新しいソリューションです。図 2 のきめ細かいリソース仮想化方法を維持しながら、ネットワーク トラフィックを図 1 の VM のようにオープンにし、それぞれが独自の方向に進むことができます。図5: マルチNICをサポートするアンダーレイ

（３）パフォーマンス

前回の記事で述べたように、VM をベンチマークとして使用して比較すると、伝送パフォーマンスの点で次のようになります。

• オーバーレイ モードの伝送パフォーマンスは約 20 ～ 30% 低下します。トンネルによって圧縮解除/カプセル化の損失が発生するため、ポッドに出入りするトラフィックはネットワーク スタックを 2 回通過する必要があります (図 6 に示すように、2 回の入力と 2 回の出力)。解凍/カプセル化のコストは明らかですが、ネットワーク スタックを 2 回通過するコストは見落とされがちです。図 6 では、「iptables オーバーヘッド」が赤でマークされています。これは、この部分が追加のワークロードであることを意味し、この部分のワークロードは実際に削除できることを示しています。
• host-gw モードではパフォーマンスが約 10% 低下します。その理由は、オーバーレイ モードと同様に、ホスト間のルーティングでもネットワーク スタックを 2 回通過する必要があるためです。

図6: ポッドとの間のトラフィックはネットワークスタックを複数回通過します

Underlay のパフォーマンスの低下はどうでしょうか?ベンチマークと比較すると、パフォーマンスの低下はほとんどありません。理由は簡単にわかります。解凍/カプセル化がなく、ネットワーク スタックを 2 回通過する必要がないからです。また、Alibaba Cloud チームが自社の Web サイトで公開したパフォーマンス テスト比較レポートも添付します。レポートのリンクをここに貼っておきますので、興味のある学生は自分で勉強することができます。

図7: パフォーマンス比較

3. まとめ

実際、K8s の Overlay/host-gw/Underlay ネットワーク モードの実装は、マルチ ネットワーク ns と切り離せません。しかし、Underlay はそれをよりクリーンに、より直感的に、そしてより効率的に利用しますが、コストも高くなります。周志明教授は著書『鳳凰建築』の中で次のように述べています。「本当に大規模なデータセンターや大規模システムの場合、アンダーレイ モードが最も発展の可能性が高いネットワーク モードです。」このソリューションは、ハードウェア機能を最大限に活用でき、多くの場合、最高のパフォーマンスを実現します。ただし、ハードウェアと基盤となるネットワーク環境に直接依存するため、ソフトウェアとハ​​ードウェアの状況に応じて展開する必要があり、オーバーレイ ネットワークのすぐに使用できる柔軟性を実現することは困難です。これら二つの記事を読んで、周先生がおっしゃったことをより深く理解できたでしょうか？ 「アンダーレイにおけるマルチネットワーク ns の適用 - この記事」の冒頭で提起された 3 つの質問に対する答えはありますか?