ロード バランシングの設定には、Kubernetes の LoadBalancer サービスまたは Ingress リソースと、NCP レプリケーション コントローラの設定が含まれます。

タイプが LoadBalancer の Kubernetes サービスを構成して、レイヤー 4 ロード バランサを作成することができます。また、Kubernetes Ingress リソースを構成してレイヤー 7 ロード バランサを構成することもできます。

NSX Container Plug-in (NCP) でロード バランシングを設定するには、ncp-rc.yml ファイルで次のように設定します。

  1. use_native_loadbalancerTrue に設定します。
  2. (オプション)pool_algorithmROUND_ROBIN または LEAST_CONNECTION/IP_HASH に設定します。デフォルトは ROUND_ROBIN です。
  3. (オプション)service_sizeSMALLMEDIUM、または LARGE に設定します。デフォルトは SMALL です。

LEAST_CONNECTION/IP_HASH アルゴリズムの場合、トラフィックの送信元 IP アドレスが同じであれば、同じバックエンド ポッドに送信されます。

各種サイズの NSX-T ロード バランサのサポート対象の詳細については、『NSX-T Data Center Administration Guide』を参照してください。

ロード バランサが作成された後に、構成ファイルを更新してロード バランサのサイズを変更することはできません。変更するには、NSX Manager ユーザー インターフェイスまたは API を使用します。

レイヤー 4 およびレイヤー 7 ロード バランシングのパーシステンスの設定

NCP ConfigMap で、パーシステンス設定にパラメータ l4_persistencel7_persistence を指定できます。レイヤー 4 パーシステンスに使用可能なオプションは、送信元 IP アドレスです。レイヤー 7 パーシステンスに使用可能なオプションは、Cookie と送信元 IP アドレスです。デフォルトは <None> です。次はその例です。
   # Choice of persistence type for ingress traffic through L7 Loadbalancer.
   # Accepted values:
   # 'cookie'
   # 'source_ip'
   l7_persistence = cookie

   # Choice of persistence type for ingress traffic through L4 Loadbalancer.
   # Accepted values:
   # 'source_ip'
   l4_persistence = source_ip

Kubernetes LoadBalancer サービスの場合は、サービス仕様に sessionAffinity を指定して、グローバル レイヤー 4 のパーシステンスがオフの場合、つまり l4_persistence<None> に設定されている場合のサービスのパーシステンス動作を設定することもできます。l4_persistencesource_ip に設定されている場合、サービスのパーシステンス タイムアウトをカスタマイズするために、サービス仕様の sessionAffinity を使用できます。デフォルトのレイヤー 4 のパーシステンス タイムアウトは 10,800 秒です。これは、サービスの Kubernetes ドキュメントに指定されているものと同じです(https://kubernetes.io/docs/concepts/services-networking/serviceを参照)。デフォルトのパーシステンス タイムアウトが設定されているサービスはすべて、同じ NSX-T ロード バランサのパーシステンス プロファイルを共有します。デフォルト以外のパーシステンス タイムアウトを使用して、各サービスに専用プロファイルが作成されます。

注: Ingress のバックエンド サービスが LoadBalancer タイプのサービスである場合、サービスのレイヤー 4 仮想サーバと Ingress のレイヤー 7 仮想サーバに異なるパーシステンスを設定することはできません。たとえば、レイヤー 4 に source_ip、レイヤー 7 に cookie を設定することはできません。このようなシナリオでは、両方の仮想サーバのパーシステンス設定を同じ( source_ipcookie、または None)にするか、1 つを None(その他の設定は source_ip または cookie)にする必要があります。シナリオの例:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea
        backend:
          serviceName: tea-svc
          servicePort: 80
-----
apiVersion: v1
kind: Service
metadata:
  name: tea-svc <==== same as the Ingress backend above
  labels:
    app: tea
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: tcp
  selector:
    app: tea
  type: LoadBalancer

入力方向 (Ingress)

  • NSX-T Data Center では、TLS 仕様の Ingress と、TLS 仕様でない Ingress 用に、レイヤー 7 のロード バランサ仮想サーバが 1 つずつ作成されます。
  • すべての Ingress が、単一の IP アドレスを取得します。
  • Ingress リソースには、ncp.ini[nsx_v3] セクションにある external_ip_pools オプションで指定された外部 IP アドレス プールから、IP アドレスが割り当てられます。ロード バランサは、この IP アドレスと HTTP および HTTPS ポート(80 と 443)上に公開されます。
  • Ingress リソースには、ncp.ini[nsx_v3] セクションにある external_ip_pools_lb オプションで指定された外部 IP アドレス プールから、IP アドレスが割り当てられます。external_ip_pools_lb オプションがない場合は、external_ip_pools で指定されたプールが使用されます。ロード バランサは、この IP アドレスと HTTP および HTTPS ポート(80 と 443)上に公開されます。
  • 設定を変更して NCP を再起動することで、異なる IP アドレス プールに変更できます。
  • TLS 用のデフォルト証明書を指定できます。証明書の生成および NCP ポッドへの証明書のマウントについては、以下を参照してください。
  • TLS 仕様でない Ingress は、HTTP 仮想サーバ(ポート 80)上でホストされます。
  • TLS 仕様の Ingress は、HTTPS 仮想サーバ(ポート 443)上でホストされます。ロード バランサは SSL サーバとして機能し、クライアントの SSL 接続を終了します。
  • Secret と Ingress の作成順序は重要ではありません。Secret オブジェクトがある場合、それを参照する Ingress があると、証明書は NSX-T Data Center にインポートされます。Secret が削除された場合、または最後に Ingress が行った Secret 参照が削除された場合は、Secret に対応する証明書は削除されます。
  • Ingress への TLS セクションの追加または削除はサポートされています。Ingress の仕様から tls キーが削除されると、Ingress ルールは HTTPS 仮想サーバ(ポート 443)から HTTP 仮想サーバ(ポート 80)に転送されます。同様に、Ingress の仕様に tls キーが追加されると、Ingress ルールは HTTP 仮想サーバ(ポート 80)から HTTPS 仮想サーバ(ポート 443)に転送されます。
  • Ingress の定義で、単一クラスタに対するルールが重複している場合、最初のルールのみが適用されます。
  • 1 つのクラスタでサポートされるのは、デフォルトのバックエンドを持つ単一の Ingress のみです。どの Ingress ルールとも一致しないトラフィックは、デフォルトのバックエンドに転送されます。
  • デフォルトのバックエンドを持つ Ingress が複数ある場合は、最初の 1 つのみが設定されます。その他の Ingress は、エラーと見なされます。
  • ワイルドカードによる URI マッチングでは、正規表現の文字「.」と「*」がサポートされます。たとえば、パス「/coffee/.*」は、「/coffee/」の後に 0 個または 1 個以上の文字が続く文字列、たとえば「/coffee/」、「/coffee/a」、「/coffee/b」と一致します。「/coffee」、「/coffeecup」、「/coffeecup/a」なとは一致しません。
    Ingress の仕様の例:
    kind: Ingress
    metadata:
      name: cafe-ingress
    spec:
      rules:
      - http:
          paths:
          - path: /coffee/.*    #Matches /coffee/, /coffee/a but NOT /coffee, /coffeecup, etc.
            backend:
              serviceName: coffee-svc
              servicePort: 80
  • Ingress のリソースにアノテーションを追加して、URL リクエスト rewrite を設定できます。次はその例です。
    kind: Ingress
    metadata:
      name: cafe-ingress
      annotations:
        ingress.kubernetes.io/rewrite-target: /
    spec:
      rules:
      - host: cafe.example.com
        http:
          paths:
          - path: /tea
            backend:
              serviceName: tea-svc
              servicePort: 80
          - path: /coffee
            backend:
              serviceName: coffee-svc
              servicePort: 80

    パス「 /tea 」および「 /coffee 」は、バックエンド サービスへの URL 送信前に「 / 」に書き換えられます。

  • 入力方向のアノテーション kubernetes.io/ingress.allow-http がサポートされます。
    • アノテーションを false に設定すると、HTTPS ルールのみが作成されます。
    • アノテーションを true に設定するか、アノテーションが見つからない場合は、HTTP ルールが作成されます。また、Ingress の仕様に TLS セクションがある場合は、HTTPS ルールが作成されます。
  • Ingress リソースにエラーのアノテーションが追加されます。エラー キーは ncp/error.loadbalancer で、警告キーは ncp/warning.loadbalancer です。想定されるエラーおよび警告は次のとおりです。
    • ncp/error.loadbalancer: DEFAULT_BACKEND_IN_USE

      このエラーは、デフォルトのバックエンドがある Ingress があることを示しています。Ingress は非アクティブになります。TLS の有無にかかわらず、Ingress のグループに含むことができるバックエンドはデフォルトで 1 つのみです。エラーを修正するには、Ingress を削除して適切な仕様で再作成します。

    • ncp/warning.loadbalancer: SECRET_NOT_FOUND

      このエラーは、Ingress の仕様で指定されている Secret が見つからないことを示しています。Ingress は、部分的にアクティブになります。エラーを修正するには、不足している Secret を作成します。アノテーションに警告がある場合、Ingress リソースのライフ サイクルでは消去されません。

    • ncp/warning.loadbalancer: INVALID_INGRESS
      このエラーは、次の条件のいずれかが True であることを示します。Ingress は非アクティブになります。エラーを修正するには、Ingress を削除して適切な仕様で再作成します。
      • Ingress ルールが、同じ Kubernetes クラスタ内の別の Ingress ルールと競合します。
      • allow-http アノテーションは False に設定され、Ingress には TLS セクションが設定されません。
      • Ingress ルールには host および path が指定されていません。このような Ingress ルールには Ingress のデフォルトのバックエンドと同じ機能があります。代わりに Ingress のデフォルトのバックエンドを使用します。

LoadBalancer タイプのサービス

  • NSX-T Data Center は、各サービス ポートにレイヤー 4 のロード バランサ仮想マシンおよびプールを作成します。
  • TCP および UDP の両方がサポートされます。
  • 各サービスには一意の IP アドレスが割り当てられます。
  • サービスには、LoadBalancer 定義の loadBalancerIP フィールドに基づいて外部 IP アドレス プールから IP アドレスが割り当てられます。loadBalancerIP フィールドは空白の場合もあれば、IP アドレスが設定されている場合もあります。また、IP アドレス プールの名前または ID が指定されている場合もあります。loadBalancerIP フィールドが空白の場合、IP アドレスは、ncp.ini[nsx_v3] セクションにある external_ip_pools_lb オプションで指定された外部 IP アドレス プールから割り当てられます。external_ip_pools_lb オプションがない場合は、external_ip_pools で指定されたプールが使用されます。LoadBalancer サービスは、この IP アドレスとサービス ポートを通じて公開されます。
  • 設定を変更して NCP を再起動することで、異なる IP アドレス プールに変更できます。
  • loadBalancerIP で指定される IP アドレス プールには、タグ {"ncp/owner": cluster:<cluster>} を含める必要があります。

  • サービスにはエラーのアノテーションが追加されます。エラー キーは ncp/error.loadbalancer です。想定されるエラーは次のとおりです。
    • ncp/error.loadbalancer: IP_POOL_NOT_FOUND

      このエラーは、指定した loadBalancerIP: <nsx-ip-pool> 中の <nsx-ip-pool> が見つからないことを示しています。サービスは非アクティブになります。エラーを修正するには、有効な IP アドレス プールを指定し、サービスを削除して再作成します。

    • ncp/error.loadbalancer: IP_POOL_EXHAUSTED

      このエラーは、指定した loadBalancerIP: <nsx-ip-pool> 中の IP アドレス プールで IP アドレスが枯渇していることを示しています。サービスは非アクティブになります。エラーを修正するには、使用可能な IP アドレスのある IP アドレス プールを指定し、サービスを削除して再作成します。

    • ncp/error.loadbalancer: IP_POOL_NOT_UNIQUE

      このエラーは、loadBalancerIP: <nsx-ip-pool> で指定された名前を持つ IP アドレス プールが複数あることを示します。サービスは非アクティブになります。

    • ncp/error.loadbalancer: POOL_ACCESS_DENIED

      このエラーは、loadBalancerIP で指定された IP アドレス プールにタグ {"ncp/owner": cluster:<cluster>} がないか、またはタグで指定されたクラスタが Kubernetes クラスタの名前と一致しないことを示します。

    • ncp/error.loadbalancer: LB_VIP_CONFLICT

      このエラーは、loadBalancerIP フィールドの IP アドレスがアクティブなサービスの IP アドレスと同じであることを示しています。サービスは非アクティブになります。

  • レイヤー 4 ロード バランサの自動スケーリングがサポートされます。Kubernetes LoadBalancer サービスが追加の仮想サーバを必要とするように作成または変更されており、既存のレイヤー 4 ロード バランサに十分な容量がない場合、新しいレイヤー 4 ロード バランサが作成されます。また、NCP は、仮想サーバが接続されていないレイヤー 4 ロード バランサも削除します。この機能はデフォルトで有効になっています。NCP ConfigMap で l4_lb_auto_scalingFalse に設定することで無効にできます。

ロード バランサおよびネットワーク ポリシー

NSX ロード バランサ仮想サーバからポッドにトラフィックを転送する場合は、送信元 IP アドレスが Tier-1 ルーターのアップリンク ポートの IP アドレスになります。このアドレスはプライベート Tier-1 移行ネットワーク上にあるため、許可されるべきトラフィックが CIDR ベースのネットワーク ポリシーにより許可されないことがあります。この問題を避けるには、Tier-1 ルーターのアップリンク ポートの IP アドレスが、許可されている CIDR ブロックに含まれるようにネットワーク ポリシーを設定する必要があります。この内部 IP アドレスは、status.loadbalancer.ingress.ip フィールドと Ingress リソースのアノテーション (ncp/internal_ip_for_policy) として表示されます。

たとえば、仮想サーバの外部 IP アドレスが 4.4.0.5 であり、内部 Tier-1 ルーターのアップリンク ポートの IP アドレスが 100.64.224.11 の場合、ステータスは次のようになります。
    status:
      loadBalancer:
      ingress:
      - ip: 4.4.0.5
      - ip: 100.64.224.11
Ingress と LoadBalancer タイプ サービスのリソースのアノテーションは、次のようになります。
    ncp/internal_ip_for_policy: 100.64.224.11
IP アドレス 100.64.224.11 は、ネットワーク ポリシーの ipBlock セレクタで許可された CIDR に属している必要があります。次はその例です。
    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    ...
    ingress:
    - from:
      - ipBlock:
         cidr: 100.64.224.11/32

CA 署名証明書を生成するサンプル スクリプト

次のスクリプトによって、CA 署名証明書とプライベート キーが生成され、それぞれファイル <filename>.crt および <finename>.key として格納されます。 genrsa コマンドで CA キーを生成します。CA キーは暗号化する必要があります。 aes256 などのコマンドを使用して、暗号化方式を指定できます。
#!/bin/bash
host="www.example.com"
filename=server

openssl genrsa -out ca.key 4096
openssl req -key ca.key -new -x509 -days 365 -sha256 -extensions v3_ca -out ca.crt -subj "/C=US/ST=CA/L=Palo Alto/O=OS3/OU=Eng/CN=${host}"
openssl req -out ${filename}.csr -new -newkey rsa:2048 -nodes -keyout ${filename}.key -subj "/C=US/ST=CA/L=Palo Alto/O=OS3/OU=Eng/CN=${host}"
openssl x509 -req -days 360 -in ${filename}.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out ${filename}.crt -sha256

デフォルトの証明書とキーの NCP ポッドへのマウント

証明書とプライベート キーは生成後、ホスト仮想マシンのディレクトリ /etc/nsx-ujo に配置されます。証明書とキー ファイルの名前がそれぞれ lb-default.crtlb-default.key の場合、以下のように ncp-rc.yaml を編集して、ホスト上のこれらのファイルが、ポッドにマウントされるようにします。次はその例です。
spec:
  ...
  containers:
  - name: nsx-ncp
    ...
    volumeMounts:
    ...
    - name: lb-default-cert
      # Mount path must match nsx_v3 option "lb_default_cert_path"
      mountPath: /etc/nsx-ujo/lb-default.crt
    - name: lb-priv-key
      # Mount path must match nsx_v3 option "lb_priv_key_path"
      mountPath: /etc/nsx-ujo/lb-default.key
  volumes:
  ...
  - name: lb-default-cert
    hostPath:
      path: /etc/nsx-ujo/lb-default.crt
  - name: lb-priv-key
    hostPath:
      path: /etc/nsx-ujo/lb-default.key