CRD (CustomResourceDefinitions) を作成して NSX ロード バランサの使用状況を監視し、デフォルトのロード バランサでは処理できない Ingress ワークロードを処理するための追加の NSX レイヤー 7 ロード バランサを作成できます。これらの CRD は、Kubernetes LoadBalancer サービス用に作成されたレイヤー 4 ロード バランサのスケーリングのためのものではありません。
共有 Tier-1 トポロジがある場合にこの機能を使用するには、nsx-ncp-config ConfigMap の [nsx_v3] で tier0_gateway を構成する必要があります。
- NSXLoadBalancerMonitor - この CRD は、NSX ロード バランサの使用統計情報を報告するために使用されます。ポリシー モードの場合、この CRD は LoadBalancer CRD で作成された名前空間のロード バランサのみを監視します。
- LoadBalancer - この CRD は、新しい NSX ロード バランサを作成するために使用されます。このリソースの定義は、NCP YAML ファイルにあります。ポリシー モードと TKGI 環境の場合は、名前空間のリソースです。マネージャ モード環境の場合、これはクラスタ全体のリソースになります。
この機能を有効にする手順は、マネージャ モードとポリシー モードで同じです。
- [k8s] セクションの enable_lb_crd オプションを True に設定します。
- 次のコマンドを使用して、NCP YAML ファイルを適用します。
kubectl apply -f ncp-<platform>.yaml
apiVersion: vmware.com/v1alpha1 kind: LoadBalancer metadata: name: cluster1-lbs0 spec: httpConfig: {} size: SMALL
この YAML ファイルは、指定したサイズの NSX ロード バランサと、パーシステンス、SSL、または X-Forward 設定を持たないレイヤー 7 仮想サーバのペアを作成します。size パラメータには、SMALL、MEDIUM、または LARGE を指定できます。デフォルト値は SMALL です。NSX ロード バランサを作成した後は、サイズを変更することはできず、size パラメータの更新は無視されます。仮想サーバの IP アドレスは、ロード バランサ用に設定されたデフォルトの外部プールから割り当てられます。デフォルトのポートは 80 および 443 です。HTTP HOST ヘッダーにカスタム ポートが含まれている場合は、標準以外のポートもサポートされます。カスタム ポートは、非 TLS Ingress でのみサポートされることに注意してください。また、LoadBalancer CRD によって作成された仮想サーバは、「アクセス ログの有効化」パラメータをサポートしていません。
kubectl get lb <name of the LoadBalancer> -o yaml
status: conditions: - status: "True" type: Ready httpVirtualIP: <realized virtual IP>
この結果は、作成が成功したことを示します。作成に失敗した場合、status は False となり、仮想 IP アドレスは含まれません。
spec: httpConfig: virtualIP: <ip address, default to auto-allocate> port: <port number, default to 80>
注: 異なる LoadBalancer CRD に同じ VirtualIP を構成しないでください。
spec: httpConfig: xForwardedFor: <INSERT or REPLACE, default to None> affinity: type: <source_ip or cookie, default to None> timeout: <timeout number, default to 10800>
spec: httpConfig: tls: port: <tls port number, default to 443> secretName: <name of secret, default to None>
curl -I -HHost:tea.example.com http://$INGRESS_IP:$CRD_LB_HTTP_PORT/tea
LoadBalancer の作成前または作成後にシークレットを作成できます。証明書を更新するには、最初に LoadBalancer の仕様から secretName を削除し、シークレットのデータを更新してから、上記の構成を使用して同じシークレットを再接続します。新しいシークレットの作成および secretName の更新も同じ動作をします。異なる CRD ロード バランサ間で同じシークレット データを共有することはサポートされていません。異なる証明書を使用して CRD ロード バランサを設定する必要があります。
kubectl get lbm
- 使用状況 - NSX ロード バランサ上のワークロードの数。
- トラフィック - 各仮想サーバの集約された統計情報。
- 健全性 - このフィールドには 2 つのディメンションがあります。
- servicePressureIndex - ロード バランサのパフォーマンスを示します。スコアと重要度という 2 つの値が提供されます。
- infraPressureIndex - 基盤となるインフラストラクチャ コンポーネントのパフォーマンスを示します。NCP 2.5.1 では、この値は必ずしも正確ではありません。
- フィールド metrics には、健全性スコアの計算時に考慮されるパラメータの概念が示されています。
ロード バランサの servicePressureIndex が HIGH の場合は、Ingress のワークロードを別のロード バランサに移行できます。これは、LoadBalancer CRD を使用して作成されたデフォルトのロード バランサである必要があります。
annotations: nsx/loadbalancer: <name of the LoadBalancer CRD>
アノテーションがない場合、または null に設定されている場合、Ingress はデフォルトの NSX ロード バランサに配置されます。