Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

ON THIS PAGE

Contrail 受信

 

第3章には、基本的な事柄、サービスへの関係、入口タイプ、各タイプの YAML ファイルが含まれています。

この章では、Contrail 実装における受信ワークフローの詳細について説明した後、いくつかのテストケースを使用して、Contrail 環境での受信を実証し、検証します。

入口ロードバランサーの Contrail

Contrail’s サービスの実装と同様に、Contrail 受信もロードバランサーを介して実装されますが、異なる loadbalancer_provider 属性を使用します。したがって、contrail の監視コンポーネントは、さまざまなアクションを実行して、Contrail の環境で受信機能を実装します。

Kubernetes アーキテクチャのセクション Contrail では、Kubernetes と Contrail の間でオブジェクトマッピングを行いました。 Kubernetes service map (ネイティブ) および受信マップが Haproxy ロードバランサーにマップされます。

ロードバランサーとその関連オブジェクト (リスナー、プール、メンバー) について調査していた場合、『サービスセクション』では’、ロードバランサーの loadbalancer_provider タイプがネイティブであることに気付きました。

このセクション’では、受信したロードバランサーの’loadbalancer_provider タイプが opencontrail であることを確認します。また’、サービスロードバランサーと受信ロードバランサーの類似点と相違点についても説明します。

Contrail 受信ワークフロー

Contrail Kubernetes 環境で受信が設定されると、そのイベントは他のシステムコンポーネントによって認識され、多数のアクションがトリガーされます。このガイドでは、ディープレベルの実装については扱いませんが、高レベルでは次のようなワークフローになります。

  • Contrail kube マネージャーは、kube api サーバーのイベントをリッスンしています。

  • ユーザーが受信オブジェクト (ルール) を作成します。

  • Contrail kube マネージャーは、kube-apiserver からイベントを取得します。

  • Contrail は、contrail DB でロードバランサーオブジェクトを作成し、ロード balancer_ プロバイダタイプを受信用のオープンな contrail (サービスに対してネイティブ) として設定します。

前に説明したように、contrail モニターコンポーネントは、ロード balancer_provider タイプに基づいてロードバランサー作成イベントを認識し、指定されたロード balancer_provider タイプの登録済みロードバランサードライバーを呼び出します。

  • Load balancer_provider type がネイティブの場合、ecmp loadbalancer ドライバーを起動します。このロードバランシングは、前述のセクションで確認しています。

  • Load balancer_provider タイプが open contrail の場合、Kubernetes ノードで haproxy プロセスが起動するきっかけとなる、haproxy ロードバランサードライバーを呼び出します。

ご覧のように、Contrail は Contrail Kubernetes オブジェクトマッピングのセクションを読みながら、haproxy ロードバランサーを使用して受信を実装しています。第3章では、受信コントローラーについて説明し、複数の受信コントローラを Contrail に共存させる方法を示します。Contrail 環境では、Contrail-kube マネージャーが入口コントローラーの役割を再生します。ユーザーが入力した受信ルールを読み取り、ロードバランサーにプログラムします。また

  • 受信オブジェクトごとに1つのロードバランサーが作成されます。

  • 受信用に2つの haproxy プロセスが作成され、それらがアクティブ/スタンバイモードで動作しています。

    • 1つの計算ノードでアクティブな haproxy プロセスが実行されます。

    • もう1つのコンピューティングノードはスタンバイの haproxy プロセスを実行します。

  • Haproxy プロセスはどちらも、受信オブジェクトに定義されたルールに基づいて適切な構成でプログラムされます。

受信トラフィックフローの Contrail

オーバーレイトラフィックのタイプなど、クライアントの要求は、要求を開始したユーザーに応じて、2つの異なるソースから取得されることがあります。

  • 内部要求: クラスター内の別のポッドから着信するリクエスト

  • 外部要求: クラスター外のインターネットホストから送られてくる要求

この2つの場合の唯一の違いは、トラフィックがアクティブな haproxy に到達する方法です。入口には2つの IPs が割り当てられます。クラスター内部仮想 IP と外部仮想 IP。

クライアントの要求に対するトラフィックフローは以下のとおりです。

  1. 内部の要求では、受信’した内部 VIP を直接使用します。
  2. 外部要求の場合、’最初に受信した外部– VIP は、外部’に公開されている浮動 IP、FIP セクションで説明したように、’NAT が開始したときの状態を示しています。NAT 処理後、トラフィックは内部受信 VIP に転送されます。
  3. この瞬間には、どちらのタイプの要求もまったく同じように処理されます。
  4. 要求は、対応するサービス IP によってプロキシ化されます。
  5. バックエンドポッドの可用性に応じて、バックエンドポッドの1つが位置しているノードに送信され、最終的にターゲットポッドに到達します。
  6. バックエンドポッドが、アクティブな haproxy を実行しているのとは異なる計算ノードで実行されている場合は、2つのコンピュートノード間で UDP トンネルの MPLS が作成されます。

Figure 1とFigure 2は、クラスター内のポッドからアクセスしている場合や、インターネットホストからアクセスしている場合のエンドツーエンドのサービス要求フローを示しています。

Contrail では、次の3種類の受信がサポートされています。

  • HTTP ベースのシングルサービス受信

  • シンプルな fanout の入口

  • 名前ベースの仮想ホスティング

次に入力’すると、さまざまな受信タイプが表示されるようになります。

Figure 1: 受信トラフィックフロー: 内部からのアクセス
受信トラフィックフロー: 内部からのアクセス
Figure 2: 受信トラフィックフロー: 外部からのアクセス
受信トラフィックフロー: 外部からのアクセス

入口の設定

このガイド’のラボでは、Figure 3に示すように、サービステストに使用されるのと同じ testbed を使用しています。

Figure 3: 受信 Testbed
受信 Testbed

単一のサービスの入口

1つのサービス受信は、最も基本的な入口の形式です。ルールを定義しているわけではありません。また、その主な用途は、サービスを外部の世界に公開することです。すべての受信サービス要求を同じ単一のバックエンドサービスにプロキシします。

単一のサービスタイプの受信を示すには、次のようなオブジェクトを作成する必要があります。

  • バックエンドサービスを定義する入口オブジェクト

  • バックエンドサービスオブジェクト

  • サービス用のバックエンドポッドが少なくとも1つ

入口の定義

単一のサービス受信テストラボでは、servicePort 8888 を使用して、任意の Url をサービスの web/clusterip に送信するよう要求しています。対応する YAML 定義ファイルは次のとおりです。

このようにしても効果はありません。基本的には、バックエンドとして1つのサービスサーバーを参照することはありません。すべての HTTP 要求がこのサービスにディスパッチされ、そこからバックエンドポッドに到達することが要求されます。シンプルです。バック’エンドサービスを見てみましょう。

バックエンドサービスの定義

次の例のサービスとまったく同じサービスを使用できます。

Note

サービスタイプはオプションです。入口では、サービスを外部に公開する必要はありません。そのため、ロードバランサータイプのサービスは必要ありません。

バックエンドポッドの定義

サービスの例と同様に、完全に同じ web サーバーの導入を使用してバックエンドポッドを起動できます。

1つの YAML ファイル内のすべて

通常は、各オブジェクトの個別の YAML ファイルを作成できますが、これらのオブジェクトを常に作成してまとめ’て受信する必要があると考えると、これらすべてのオブジェクトの定義を1つの yaml ファイルにマージすることをお勧めします。YAML 構文は、ドキュメントの区切り記号 (各オブジェクト定義間の---ライン) を使用してこれをサポートします。

オールインワン YAML ファイルのメリットは次のとおりです。

  • Kubectl apply コマンドを1つだけ使用して、YAML ファイル内のすべてのオブジェクトを1つの go で作成または更新できます。

  • 同様に、何か問題が発生してクリーンアップする必要がある場合は、YAML ファイルで作成されたすべてのオブジェクトを kubectl delete コマンドで削除することができます。

  • 必要に応じて、オブジェクト名を指定することで、個々のオブジェクトを個別に削除することもできます。

Tip

テスト処理では、すべてのオブジェクトを非常に頻繁に作成して削除しなければならない場合があります。1つの YAML ファイルで複数のオブジェクトをグループ化することは非常に便利です。

単一のサービス受信を導入

YAML ファイルを適用してすべてのオブジェクトを取得する前’に、2つのノードを簡単に見てみましょう。入口なしで haproxy プロセスが実行されているかどうかを確認する必要があるので、後で、入口を導入した後、以下のように比較してください。

その答えは「いいえ」ですから、どちらのノードにも haproxy プロセスはありません。Haproxy は、受信の作成後、対応するロードバランサーオブジェクトが contrail モニターに表示される場合にのみ作成されます。’次のように、受信した後にこのチェックボックスをオンにします。

これで、受信した1つのサービスと1つの導入オブジェクトが作成されました。

受信オブジェクト

’入口オブジェクトを検証します。

予想通り、バックエンドサービスは受信に適切に適用されます。このシングルサービス受信では、特定の URL を別のサービス–にマップするための明示的なルールが定義されていません。すべての HTTP 要求が同じバックエンドサービスにディスパッチされます。

Tip

「項目メタデータ注釈」の kubectl.kubernetes.io/last-applied-configuration セクションを参照してください。…

…指定した構成情報が実際に含まれています。Python’s json のような json 形式ツールを使用して、フォーマットすることができます。より良いビューを得るには、…

…また、その他のオブジェクトにも同じ書式を設定して、読みやすくすることができます。

But what may confuse you are the two IP addresses shown here:

サービス’の例では、以下の2つのサブネットを見てきました。

  • 10.47.255 は、pod’s のデフォルトサブネットから割り当てられたクラスタ内部の podip であり、

  • 101.101.101 は、内部 IP に関連付けられたパブリック FIP です。質問は次のとおりです。入口でも FIP を必要としているのはなぜでしょうか。

回答’をすぐにオフにして、オールインワン yaml ファイルから作成されたサービスと pod オブジェクトをチェックしてみてください。すぐ’にこの質問に戻ってきます。

サービスオブジェクト

Let’のチェックオン

サービス

サービスが作成され、clusterIP が割り当てられます。これ’についてはこれまでに見てきましたが、特別なものではありません。ここで、’バックエンドとクライアントポッドを見てみましょう。

ここではすべて正常に見えます。サービスのバックエンドポッドが動作しています。サービスポッドの関連付けにおいて、セレクターとラベルがどのように機能するかについては既に学習しました。何も新しいものではありません。そこで’、haproxy を検証して、受信オブジェクトに割り当てられた2つの IPs をなんらかの意味で確認してみましょう。

Haproxy プロセス

前述のように、受信が作成される前に、ノードで haproxy プロセスを探していましたが、何も表示されませんでした。もう’一度チェックして、マジックが行われているかどうかを確認してみましょう。

ノード cent222:

ノード cent333:

そして、入口が作成されたら、2つのノードのそれぞれに haproxy プロセスが作成されています。これまでに、Contrail 受信もロードバランサー (サービスと同様) で実装されていることを指摘しました。受信’s loadbalancer_provider タイプは opencontrail である‘ため、contrail-svc monitor によって haproxy ロードバランサードライバーが起動されます。Haproxy ドライバーは、受信ルールに必要な haproxy 構成を生成し、Kubernetes ノードで生成された設定を使用して、haproxy プロセスを (アクティブスタンバイモードで) 起動するトリガーを実行します。

入口ロードバランサーオブジェクト

受信’ロードバランサーについては数回説明しまし’たが、まだそれを見ていませんでした。「サービス」セクション’では、サービスロードバランサーオブジェクトを UI で確認し、オブジェクトのデータ構造に関するいくつかの詳細を確認しました。ここで、受信オブジェクトを作成した’後に、ロードバランサーオブジェクトのリストをもう一度チェックし、> ロードバランサーを構成するための UI から、受信がどのようになるかを確認してみましょう。

Figure 4: </C1> ロードバランサーの構成
</C1> ロードバランサーの構成

オールインワン YAML ファイルを適用すると、次の2つのロードバランサーが生成されます。

  • ロードバランサー ns-ユーザー-1 受信受信 ss 用入口-ss

  • ロードバランサー ns-ユーザー-1 の webservice ip (service webserver-clusterip)

’すでにサービスロードバランサーオブジェクトを使用してきましたが、サービスを拡張すると、詳細な情報が表示されますが、何も驚くべきことはありません。

Figure 5: サービスロードバランサーオブジェクト (ロードバランサーの左にある三角形をクリックしてください)
サービスロードバランサーオブジェクト (ロードバランサーの左にある三角形をクリックしてください)

このように、サービスロードバランサーは、ポート8888でリッスンする clusterIP とリスナーオブジェクトを持っています。注目すべき点の1つは、loadbalancer_provider です。このタイプはネイティブなので、contrail はレイヤー 4 (アプリケーション層) ECMP プロセスを採用しています。これは、サービスセクションで広範囲にわたって取り上げられています。受信’ロードバランサーを拡張し、詳細を見ることができます。

Figure 6: 受信ロードバランサーオブジェクト
受信ロードバランサーオブジェクト

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

  • Loadbalancer_provider は opencontrail

  • 受信ロードバランサーには、バーチャルマシンインターフェイス (VMI) オブジェクトへの参照が含まれています。

  • また、VMI オブジェクトは、(固定) IP 10.47.255.238 と、(浮動小数点数の) IP 101.101.101.1 を使用する浮動 ip オブジェクトを使用して、インスタンス-ip オブジェクトによって参照されます。

受信 IP 10.47.255.238 については、以下のように説明することができます。

  • ロードバランサー VIP としてデフォルトのポッドネットワークから割り当てられたクラスタ内部 IP アドレスです。

  • 入口ロードバランサーが HTTP リクエストをリスンするフロントエンド IP です。

  • さらに、パブリック浮動小数点数型 IP 101.101.101.1 が NAT に対応しています。

Tip

本書では、このプライベート IP を異なる名前で示しています。これは、次のように同義で使用されています。受信内部 IP、受信内部 VIP、受信プライベート IP、受信ロードバランサーインターフェイス IP などは、受信するパブリック浮動 IP と区別するためのものです。内部 VIP がポッドネットワークから割り当てられているため、受信 pod IP として名前を指定することもできます。同様に、受信する外部 IP アドレスとして受信するパブリック浮動 IP を意味します。

ここで、これら2つの IPs のさまざまな目的を比較してみましょう。

  • 入口ポッド IP は、クラスター内の他のポッドに対応する VIP です。クラスター内からの入口に到達するために、他のポッドからのリクエストは宛先 IP が受信・ podIP に設定されます。

  • 受信 floating IP は、世界中のインターネットホストに向けた VIP です。クラスター外からの入口に到達するには、インターネットホストからの要求に対して、宛先 IP が受信 FIP に設定されている必要があります。ノードが受信浮動 IP に送信されるトラフィックをクラスターの外部から受け取ると、vRouter はそれを入口となる podIP に変換します。

詳細な受信ロードバランサーオブジェクトの実装はサービスインスタンスを指し、サービスインスタンスには他のデータ構造やその他のオブジェクトへの参照 (Vm、VMIs など) が含まれます。全体的な it は、このガイドで説明した’内容よりも複雑で、詳細が含まれています。一部’の詳細を大まかにカスタマイズして、haproxy や2つの受信 ip などの重要な概念を少なくとも理解できるようにしました。

HTTP/HTTPS 要求が受信した podIP (内部または外部) に到着すると、入口となるロードバランサーは、haproxy プロセスによって HTTP/HTTPS プロキシ操作を実行し、要求をサービスにディスパッチし、最終的にバックエンドポッドに送信します。

’Haproxy プロセスが実行中であることを確認し、このプロキシ操作の詳細を確認する’には、実行中のパラメーターの詳細について構成ファイルをチェックしてみます。

Haproxy conf ファイル

In each (compute) node, under the /var/lib/contrail/Loadbalancer/haproxy/ folder there will be a subfolder for each load balancer UUID. The file structure looks like this:

Haproxy の設定については、haproxy. conf ファイルを確認できます。

構成はシンプルなので、図6.7 に示すようになります。図6.7 の特長は次のとおりです。

  • Haproxy フロントエンドは、入口となるクライアントのフロントエンドを表します。

  • Haproxy バックエンドは、受信している、接続されたサービスのバックエンドを表します。

  • Haproxy フロントエンドは、受信した podIP および mode http へのバインドを定義します。このようなノブはフロントエンドがリッスンしているものを示しています。

  • Haproxy バックエンドセクションでは、サーバーを定義します (ここではバックエンドサービスです)。ServiceIP: servicePort の形式があり、オールインワン YAML ファイルを使用’して作成された正確なサービスオブジェクトです。

  • フロントエンドセクションの default_backend では、どのバックエンドがデフォルトであるかを定義しています。このメソッドは、haproxy が、フロントエンドセクションの任意の場所に明示的に一致しない URL 要求を受信したときに使用されます。この場合、default_backend はバックエンドサービス 10.97.226.91: 8888 のみを参照します。これは、単一のサービス受信で定義されているルールがないという事実が原因です。すべての HTTP 要求は、クライアントがどの URL であるかにかかわらず、同じ default_backend サービスに送られます。送信.

Figure 7: 単一のサービスの入口
単一のサービスの入口
Note

その後、シンプルな fanout の入口と名前ベースの仮想ホスティングの例では、別の種類の設定 use_backend……文が表示されます。これを使用して、各 URL を別のバックエンドに強制的に移動させることもできます。

この構成全体で、haproxy は単一のサービス受信を実装していました。

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

’クラスター内で多くのことを検討していたため’、次にゲートウェイルーター’s VRF テーブルを見てみましょう。

サービスの例と同じように、クラスターの外部からは、floating IP のみが表示されます。Show コマンドの詳細なバージョンを実行すると、より多くの情報が伝達されます。

[詳細の表示] では以下が明らかです。

  • VRouter は、フローティング IP プレフィックスを、XMPP を通じて Contrail コントローラに通知します。この出力から取得した情報のうち、少なくとも2つは、この例でフローティング IP を表す人物を示しています。

    • 10.169.25.20 のプロトコルのネクストホップ

    • ルート識別子の 10.169.25.20: 5

  • さらに、Contrail コントローラは MP BGP から、浮動 IP プレフィックスをゲートウェイルーターに反映しています。出典：10.169.25.19 はこの事実を示しています。

そのため、アクティブな haproxy ノードとして cent222 が選択されているように見え、もう一方のノードである cent333 はスタンバイになっています。そのため、インターネットホストからのクライアント要求がノード cent222 に最初に送られることが望まれます。当然ながら、オーバーレイトラフィックは GRE トンネルを介して MPLS で伝達されます。これは’、サービスの例で示したものと同じです。

この浮動 IP アドバタイズメントは、ゲートウェイルーターに対するものとは異なり、すべてのタイプの ingresses でまったく同じです。

また、目的に’ついて少しスキップしたもう1つの事実は、浮動 IP プレフィックスをアドバタイズするときに、アクティブおよびスタンバイノードによって使用される、ローカル優先度値の違いです。完全な試験には、アクティブノード選択アルゴリズムなどの複雑なトピックが含まれていますが、これを高レベルから理解することも価値があります。

どちらのノードもロードバランサーと haproxy を実行しているため、両方が浮動 IP プレフィックス101.101.101.1 をゲートウェイルーターに通知します。ただし、異なるローカル優先値で通知されます。アクティブノードは、値が200、スタンバイノードは100を使用してアドバタイズされます。Contrail コントローラはどちらも2つのノードからのルートを持っていますが、成功したのはゲートウェイルーターに提供されるのは1つだけです。そのため、他の BGP ルートはドロップされ、1つだけが表示されます。Localpref が200であることは、アクティブなコンピューティングノードから来ていることが証明されています。これは、受信パブリック浮動 IP ルートと内部 VIP ルートアドバタイズの両方に適用されます。

入口の検証: 内部

入口ロードバランサーとそれ’に関連するサービス、pod オブジェクトなどに関する多くの情報を確認した後、エンドツーエンドのテスト結果を検証しました。受信はクラスターの内部と外部の両方で行われるため、検証はクラスター内のクライアントポッドから始まり、その外部のインターネットホストから開始されます。まず、クラスターの内側から次のようになります。

その場合でも、curl コマンドを使用して、HTTP’リクエストを受信したプライベート IP に対してトリガーします。受信が成功したことを証明します。別の Url への要求は、デフォルトのバックエンドサービスであるサービス web clusterip を介して、すべてが同じバックエンドポッドに対してプロキシされます。

4つ目の要求’では、-H を介して URL を提供しなかったため、curl は、このテストでホストに要求 IP アドレスを設定し、10.47.255.238 を同じバックエンドポッドに移動して、同じ応答を返します。

Note

-H オプションは、curl を使用した入口テストで重要です。このプロトコルは、受信ロードバランサーが待機している HTTP ペイロードの完全な URL を保持しています。それがなければ、HTTP ヘッダーは Host: ということになります。10.47.255.238 は、一致するルールがないため、不明な URL と同様に扱われます。

入口の検証: 外部 (インターネットホスト)

このテストのより魅力的な部分は、Url に外部でアクセスすることです。全体的には’、インターネットホストにサービスを公開しようとしている入口を期待していましたが、そうする必要はありませんでした。URL が正しい浮動 IP アドレスに解決されるようにするには、最後–に1行追加して/etc/hosts ファイルを更新する必要が’あります。最終的には、試験結果として正規の web サイトからすばらしい web ページを作成してしまうのではないでしょうか。

ここで、インターネットのホスト’s デスクトップからブラウザーを起動し、3つの url のいずれかを入力します。ページを更新することで、Figure 8に示すように、すべての HTTP 要求が同じバックエンドポッドによって返されることを確認できます。

Figure 8: インターネットホストから www.juniper.net にアクセスする
インターネットホストから www.juniper.net にアクセスする

Curl からも同じ結果を表示できます。このコマンドは、ポッドからテストするとき’に使用したものとまったく同じですが、受信内部 podip ではなく、入口で処理された外部 floating IP に要求を送信する点が異なります。インターネットホストマシンから:

すべてが機能しています。それ’では、2つ目の受信タイプでシンプルな fanout 入口を見てみましょう。先へ進む前に、オールインワン YAML ファイルを利用して、すべての kubectl delete コマンドで同じオールインワンの YAML ファイルを使用すると、すべてをクリアできます。

シンプルな Fanout の入口

Fanout のシンプルな受信と名前ベースのバーチャルホストの受信はどちらも URL ルーティングをサポートしますが、前者はパスに基づいており、後者はホストに基づいているという点が異なります。

URL パスとルールをベースにしたシンプルな fanout 受信により、受信ロードバランサーは次のように、トラフィックをさまざまなバックエンドサービスに渡します。

シンプルなファンアウトタイプの受信を示すには、次のようなオブジェクトを作成する必要があります。

  • 入口オブジェクト: ルールを定義し、2つのパスを2個のバックエンドサービスにマッピングします。

  • 2つのバックエンドサービスオブジェクト

  • 各サービスには、バックエンドとして少なくとも1つのポッドが必要です。

  • 前の例で使用されていたクラスター内部クライアントと同じクライアントポッドです。

受信オブジェクトの定義

ホスト www.juniper.net のシンプルな fanout 入口テストラボの目標は、以下のとおりです。

  • パスに向かうリクエスト/dev は、servicePort 8888 を使用したサービス webservice-1 に送信されます。

  • Path/qa への要求は、servicePort 8888 を使用した webservice to サービスに送信されます。これらの目標を実装するための、対応する YAML ファイルを以下に示します。

単一のサービスの受信と対照的に、シンプルな fanout 受信オブジェクト (および名前ベースのバーチャルホストの受信) では– 、ここで定義したルールは、さまざまなバックエンドサービスへの複数のパスからのマッピングを示しています。

バックエンドサービスの定義

パスごとに2つのルールが定義されているため、それに応じて2つのサービスが必要です。1つのサービスの受信例で前のサービスを複製して、サービス’名とセレクターを変更すれば、2つ目のサービスが生成されます。たとえば、これは webservice-1 サービスと webservice service の定義です。

バックエンドポッドの定義

ここで2つのバックエンドサービスがあるので、少なくとも2つのバックエンドポッドを使用して、それぞれにサービスに対応するラベルを付けておく必要があります。前の導入環境を2つに複製し、2つ目の導入の名前とラベルを変更するだけで済みます。

ウェブ・サーバの導入-1:

また、web webserver の導入にも対応します。

シンプルな Fanout の入口を導入

単一のサービス入力と同様に、すべてをまとめて、オールインワンの YAML ファイルを取得して、シンプルな fanout 受信をテストします。

ここでは、オールインワン YAML ファイルを適用して、すべてのオブジェクトを作成します。

これで、受信した2つのサービスと2つの導入オブジェクトが作成されました。

受信後の試験

ルールは適切に定義されており、各ルール内には、対応するサービスへのパスからのマッピングがあります。前述の単一のサービスの受信例で見られるように、同じ入口の internal podIP と external floating IP を見ることができます。

このため、ゲートウェイルーター’の観点から見ると、すべてのタイプの受信に違いはありません。すべての場合において、パブリック浮動 IP が受信に割り当てられ、ゲートウェイルーターに通知されることになります。

ここで、バックエンドサービスとポッドを確認します。最初のサービスオブジェクト:

その後、バックエンドとクライアントポッド:

2つのサービスが作成され、それぞれに異なる割り当て済みの clusterIP があります。各サービスにはバックエンドポッドがあります。その後、クライアント’からの入口を確認するときに、返された web ページにこれらの podips が表示されます。

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

単一のサービスの受信と比較すると、唯一の違いは、次の画面キャプチャに示す1つのサービスロードバランサーです。

Figure 9: シンプルな Fanout 入口ロードバランサー (UI: configuration > Network > Floating IPs)
シンプルな Fanout 入口ロードバランサー (UI: configuration > Network > Floating IPs)

シンプルな Fanout 入口ロードバランサー (UI: configuration > Network > Floating IPs) このテストで生成される3つのロードバランサーは以下のとおりです。

  • ロードバランサー ns-ユーザー-1 受信受信用入口-sf

  • ロードバランサー ns-service webserver for user-1 for webservice-1

  • ロードバランサー ns-ユーザー-2 for service webserver-2

’オブジェクト’の詳細を確認するには、サービスの主要なパラメーターを調査し、ロードバランサーを1つのサービスが受信していて、特に何も新しいものがないというわけではありません。

Haproxy プロセスと Haproxy com.cfg ファイル

単一のサービスの受信例では、loadbalancer が loadbalancer_provider で表示され、opencontrail に設定されると、contrail monitor によって呼び出される2つの haproxy プロセスを示しています。この例の最後に、1つのサービス受信を削除した後、クラスターには受信が残っていないため、2つの haproxy プロセスが終了します。新しい受信の作成が完了すると、2つの新しい haproxy プロセスが再起動されます。

ノード cent222:

ノード cent333:

ここでは、簡単な fanout の入口ルールが haproxy. conf ファイルでどのようにプログラムされるかをご紹介します。Haproxy 設定ファイルを見てみましょう’。

Note

設定ファイルは、ページ幅に合わせてわずかな書式になっています。

この構成は、1つのサービス受信の場合よりもやや複雑に見えますが、最も重要な部分は非常に簡単です。

  • Haproxy フロントエンドセクション: これで Url が定義されています。各 URL は、1組の acl ステートメント、ホスト用、およびパス用として表されます。一言で言えば、host はドメイン名とパスであり、URL 文字列でホストに続くものです。ここでは、fanout がジュニパーネットワークスを提供しています。2つの異なるパスを持つネット: \qa.

  • Haproxy バックエンドセクション: 今では2つのものがあります。各パスには専用のサービスがあります。

  • フロントエンド…セクション…の use_backend if コマンドは、以下のとおりです。この文では、2 –つの ACL ペアのいずれかでプログラムされたパスと一致するように、URL 要求に指定されている場合、受信ルールを宣言し、対応するバックエンド (サービス) を使用してトラフィックを転送します。

たとえば、acl 020e371c-e222-400f-b71f-5909c93132de_path パス/qa はパス/qa. を定義します。URL リクエストにこのようなパスが含まれている場合、haproxy は 020e371c71 e222--5909c93132de (バックエンドセクションで見つけることができます) に use_backend なります。バックエンドは、サーバー c13b0d0d-6e4a-4830-bb46-2377ba4caf23 10.100.156.38: 8888 weight 1 (実質的にはサービス) を参照している UUID です。このことは、serviceIP: port で確認することができます。10.100.156.38:8888.

構成ファイルは、Figure 10に示しています。

Figure 10: シンプルな Fanout サービス
シンプルな Fanout サービス

このプロキシ. conf ファイルでは、haproxy がシンプルな fanout 受信を実装しています。

  • 完全な URL が host www.juniper.net と path/dev で構成されている場合、要求は webservice-1 (10.96.51.227: 8888) にディスパッチされる。

  • 完全な URL が host www.juniper.net と path/qa で構成されている場合は、要求は webservice-2 (10.100.156.38: 8888) にディスパッチされることになります。

  • それ以外の Url では、その要求は、対応するバックエンドサービスが定義されていないため削除されます。

Note

実際には、ルールに一致する Url がないすべての HTTP 要求を処理するために、default_backend サービスが必要になることがよくあります。これ’については、1つのサービス受信の前の例で見られています。名前ベースのバーチャルホスティングの入口セクション’では、このような柔軟性を実現するために、use_backend と default_backend を統合しています。

入口の検証: 内部から

URL’をさまざまなパスでテストしてみましょう。

返された結果は、受信した機能を示しています。/qa および/dev パスへの2つの要求は、2つのバックエンドサービスを通して2つの異なるバックアウトポッドにプロキシされます。webservice-1 と webservice-2 のそれぞれに対応しています。

パス abc を使用した3つ目の要求では、受信設定で一致するサービスを持たない不明な’URL を構成しているため、配信されません。最後’の2つの要求についても同じことが言えます。パスを使用しない場合、または別のホストを使用している場合、受信’した url は配信されないようになります。

このようなシナリオを含めるには、ルールを追加する必要があると考えるかもしれません。これはうまく機能しますが’、拡張性–にはなりません。サーバーに侵入する可能性のあるパスや url をすべて網羅することはできません。前述したように、1つのソリューションでは、default_backend サービスを使用して他のすべての HTTP 要求を処理することで、次の例で説明されています。

入口の検証: 外部 (インターネットホスト) から

クラスター外からのシンプルな fanout 受信をテストする場合、このコマンドは、インターネットホストから’開始した場合を除き、pod の内部から HTTP 要求を開始したときと同じです。HTTP’リクエストを、内部の podip で’はなく、受信したパブリックな floating IP に送信しましょう。したがって、インターネットホストマシンの場合は次のようになります。

バーチャルホスティングの受信

バーチャルホスティングの受信では、同一の IP アドレスで複数のホスト名に HTTP トラフィックをルーティングできます。URL とルールに基づいて、受信ロードバランサーはトラフィックを異なるバックエンドサービスに送信し、各サービスはトラフィックをバックエンドポッド (次の図のようなように) に指示します。

受信の仮想ホストタイプを示すために、以前のシンプルな fanout 受信と同じオブジェクトを作成する必要があります。

  • 入口オブジェクト: 2つの Url を2つのバックエンドサービスにマッピングするルール

  • 2つのバックエンドサービスオブジェクト

  • 各サービスには、バックエンドとして少なくとも1つのポッドが必要です。

受信オブジェクトの定義

の virtual host ingress test演習では、以下のルールを定義しました。

  • URL www.juniper.net に向けた要求は、servicePort 8888 を使用したサービス webservice-1 に送信されます。

  • URL www.cisco.com に向けた要求は、servicePort 8888 を使用したサービス webservice-2 に送信されます。

  • この2つ以外の Url へのリクエストは、servicePort 8888 を使用して webservice-1 に送信されます。効率的に、web サービスをデフォルトのバックエンドサービスにしたいと考えています。

対応する YAML 定義ファイルは以下のとおりです。

バックエンドサービスとポッドの定義。

ここでは、単純な fanout 入口で使用されたものと同じ正確なサービスと導入の定義を使用できます。さらに briefer をお持ちの’方は、オールインワン yaml ファイルをご覧ください。

’ここでは、オールインワンの yaml ファイルを適用して、入口およびその他の必要なオブジェクトを作成します。

受信した2つのサービスと、2つの導入オブジェクトが作成されていることがわかります。

受信後の試験’受信オブジェクトを調べることができます。

このとき、シンプルな fanout の受信と比較して、1つではなく2つのホストを表示できます。各ホストはドメイン名を表しています。

ルールは適切に定義されており、各ルール内には、ホストから対応するサービスへのマッピングが含まれています。ゲートウェイルーターの動作に対するサービス、ポッド、フローティング IP プリフィックスはすべて、シンプルな fanout 受信とまったく同じであることに注意してください。

入口になったロードバランサーオブジェクトの調査

オールインワン YAML ファイルを適用した後、3つのロードバランサーが生成されました。1つは受信用、2つはサービス用です。

このテストで作成されたロードバランサーは、次の画面キャプチャのFigure 11に示すように、シンプルな fanout 入口テストで作成したものとほぼ同じです。

Figure 11: ロードバランサー
ロードバランサー

それでは’、名前ベースの haproxy 設定ファイルをチェックしてみましょう

バーチャルホストの入口。ここ’では、haproxy. conf ファイルの調査を行います。

次の点に注目してください。

  • Haproxy フロントエンドセクションは、各 URL またはホスト、およびそのパスを定義します。この例では、2つのホストは www.juniper.net および www.cisco.com で、両方のパスは/です。

  • Haproxy バックエンドセクションでは、サーバーが定義されています。ここでは、すべてのサービスを対象としています。サービスの作成に使用される serviceIP: servicePort の形式があります。

  • フロントエンド…セクション…の use_backend if コマンドは、受信ルールを宣言します。指定された URL とパスが要求に含まれている場合は、対応するバックエンドを使用してトラフィックを転送します。

  • Default_backend では、デフォルトとして機能するサービスを定義しています。このメソッドは、haproxy が、定義されたルールに明示的に一致しない URL 要求を受信した場合に使用されます。

Figure 12は、設定ファイルのワークフローを示しています。

Figure 12: Haproxy 構成ファイル’s ワークフロー
Haproxy 構成ファイル’s ワークフロー

設定を通じて、haproxy は次のような受信機能を実装しています。

  • Www.juniper.net の場合、完全な URL を指定/作成すると、リクエストが webservice-1 (10.99.225.17: 8888) へディスパッチされます。

  • Www.cisco.net の場合、完全な URL を指定/作成すると、リクエストが webservice-2 (10.105.134.79: 8888) へディスパッチされます。

  • その他の Url はデフォルトのバックエンドに移動します。これはサービス

webservice-1. で’は、これらの動作を検証してみましょう。

入口の検証: 内部から

クラスター内から:

入口が機能します。Juniper への2つの要求は、それぞれが2つの異なるバックエンドポッドを介して、2つのバックエンドサービス、webservice-1、および webservice-2 を介してプロキシされます。Google への3つ目の要求は、不明な URL であり、入口構成に一致するサービスがないため、デフォルトのバックエンドサービスである webservice-1 に入り、同じバックエンドポッドに到達します。

同じルールが4番目の要求にも適用されます。-H を使用して URL を指定しなかった場合、curl は、ホストに要求 IP アドレス (このケースでは 10.47.255.238) を入力します。その URL’には定義されたバックエンドサービスがないため、デフォルトバックエンドサービスが使用されます。私たちのラボでは、同じ導入によって生成される各サービスにバックエンドポッドを使用しているため、返された web ページ内の podIP は、だれが誰であるかを示しています。2番目のテストでは、返された podIP は10.47.255.235 を表していましたが、他の3つのテストでは webservice-1 の podIP が返されていました。

入口の検証: 外部 (インターネットホスト) から

インターネットホスト’s のデスクトップでは、2つの Chrome ページを並べて、もう一方の www.cisco.com と入力 www.juniper.net を起動し、ページの更新を維持しました。Juniper ページは、導入された webserver-1 pod 10.47.255.236 によって常に返されることを確認できます。また、Cisco ページは、導入された webserver-2 ポッド10.47.255.235 によって常に返されます。次に、www.google.com に向けて3つ目のクロムページを開き、Figure 13のスクリーンショットに示すように、Juniper インスタンスを提供する同じ pod によって返されました。

Figure 13: インターネットホスト
インターネットホスト

同じ結果を curl からも見ることができます。ここで’は、インターネットホストマシンについて説明しています。

サービスと受信トラフィックフロー

サービスと受信の両方がロードバランサーで実装されていますが、さまざまな loadbalancer_ プロバイダタイプを使用していますが、サービスと受信の転送モードは大きく異なります。サービス転送では’、これを1ホッププロセスとして行います。クライアントは、要求を clusterIP または floating IP に送信します。NAT では、リクエストは宛先のバックエンドポッドに到達します。受信転送では、宛先ポッドに到着するために、トラフィックは2ホッププロセスを取ります。このリクエストはまずアクティブな haproxy に入り、次に HTTP/HTTPS レベルのプロキシプロシージャを開始して、サービス転送が最終ポッドに到達します。NAT 処理は両方の転送プロセスで行われますが、受信とサービスの両方でパブリックな floating IP 実装に依存しているためです。

第7章では、この Contrail パケットフローの詳細について説明します。