NSX-T Data Centerロード バランサは、OpenShift と連携し、OpenShift Router として機能します。

NCP は OpenShift Route とエンドポイントのイベントを監視し、ルートの仕様に基づいて、ロード バランサ上のロード バランシング ルールを構成します。結果的に、NSX-T Data Centerロード バランサはこのルールに基づき、適切なバックエンド ポッドにレイヤー 7 の受信トラフィックを転送します。

ロード バランシングの設定には、Kubernetes LoadBalancer サービスや OpenShift Route の設定などが含まれます。また、NCP レプリケーション コントローラの設定も必要です。LoadBalancer サービスは、レイヤー 4 トラフィック向け、OpenShift Route は、レイヤー 7 トラフィック向けです。

Kubernetes LoadBalancer サービスを設定すると、設定した外部の IP アドレス ブロックの IP アドレスが割り当てられます。ロード バランサは、この IP アドレスとサービス ポートを通じて公開されます。LoadBalancer に定義されている loadBalancerIP を使用して、IP アドレス プールの名前または ID を指定できます。LoadBalancer サービスの IP アドレスは、この IP アドレス プールから割り当てられます。loadBalancerIP が空白の場合、IP アドレスは事前設定した外部 IP アドレス ブロックから割り当てられます。

loadBalancerIP によって指定された IP プールには、scope: ncp/owner, tag: cluster:<cluster_name> タグが必要です。

NSX-T Data Center のロード バランサを使用するには、ロード バランシングを NCP で設定する必要があります。ncp_rc.yml ファイルで次の操作を行います。

  1. use_native_loadbalancerTrue に設定します。
  2. pool_algorithmWEIGHTED_ROUND_ROBIN に設定します。
  3. lb_default_cert_pathlb_priv_key_path が、それぞれ認証局 (CA) 署名証明書ファイルとプライベート キー ファイルの完全パス名になるように設定します。CA 署名証明書を生成するサンプル スクリプトについては、以降を参照してください。また、NCP ポッドに、デフォルトの証明書とキーをマウントします。手順については、以降を参照してください。
  4. (オプション)パーシステンスの設定にパラメータ 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
  5. (オプション)service_sizeSMALLMEDIUM、または LARGE を設定します。デフォルトは SMALL です。
  6. OpenShift 3.11 を実行している場合、次の設定を実行して、OpenShift が LoadBalancer サービスに IP アドレスを割り当てないようにする必要があります。
    • /etc/origin/master/master-config.yaml ファイル中の networkConfig で、ingressIPNetworkCIDR を 0.0.0.0/32 に設定します。
    • 次のコマンドを使用して API サーバとコントローラを再起動します。
         master-restart api
         master-restart controllers

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

レイヤー 7 ロード バランサの例

次の YAML ファイルでは、レイヤー 7 ロード バランシングを提供する 2 つのレプリケーション コントローラ(tea-rc および coffee-rc)、2 つのサービス(tea-svc および coffee-svc、2 つのルート(cafe-route-multi および cafe-route)を設定しています。
# RC
apiVersion: v1
kind: ReplicationController
metadata:
  name: tea-rc
spec:
  replicas: 2
  template:
    metadata:
       labels:
         app: tea
    spec:
      containers:
      - name: tea
        image: nginxdemos/hello
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: ReplicationController
metadata:
  name: coffee-rc
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: coffee
    spec:
      containers:
      - name: coffee
        image: nginxdemos/hello
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
---
# Services
apiVersion: v1
kind: Service
metadata:
  name: tea-svc
  labels:
    app: tea
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: tea
---
apiVersion: v1
kind: Service
metadata:
  name: coffee-svc
  labels:
    app: coffee
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: coffee
---
# Routes
apiVersion: v1
kind: Route
metadata:
  name: cafe-route-multi
spec:
  host: www.cafe.com
  path: /drinks
  to:
    kind: Service
    name: tea-svc
    weight: 1
  alternateBackends:
  - kind: Service
    name: coffee-svc
    weight: 2
---
apiVersion: v1
kind: Route
metadata:
  name: cafe-route
spec:
  host: www.cafe.com
  path: /tea-svc
  to:
    kind: Service
    name: tea-svc
    weight: 1

補注

  • edgepassthroughreencrypt のすべての終了モードがサポートされています。
  • ワイルドカードを使用するサブドメインの指定がサポートされています。たとえば、SubdomainwildcardPolicy が設定されていて、ホスト名が wildcard.example.com に設定されている場合、*. example.com へのすべての要求に対してサービスが提供されます。
  • 設定の誤りが原因で、Route イベントの処理中に NCP でエラーが発生する場合は、Route の YAML ファイルを修正し、Route リソースを削除して再作成する必要があります。
  • NCP では、ネームスペースによるホスト名の所有は適用されません。
  • Kubernetes クラスタあたり 1 つの LoadBalancer サービスがサポートされます。
  • NSX-T Data Center は、各 LoadBalancer サービス ポートにレイヤー 4 のロード バランサ仮想サーバおよびプールを作成します。TCP および UDP の両方がサポートされます。
  • NSX-T Data Center ロード バランサには、異なるサイズを使用できます。NSX-T Data Center のロード バランサの構成については、『NSX-T Data Center 管理ガイド 』を参照してください。

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

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

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