Das Konfigurieren des Lastausgleichs 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 das Tag {"ncp/owner": cluster:<cluster>} aufweisen.

Um den Load Balancer von NSX-T Data Center zu verwenden, müssen Sie den Lastausgleich 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 des von der Zertifizierungsstelle signierten Zertifikats 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-Lastausgleichs. Für jeden Dienst mit einer nicht standardmäßigen Persistenz-Zeitüberschreitung wird ein dediziertes Profil erstellt.

Hinweis:

Wenn der Backend-Dienst eines Dateneingangs 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 Dateneingang 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

Router-Sharding

NCP verarbeitet immer TLS-Edge-Beendigungs- und HTTP-Routen und überspringt TLS-Passthrough-Routen und TLS-Neuverschlüsselungsrouten unabhängig von deren Namespaces oder Namespace-Bezeichnungen. Um einen OpenShift-Router auf die ausschließliche Verarbeitung von TLS-Neuverschlüsselungs- und TLS-Passthrough-Routen zu beschränken, müssen Sie die folgenden Schritte ausführen:

  • Fügen Sie dem OpenShift-Router eine Namespace-Bezeichnungsauswahl hinzu.

  • Fügen Sie dem Ziel-Namespace eine Namespace-Bezeichnung hinzu.

  • Erstellen Sie im Ziel-Namespace TLS-Neuverschlüsselungs-/TLS Passthrough-Routen.

Um beispielsweise einen Router mit einer Namespace-Bezeichnungsauswahl zu konfigurieren, führen Sie den folgenden Befehl aus (davon ausgehend, dass der Dienstkontoname des Routers router lautet):

oc set env dc/router NAMESPACE_LABELS="router=r1"

Der Router verarbeitet jetzt Routen von den ausgewählten Namespaces. Damit diese Auswahl mit einem Namespace übereinstimmt, führen Sie den folgenden Befehl aus (davon ausgehend, dass der Namespace den Namen ns1 hat):

oc label namespace ns1 "router=r1"

Beispiel für einen Load Balancer auf Schicht 7:

Zur Bereitstellung des Lastausgleichs 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

  • Nur die Edge-Beendigung wird für HTTPS-Datenverkehr unterstützt.

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

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