ロード バランシングの構成
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
ファイルで次の操作を行います。
- 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
ロード バランサのパーシステンス プロファイルを共有します。デフォルト以外のパーシステンス タイムアウトを使用して、各サービスに専用プロファイルが作成されます。 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
ルーターのシャーディング
OpenShift 4 では、各ルートのメタデータ フィールドに任意の数のラベルを付けることができます。ルーターは、セレクタを使用して、ルート プール全体からルートのサブセットを選択します。ルートのネームスペースのラベルも選択できます。選択したルートがルート シャードを形成します。
ルート シャードは、次のような目的で作成できます。
- ルート ラベルまたはネームスペースに基づいて Ingress を構成します。
- アプリケーションに異なるルートを構成します。
- 複数のロード バランサ サービスにワークロードを分散して、パフォーマンスを向上させます。
この機能は、レイヤー 7 ロード バランサ サービスのシャーディングのみをサポートします。
ルーター シャーディングの構成手順:
- configmap.yamlの[k8s]セクションでenable_lb_crdオプションを True に設定して、YAML ファイルを適用します。LoadBalancer CRD (CustomResourceDefinition) を定義する YAML ファイルを作成して適用します。次はその例です。apiVersion: vmware.com/v1alpha1 kind: LoadBalancer metadata: name: lbs-crd-1 spec: httpConfig: virtualIP: 192.168.4.4 # VIP for HTTP/HTTPS server. Default to auto_allocate port: 81 # HTTP port number. Default to 80 tls: port: 9998 # HTTPS port number. default to 443 secretName: default_secret # Default certificate for HTTPS server. Default to nil secretNamespace: default # Need to be set with secretName xForwardedFor: INSERT # Available values are INSERT, REPLACE. Default to nil affinity: type: source_ip # Available values are sourceIP, cookie timeout: 100 # Default to 10800 size: MEDIUM # Default to SMALL
- ネームスペースラベル セレクタを使用してルーターを構成するには、次のコマンドを実行します(ルーターの dc/svc が router であるとします)。oc set env dc/router NAMESPACE_LABELS="router=r1"
- 前の手順で構成したルーターが、選択したネームスペースからのルートを処理します。このセレクタをネームスペースと一致させるには、ネームスペースに適切なラベルを設定します。次はその例です。apiVersion: v1 kind: Route metadata: name: cafe-route annotations: nsx/loadbalancer: lbs-crd-1 spec: host: cafe.example.com to: kind: Service name: tea-svc weight: 1次のコマンドを実行します。oc label namespace targetns "router=r1"targetns は、ターゲット ルートが存在する正確なネームスペースに置き換えます。次はその例です。apiVersion: v1 kind: Namespace metadata: name: qe annotations: nsx/loadbalancer: lbs-crd-1注:ネームスペース内のルートに別のアノテーションがある場合は、ルートのアノテーションが優先されます。
レイヤー 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 Administration Guide』を参照してください。ロード バランサが作成された後に、構成ファイルを更新してロード バランサのサイズを変更することはできません。変更するには、ユーザー インターフェイスまたは API を使用します。
- レイヤー 4 ロード バランサの自動スケーリングがサポートされます。Kubernetes LoadBalancer サービスが追加の仮想サーバを必要とするように作成または変更されており、既存のレイヤー 4 ロード バランサに十分な容量がない場合、新しいレイヤー 4 ロード バランサが作成されます。また、NCP は、仮想サーバが接続されていないレイヤー 4 ロード バランサも削除します。この機能はデフォルトで有効になっています。NCP ConfigMap でl4_lb_auto_scalingをFalseに設定することで無効にできます。
- ルートの仕様でdestinationCACertificateパラメータはサポートされていません。このパラメータは NCP によって無視されます。
- 各 TLS ルートには異なる CA 署名証明書が必要です。
- NSX ロード バランサでルートを管理しない場合は、ルート仕様に注釈use_nsx_controller:Falseを追加します。
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