Kubernetesのネットワーキングの図解ガイド。 パート1および2

ご注意 perev。 ：記事の著者であるAmanpreet Singhは自分自身を「まだネットワークの世界の初心者」と呼んでいますが、これが彼がKubernetesの基本的なデバイス（本番で使用）を理解し、非常にアクセスしやすい素材をコミュニティとビジュアルで共有するきっかけとなりましたイラスト。 原文では2つの 部分に分かれていますが、この翻訳ではそれらを1つの記事にまとめました。



したがって、Kubernetesクラスターで多くのサービスを開始し、その恩恵を享受しています...または少なくともそれを行うつもりです。 ただし、クラスターを構成および管理するためのユーティリティは多数ありますが、すべてが「内部」でどのように機能するかに関心があります。 何かが壊れている場合はどこを探しますか？ 私はこれが重要であることを自分で知っています。

Kubernetesを使用すると、簡単に開始できます。 しかし、内部を見ると、複雑なシステムが存在します。 多数の「動く」コンポーネントがあり、障害の可能性に備えたい場合は、その機能と相互作用を理解する必要があります。 Kubernetesの最も複雑で、おそらく最も重要なコンポーネントの1つはネットワークです。

だから私はそれがどのように機能するかを正確に理解することに決めました：私はドキュメントを読み、レポートを聞き、さらにコードベースを見ました-そしてこれが私が見つけたものです...

ネットワークモデルKubernetes

Kubernetesネットワークデバイスの中心には、重要なアーキテクチャ上の原則があります。「 各炉には独自のIPがあります 。」

IP囲炉裏はすべてのコンテナに分割され、他のすべての囲炉裏からアクセス可能（ルーティング可能）です。 ノードで一時停止コンテナが機能していることに気付いたことがありますか？ それらは「 サンドボックスコンテナ」とも呼ばれます。これは、すべてのポッドコンテナで使用されるネットワークネームスペース（netns）を予約および管理することがその仕事であるためです。 このため、ポッドのIPは、コンテナが死んでその場所に新しいコンテナが作成された場合でも変更されません。 このモデル-各炉床のIP（ポッドごとのIP） -の大きな利点は、基盤となるホスト上のIP /ポートの衝突がないことです。 また、どのポートがアプリケーションを使用するかを心配する必要はありません。

したがって、Kubernetesの唯一の要件は、ハースのこれらのすべてのIPアドレスが、どのホストにあるかに関係なく、他のハースからアクセス可能/ルーティング可能でなければならないことです。

ノード内の相互作用（ノード内）

最初のステップは、1つのノードのポッドが相互に通信できることを確認することです。 次に、このアイデアは、ノード間、インターネットなどとの相互作用に拡張されます。

各Kubernetesノード（この場合はLinuxマシン）には、ルートネットワーク名前空間-root netnsがあります。 メインネットワークインターフェイス-eth0-は、このルートネットにあります。



同様に、各囲炉裏には、ルートイーサネットに接続する仮想イーサネットインターフェイスを備えた独自のネットがあります。 実際、これは一方がルートネットに、もう一方がネットにある仮想リンクです。



囲炉裏の端はeth0という名前ですeth0は基礎となるホストを知らず、独自のルートネットワーク構成があると考えているためです。 もう一方の端には、 vethxxxような名前が付けられます。 ifconfigまたはip aコマンドを使用して、Kubernetesホストでこれらのインターフェイスをすべて表示できます。

これは、アセンブリ上のすべての囲炉裏の配置です。 ポッドが相互に通信するために、Linuxイーサネットブリッジcbr0がcbr0ます。 Dockerはdocker0と呼ばれる同様のブリッジを使用します。



brctl showコマンドを使用して、ブリッジをリストできます。

パケットがpod1からpod1に送信されたpod1しpod2 ：

1. eth0からeth0を介してpod1を通過し、vethxxxを介してルートネットに到達しvethxxx 。
2. cbr0 、ARP要求を使用して「このようなIPアドレスを持っているのは誰ですか？」
3. vethyyyは、正しいIPを持っていると応答します。そのため、ブリッジはパケットの転送先を認識します。
4. パケットはvethyyy到達し、仮想リンクを通過して、pod2が所有するpod2ます。

したがって、1つのノードのコンテナは互いに通信します。 明らかに、他の対話方法もありますが、これがおそらく最も簡単です。 Dockerも使用します。

ノード間通信

前述のように、囲炉裏にはすべてのノードからアクセスできる必要があります。 また、Kubernetesにとって、これがどのように実装されるかはまったく問題ではありません。 したがって、L2（ノード間のARP）、L3（ノード間のIPルーティング-クラウドプロバイダーのルーティングテーブルに類似）、オーバーレイネットワーク、さらにはハトを使用できます。 各ノードには、ポッドによって発行されたIPアドレスの一意のCIDRブロック（IP範囲）が割り当てられているため、各ポッドには独自の一意のIPがあり、他のノードのポッドと競合しません。

ほとんどの場合、特にクラウド環境では、クラウドプロバイダーはルーティングテーブルを使用して、パケットが正しい受信者に確実に届くようにします。 同じことは、各ノードのルートを使用して構成できます。 問題を解決する他の多くのネットワークプラグインもあります。

上記のような2つのノードの例を考えてみましょう。 各ノードには、異なるネットワーク名前空間、ネットワークインターフェイス、およびブリッジがあります。



パッケージがpod1からpod4 （別のノード上）に続くと仮定します。

1. eth0からeth0を介してpod1を通過し、vethxxxを介してルートネットに到達しvethxxx 。
2. これcbr0 、宛先を検索してARP要求を作成します。
3. このノードのpod4対応するIPアドレスを持たないため、 cbr0からメインネットワークインターフェイスeth0にpod4ます。
4. node1マシンを残し、値src=pod1およびdst=pod4ネットワークワイヤに残ります。
5. ルーティングテーブルでは、各ノードのCIDRブロックに対してルーティングが設定されます。それに応じて、パケットは、CIDRブロックにIPアドレスpod4が含まれるノードに送信されます。
6. パケットは、 node2メインネットワークインターフェイスeth0到着しnode2 。 現在、 pod4 eth0 IPアドレスでpod4ませんが、ノードでIP転送が有効になっているため、パケットはcbr0リダイレクトされます。 ホストルーティングテーブルは、 pod4 IPアドレスに一致するルートについてスキャンされます。 このノードのCIDRブロックの宛先としてcbr0を見つけます。 route -nコマンドを使用してホストルーティングテーブルを表示できます。 cbr0ようにcbr0のルートが表示されます。
   
   
7. ブリッジはパケットをvethyyy 、ARP要求をvethyyyし、IPがvethyyy属していることをvethyyyます。
8. パケットは仮想リンクを通過してpod4入りpod4 。

オーバーレイネットワーク

オーバーレイネットワークはデフォルトでは必要ありませんが、状況によっては便利です。 たとえば、十分なIPアドレス空間がない場合、またはネットワークが追加のルートを管理できない場合。 または、オーバーレイによって提供される追加の管理機能を取得したい場合。 よくあるケースは、クラウドプロバイダーのルーティングテーブルでサポートされるルートの数に制限があることです。 たとえば、AWSのルーティングテーブルの場合、ネットワークパフォーマンスに影響を与えることなく、最大50のルートのサポートが宣言されます。 50を超えるKubernetesノードが必要な場合、AWSルーティングテーブルでは不十分になります。 このような場合、オーバーレイネットワークが役立ちます。

オーバーレイネットワークは、ノード間のネットワークを通過するパケットをカプセル化します。 すべてのパケットをカプセル化およびカプセル化解除すると、遅延と複雑さが少し増えるため、使用しない方がよい場合があります。 多くの場合、これは必要ありません。使用を決定する際に検討する価値があります。

オーバーレイネットワークでトラフィックがどのように実行されるかを理解するために、CoreOSのオープンソースプロジェクトであるフランネルの例を考えてみましょう。



ここでは、前の設定と同様の設定が表示されていますが、 flannel0と呼ばれる新しい仮想イーサネットデバイスが表示されflannel0これはルートネームスペース（ルートネット）にあります。 これは、仮想拡張LAN（VXLAN）の実装であり、Linuxの単なる別のネットワークインターフェイスです。

パッケージをpod1からpod4 （別のノード上にある）に渡すと、次のようになります。

1. eth0を通過するパケットは、pod1に属するpod1を残して、vethxxxのルートネットにvethxxxます。
2. cbr0 、宛先を見つけるためにARP要求を作成します。
3. • このノードにはpod4に対応するIPアドレスがないため、ブリッジはpod4にパケットを送信します。ノードのルーティングテーブルは、炉床のネットワーク範囲のターゲットとしてflannel0を使用するように構成されます。
   • flanneldデーモンは、Kubernetes apiserverまたは基盤となるetcdと対話し、そこから炉床のすべてのIPアドレスと、それらに配置されているノードに関する情報を受信します。 したがって、flannelは、囲炉裏のIPアドレスとノードのIPアドレスの適切なマッピング（ユーザー空間内）を作成します。 flannel0はパケットをflannel0 、送信元および宛先IPアドレスを対応するノードに変更する追加ヘッダー付きのUDPパケットでラップし、特別なvxlanポート（通常8472）に送信します。
     
     
     
     マッピングはユーザー空間にありますが、実際のデータのカプセル化と通過はカーネル空間で行われるため、十分に高速です。
   • カプセル化されたパケットは、ホストトラフィックのルーティングを担当するため、 eth0を介して送信されます。
4. パケットは、ノードのIPアドレスを送信元および宛先としてノードを離れます。
5. クラウドプロバイダーのルーティングテーブルは、ノード間でトラフィックをルーティングする方法をすでに知っているため、パケットは受信ノードnode2送信されnode2 。
6. • パケットはnode2 eth0に到着しnode2 。 特別なvxlanがポートとして使用されるため、カーネルはパケットをflannel0送信しflannel0 。
   • flannel0はパッケージのカプセル化をflannel0 、ルートネットに転送します。 パケットは、ノードのIPアドレスを送信元および宛先としてノードを離れます。 追加のパスは、通常の（非認証）ネットワークの場合と一致します。
   • IP転送が有効になっているため、カーネルはルーティングテーブルに従ってパケットをcbr0に送信します。
7. ブリッジはパケットをvethyyy 、ARP要求を作成し、目的のIPアドレスがvethyyy属していることをvethyyyます。
8. パケットは仮想リンクを通過してpod4入りpod4 。

実装ごとにわずかな違いがあるかもしれませんが、全体として、これがKubernetesのオーバーレイネットワークの仕組みです。 Kubernetesでの使用が必要であるという一般的な誤解がありますが、真実はすべてが特定のケースに依存するということです。 そのため、まず絶対に必要な場合にのみ使用するようにしてください。

翻訳者からのPS

ブログもご覧ください。

• 「 Kubernetesでのネットワーキングの図解ガイド。」 パート3 ";
• “ Kubernetesのネットワークの舞台裏 ”;
• “ Kubernetesのネットワークパフォーマンスの比較 ”;
• 「 Container Networking Interface（CNI）-Linuxコンテナのネットワークインターフェイスおよび標準 」;
• 「kubectlの実行が開始されるとKubernetesで何が起こりますか？」： パート1およびパート2 ;
• 「 Kubernetesスケジューラは実際にどのように機能しますか？」 ";
• 「 手頃な価格のサービスとしてKubernetesを使用したインフラストラクチャ 。」