ロードバランシングの設定

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 ファイルで次の操作を行います。

use_native_loadbalancer を True に設定します。
pool_algorithm を WEIGHTED_ROUND_ROBIN に設定します。
lb_default_cert_path と lb_priv_key_path が、それぞれ認証局 (CA) 署名証明書ファイルとプライベートキーファイルの完全パス名になるように設定します。CA 署名証明書を生成するサンプルスクリプトについては、以降を参照してください。また、NCP ポッドに、デフォルトの証明書とキーをマウントします。手順については、以降を参照してください。
（オプション）パーシステンスの設定にパラメータ l4_persistence と l7_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
```
（オプション）service_size に SMALL、MEDIUM、または LARGE を設定します。デフォルトは SMALL です。
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_persistence が source_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_ip、 cookie、または 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

補注

edge、passthrough、reencrypt のすべての終了モードがサポートされています。
ワイルドカードを使用するサブドメインの指定がサポートされています。たとえば、Subdomain に wildcardPolicy が設定されていて、ホスト名が 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_scaling を False に設定することで無効にできます。
ルートの仕様で 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

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

補注

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

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

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