ロード バランシングの設定には、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 アドレス プールには、タグ {"ncp/owner": cluster:<cluster>} を含める必要があります。

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

  1. use_native_loadbalancerTrue に設定します。

  2. pool_algorithmWEIGHTED_ROUND_ROBIN に設定します。

  3. lb_default_cert_path と lb_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

ルーターのシャーディング

NCP は常に TLS Edge ターミネーションと HTTP ルートを処理し、名前空間や名前空間ラベルに関係なく、TLS パススルー ルートおよび TLS 再暗号化ルートをスキップします。OpenShift ルーターが TLS 再暗号化およびパススルー ルートのみを処理するように制限するには、次の手順を実行する必要があります。

  • Openshift ルーターに名前空間ラベル セレクタを追加します。

  • ターゲット名前空間に名前空間ラベルを追加します。

  • ターゲット名前空間に TLS 再暗号化/パススルー ルートを作成します。

たとえば、名前空間ラベル セレクタを使用してルーターを設定するには、次のコマンドを実行します(ルーターのサービス アカウント名が router であると仮定します)。

oc set env dc/router NAMESPACE_LABELS="router=r1"

ルーターは選択された名前空間からルートを処理するようになります。このセレクタを名前空間と一致させるには、次のコマンドを実行します(名前空間は ns1 であると仮定します)。

oc label namespace ns1 "router=r1"

レイヤー 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

補注

  • HTTPS トラフィックでは Edge ターミネーションのみがサポートされます。

  • ワイルドカードを使用するサブドメインの指定がサポートされています。たとえば、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 に設定することで無効にできます。

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