クラウドネイティブのContrail NetworkingにおけるNodePortサービスサポート

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

図 1 と以下のリストは、Contrail Networking のロード バランサー オブジェクトについて説明しています。

• Contrail Networking の各サービスは、ロード バランサー オブジェクトで表されます。
• サービス ポートごとに、同じサービス ロード バランサーに対してリスナー オブジェクトが作成されます。
• リスナーごとにプール・オブジェクトがあります。
• プールにはメンバーが含まれています。バックエンドポッドの数によっては、1つのプールに複数のメンバーが含まれている場合があります。
• プール内の各メンバーオブジェクトは、バックエンドポッドの1つにマッピングされます。
• はcontrail-kube-manager、kube-apiserverKubernetes サービスをリッスンします。サービスが作成されると、型nativeを持つloadbalancer_providerロード バランサー オブジェクトが作成されます。
• ロードバランサーには、サービスIPアドレスと同じ仮想IPアドレス(VIP)があります。
• サービスIP/VIPアドレスは、各バックエンドポッドのインターフェイスにリンクされています。ECMP ロード バランサー ドライバーを使用してこれを実現します。
• サービスIPアドレスから複数のバックエンドポッドのインターフェイスへのリンクは、Contrail NetworkingでECMPネクストホップを作成します。トラフィックは、ソースポッドからバックエンドポッドの1つに直接負荷分散されます。
• は contrail-kube-manager 、変更を受け取り kube-apiserver 続けます。エンドポイントのポッドリストに基づいて、 contrail-kube-manager 最新のバックエンドポッドを把握し、プール内のメンバーを更新します。

Contrail Networking の NodePort サービス

コントローラサービスは、 でkube-manager実装されます。はkube-manager、サービスなどのKubernetesコアリソースと、 などの拡張ContrailリソースVirtualNetworkRoutingInstanceの間のインターフェイスです。このコントローラサービスは、リソースエンドポイントを通過するイベントを監視します。エンドポイントは、そのサービスに関連する変更に関するイベントを受信します。エンドポイントは、サービスセレクターと一致する作成および削除されたポッドのイベントも受信します。コントローラ サービスは、必要な Contrail リソースの作成を処理します。図 2 を参照してください。

• InstanceIP に関連するリソース ServiceNetwork
• FloatingIP リソースと関連する VirtualMachineInterfaces

ユーザーがサービスを作成すると、Kubernetes によって関連付けられたエンドポイントが自動的に作成され、コントローラ サービスは新しいリクエストを受信できるようになります。

NodePortサービス作成ワークフロー

図 3 と以下の手順では、NodePort サービスが作成されたときのワークフローについて詳しく説明します。

1. NodePort サービスが作成されると、 InstanceIP (IIP)が作成されます。リソースは InstanceIP 、固定 IP アドレスと、参照される仮想ネットワークのサブネットに属するその特性を指定します。
2. エンドポイントが NodePort サービスに接続されると、 が FloatingIP 作成されます。 kube-manager サービスに接続されたエンドポイントの作成を監視します。
3. 新しいエンドポイントが作成されたら、kube-managerサブネット内に をInstanceIPServiceVirtualNetwork作成します。次にkube-manager、 をFloatingIP親として使用して InstanceIP を作成します。
4. リソースは FloatingIP 、特定 VirtualMachineInterface (VMI)に属さない特別な種類の IP アドレスを指定します。は FloatingIP 、別 VirtualNetwork のサブネットから割り当てられ、複数の VMI に関連付けることができます。複数の VMI に関連付けられている場合、 宛 FloatingIP てのトラフィックは、すべての VMI に ECMP を使用して分散されます。

VVIに関する注意:

• VMIは、ポッドやラベルの追加や削除に応じて動的に更新されます。
• VMI は仮想ネットワークへのインターフェイス(ポート)を表し、対応する仮想マシンが存在する場合とそうでない場合があります。
• VMI には、最低でも MAC アドレスと IP アドレスがあります。

VMに関する注意:

• VM リソースは、コンピューティング コンテナーを表します。例えば、VM、ベアメタル、ポッド、コンテナなどです。
• 各 VM は、ポリシーの制限を受けて、同じテナント ネットワーク上の他の VM と通信できます。
• テナントネットワークが分離されると、1つのテナント内のVMは、特にポリシーで許可されていない限り、別のテナントのVMと通信できません。

KubernetesプローブとKubernetes NodePortサービス

各ノード上で動作するエージェントである この エージェントは kubelet、ライブ性と準備状況プローブのためにポッドへの到達可能性を必要とします。Contrailネットワークポリシーは、ノードとポッド間の到達可能性を提供するために、IPファブリックネットワークとポッドネットワークの間で作成されます。ポッドネットワークが作成されるたびに、ネットワークポリシーがポッドネットワークにアタッチされ、ノードとポッドの間の到達可能性を提供します。その結果、ノード内のすべてのプロセスがポッドに到達できます。

Kubernetes NodePortサービスは、ポッドへのノード到達可能性に基づいています。Contrail Networkingは、Contrailネットワークポリシーを通じてノードとポッド間の接続を提供するため、NodePortがサポートされています。

NodePortサービスは、2種類のトラフィックをサポートしています。

• East-West
• ファブリックからポッドへ

NodePort サービス ポート マッピング

Kubernetes NodePort サービスのポート マッピングは、YAML ファイル内の FloatingIp リソース内にあります。では FloatingIp、 でポートが追加 "floatingIpPortMappings"されます。

サービスで、 targetPort が言及されていない場合、 port 値はデフォルトとして指定されます。

ポートの詳細を含む NodePort サービスの YAML ファイルの例 spec :

上記の YAML 例 spec では、 "floatingIpPortMappings" リソースで FloatingIp 作成されます。

YAMLの例 "floatingIpPortMappings" :

例:NodePortサービスリクエストの移行

リクエストがノードポートに到達した時点から、サービスリクエストがバックエンドポッドに到達するまで、NodePortサービスリクエストの過程をたどりましょう。

Nodeportサービスは kubeproxy.Kubernetesネットワークプロキシ(kube-proxy)は、各ノードで実行されているデーモンです。クラスターで定義されたサービスを反映し、サービスのバックエンドポッドにリクエストをロードバランスするためのルールを管理します。

次の例では、NodePort サービス apple-service が作成され、そのエンドポイントが関連付けられています。

サービスが作成、削除、またはエンドポイントが変更されるたびに、 kube-proxy クラスターの iptables 各ノードのルールを更新します。チェーンを表示して、 iptables リクエストの過程を把握し、追跡します。

まず、KUBE-NODEPORTSチェーンは、タイプ NodePortのサービスに入ってくるパケットを考慮します。

ポート 31050 に入ってくる各パケットは、まず KUBE-MARK-MASQ によって処理されます。このパケットに値を 0x4000 タグ付けします。

次に、パケットは KUBE-SVC-Y4TE457BRBWMNDKG チェーン(上記の KUBE-NODEPORTS チェーンで参照)によって処理されます。その点を詳しく見ると、追加のiptablesチェーンが表示されます。

KUBE-SEP-LCGKUEHRD52LOEFX チェーンを検査して、アプリケーションを実行しているバックエンド ポッドの 1 つへのルーティングを apple-service 定義していることを確認します。

これにより、リクエストがノードポートに到達したときから、サービスリクエストがバックエンドポッドに到達するまで、NodePortサービスリクエストの移行が完了します。

外部トラフィック ポリシーにおけるローカル オプションの制限

として設定Localされた NodePort サービスexternalTrafficPolicyは、Contrail Networking リリース 22.1 ではサポートされていません。

このサービスが externalTrafficPolicy 外部トラフィックをノードローカルまたはクラスタ全体のエンドポイントにルーティングすることを望む場合を示します。

• Local はクライアントの送信元 IP アドレスを保持し、NodePort タイプ サービスのセカンド ホップを回避します。
• Cluster はクライアントの送信元IPアドレスを曖昧にし、別のノードにセカンドホップが発生する可能性があります。

Cluster は のデフォルトです externalTrafficPolicy。

サービスの更新または削除、またはサービスからポッドを削除する

• サービスの更新 - 変更可能なフィールドは、 と Namespaceを除いて Name変更できます。たとえば、Nodeport サービスは、サービス YAML 定義のフィールドをType変更することでに変更ClusterIpできます。
• サービスの削除 —サービスは、に関係なく Type、 コマンドで削除できます。

  kubectl delete -n <name_space> <service_name>

• ポッドをサービスから削除する — これは、 および Selector をLabelsサービスまたはポッドで変更することで実現できます。