Contrail サービス

Kubernetes サービス

サービスは、Kubernetes のコアオブジェクトです。第3章では、Kubernetes サービスとは何か、YAML ファイルを使用してサービスオブジェクトを作成する方法について学びました。機能的には、サービスは、クライアントとサーバーの間を移動するレイヤー 4 (トランスポートレイヤー) として実行されます。クライアントは、サービスを要求しているものである可能性があります。コンテキスト内のサーバーは、その要求に応答するバックエンドポッドです。このクライアントは、サービスによって公開されるフロントエンド a サービス IP およびサービスポートのみを認識し、どのバックエンドポッド (または pod IP) がサービスリクエストに実際に応答するかについては、気にする必要はありません。クラスター内では、サービス IP (クラスター IP とも呼ばれる) が一種の仮想 IP (VIP) です。

Contrail 環境では、浮動 IP によって実装されます。

Contrail Kubernetes の統合環境では、次の3種類のサービスがサポートされています。

• clusterIP

• nodePort

• ロード

では’、サービスがどのように Contrail に実装されているかを見てみましょう。

Contrail サービス

第3章で’は、Kubernetes のサービスのデフォルト実装を kube に導入しました。第3章では、CNI プロバイダが独自の実装を持つことができることを述べました。Contrail では、nodePort サービスは kube によって実装されています。ただし、clusterIP および loadbalancer サービスは、Contrail’のロードバランサー (LB) によって実装されています。

Contrail で Kubernetes サービスの詳細について説明する前’に、Contrail における従来の openstack ベースのロードバランサーの概念を確認しておきましょう。

Contrail Openstack ロードバランサー

ロードバランサーは Contrail 最初のリリース以降にサポートされている基礎機能です。アプリケーションにサービスを提供する Vm のプールを作成し、1つのバーチャル ip (VIP) をフロントエンド IP としてクライアントに向けて共有できます。Figure 1は、Contrail ロードバランサーとそのコンポーネントを示しています。

Figure 1: Contrail OpenStack ロードバランサー

Figure 1には、以下のような特徴があります。

• 内部 VIP 30.1.1.1 を使用して、LB が作成されます。各リスニングポートに対して、負荷分散リスナーも作成されます。

• すべてのバックエンド Vm は、30.1.1.0/24 サブネットを使用したプールを構成します。’これは、LB s 内部 VIP と同じです。

• プール内の各バックエンド VM (メンバーとも呼ばれる) には、プールサブネット 30.1.1.0/24 から IP が割り当てられます。

• ポンドを外部の世界に公開するために、外部 VIP 20.1.1.1 となるもう1つの VIP が割り当てられています。

• クライアントは、サービス全体を表す1つの外部 VIP 20.1.1.1 のみを認識します。

• 負荷がクライアントからの要求を認識すると、TCP 接続のプロキシ化が行われます。つまり、クライアントとの TCP 接続を確立し、クライアント’の HTTP/HTTPS 要求を抽出して、プールからバックエンド vm の1つに新しい tcp 接続を作成し、新しい tcp 接続で要求を送信することを意味します。

• LB が VM から応答を取得すると、応答をクライアントに転送します。

• また、クライアントが負荷分散への接続を切断すると、負荷分散によってバックエンド VM との接続が切断される場合もあります。

このロードバランサーモデルは、Kubernetes サービスの概念とよく似ていることがわかります。

• VIP はサービス IP です。

• バックエンド VM がバックエンドポッドになります。

• メンバーは OpenStack ではなく Kubernetes によって追加されています。

実際、Kubernetes サービス実装では Contrail、このモデルの重要な部分を再利用しています。サービスのロードバランシングをサポートするために、Contrail はロードバランサーを新しいドライバーで拡張します。ドライバーとともに、サービスは、レイヤー 4 (トランスポートレイヤー) で動作するのと同等のコストのマルチパス (ECMP) ロードバランサーとして実装されます。これは、OpenStack ロードバランサータイプによって使用されるプロキシモードと比較した場合の最大の違いです。

• 実際、どのロードバランサーでも、Contrail コンポーネントを使用してレールから Contrail と統合できます。

• 各ロードバランサーには、loadbalancer_provider タイプの Contrail に登録されたロードバランサードライバーがあります。

• Contrail は、ロードバランサー、リスナー、プール、メンバーの各オブジェクト Contrail を監視します。また、登録されたロードバランサードライバーを呼び出して、loadbalancer_provider タイプに基づいて他の必要なジョブを実行します。

• Contrail デフォルトでは、ECMP ロードバランサー (loadbalancer_provider はネイティブ) および haproxy ロードバランサー (loadbalancer_provider は opencontrail) に提供されます。

• OpenStack ロードバランサーは、haproxy ロードバランサーを使用しています。

• 一方、受信は概念的には、OpenStack ロードバランサーの方がレイヤー 7 (アプリケーション層) プロキシベースであるという意味ではさらに深くなっています。入口の詳細については、後のセクションで説明します。

Contrail サービスロードバランサー

サービス’ロードバランサーとそれに関連するオブジェクトについて見てみましょう。

Figure 2: サービスロードバランサー

の特長Figure 2は以下のとおりです。

• 各サービスはロードバランサーオブジェクトによって表されています。

• ロードバランサーオブジェクトには、loadbalancer_provider プロパティが用意されています。サービス実装では、「ネイティブ」と呼ばれる新しい loadbalancer_provider タイプが実装されています。

• 各サービスポートに対して、同じサービスロードバランサーに対してリスナーオブジェクトが作成されます。

• 各リスナーには、プールオブジェクトがあります。

• このプールにはメンバーが含まれており、バックエンドポッド数によっては、1つのプールに複数のメンバーが存在する場合があります。

• プール内の各メンバーオブジェクトは、バックエンドポッドの1つにマップされます。

• Contrail-kube は、k8s サービス向け kube-apiserver をリッスンし、custerIP またはロードバランサータイプのサービスが作成されると、ロードバランサーオブジェクトが loadbalancer_provider のプロパティをネイティブとして作成されます。

• ロードバランサーには、serviceIP と同じ仮想 IP VIP が含まれています。

• サービス ip/VIP は各バックエンドポッドのインターフェイスにリンクされます。これは ECMP ロードバランサードライバーで実行されます。

• サービス ip から複数のバックエンドポッドのインターフェイスへのリンクによって Contrail で ECMP のネクストホップが作成され、トラフィックは、ソースポッドからバックエンドポッドのいずれかに直接負荷を分散します。’その後、POD’s VRF テーブルに ecmp プレフィックスを表示します。

• Contrail は、エンドポイントのポッドリストに基づいて、kube のすべての変更について、kube のマネージャーを使用し続けることなく、最新のバックエンドポッドを把握し、プールのメンバーを更新します。

これまでに説明した最もFigure 2重要な点は、従来の neutron ロードバランサー (後で説明する’受信ロードバランサー) とは対照的に、このプロセスにはアプリケーションレイヤープロキシがないということです。Contrail サービスの実装は、レイヤー 4 (トランスポートレイヤー) ECMP ベースの負荷分散に基づいています。

ロードバランサーオブジェクトの Contrail

Contrail’ロードバランサーオブジェクトの詳細について詳しく説明しましたが、実際にはどのようなものであるかという疑問を持つかもしれません。それで’は、ロードバランサーとサポートオブジェクトについて少し詳しく見てみましょう。リスナー、プール、メンバー

Contrail セットアップでは、REST API をベースにした Contrail UI、CLI (カール)、またはサードパーティ製 UI ツールからオブジェクトデータを取得できます。実稼働環境では、利用できるものと便利なものに応じて、お気に入りを選択できます。

Curl’を使用してロードバランサーオブジェクトを見てみましょう。Curl ツールを使用すれば、そのオブジェクトを指す URL の FQDN が必要になります。

たとえば、次のようなサービスサービスのロードバランサーオブジェクト URL を見つけるには、ロードバランサーリストから web clusterip を探します。

特定のロードバランサー URL を使用して、特定の負荷分散オブジェクトの詳細を取得することができます。

この出力は非常に広範囲にわたっており、注目すべき情報がいくつかあることを除けば、現時点では関心のない多くの詳細情報が含まれています。

• Loadbalancer_properties では、負荷の高いサービス IP を VIP として使用しています。

• 負荷分散は、参照によってリスナーに接続されています。

• Loadbalancer_provider の属性はネイティブで、レイヤー 4 (トランスポートレイヤー) ECMP を実装するための新しい拡張機能である Kubernetes サービスを対象としています。

負荷分散とそれに関連するオブジェクトのその他の調査に’ついては、従来の Contrail UI を使用してみましょう。

各サービスには負荷分散オブジェクトがあります。Figure 3は、2つの負荷分散オブジェクトを示しています。

• ns-user-1-service-web-clusterip

• ns-user-1-service-web-clusterip-mp

Figure 3: ロードバランサーオブジェクトリスト

これは2つのサービスが作成されたことを示しています。サービスロードバランサーオブジェクト’の名前は、NS 名とサービス名を接続することで構成されるため、2つのサービスの名前を指定できます。

• サービス-web clusterip

• サービス-web clusterip mp

最初のロードバランサーオブジェクト ns-ユーザー-1-サービス web clusterip の左にある小さな三角形アイコンをクリックして展開し、右の [json の高度な表示] アイコンをクリックすると、curl キャプチャに表示されてい’た内容と同様の詳細情報を見ることができます。たとえば、VIP、ロード balancer_provider、it を参照する balancer_listener オブジェクトなどです。

Figure 4: Contrail ロードバランサー

ここから、+ 文字をクリックして loadbalancer_listener オブジェクトを拡大し、Figure 4に示すように詳細を確認できます。その’後、loadbalancer_pool が表示できます。もう一度展開すると、メンバーが表示されます。このプロセスを繰り返して、オブジェクトデータを調べることができます。

リスナー

LB 名前をクリックし、[listener] を選択してから展開し、JSON 形式で詳細を表示します。リスナーの詳細をご確認いただけます。リスナーは、サービスポート8888でリッスンしており、Figure 5のプールによって参照されています。

Figure 5: リスナー

プールとメンバー

この explorative プロセスを繰り返し実行すると、プールとその2つのメンバーが表示されます。このメンバーは、Figure 6およびFigure 7のように Pod のコンテナターゲットポートにマップされる80のポートを使用しています。

’次に、VROUTER VRF テーブルで pod を調べて、サービスロードバランサー ecmp 操作の詳細を Contrail 表示します。ロードバランサーオブジェクトに示されるロードバランサーとリスナー間の1対 N マッピングについて理解するには、’セットアップで複数ポートサービスの例も示します。’ここでは、vrouter フローテーブルを調べて、サービスパケットワークフローを示すことで、clusterip サービスのセクションを締めます。

Figure 6: グループ

Figure 7: レプリカ

Contrail サービスのセットアップ

調査を始める前に、’設定を見てみましょう。本書では、以下のデバイスを含むセットアップを構築しました。

• 1つの centos サーバーを k8s master および Contrail コントローラとして実行する

• k8s node および Contrail vRouter として実行される、2つの centos サーバー

• アンダーレイリーフとして実行される1つ Juniper QFX スイッチ

• ゲートウェイルーターとして実行されている1台の Juniper MX ルーター、またはスパイン

• 1つの centos サーバーをインターネットホストマシンとして実行する

Figure 8は、設定を示しています。

Figure 8: Contrail サービスのセットアップ

Contrail ClusterIP サービス

第3章では、clusterIP サービスを作成して検証する方法について説明しています。このセクションでは、Contrail’の特定の実装に関する重要な詳細について説明します。で’は続けて、Contrail サービスロードバランサーの実装の詳細について、いくつかのテストを追加してみてください。

ClusterIP as Floating ip

ClusterIP サービスの作成に使用される YAML ファイルを以下に示します。

ここ’では、第3章のサービスラボから得た内容を確認しています。

1つのポッドがバックエンドとして動作するように、単一のサービスを作成していることがわかります。ポッド内のラベルは、サービスのセレクターと同じです。Pod 名は、これが配備生成の pod であることも示しています。その後、ECMP の導入を拡張することができます。しかし、’その後、1つのポッドを守って、clusterip 実装の詳細を調べてみてください。

Contrail では、ClusterIP は実質的に floating IP の形で実装されています。サービスが作成されると、サービスサブネットからフローティング IP が割り当てられ、バックエンドポッドのすべての VMIs be が ECMP 負荷分散を形成するようになります。これで、すべてのバックエンドポッドが cluserIP 経由で到達できます (pod IP とともに使用されます)。この clusterIP (floating IP) は、クラスター内のクライアントポッドへの VIP として機能します。

ロードバランサータイプのサービスの場合、Contrail は2番目の浮動 IP を VIP として割り当てます。外部 VIP は、ゲートウェイルーターを介してクラスター外でアドバタイズされます。これらの詳細については、後ほど詳しくご確認ください。

UI から、自動的に割り当てられた浮動 IP をFigure 9の lusterIP として見ることができます。

Figure 9: 浮動 IP としてのクラスター IP

さらに、浮動 IP はポッド VMI と pod IP に関連付けられています。この場合、VMI はFigure 10に示す pod インターフェイスを表しています。

Figure 10: ポッドインターフェイス

このインターフェイスは、Figure 11に示すように、次の画面キャプチャと同様に詳細を表示するように拡張できます。

Figure 11: ポッドインターフェイスの詳細

Fip_list を展開すると’、以下の情報が表示されます。

サービス/clusterIP/FIP 10.105.139.153 は podIP/fixed_ip 10.47.255.238 にマップされます。Port_map は、ポート8888が nat_port であり、6がプロトコル番号であるため、プロトコル TCP を意味していると述べています。全体的な clusterIP: port 10.105.139.153: 8888 は podIP: targetPort 10.47.255.238:80、その逆に変換されます。

現在は、clusterIP を表す floating IP について理解しているので、NAT はサービスで発生します。NAT はフローテーブルで再検証されます。

バックエンドポッドの拡張

第 3’章の clusterip サービスの例では、サービスとバックエンドポッドを作成しました。ECMP を確認するには’、レプリカユニットを2個増やして2つ目のバックエンドポッドを生成してみましょう。これはより現実的なモデルです。1つのポイント障害を回避するために、各ポッドが互いにバックアップされるようになりました。

Kubernetes の精神を念頭に置いて、YAML ファイルを使用して手動で新しい web サーバポッドを作成するのではなく、このガイドで前述したように、導入に向けた拡張を考えてみてください。当社のサービスの例’では、目的に応じて配備オブジェクトを使用して、web サーバーポッドを生成しています。

レプリカ2を使用して導入環境を拡張することで、新しい web サーバポッドを作成すると同時に、新しい pod が起動します。その後、バックエンドポッド2個を、クライアントポッドと同じノード cent222、またはクライアントポッド用のローカルノードで実行しています。もう1つは、クライアントポッド’から離れたリモートノードであるもう一方のノード cent333 で実行されています。さらに、エンドポイントオブジェクトが更新され、現在のバックエンドポッドの最新のセットを反映したものになります。

’浮動 IP をもう一度チェックします。

Figure 12: クラスタ IP as Floating IP (ECMP)

Figure 12では、同じ浮動 IP を見ることができますが、現在は、それぞれが個別の pod を表す2つの podips に関連付けられています。

ECMP ルーティングテーブル

まず、’ecmp を検証してみましょう。’Figure 13の画面キャプチャでコントローラ’s ルーティングインスタンスのルーティングテーブルを見てみましょう。

Figure 13: 制御ノードルーティングインスタンステーブル

ルーティングインスタンス (RI) には、次の形式のフルネームが含まれています。

< DOMAIN >: < PROJECT >: < VN >: < RI >

ほとんどの場合、RI はそのバーチャルネットワークから同じ名前を継承するため、この場合、完全な IPv4 ルーティングテーブルには次の名前が付いています。

Inet. 0 は、ルーティングテーブルタイプがユニキャスト IPv4 であることを示します。他にも多くのテーブルがありますが、これは私たちにとって重要ではありません。

ClusterIP と同じ正確なプレフィックスを持つ2つのルーティングエントリがルーティングテーブルに表示され、それぞれが異なるノードをポイントする2つの異なる次ホップがあります。これにより、ルート伝播プロセスに関するヒントが得られます。両方のノード (compute) は、マスター (Contrail コントローラ) に対して同じ clusterIP を公表しており、実行中のバックエンドポッドが存在することを示しています。このルート伝播は XMPP を介して行われます。その後、マスター (Contrail コントローラ) には、その他のすべての計算ノードへのルートが反映されます。

コンピューティングノードのパースペクティブ

次に、クライアントポッドノード cent222 から開始して’、パケットが’Figure 14の画面キャプチャのバックアウトポッドにどのように転送されるかを理解するために、pod s VRF テーブルを見てみましょう。

Figure 14: vRouter VRF テーブル

Figure 14のスクリーンショットの最も重要な部分は、ルーティングエントリプレフィックスです。10.105.139.153/32 (1 つのルート)、これは clusterIP アドレスのようになっています。プレフィックスの下には、ECMP 複合サブ nh の数が含まれています。2. これは、プレフィックスが複数の潜在的な次ホップに到達することを示します。

左にある小さな三角形のアイコンをクリックして、ECMP ステートメントを拡張します。このプレフィックスの詳細については、Figure 15の次の画面キャプチャに示すように、詳しく説明されています。

この出力のすべての詳細をインポートするのが最も重要なのは、nh_index です。87は、clusterIP プレフィックスの次ホップ ID (NHID) です。VRouter エージェントの Docker からは、複合 NHID をさらに詳細に解決できます。これは複合型のネクストホップの下にあるメンバーであり、サブ Nhid に対しても適用されます。

Figure 15: vRouter ECMP の次ホップ

この出力から強調するには、以下の重要な情報が必要です。

• NHID 87 は、ECMP 合成の次ホップです。

• ECMP の次ホップには、2つのサブ次ホップが含まれています。ネクストホップ43とネクストホップ28は、バックエンドポッドへの個別のパスを示しています。

• ネクストホップ51は、リモートノードのバックエンドポッドへの MPLSoUDP トンネルを表すもので、現在のノードの cent222 からトンネルを確立し、送信元 IP がローカルファブリック IP 10.169.25.20 となり、ファブリック IP が10.169.25.21 であるもう1つのノードに設定されます。2つのバックエンドポッドがある場所を覚えている場合、これは2つのノード間の転送パスです。

• ネクストホップ37は、vif 0/8 (Oif: 8) に向けたローカルパスを表し、ローカルバックエンド’ポッド s インターフェイスでもあります。

VRouter vif インターフェイスを解決するには、vif--get 8 コマンドを使用します。

出力には、対応するローカルポッド’インターフェイスの名前、IP などが表示されます。

ClusterIP サービスワークフロー

Figure 16は、’clusterip サービスのロードバランサー ecmp ワークフローを示しています。

Figure 16: Contrail ClusterIP サービスロードバランサー ECMP 転送

この問題は、転送プレーンで発生しています。

• Node cent222 に設置された pod クライアントは、サービスサービスの web clusterip にアクセスする必要があります。これは、サービス’s clusterip 10.105.139.153 とポート8888に向かってパケットを送信します。

• ポッドクライアントは、デフォルトルートに基づいて、パケットを node cent222 vRouter に送信します。

• ノード cent222 上の vRouter は、パケットを取得し、対応する VRF テーブルをチェックして、次の2つのサブホップ ID 87 を取得します。これに 37 51 より、リモートおよびローカルのバックエンドポッドを表します。これは ECMP であることを示しています。

• Node cent222 上の vRouter は、ECMP アルゴリズムに基づいて、パケットをポッドの1つに転送することを開始します。リモートバックエンドポッドが選択されている場合、フローテーブルでフローを確立した後、MPLSoUDP トンネルを通じてノード cent333 上のリモートポッドにパケットが送信されます。同じフローに属する後続のすべてのパケットは、同じパスに従います。同じことが、ローカルのバックエンドポッドへのローカルパスにも適用されます。

複数ポートサービス

サービスレイヤー 4 ECMP とラボの負荷分散オブジェクトの動作について理解できるようになりました。Figure 17は、負荷分散と関連オブジェクトを示しており、1つの負荷で2つ以上の負荷リスナーを持つことがわかります。各リスナーには、1つまたは複数のメンバーを持つ個々のバックエンドプールがあります。

Figure 17: サービスロードバランサー

Kubernetes では、ロードバランサーとリスナー間のこの 1: N マッピングは、複数のポートを持つ1つのサービスとして、マルチポートサービスを示しています。It’の yaml ファイルを見てみましょう。svc/service-web-clusterip-mp:

追加された内容は、ポートリストのもう1つの項目です。コンテナー’s ターゲットポート90にマップされた新しいサービスポート9999。次に、2つのポートマッピングを使用して、それぞれのポートに名前、port1、port2 などをそれぞれ指定する必要があります。

ここで YAML ファイルを適用します。2つのポートを持つ新しいサービスサービスの web clusterip mp が作成されます。

すべてがうまくいって’いないでしょうか? 新しいサービスは、8888、以前の例でテストした古い1つ’のサービスポート、新しい9999ポートと同様に適切に動作するようになります。しかし、これは実際はそうではありません。で’は、調査してみましょう。

サービスポート8888の動作:

サービスポート 9999’は機能しません。

ポート9999への要求は拒否されます。その理由は、targetPort がポッドコンテナで実行されていないため、そのポートから応答を受け取ることができないからです。

第3章で導入された readinessProbe は、この状況を検知する公式な Kubernetes ツールであり、pod の準備が整っていない場合は再起動され、イベントをキャッチします。

このことを解決’するために、ポッド内で新しいサーバーを起動し、新しいポート90をリッスンしてみましょう。HTTP サーバーを開始する最も簡単な方法の1つは、python パッケージに同梱されている SimpleHTTPServer モジュールを使用することです。このテストでは、リスニングポートを90に設定する必要があります (デフォルト値は 8080)。

TargetPort がオンになっています。Cirros ポッドからサービスポート9999への要求を再び開始できるようになりました。今回は成功し、Python’s SimpleHTTPServer から返された web ページを取得します。

次に、受信する各要求について、SimpleHTTPServer は要求の送信元の IP アドレスを使用して1行の出力をログに記録します。この場合、要求はクライアントポッドから IP アドレスで受信されます。

Contrail フローテーブル

ここまでは、’clusterip サービスをテストして、’クライアントの要求をサービス IP に送信してきました。Contrail では、vrouter はすべてのパケット転送を行うモジュールです。Vrouter は、クライアントポッドからパケットを取得すると、vRouter モジュール内でクライアントポッド (クライアント) に対応する VRF テーブルを検索し、次ホップを取得して、正しい送信インターフェイスと適切なカプセル化を解決します。これまでのところ、クライアントとバックエンドポッドは2つの異なるノードに存在し、ソース vrouter は、MPLSoUDP トンネルで送信する必要のあるパケットを、バックエンドポッドが実行されているノードに対して決定します。最も興味を持っているのは何でしょうか。

• サービス IP およびバックエンドポッド IP をどのように相互に変換していますか?

• 比較のために、翻訳の前後で2つの IPs を取得して表示する方法はありますか。

最も簡単な方法は、パケットをキャプチャし、デコードしてから、結果を確認することです。しかし、これを実現するのは簡単なことではないかもしれません。まず、パケットをさまざまな場所で捕捉する必要があります。

• Pod インターフェイスでは、これはアドレスが変換された後で’、そのことは簡単です。

• ファブリックインターフェイスでは、これはパケットが変換されてポッドインターフェイスに到達する前に実行されます。ここでパケットは、ノード間でデータプレーンのパケットがトンネリングされるため、MPLSoUDP カプセル化によって行われます。

その後、pcap ファイルをコピーして読み込み、Wireshark を使用してデコードする必要があります。また、MPLSoUDP のカプセル化を認識するように Wireshark を設定する必要もあります。

もっと簡単な方法は、トラフィックフローに関する IP とポートの詳細を記録する vRouter フローテーブルを確認することです。それ’をテストするために、バックエンドの web の大規模なファイルを準備し、クライアントポッドからダウンロードしてみてみましょう。

そのため、クライアントポッド curl URL では、単にルートパスを与えるだけでなく、フォルダー内のファイルの’リストを取得する代わりに、次のようにファイルをプルしてみましょう。file.txt:

サーバーポッドで、ファイルのダウンロードが開始されたことを示すログが表示されます。

ファイル転送が進むにつれて、クライアントと’サーバーの両方のノードから、vrouter コンテナにフローテーブルを収集するために十分な時間ができました。

クライアントノードフローテーブル:

この出力のハイライトは以下のとおりです。

• クライアントポッドは、ポッド IP 10.47.255.237 から TCP 接続を開始し、サービス IP 10.101.102.27 およびサーバーポート9999の方向にランダムな発信元ポートを開きます。

• フロー TCP フラグ SSrEEr では、セッションが双方向で確立されていることを示します。

• このアクションは以下のとおりです。F は転送を意味します。ここでの NAT のような特殊処理は存在しないことに注意してください。

クライアントノード’の視点から見ると、サービス IP のみを見ることができます。また、バックエンドポッド ip をまったく認識していません。

サーバー’ノード Vrouter Docker コンテナのサーバーノードフローテーブルを見てみましょう。

2つ目のフローエントリは– 、まず、クライアント側のキャプチャで見ていたものと同じように見えます。VRouter ファブリックインターフェイスは、トラフィックによって、リモートクライアントポッドノードから MPLSoUDP トンネル上で実行されます。宛先 IP とポートは、それぞれサービス IP とサービスポートです。特に重要なことはありません。

ただし、フローアクションは F ではなく N (DPd) に設定されるようになりました。フローコマンド出力のヘッダー行によると、DNAT (宛先アドレス変換) は DPAT (宛先ポート変換) –を使用していることを NAT 意味します。これは、サービス IP とサービスポートの両方がバックエンドポッド ip およびポートに変換されます。

それでは、最初のフローエントリを見てみましょう。送信元 IP 10.47.255.238 はバックエンドポッド IP であり、送信元ポートは、バックエンドコンテナでオープンされた Python サーバーポート90です。当然のことですが、これはファイルのダウンロードがまだ進行中であることを示すトラフィックを返しています。アクションは NAT (N) でもありますが、今回は逆引き操作–ソース NAT (SNAT) およびソース PAT (spat) を対象としています。

VRouter は、バックエンド’のソース IP 送信元ポートを MPLSoUDP トンネルに入れてからリモートノードのクライアントポッドに戻す前に、サービス IP とポートに変換します。

完全なエンドツーエンドのトラフィックフローをFigure 18に示します。

Figure 18: ClusterIP サービストラフィックフロー (NAT)

Contrail ロードバランサーサービス

第3章ロードバランサーサービスについて簡単に説明しました。ここでは、サービスをクラスター外の外部環境に公開することが目標である場合、サービス YAML ファイルで LoadBalancer として ServiceType を指定するだけで済みます。

Contrail では、次のタイプのサービスをいつでも行うことができます。ロードバランサーは、クラスター内の他のポッドに割り当てられて公開されるだけでなく、パブリックな floating IP プールの floating IP が外部 IP として割り当てられ、クラスター外のパブリック世界に公開されるようになります。

ClusterIP はクラスター内のクライアントへの VIP として動作しますが、floating ip または外部 ip は、そのクラスター外にあるクライアントに対応する VIP として機能します。たとえば、ゲートウェイルーター全体でサービスに要求を送信するリモートインターネットホストなどです。

次のセクションでは、ロードバランサータイプのサービスが、Kubernetes クラスター、ファブリックスイッチ、ゲートウェイルーター、インターネットホストなど、エンドツーエンドのラボセットアップでどのように機能するかを示します。

浮動 IP としての外部 IP

ロード’バランサーサービスの yaml ファイルを見てみましょう。これ’は、サービスタイプを宣言するラインがもう1つだけあることを除けば、clusterip サービスと同じです。

サービスを作成して検証します。

出力を clusterIP サービスタイプと比較します。このとき、外部 IP 列に IP アドレスが割り当てられています。「Floating IP プール」’セクションで取り上げた内容を覚えている場合は、この外部 ip が実際には、NS FIP プールまたはグローバル FIP プールから割り当てられた FIP であることを理解しておく必要があります。サービスオブジェクト YAML ファイルに特定の浮動 IP プール情報を提供していませんでした。このため、右のフローティング IP プールが自動的に使用されます。

ロードバランサーサービスでは、現在は2つの floating IPs があることが UI からわかるようになっています。Figure 19に示すように、1つは clusterip (内部 vip) であり、もう一方は外部 ip (外部 vip) として使用されます。

Figure 19: ロードバランサーサービス用の2つの Floating IPs

両方のフローティング IPs は、次の画面キャプチャに示される pod インターフェイスに関連付けられています (Figure 20)。

Figure 20: ポッドインターフェイス

タップインターフェイスを展開すると、次のような2つの浮動 IPs が表示されます。 fip_list:

Figure 21: ポッドインターフェイスの詳細

この2種類のサービスの違いを理解しておくことは、ロードバランサーサービスにとって、FIP は、ゲートウェイルーターにアドバタイズされ、外部の VIP として動作するパブリック FIP プールから余分に割り当てられていることになります。これがロードバランサーサービスによって外部世界に公開されています。

ゲートウェイルーター VRF テーブル

Contrail floating IP セクションでは、’浮動 ip の提供方法を学習しました。しかし、ここ’では、主な概念を確認して Contrail サービスの実装でどのように機能するかを理解できるようにしています。

浮動 IP VN のルートターゲットのコミュニティー設定により、インターネットホストからアクセス可能になります。これにより、事実上、サービスは、クラスター内でのみでなく、インターネットにも公開されるようになりました。ゲートウェイルーター’s VRF テーブルを調べると、以下のようになります。

この浮動 IP ホストルートは、ゲートウェイルーターによって、Contrail コントローラ–から学習されます。 – Contrail 制御ノードは、コンピューティングノードとゲートウェイルーター間のルートを反映する標準の MP BGP VPN RR として動作します。同じルートの詳細なバージョンでは、プロセスに関する詳細情報が表示されます。

ここでの出力のハイライトは以下のとおりです。

• 送信元は、ルート BGP ピア学習していることを示しています。10.169.25.19 は、ガイド’ラボの Contrail コントローラ (および Kubernetes master) です。

• プロトコルのネクストホップは、ルートの生成者を示します。10.169.25.20 は、バックエンド web サーバポッドが実行されているノード cent222 です。

• -2/2/0.32771 は、ゲートウェイルーターとノード cent333 の間の (MPLS オーバー) GRE トンネルを表すインターフェイスです。

ロードバランサーサービスワークフロー

要約すると、外部 IP がゲートウェイルーターに通知され、ルーター’の VRF テーブルに読み込まれるときに、フローティング ip がサービスに与えられます。MPLSoGRE トンネルを介して、インターネットホストが floating IP に要求を送信すると、ゲートウェイルーターは、バックエンドポッドが置かれているコンピューティングノードにそれを転送します。

Figure 22は、パケットフローを示しています。

Figure 22: ロードバランサーサービスワークフロー

Figure 22の全記事をご覧ください。

• ルートターゲットを使用して、パブリック VN から FIP プールを作成します。VN は、MP-BGP 経由でリモートゲートウェイルーターにアドバタイズされます。

• ラベルアプリを使用した pod の作成: Kubernetes では、ノード cent333 で pod が作成されるように決定されます。このノードは XMPP 経由で pod IP を公開しています。

• Loadbalancer タイプのサービスを、サービスポートとラベルセレクター app = webserver を使用して作成します。Kubernetes は、サービス IP を割り当てます。

• Kubernetes は、マッチングされたラベルを使用して pod を検索し、ポッドの IP アドレスとポート情報でエンドポイントを更新します。

• Contrail ロードバランサーのインスタンスを作成し、フローティング IP を割り当てます。Contrail は、この浮動 IP を pod インターフェイスに関連付けることもできます。そのため、浮動 ip と pod IP の間で1対1の NAT の運用が発生します。

• XMPP を使用すると、node cent333 はこの浮動 IP Contrail をゲートウェイルーターにアドバタイズし、コントローラ cent111 にアドバタイズします。

• VRF の floating IP プレフィックスを受信すると、ゲートウェイルーターは、プレフィックスの RT と想定される日時’が一致していることを確認し、ローカルのテーブルにプレフィックスをインポートします。この時点で、cent333 は浮動 IP の次ホップを学習します。そのため、cent333 へのソフト GRE トンネルを生成します。

• ゲートウェイルーターは、インターネットから floating IP への要求を認識すると、cent333 over GRE トンネルを介し MPLS てその要求をノードに送信します。

• このノード内の vRouter は、浮動 IP 宛てのパケットを認識し、NAT を実行して、適切なバックエンドのポッドにパケットを送信します。

ロードバランサーサービスの検証

インターネットホストからバックエンドのポッドへのエンドツーエンドのサービスアクセスを確認する’には、インターネットホストデスクトップにログインし、URL を http://101.101.101.252:8888 にポイントしてブラウザーを起動します。

返された web ページは、Figure 23の下のブラウザーで確認できます。

Figure 23: エンドツーエンドのサービスを確認する

テストを簡素化するために、インターネットホストに SSH を接続して、curl ツールでテストすることもできます。

Kubernetes のサービスをインターネットから入手できます。

ロードバランサーサービス ECMP

ロード’バランサーの種類のサービスをインターネットに公開する方法と、フローティング IP がどのようにトリックを出したかを見てきました。『 ClusterIP サービスのセクションでは’、サービスロードバランサー ecmp の仕組みについても説明しました。しかし、どのよう’にしても、ecmp の処理がロードバランサータイプのサービスで動作するのはどのようなものではありませんでした。このことを確認するために、RC を拡張して、サービスの背後にバックアウトした1つのポッドを生成することができます。

ここ’で疑問があります。ゲートウェイルーター’の観点から見ると、異なるノードに2個のポッドがあり、現在、バックエンドとしてサービス要求を取得した場合、どのノードでトラフィックを転送するかを選択します。

ゲートウェイ’ルーター’の VRF テーブルをもう一度確認してみてください。

前の例で示したよう’に、同じ浮動 IP プレフィックスがインポートされますが、今では同じルートが2回学習され、追加の MPLSoGRE トンネルが作成される点が異なります。以前は、clusterIP サービスの例では、show route コマンドで detail オプションを使用してトンネルエンドポイントを検索しました。今度は、ソフト GRE gr インターフェースを調べて、同じものを見つけます。

Gr インターフェイスの IP ヘッダーは、GRE トンネルの2つのエンドポイントを示します。

• 10.169.25.20:192.168.0.204: ここでは、ノード cent222 とゲートウェイルーターの間にトンネルを置いています。

• 10.169.25.21:192.168.0.204: ここでは、ノード cent333 とゲートウェイルーターの間にトンネルを置いています。

ゲートウェイルーターで2つのトンネルが必要になり、それぞれがバックエンドポッドを実行している異なるノードをポイントするようになります。今では、ルーターは、同じ浮動 IP へのサービス要求を取得するたびに、2つの GRE tun-nels の間で ECMP 負荷分散を実行していると考えています。その’ことを確認してみましょう。

ロードバランサーサービス ECMP を検証します。

ECMP を確認する’ために、web ページをもう少しだけ取得してみましょう。その結果、最終的には、両方の pod IPs が表示されるようになります。

この問題が発生することはありません。

唯一の web ページは、ノード cent222 で実行される最初のバックエンドポッド10.47.255.236、webserver-846c9ccb8b-xkjpw からのものです。他の1つは表示されません。そのため、必要な ECMP はまだ発生していません。しかし、詳細または高度なキーワード’を使用してルートを調べると、根本原因が見つかります。

このことは、ルーターが両方のノードの同じプレフィックスを学習していても、1つだけ’がアクティブであり、他方はベストではないため、その他のメリットは有効であることを示しています。そのため、2つ目のルートと対応する GRE インターフェイス gr-2/0.32771 が転送テーブルにロードされることはありません。

これは、Junos BGP パス選択のデフォルトの動作ですが、このガイドの範囲を越えた詳細な説明が記載されています。

この問題を解決するには、VRF の表の下で、マルチパス vpn に対応していないコストのノブを有効にします。

では’、VRF テーブルをもう一度チェックしてみましょう。

IP プレフィックスとして GRE インターフェイスを使用したマルチパスでは、「転送テーブル」は、以下のようになります。

ここで、curl または web ブラウザーを使用してインターネットホストから複数回 web ページを取得’しようとすると– 、バックエンドポッドが要求と応答を返すランダムな結果が得られます。

Figure 24は、エンドツーエンドのパケットフローを示しています。

Figure 24: ロードバランサーサービス ECMP