Ab NCP 2.5.1 können Sie CRDs (CustomResourceDefinitions) erstellen, um die Nutzung von NSX Load Balancer zu überwachen und zusätzliche NSX Load Balancer auf Schicht 7 zu erstellen, um Ingress-Arbeitslasten zu verarbeiten, die der Standard Load Balancer nicht verarbeiten kann. Diese CRDs sind nicht für die Skalierung von Load Balancer auf Schicht 4 vorgesehen, die für Kubernetes LoadBalancer-Dienste erstellt wurden.

Die CRDs:
  • NSXLoadBalancerMonitor – Diese CRD wird verwendet, um Nutzungsstatistiken der NSX Load Balancer zu erstellen.
  • LoadBalancer – Diese CRD wird zur Erstellung neuer NSX Load Balancer verwendet. Die Definition dieser Ressource befindet sich in der NCP YAML-Datei. Dies ist eine clusterweite Ressource, die nicht an einen bestimmten Namensraum gebunden ist.

Um diese Funktion zu aktivieren, muss in der NCP YAML-Datei die Option enable_lb_crd im Abschnitt k8s auf True und die Option policy_nsxapi auf False gesetzt werden. Aus diesem Grund müssen Sie die Manager-Benutzeroberfläche und -API verwenden, um NSX-T-Ressourcen zu konfigurieren.

Um einen neuen NSX Load Balancer zu erstellen, wenden Sie eine YAML-Datei an, die eine LoadBalancer-CRD definiert. Beispiel: 
apiVersion: vmware.com/v1alpha1
kind: LoadBalancer
metadata:
    name: cluster1-lbs0
spec:
    httpConfig: {}

Diese YAML-Datei erstellt einen NSX Load Balancer mit einer geringen Größe und ein Paar von virtuellen Servern auf Schicht 7 ohne Persistenz, SSL oder X-forward-Einstellungen. Die IP des virtuellen Servers wird von dem als Standard konfigurierten externen Pool für Load Balancer zugeteilt. Die Ports sind standardmäßig 80 und 443.

Um den Erstellungsstatus der LoadBalancer-CRD zu überprüfen, führen Sie den folgenden Befehl aus: 
kubectl get lb <name of the LoadBalancer> -o yaml
Das Ergebnis sieht ungefähr so aus wie das folgende: 
status:
 conditions:
 - status: "True"
   type: Ready
 httpVirtualIP: <realized virtual IP>

Dieses Ergebnis gibt an, dass die Erstellung erfolgreich war. Wenn die Erstellung fehlgeschlagen ist, wird status gleich "False" und es gibt keine virtuelle IP-Adresse.

Sie können auch die Einstellungen für den NSX Load Balancer und die virtuellen Server anpassen. So konfigurieren Sie die IP und den Port für den virtuellen Server: 
spec:
    httpConfig:
        virtualIP: <ip address, default to auto-allocate>
        port: <port number, default to 80>
So geben Sie die Sitzungsaffinität und den X-forwarded-Modus an: 
spec:
    httpConfig:
         xForwardedFor: <INSERT or REPLACE, default to None>
         affinity:
             type: <source_ip or cookie, default to None>
             timeout: <timeout number, default to 10800>
So konfigurieren Sie TLS-Einstellungen: 
spec:
    httpConfig:
        tls:
            port: <tls port number, default to 443>
            secretName: <name of secret, default to None>
            secretNamespace: <namespace of secret, default to None>
Selbst wenn Sie die HTTP- und HTTPS-Ports auf Nicht-Standardwerte setzen, zeigt der Ingress-Drucker aufgrund einer Kubernetes-Einschränkung bei der Anzeige des Ingress-Status immer die Standard-Portwerte (80 und 443) an. Sie sollten weiterhin die konfigurierten Ports für den Zugriff auf den Ingress verwenden. Beispiel: 
curl -I -HHost:tea.example.com http://$INGRESS_IP:$CRD_LB_HTTP_PORT/tea

Sie können den Schlüssel vor oder nach der Erstellung von LoadBalancer erstellen. Um das Zertifikat zu aktualisieren, entfernen Sie zuerst secretName und secretNamespace aus der LoadBalancer-Spezifikation, aktualisieren Sie die Daten des geheimen Schlüssels und fügen Sie dann denselben geheimen Schlüssel mithilfe der obigen Konfiguration erneut an. Das Erstellen eines neuen geheimen Schlüssels und das Aktualisieren von secretName und secretNamespace funktionieren ebenfalls. Beachten Sie, dass die gemeinsame Nutzung derselben Daten des geheimen Schlüssels zwischen verschiedenen CRD Load Balancer nicht unterstützt wird. Sie müssen CRD Load Balancer mit unterschiedlichen Zertifikaten konfigurieren.

Führen Sie den folgenden Befehl aus, um den Status und die Statistiken der NSX Load Balancer anzuzeigen: 
kubectl get lbm
Dadurch werden alle NSXLoadBlancerMonitors aufgelistet, einer für jeden NSX Load Balancer. Die folgenden Informationen werden angezeigt:
  • Nutzung – die Anzahl der Arbeitslasten im NSX Load Balancer.
  • Datenverkehr – die aggregierten Statistiken jedes virtuellen Servers.
  • Integrität – Dieses Feld hat zwei Dimensionen:
    • servicePressureIndex – Dies zeigt die Leistung des Load Balancer an. Es werden zwei Werte angegeben: Punktzahl und Schweregrad.
    • infraPressureIndex – Dies zeigt die Leistung der zugrunde liegenden Infrastrukturkomponenten an. In NCP 2.5.1 ist dieser Wert nicht immer korrekt.
    • Das Feld metrics liefert eine Vorstellung der Parameter, die berücksichtigt werden, wenn die Integritäts Punktzahl berechnet wird.

Wenn der Wert servicePressureIndex eines Load Balancer HIGH ist, können Sie die Arbeitslast für den Ingress auf andere Load Balancer migrieren, wobei es sich um den standardmäßigen Load Balancer oder den Load Balancer handelt, der mit der LoadBalancer-CRD erstellt wurde.

Um einen Ingress in einen dedizierten Load Balancer zu verlegen, fügen Sie der Ingress-Spezifikation eine Anmerkung hinzu. Beispiel: 
 annotations:
   nsx/loadbalancer: <name of the LoadBalancer CRD>

Wenn die Anmerkung fehlt oder auf null festgelegt ist, wird der Ingress auf dem standardmäßigen NSX Load Balancer platziert.