Der NSX-T Data Center-Load Balancer ist in OpenShift integriert und fungiert als OpenShift-Router.

NCP überwacht OpenShift-Routen- und -Endpoint-Ereignisse und konfiguriert Load Balancing-Regeln auf dem Load Balancer basierend auf der Routenspezifikation. Dies führt dazu, das der NSX-T Data Center-Load Balancer eingehenden Schicht 7-Datenverkehr basierend auf den Regeln zu den geeigneten Backend-Pods weiterleitet.

Das Konfigurieren des Load Balancing umfasst das Konfigurieren eines Kubernetes-LoadBalancer-Diensts oder einer OpenShift-Route. Sie müssen auch den NCP ReplicationController konfigurieren. Der LoadBalancer-Dienst wird für den Schicht 4-Datenverkehr und die OpenShift-Route für den Schicht 7-Datenverkehr verwendet.

Wenn Sie einen Kubernetes-LoadBalancer-Dienst konfigurieren, wird diesem eine IP-Adresse aus dem von Ihnen konfigurierten externen IP-Block zugeteilt. Der Load Balancer wird auf dieser IP-Adresse und dem Dienst-Port bereitgestellt. Sie können den Namen oder die ID eines IP-Pools mithilfe der loadBalancerIP-Spezifikation in der Definition des LoadBalancer-Diensts angeben. Die IP-Adresse des LoadBalancer-Diensts wird aus diesem IP-Pool zugeteilt. Wenn die loadBalancerIP-Spezifikation leer ist, wird die IP-Adresse aus dem externen IP-Block zugeteilt, den Sie konfigurieren.

Der von loadBalancerIP angegebene-IP-Pool muss über das Tag scope: ncp/owner, tag: cluster:<cluster_name> verfügen.

Um den Load Balancer von NSX-T Data Center zu verwenden, müssen Sie Load Balancing in NCP konfigurieren. Führen Sie in der Datei ncp_rc.yml die folgenden Schritte aus:

  1. Legen Sie use_native_loadbalancer = True fest.
  2. Legen Sie pool_algorithm auf WEIGHTED_ROUND_ROBIN fest.
  3. Legen Sie lb_default_cert_path und lb_priv_key_path als vollständige Pfadnamen der von der Zertifizierungsstelle signierten Zertifikatdatei und der Datei mit dem privaten Schlüssel fest. Ein Beispielskript zum Generieren eines von einer Zertifizierungsstelle signierten Zertifikats finden Sie unten. Mounten Sie darüber hinaus das Standardzertifikat und den Standardschlüssel in den NCP-Pod. Anweisungen hierzu finden Sie unten.
  4. (Optional) Legen Sie mit den Parametern l4_persistence und l7_persistence eine Persistenzeinstellung fest. Die verfügbare Option für die Schicht-4-Persistenz ist „Quell-IP“. Die verfügbaren Optionen für die Schicht-7-Persistenz sind „Cookie“ und „Quell-IP“. Die Standardeinstellung ist <None>. Beispiel:
       # 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. (Optional) Legen Sie service_size = SMALL, MEDIUM oder LARGE fest. Die Standardeinstellung ist SMALL.
  6. Wenn Sie OpenShift 3.11 ausführen, müssen Sie die folgende Konfiguration ausführen, damit OpenShift dem LoadBalancer-Dienst keine IP zuweist.
    • Legen Sie ingressIPNetworkCIDR unter networkConfig in der Datei /etc/origin/master/master-config.yaml auf „0.0.0.0/32“ fest.
    • Starten Sie den API-Server und die API-Controller mit den folgenden Befehlen neu:
         master-restart api
         master-restart controllers

Für einen Kubernetes-LoadBalancer-Dienst können Sie sessionAffinity auch in der Dienstspezifikation angeben, um das Persistenzverhalten für den Dienst zu konfigurieren, wenn die globale Schicht-4-Persistenz deaktiviert, also l4_persistence auf <None> festgelegt ist. Wenn l4_persistence auf source_ip festgelegt ist, kann die sessionAffinity auf der Dienstspezifikation verwendet werden, um die Persistenz-Zeitüberschreitung für den Dienst anzupassen. Die standardmäßige Persistenz-Zeitüberschreitung von Layer 4 beträgt 10.800 Sekunden (wie in der Kubernetes-Dokumentation für Dienste (https://kubernetes.io/docs/concepts/services-networking/service) angegeben. Alle Dienste mit standardmäßiger Persistenz-Zeitüberschreitung nutzen das gleiche Persistenz-Profil des NSX-T-Load Balancer. Für jeden Dienst mit einer nicht standardmäßigen Persistenz-Zeitüberschreitung wird ein dediziertes Profil erstellt.

Hinweis: Wenn der Backend-Dienst eines Ingress ein Dienst des Typs LoadBalancer ist, dürfen der virtuelle Server der Schicht 4 für den Dienst und der virtuelle Server der Schicht 7 für den Ingress nicht unterschiedliche Persistenzeinstellungen aufweisen, beispielsweise source_ip für Schicht 4 und cookie für Schicht 7. In einem Szenario dieser Art müssen die Persistenzeinstellungen für beide virtuelle Server identisch sein ( source_ip, cookie oder None), oder einer davon hat die Einstellung None (in diesem Fall kann die andere Einstellung source_ip oder cookie lauten). Beispiel für ein Szenario dieser Art:
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

Beispiel für einen Load Balancer auf Schicht 7:

Zur Bereitstellung von Load Balancing auf Schicht 7 konfiguriert die folgende YAML-Datei zwei Replikations-Controller (tea-rc und coffee-rc), zwei Dienste (tea-svc und coffee-svc) sowie zwei Routen (cafe-route-multi und 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

Zusätzliche Hinweise

  • Es werden alle Beendigungsmodi unterstützt: edge, passthrough und reencrypt.
  • Unterdomänen als Platzhalter werden unterstützt. Wenn zum Beispiel wildcardPolicy auf Unterdomäne und der Hostname auf wildcard.example.com festgelegt ist, werden alle Anforderungen an *.example.com verarbeitet.
  • Wenn NCP aufgrund einer fehlerhaften Konfiguration einen Fehler während der Verarbeitung eines Routen-Ereignisses auslöst, müssen Sie die YAML-Datei der Route korrigieren und die Routen-Ressource löschen und neu erstellen.
  • NCP erzwingt den Hostnamen-Besitz nicht nach Namespaces.
  • Ein LoadBalancer-Dienst wird pro Kubernetes-Cluster unterstützt.
  • NSX-T Data Center erstellt für jeden LoadBalancer-Dienst-Port einen virtuellen Server und einen Pool des Load Balancers auf Schicht 4. TCP und UDP werden unterstützt.
  • Der Load Balancer von NSX-T Data Center ist in verschiedenen Größen erhältlich. Weitere Informationen zum Konfigurieren eines Load Balancers für NSX-T Data Center finden Sie im Administratorhandbuch für NSX-T Data Center.

    Nachdem der Load Balancer erstellt wurde, kann seine Größe nicht durch Aktualisierung der Konfigurationsdatei geändert werden. Die Größe kann über die Benutzeroberfläche oder API geändert werden.

  • Das automatische Skalieren des Load Balancers auf Schicht 4 wird unterstützt. Wenn ein Kubernetes-LoadBalancer-Dienst erstellt oder geändert wird, sodass er zusätzliche virtuelle Server erfordert, und der vorhandene Load Balancer auf Schicht 4 nicht über ausreichend Kapazität verfügt, wird ein neuer Load Balancer auf Schicht 4 erstellt. NCP löscht einen Load Balancer auf Schicht 4 auch, wenn keine virtuellen Server mehr an ihn angehängt sind. Diese Funktion ist standardmäßig aktiviert. Sie können sie deaktivieren, indem Sie in der NCP-ConfigMap l4_lb_auto_scaling auf false festlegen.
  • In einer Routenspezifikationen wird der Parameter destinationCACertificate nicht unterstützt und von NCP ignoriert.
  • Jede TLS-Route muss über ein anderes von einer Zertifizierungsstelle signiertes Zertifikat verfügen.

Beispielskript zum Generieren eines von einer Zertifizierungsstelle signierten Zertifikats

Das nachfolgende Skript generiert ein von einer Zertifizierungsstelle signiertes Zertifikat und einen privaten in den Dateien <Dateiname>.crt und <Dateiname>.key gespeicherten privaten Schlüssel. Der Befehl genrsa generiert einen Zertifizierungsstellen-Schlüssel. Der Zertifizierungsstellen-Schlüssel muss verschlüsselt werden. Sie können eine Verschlüsselungsmethode mit einem Befehl wie zum Beispiel aes256 angeben.
#!/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