VMware NSX Container Plugin 3.0

4.2 4.1 4.0 3.2 3.1 3.0
简体中文 Deutsch Español Français Italiano 日本語 한국어 繁體中文 English

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

NSX
ロード バランサは、OpenShift と連携し、OpenShift Router として機能します。
NCP は OpenShift Route とエンドポイントのイベントを監視し、ルートの仕様に基づいて、ロード バランサ上のロード バランシング ルールを構成します。結果的に、
NSX
ロード バランサはこのルールに基づき、適切なバックエンド ポッドにレイヤー 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
 のロード バランサを使用するには、ロード バランシングを NCP で設定する必要があります。
ncp_rc.yml
 ファイルで次の操作を行います。
  1. use_native_loadbalancer
     を
    True
     に設定します。
  2. pool_algorithm
     を
    WEIGHTED_ROUND_ROBIN
     に設定します。
  3. lb_default_cert_path
     と
    lb_priv_key_path
     が、それぞれ認証局 (CA) 署名証明書ファイルとプライベート キー ファイルの完全パス名になるように設定します。CA 署名証明書を生成するサンプル スクリプトについては、以降を参照してください。また、NCP ポッドに、デフォルトの証明書とキーをマウントします。手順については、以降を参照してください。
  4. （オプション）パーシステンスの設定にパラメータ
    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
  5. （オプション）
    service_size
     に
    SMALL
    、
    MEDIUM
    、または
    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_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
     は、各 LoadBalancer サービス ポートにレイヤー 4 のロード バランサ仮想サーバおよびプールを作成します。TCP および UDP の両方がサポートされます。
  • NSX
     ロード バランサには、異なるサイズを使用できます。
    NSX
     のロード バランサの構成については、『
    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

Content feedback and comments