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

の特長Figure 1は以下のとおりです。
各サービスはロードバランサーオブジェクトによって表されています。
ロードバランサーオブジェクトには、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 1重要な点は、従来の neutron ロードバランサー (後で説明する’受信ロードバランサー) とは対照的に、このプロセスにはアプリケーションレイヤープロキシがないということです。Contrail サービスの実装は、レイヤー 4 (トランスポートレイヤー) ECMP ベースの負荷分散に基づいています。
ロードバランサーオブジェクトの Contrail
Contrail’ロードバランサーオブジェクトの詳細について詳しく説明しましたが、実際にはどのようなものであるかという疑問を持つかもしれません。それで’は、ロードバランサーとサポートオブジェクトについて少し詳しく見てみましょう。リスナー、プール、メンバー
Contrail セットアップでは、REST API をベースにした Contrail UI、CLI (カール)、またはサードパーティ製 UI ツールからオブジェクトデータを取得できます。実稼働環境では、利用できるものと便利なものに応じて、お気に入りを選択できます。
Curl’を使用してロードバランサーオブジェクトを見てみましょう。Curl ツールを使用すれば、そのオブジェクトを指す URL の FQDN が必要になります。
たとえば、次のようなサービスサービスのロードバランサーオブジェクト URL を見つけるには、ロードバランサーリストから web clusterip を探します。
$ curl http://10.85.188.19:8082/loadbalancers | \ python -mjson.tool | grep -C4 `service-web-clusterip` { "fq_name": [ "default-domain", "k8s-ns-user-1", "service-web-clusterip 99fe8ce7-9e75-11e9-b485-0050569e6cfc" ], "href": "http://10.85.188.19:8082/loadbalancer/99fe8ce7-9e75-11e9-b485-0050569e6cfc", "uuid": "99fe8ce7-9e75-11e9-b485-0050569e6cfc" },
特定のロードバランサー URL を使用して、特定の負荷分散オブジェクトの詳細を取得することができます。
$ curl \ http://10.85.188.19:8082/loadbalancer/99fe8ce7-9e75-11e9-b485-0050569e6cfc \ | python -mjson.tool { "loadbalancer": { "annotations": { "key_value_pair": [ { "key": "namespace", "value": "ns-user-1" }, { "key": "cluster", "value": "k8s" }, { "key": "kind", "value": "Service" }, { "key": "project", "value": "k8s-ns-user-1" }, { "key": "name", "value": "service-web-clusterip" }, { "key": "owner", "value": "k8s" } ] }, "display_name": "ns-user-1 service-web-clusterip", "fq_name": [ "default-domain", "k8s-ns-user-1", "service-web-clusterip 99fe8ce7-9e75-11e9-b485-0050569e6cfc" ], "href": "http://10.85.188.19:8082/loadbalancer/99fe8ce7-9e75-11e9-b485-0050569e6cfc", "id_perms": { ...<snipped>... }, "loadbalancer_listener_back_refs": [ #<--- { "attr": null, "href": "http://10.85.188.19:8082/loadbalancer-listener/3702fa49-f1ca-4bbb-87d4-22e1a0dc7e67", "to": [ "default-domain", "k8s-ns-user-1", "service-web-clusterip 99fe8ce7-9e75-11e9-b485-0050569e6cfc-TCP-8888- 3702fa49-f1ca-4bbb-87d4-22e1a0dc7e67" ], "uuid": "3702fa49-f1ca-4bbb-87d4-22e1a0dc7e67" } ], "loadbalancer_properties": { "admin_state": true, "operating_status": "ONLINE", "provisioning_status": "ACTIVE", "status": null, "vip_address": "10.105.139.153", #<--- "vip_subnet_id": null }, "loadbalancer_provider": "native", #<--- "name": "service-web-clusterip 99fe8ce7-9e75-11e9-b485-0050569e6cfc", "parent_href": "http://10.85.188.19:8082/project/86bf8810-ad4d-45d1-aa6b-15c74d5f7809", "parent_type": "project", "parent_uuid": "86bf8810-ad4d-45d1-aa6b-15c74d5f7809", "perms2": { ...<snipped>... }, "service_appliance_set_refs": [ ...<snipped>... ], "uuid": "99fe8ce7-9e75-11e9-b485-0050569e6cfc", "virtual_machine_interface_refs": [ { "attr": null, "href": "http://10.85.188.19:8082/virtual-machine- interface/8d64176c-9fc7-491a-a44d-430e187d6b52", "to": [ "default-domain", "k8s-ns-user-1", "k8s Service service-web-clusterip 99fe8ce7-9e75-11e9-b485-0050569e6cfc" ], "uuid": "8d64176c-9fc7-491a-a44d-430e187d6b52" } ] } }
この出力は非常に広範囲にわたっており、注目すべき情報がいくつかあることを除けば、現時点では関心のない多くの詳細情報が含まれています。
Loadbalancer_properties では、負荷の高いサービス IP を VIP として使用しています。
負荷分散は、参照によってリスナーに接続されています。
Loadbalancer_provider の属性はネイティブで、レイヤー 4 (トランスポートレイヤー) ECMP を実装するための新しい拡張機能である Kubernetes サービスを対象としています。
負荷分散とそれに関連するオブジェクトのその他の調査に’ついては、従来の Contrail UI を使用してみましょう。
また、新しい Contrail コマンド UI を簡単に使用することもできます。
各サービスには負荷分散オブジェクトがあります。Figure 2は、2つの負荷分散オブジェクトを示しています。
ns-user-1-service-web-clusterip
ns-user-1-service-web-clusterip-mp

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

ここから、+ 文字をクリックして loadbalancer_listener オブジェクトを拡大し、Figure 3に示すように詳細を確認できます。その’後、loadbalancer_pool が表示できます。もう一度展開すると、メンバーが表示されます。このプロセスを繰り返して、オブジェクトデータを調べることができます。
リスナー
LB 名前をクリックし、[listener] を選択してから展開し、JSON 形式で詳細を表示します。リスナーの詳細をご確認いただけます。リスナーは、サービスポート8888でリッスンしており、Figure 4のプールによって参照されています。

オブジェクトの詳細なパラメーターを JSON 形式で表示するには、ロードバランサー名の左にある三角形をクリックして展開し、拡張ビューの右上隅にある [JSON の高度な表示] アイコンをクリックします。このガイドでは、JSON ビューを使用して、さまざまな Contrail オブジェクトについて解説しています。
プールとメンバー
この explorative プロセスを繰り返し実行すると、プールとその2つのメンバーが表示されます。このメンバーは、Figure 5およびFigure 6のように Pod のコンテナターゲットポートにマップされる80のポートを使用しています。
’次に、VROUTER VRF テーブルで pod を調べて、サービスロードバランサー ecmp 操作の詳細を Contrail 表示します。ロードバランサーオブジェクトに示されるロードバランサーとリスナー間の1対 N マッピングについて理解するには、’セットアップで複数ポートサービスの例も示します。’ここでは、vrouter フローテーブルを調べて、サービスパケットワークフローを示すことで、clusterip サービスのセクションを締めます。

