Das Konfigurieren des Load Balancing umfasst das Konfigurieren eines Kubernetes-LoadBalancer-Diensts oder einer -Ingress-Ressource und des NCP ReplicationController.

Sie können einen Load Balancer auf Schicht 4 erstellen, indem Sie einen Kubernetes-Dienst des Typs LoadBalancer konfigurieren. Einen Load Balancer auf Schicht 7 erstellen Sie, indem Sie eine Kubernetes-Ingress-Ressource konfigurieren.

Gehen Sie zum Konfigurieren von Load Balancing in NCP in der Datei ncp-rc.yml wie folgt vor:

  1. Legen Sie use_native_loadbalancer = True fest.
  2. (Optional) Legen Sie pool_algorithm auf ROUND_ROBIN oder LEAST_CONNECTION/IP_HASH fest. Die Standardeinstellung ist ROUND_ROBIN.
  3. (Optional) Legen Sie service_size = SMALL, MEDIUM oder LARGE fest. Die Standardeinstellung ist SMALL.

Der Algorithmus LEAST_CONNECTION/IP_HASH bedeutet, dass Datenverkehr von derselben Quell-IP-Adresse zum selben Backend-Pod gesendet wird.

Weitere Informationen dazu, was von NSX-T-Load Balancern unterschiedlicher Größe unterstützt wird, 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 NSX Manager-Benutzeroberfläche oder -API geändert werden.

Festlegen der Persistenz für Load Balancing auf Schicht 4 und Schicht 7

Mit den Parametern l4_persistence und l7_persistence können Sie im NCP-ConfigMap-Objekt eine Persistenzeinstellung angeben. 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

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

Ingress

  • NSX-T Data Center erstellt einen Load Balancer auf Schicht 7 für Ingresses mit TLS-Spezifikation und einen Load Balancer auf Schicht 7 für Ingresses ohne TLS-Spezifikation.
  • Alle Ingresses erhalten eine einzelne IP-Adresse.
  • Der Ingress-Ressource wird eine IP-Adresse aus dem externen IP-Pool zugeteilt, der durch die Option external_ip_pools im Abschnitt [nsx_v3] in ncp.ini angegeben ist. Der Load Balancer wird unter dieser IP-Adresse und auf den HTTP- und HTTPS-Ports (80 und 443) bereitgestellt.
  • Der Ingress-Ressource wird eine IP-Adresse aus dem externen IP-Pool zugeteilt, der durch die Option external_ip_pools_lb im Abschnitt [nsx_v3] in ncp.ini angegeben ist. Wenn die Option external_ip_pools_lb nicht vorhanden ist, wird der von external_ip_pools angegebene Pool verwendet. Der Load Balancer wird unter dieser IP-Adresse und auf den HTTP- und HTTPS-Ports (80 und 443) bereitgestellt.
  • Sie können zu einem anderen IP-Pool wechseln, indem Sie die Konfiguration ändern und NCP neu starten.
  • Sie können ein Standardzertifikat für TLS angeben. Informationen zum Erstellen eines Zertifikats sowie zum Mounten eines Zertifikats in den NCP-Pod finden Sie unten.
  • Ingresses ohne TLS-Spezifikation werden auf dem virtuellen HTTP-Server (Port 80) gehostet.
  • Ingresses mit TLS-Spezifikation werden auf dem virtuellen HTTPS-Server (Port 443) gehostet. Der Load Balancer fungiert als SSL-Server und beendet die SSL-Clientverbindung.
  • Die Reihenfolge bei der Erstellung von geheimen Schlüsseln und Ingress spielt keine Rolle. Wenn das Objekt für den geheimen Schlüssel vorhanden ist und ein Ingress darauf verweist, wird das Zertifikat in NSX-T Data Center importiert. Falls der geheime Schlüssel oder der letzte Ingress, der auf den geheimen Schlüssel verweist, gelöscht wird, wird das dem geheimen Schlüssel entsprechende Zertifikat gelöscht.
  • Eine Ingress-Änderung durch Hinzufügen oder Entfernen des TLS-Abschnitts wird nicht unterstützt. Nach dem Entfernen des tls-Schlüssels aus der Ingress-Spezifikation werden die Ingress-Regeln vom virtuellen HTTPS-Server (Port 443) auf den virtuellen HTTP-Server (Port 80) übertragen. Ebenso werden die Ingress-Regeln vom virtuellen HTTP-Server (Port 80) auf den virtuellen HTTPS-Server (Port 443) übertragen, wenn der tls-Schlüssel zur Ingress-Spezifikation hinzugefügt wird.
  • Wenn in Ingress-Definitionen für einen einzelnen Cluster doppelte Regeln vorliegen, wird nur die erste Regel angewendet.
  • Pro Cluster wird nur ein einzelner Ingress mit einem Standard-Backend unterstützt. Datenverkehr, der mit keiner Ingress-Regel übereinstimmt, wird an das Standard-Backend weitergeleitet.
  • Wenn mehrere Ingresses mit einem Standard-Backend vorhanden sind, wird nur der erste konfiguriert. Die anderen erhalten einen Fehlerkommentar.
  • Die Ermittlung übereinstimmender URIs mit Platzhaltern wird mit folgenden Zeichen für reguläre Ausdrücke unterstützt: „.“ und „*“. Beispiel: Der Pfad „/coffee/.*“ stimmt mit „/coffee/“, gefolgt von null, einem oder mehreren Zeichen wie etwa „/coffee/“, „/coffee/a“, „/coffee/b“ überein, nicht jedoch mit „/coffee“, „/coffeecup“ oder „/coffeecup/a“.
    Beispiel für eine Ingress-Spezifikation:
    kind: Ingress
    metadata:
      name: cafe-ingress
    spec:
      rules:
      - http:
          paths:
          - path: /coffee/.*    #Matches /coffee/, /coffee/a but NOT /coffee, /coffeecup, etc.
            backend:
              serviceName: coffee-svc
              servicePort: 80
  • Sie können das Umschreiben von URL-Anforderungen durch Hinzufügen einer Anmerkung zur Ingress-Ressource konfigurieren. Beispiel:
    kind: Ingress
    metadata:
      name: cafe-ingress
      annotations:
        ingress.kubernetes.io/rewrite-target: /
    spec:
      rules:
      - host: cafe.example.com
        http:
          paths:
          - path: /tea
            backend:
              serviceName: tea-svc
              servicePort: 80
          - path: /coffee
            backend:
              serviceName: coffee-svc
              servicePort: 80

    Die Pfade /tea und /coffee werden in / umgeschrieben, bevor die URL an den Backend-Dienst gesendet wird.

  • Die Ingress-Anmerkung kubernetes.io/ingress.allow-http wird unterstützt.
    • Wenn die Anmerkung auf false festgelegt ist, werden nur HTTPS-Regeln erstellt.
    • Wenn die Anmerkung auf true festgelegt ist oder fehlt, werden HTTP-Regeln erstellt. Darüber hinaus werden HTTPS-Regeln erstellt, wenn der TLS-Abschnitt in der Ingress-Spezifikation vorhanden ist.
  • Fehler werden in der Ingress-Ressource als Anmerkung dokumentiert. Der Fehlerschlüssel lautet ncp/error.loadbalancer, der Schlüssel für Warnungen ncp/warning.loadbalancer. Dies sind die möglichen Fehler und Warnungen:
    • ncp/error.loadbalancer: DEFAULT_BACKEND_IN_USE

      Dieser Fehler weist darauf hin, dass bereits ein Ingress mit einem Standard-Back-End vorhanden ist. Der Ingress ist dann inaktiv. Für eine Gruppe von Ingresses kann nur ein Standard-Back-End mit und ohne TLS vorhanden sein. Um den Fehler zu beheben, löschen Sie den Ingress und erstellen Sie ihn mit einer korrekten Spezifikation neu.

    • ncp/warning.loadbalancer: SECRET_NOT_FOUND

      Dieser Fehler weist darauf hin, dass der in der Ingress-Spezifikation angegebene geheime Schlüssel nicht vorhanden ist. Der Ingress ist dann nur teilweise aktiv. Um den Fehler zu beheben, erstellen Sie den fehlenden geheimen Schlüssel. Beachten Sie, dass eine Warnung in der Anmerkung während des Lebenszyklus der Ingress-Ressource nicht gelöscht wird.

    • ncp/warning.loadbalancer: INVALID_INGRESS
      Dieser Fehler weist darauf hin, dass eine der folgenden Bedingungen wahr ist. Der Ingress ist dann inaktiv. Um den Fehler zu beheben, löschen Sie den Ingress und erstellen Sie ihn mit einer korrekten Spezifikation neu.
      • Eine Ingress-Regel steht im Konflikt mit einer anderen Ingress-Regel im selben Kubernetes-Cluster.
      • Die Anmerkung allow-http wird auf Falsch gesetzt, und der Ingress hat keinen TLS-Abschnitt.
      • Bei einer Ingress-Regel sind host und path nicht angegeben. Eine Ingress-Regel dieser Art weist dieselbe Funktionalität wie das Ingress-Standard-Backend auf. Verwenden Sie stattdessen das Ingress-Standard-Backend.

Dienst vom Typ LoadBalancer

  • NSX-T Data Center erstellt für jeden Dienst-Port einen virtuellen Server und einen Pool des Load Balancers auf Schicht 4.
  • TCP und UDP werden unterstützt.
  • Jeder Dienst hat eine eindeutige IP-Adresse.
  • Dem Dienst wird eine IP-Adresse aus einem externen IP-Pool zugeteilt, die auf dem Feld "loadBalancerIP" in der LoadBalancer-Definition basiert. Das Feld "loadBalancerIP" kann leer sein, eine IP-Adresse oder den Namen oder die ID eines IP-Pools enthalten. Wenn die Spezifikation loadBalancerIP leer ist, wird die IP-Adresse aus dem externen IP-Pool zugeteilt, der durch die external_ip_pools_lb-Option im Abschnitt [nsx_v3] in ncp.ini angegeben ist. Wenn die Option external_ip_pools_lb nicht vorhanden ist, wird der von external_ip_pools angegebene Pool verwendet. Der LoadBalancer-Dienst wird unter dieser IP-Adresse und auf dem Dienst-Port bereitgestellt.
  • Sie können zu einem anderen IP-Pool wechseln, indem Sie die Konfiguration ändern und NCP neu starten.
  • Der von loadBalancerIP angegebene-IP-Pool muss über das Tag scope: ncp/owner, tag: cluster:<cluster_name> verfügen.

  • Fehler werden im Dienst als Anmerkung dokumentiert. Der Fehlerschlüssel lautet ncp/error.loadbalancer. Dies sind die möglichen Fehler:
    • ncp/error.loadbalancer: IP_POOL_NOT_FOUND

      Dieser Fehler weist darauf hin, dass Sie loadBalancerIP: <nsx-ip-pool> angeben, <nsx-ip-pool> aber nicht vorhanden ist. Der Dienst ist dann inaktiv. Um den Fehler zu beheben, geben Sie einen gültigen IP-Pool ein, löschen Sie den Dienst und erstellen Sie ihn neu.

    • ncp/error.loadbalancer: IP_POOL_EXHAUSTED

      Dieser Fehler weist darauf hin, dass Sie loadBalancerIP: <nsx-ip-pool> angeben, die IP-Adressen im IP-Pool aber ausgeschöpft sind. Der Dienst ist dann inaktiv. Um den Fehler zu beheben, geben Sie einen IP-Pool mit verfügbaren IP-Adressen an, löschen Sie den Dienst und erstellen Sie ihn neu.

    • ncp/error.loadbalancer: IP_POOL_NOT_UNIQUE

      Dieser Fehler weist darauf hin, dass mehrere IP-Pools den von loadBalancerIP angegebenen Namen aufweisen: <nsx-ip-pool>. Der Dienst ist dann inaktiv.

    • ncp/error.loadbalancer: POOL_ACCESS_DENIED

      Dieser Fehler weist darauf hin, dass der von loadBalancerIP angegebene IP-Pool das Tag scope: ncp/owner, tag: cluster:<cluster_name> nicht aufweist oder der Name des im Tag angegebenen Clusters nicht mit dem Namen des Kubernetes-Clusters übereinstimmt.

    • ncp/error.loadbalancer: LB_VIP_CONFLICT

      Dieser Fehler weist darauf hin, dass die IP im loadBalancerIP-Feld mit der IP eines aktiven Diensts identisch ist. Der Dienst ist dann inaktiv.

  • 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.

Load Balancer und Netzwerkrichtlinie

Wenn Datenverkehr über den virtuellen Server des NSX-Load Balancer an die Pods weitergeleitet wird, handelt es sich bei der Quell-IP um die IP-Adresse des Uplink-Ports des Tier-1-Routers. Diese Adresse befindet sich im privaten Tier-1-Transit-Netzwerk und kann dazu führen, dass die CIDR-basierten Netzwerkrichtlinien zulässigen Datenverkehr nicht zulassen. Zur Vermeidung dieses Problems muss die Netzwerkrichtlinie so konfiguriert werden, dass die IP-Adresse des Uplink-Ports des Tier-1-Routers Teil des zulässigen CIDR-Blocks ist. Diese interne IP-Adresse wird im Feld "status.loadbalancer.ingress.ip" und als Anmerkung (ncp/internal_ip_for_policy) auf der Ingress-Ressource angezeigt.

Lautet die externe IP-Adresse des virtuellen Servers beispielsweise 4.4.0.5 und die IP-Adresse des Uplink-Ports des internen Tier-1-Routers 100.64.224.11, sieht der Status folgendermaßen aus:
    status:
      loadBalancer:
      ingress:
      - ip: 4.4.0.5
      - ip: 100.64.224.11
Die Anmerkung zum Ingress und zum Dienst vom Typ LoadBalancer lautet:
    ncp/internal_ip_for_policy: 100.64.224.11
Die IP-Adresse 100.64.224.11 muss zur zulässigen CIDR im ipBlock-Selektor der Netzwerkrichtlinie gehören. Beispiel:
    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    ...
    ingress:
    - from:
      - ipBlock:
         cidr: 100.64.224.11/32

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

Mounten Sie das Standardzertifikat und den Standardschlüssel in den NCP-Pod

Wenn Sie das Zertifikat und den privaten Schlüssel erstellt haben, platzieren Sie sie im Verzeichnis /etc/nsx-ujo auf dem VM-Host. Vorausgesetzt, dass die Zertifikats- und Schlüsseldateien die Namen lb-default.crt und lb-default.key aufweisen, bearbeiten Sie ncp-rc.yaml , sodass diese Dateien auf dem Host in den Pod gemountet werden. Beispiel:
spec:
  ...
  containers:
  - name: nsx-ncp
    ...
    volumeMounts:
    ...
    - name: lb-default-cert
      # Mount path must match nsx_v3 option "lb_default_cert_path"
      mountPath: /etc/nsx-ujo/lb-default.crt
    - name: lb-priv-key
      # Mount path must match nsx_v3 option "lb_priv_key_path"
      mountPath: /etc/nsx-ujo/lb-default.key
  volumes:
  ...
  - name: lb-default-cert
    hostPath:
      path: /etc/nsx-ujo/lb-default.crt
  - name: lb-priv-key
    hostPath:
      path: /etc/nsx-ujo/lb-default.key