Lastverteilung für Kubernetes-Dienste mit NGINX Plus

Michael Pleshakov

Kubernetes ist ein von Google entwickeltes Open-Source-System zum Ausführen und Verwalten containerisierter, auf Microservices basierender Anwendungen in einem Cluster. Kubernetes-Nutzer müssen die in Kubernetes erstellten Dienste häufig von außerhalb ihres Kubernetes-Clusters zugänglich machen.

Obwohl Kubernetes integrierte Lösungen für die Bereitstellung von Diensten bietet, die weiter unten unter „Bereitstellen von Kubernetes-Diensten mit integrierten Lösungen“ beschrieben werden, sind Sie mit diesen Lösungen auf Layer-4-Lastverteilung oder HTTP-Lastverteilung nach dem Round-Robin-Verfahren beschränkt.

Dieser Beitrag zeigt, wie Sie NGINX Plus als fortschrittliche Layer-7-Load-Balancing-Lösung einsetzen, um Kubernetes-Dienste über das Internet bereitzustellen – unabhängig davon, ob Sie Kubernetes in der Cloud oder in Ihrer eigenen Infrastruktur betreiben.

Wir gehen davon aus, dass Sie über grundlegende Kenntnisse von Kubernetes (Pods, Services, Replikationscontroller und Labels) sowie über einen laufenden Kubernetes-Cluster verfügen. Weitere Informationen zu Kubernetes finden Sie im offiziellen Kubernetes-Benutzerhandbuch.

Kubernetes-Dienste mit integrierten Lösungen verfügbar machen

Kubernetes bietet mehrere Möglichkeiten, Services bereitzustellen. Zwei davon – NodePort und LoadBalancer – entsprechen jeweils einem bestimmten Service-Typ. Eine dritte Option, die Ingress API, wurde mit Kubernetes 1.1 als Betaversion eingeführt.

NodePort

Wenn Sie als Diensttyp NodePort angeben, ist der Dienst auf jedem Kubernetes-Knoten über denselben Port verfügbar. Um den Dienst im Internet bereitzustellen, geben Sie einen oder mehrere Knoten über diesen Port frei. Für eine hohe Verfügbarkeit können Sie mehrere Knoten freigeben und den Datenverkehr mithilfe von DNS-basiertem Lastenausgleich auf diese verteilen oder die Knoten hinter einem Lastenausgleich Ihrer Wahl platzieren.

Wenn eingehender Datenverkehr einen Knoten über diesen Port erreicht, wird er auf die Pods des Dienstes verteilt. Der Lastenausgleich durch den Kubernetes-Netzwerkproxy (kube-proxy), der auf jedem Knoten ausgeführt wird, ist auf TCP/UDP-Lastenausgleich beschränkt.

LoadBalancer

Wenn Sie den Diensttyp als „LoadBalancer“ festlegen, wird ein Cloud-Load-Balancer bereitgestellt, der den eingehenden Datenverkehr auf die Pods des Dienstes verteilt.

Die LoadBalancer-Lösung wird nur von bestimmten Cloud-Anbietern und der Google Container Engine unterstützt und ist nicht verfügbar, wenn Sie Kubernetes auf Ihrer eigenen Infrastruktur betreiben. Darüber hinaus können Sie mit Kubernetes nur TCP-Lastverteilung nach dem Round-Robin-Verfahren konfigurieren, selbst wenn der Cloud-Load-Balancer erweiterte Funktionen wie Sitzungspersistenz oder Anfragezuordnung bietet.

Ingress-API

Durch das Erstellen einer Ingress-Ressource können Sie Dienste unter benutzerdefinierten URLs im Internet bereitstellen (beispielsweise Dienst A unter der URL /foo und Dienst B unter der URL /bar) sowie mehrere virtuelle Hostnamen verwenden (beispielsweise foo.example.com für eine Gruppe von Diensten und bar.example.com für eine andere Gruppe). Ein Ingress-Controller verarbeitet eine Ingress-Ressource und richtet einen externen Load Balancer ein.

Ein Ingress-Controller ist nicht Bestandteil einer standardmäßigen Kubernetes-Bereitstellung: Sie müssen den Controller auswählen, der Ihren Anforderungen am besten entspricht, oder selbst einen implementieren und ihn Ihrem Kubernetes-Cluster hinzufügen. Es ist zu erwarten, dass bald viele Controller-Implementierungen verfügbar sein werden. Derzeit ist jedoch nur der Controller für den HTTP Load Balancer von Google Compute Engine verfügbar, der nur funktioniert, wenn Sie Kubernetes auf Google Compute Engine oder Google Container Engine ausführen. Die Ingress-API unterstützt ausschließlich HTTP-Lastverteilung nach dem Round-Robin-Verfahren, selbst wenn der eigentliche Load Balancer erweiterte Funktionen unterstützt.

Zum Zeitpunkt der Erstellung dieses Textes befinden sich sowohl die Ingress-API als auch der Controller für den HTTP Load Balancer von Google Compute Engine in der Betaphase.

Update – Der NGINX Ingress Controller für NGINX und NGINX Plus ist jetzt in unserem GitHub-Repository verfügbar. Produktdetails finden Sie unter NGINX Ingress Controller.

Obwohl die oben genannten Lösungen einfach einzurichten und sofort einsatzbereit sind, bieten sie keine erweiterten Funktionen, insbesondere keine Funktionen für den Lastenausgleich auf Layer 7.

Kubernetes-Dienste mit NGINX Plus verfügbar machen

[Redaktion – Dieser Abschnitt wurde aktualisiert und verweist nun auf die NGINX Plus API, die das ursprünglich hier behandelte separate Modul für die dynamische Konfiguration ersetzt und als veraltet kennzeichnet.]

Um NGINX Plus in Kubernetes zu integrieren, müssen wir sicherstellen, dass die NGINX Plus-Konfiguration mit Kubernetes synchronisiert bleibt und Änderungen an Kubernetes-Diensten, etwa das Hinzufügen oder Löschen von Pods, berücksichtigt werden. Bei NGINX Open Source ändern Sie die NGINX-Konfigurationsdatei manuell und laden die Konfiguration neu. Bei NGINX Plus gibt es zwei Möglichkeiten, die Konfiguration dynamisch zu aktualisieren:

• Mit APIs – Diese Methode verwendet die NGINX Plus API, um Einträge für Kubernetes-Pods in der NGINX Plus-Konfiguration hinzuzufügen und zu entfernen, sowie die Kubernetes-API, um die IP-Adressen der Pods abzurufen. Für diese Methode müssen wir etwas Code schreiben, worauf wir hier nicht näher eingehen werden. Weitere Informationen finden Sie im Webinar von Kelsey Hightower: Kubernetes mit NGINX Plus an den Netzwerkrand bringen. Darin untersucht er die APIs und erstellt eine Anwendung, die sie nutzt.
• Durch erneutes Auflösen von DNS-Namen – Diese Methode erfordert lediglich eine einmalige ordnungsgemäße Konfiguration von NGINX Plus, wie im folgenden Abschnitt beschrieben.

DNS‑basierte Neukonfiguration verwenden

Wir gehen davon aus, dass Sie bereits über einen laufenden Kubernetes-Cluster und einen Host verfügen, auf dem das Dienstprogramm kubectl zur Verwaltung des Clusters verfügbar ist. Eine Anleitung finden Sie im Leitfaden für die ersten Schritte mit Kubernetes für Ihren Clustertyp. Außerdem müssen Sie ein Docker-Image für NGINX Plus erstellt haben. Eine Anleitung dazu finden Sie im Beitrag Bereitstellen von NGINX und NGINX Plus mit Docker in unserem Blog.

Im Folgenden finden Sie einen Überblick über die einzelnen Schritte:

1. Konfigurieren Sie einen NGINX-Plus-Pod, um den in Schritt 2 erstellten Dienst bereitzustellen und dessen Last zu verteilen.
2. Erstellen Sie eine einfache Webanwendung als unseren Dienst.
3. Skalieren Sie den Dienst hoch und herunter und beobachten Sie, wie NGINX Plus automatisch neu konfiguriert wird.

Hinweise: Wir haben die in diesem Blog beschriebene Lösung mit Kubernetes 1.0.6 auf Google Compute Engine und in einer lokalen Vagrant-Umgebung getestet, die wir im Folgenden verwenden.

In Befehlen werden Werte, die in Ihrer Kubernetes-Konfiguration möglicherweise abweichen, kursiv dargestellt.

Konfigurieren des NGINX-Plus-Pods

Wir stellen NGINX Plus in einem Kubernetes-Pod auf einem Knoten bereit, den wir über das Internet zugänglich machen. Unser Pod wird von einem Replikationscontroller erstellt, den wir ebenfalls einrichten. Unsere Kubernetes-spezifische Konfigurationsdatei für NGINX Plus befindet sich in einem Ordner, auf den sowohl der NGINX Plus-Pod als auch der Knoten zugreifen können, was die Wartung vereinfacht.

Auswählen eines Knotens zum Hosten des NGINX Plus-Pods

Um den Knoten festzulegen, auf dem der NGINX Plus-Pod ausgeführt wird, fügen wir diesem Knoten ein Label hinzu. Die Liste aller Knoten rufen wir mit folgendem Befehl ab:

$ kubectl get nodesNAME         LABELS                              STATUS
10.245.1.3   Kubernetes.io/hostname=10.245.1.3   Ready
10.245.1.4   Kubernetes.io/hostname=10.245.1.4   Ready
10.245.1.5   Kubernetes.io/hostname=10.245.1.5   Ready

Wir wählen den ersten Knoten aus und fügen ihm mit folgendem Befehl ein Label hinzu:

$ kubectl label node 10.245.1.3 role=nginxplus

Konfigurieren des Replikationscontrollers für den NGINX Plus-Pod

Wir erstellen einen NGINX Plus-Pod nicht direkt, sondern über einen Replikationscontroller. Den Replikationscontroller für den NGINX Plus-Pod konfigurieren wir in einer Kubernetes-Deklarationsdatei namens nginxplus-rc.yaml.

• Wir setzen die Anzahl der Replikate auf eins. Das bedeutet, dass Kubernetes sicherstellt, dass immer ein NGINX Plus-Pod ausgeführt wird: Fällt der Pod aus, wird er durch einen neuen Pod ersetzt.
• Im Feld „nodeSelector“ geben wir an, dass der NGINX Plus-Pod auf einem Knoten erstellt wird, der mit „role: nginxplus“ gekennzeichnet ist.
• Unser NGINX Plus-Container stellt zwei Ports bereit, 80 und 8080, und wir richten eine Zuordnung zu den Ports 80 und 8080 auf dem Knoten ein.
• Unser NGINX Plus-Container gibt außerdem den auf dem Knoten befindlichen Ordner /etc/nginx/conf.d frei. Wie weiter unten unter „NGINX Plus konfigurieren“ erläutert, können wir NGINX Plus durch die Freigabe des Ordners neu konfigurieren, ohne das Container-Image neu erstellen zu müssen.

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginxplus-rc
spec:
  replicas: 1
  selector:
    app: nginxplus
  template:
    metadata:
      labels:
        app: nginxplus
    spec:
      nodeSelector:
        role: nginxplus
      containers:
      - name: nginxplus
        imagePullPolicy: IfNotPresent
        image: nginxplus
        ports:
          - name: http
            containerPort: 80
            hostPort: 80
          - name: http-alt
            containerPort: 8080
            hostPort: 8080
        volumeMounts:
          - mountPath: "/etc/nginx/conf.d"
            name: etc-nginx-confd
      volumes:
        - hostPath:
            path: "/etc/nginx/conf.d"
          name: etc-nginx-confd

Das NGINX Plus-Docker-Image auf dem Knoten verfügbar machen

Wie bereits erwähnt, haben wir schon ein NGINX Plus-Docker-Image erstellt. Nun stellen wir es auf dem Knoten bereit. Der Einfachheit halber verwenden wir kein privates Docker-Repository, sondern laden das Image manuell auf den Knoten.

Auf dem Host, auf dem wir das Docker-Image erstellt haben, führen wir den folgenden Befehl aus, um das Image in einer Datei zu speichern:

$ docker save -o nginxplus.tar nginxplus

Wir übertragen nginxplus.tar auf den Knoten und führen dort den folgenden Befehl aus, um das Image aus der Datei zu laden:

$ docker load -i nginxplus.tar

NGINX Plus konfigurieren

Im Ordner /etc/nginx des NGINX Plus-Containers behalten wir die standardmäßige Hauptkonfigurationsdatei nginx.conf bei, die in den NGINX Plus-Paketen enthalten ist. Die Direktive include in der Standarddatei bindet weitere Konfigurationsdateien aus dem Ordner /etc/nginx/conf.d ein. Wie in der Deklarationsdatei für den NGINX Plus-Replikationscontroller (nginxplus-rc.yaml) angegeben, geben wir den Ordner /etc/nginx/conf.d auf dem NGINX Plus-Knoten für den Container frei. Dadurch können wir Änderungen an den im Ordner (auf dem Knoten) gespeicherten Konfigurationsdateien vornehmen, ohne das NGINX Plus-Docker-Image neu erstellen zu müssen. Dies wäre erforderlich, wenn wir den Ordner direkt im Container erstellen würden. Wir legen unsere Kubernetes-spezifische Konfigurationsdatei (backend.conf) im freigegebenen Ordner ab.

Erstellen wir zunächst den Ordner /etc/nginx/conf.d auf dem Knoten.

$ sudo mkdir -p /etc/nginx/conf.d

Anschließend erstellen wir dort die Datei backend.conf und fügen die folgenden Anweisungen ein:

• resolver – Definiert den DNS-Server, den NGINX Plus verwendet, um den Domänennamen, mit dem wir unsere Upstream-Server identifizieren, regelmäßig erneut aufzulösen (in der server-Direktive innerhalb des upstream-Blocks, die im nächsten Aufzählungspunkt erläutert wird). Wir identifizieren diesen DNS-Server anhand seines Domänennamens kube-dns.kube-system.svc.cluster.local. Der Parameter valid weist NGINX Plus an, alle fünf Sekunden eine erneute Namensauflösung anzufordern. (Beachten Sie, dass sich der Auflösungsprozess für diese Direktive von dem für Upstream-Server unterscheidet: Dieser Domänenname wird nur beim Starten oder Neuladen von NGINX aufgelöst. NGINX Plus verwendet dazu den bzw. die in der Datei /etc/resolv.conf definierten System-DNS-Server.)
• upstream – Erstellt eine Upstream-Gruppe namens backend, die die Server enthält, die den von uns bereitgestellten Kubernetes-Dienst zur Verfügung stellen. Anstatt die Server einzeln aufzulisten, geben wir sie mit einem vollständig qualifizierten Hostnamen in einer einzigen server-Direktive an. Der Parameter resolve weist NGINX Plus an, den Hostnamen zur Laufzeit gemäß den mit der resolver-Direktive festgelegten Einstellungen erneut aufzulösen. Da sowohl Kubernetes DNS als auch NGINX Plus (ab R10) DNS-Diensteinträge (SRV) unterstützen, kann NGINX Plus die Portnummern der Upstream-Server über DNS abrufen. Wir verwenden den Parameter service, damit NGINX Plus SRV-Einträge abfragt, wobei wir den Namen (_http) und das Protokoll (_tcp) für die von unserem Dienst bereitgestellten Ports angeben. Diese Werte deklarieren wir in der Datei webapp-svc.yaml, die weiter unten unter Erstellen des Replikationscontrollers für den Dienst erläutert wird. Weitere Informationen zur Diensterkennung mit DNS finden Sie in unserem Blogbeitrag DNS zur Diensterkennung mit NGINX und NGINX Plus verwenden.
• server (zweimal) – Definiert zwei virtuelle Server:
  • Der erste Server lauscht auf Port 80 und verteilt eingehende Anfragen für /webapp (unseren Dienst) auf die Pods, in denen Dienstinstanzen ausgeführt werden. Außerdem richten wir aktive Zustandsprüfungen ein.
  • Der zweite Server lauscht auf Port 8080. Hier richten wir die Live-Aktivitätsüberwachung von NGINX Plus ein. Später überprüfen wir damit, ob NGINX Plus ordnungsgemäß neu konfiguriert wurde. [Redaktion – Die Konfiguration dieses zweiten Servers wurde aktualisiert und verwendet nun die NGINX Plus API, die das ursprünglich verwendete separate Statusmodul ersetzt und als veraltet kennzeichnet.]

resolver kube-dns.kube-system.svc.cluster.local valid=5s;

upstream backend {
    zone upstream-backend 64k;
    server webapp-svc.default.svc.cluster.local service=_http._tcp resolve;
}

server {
    listen 80;
    status_zone backend-servers;

    location /webapp {
        proxy_pass http://backend;
        health_check;
    }
}

server {
    listen 8080;
    root /usr/share/nginx/html;

    location = /dashboard.html { }

    location = / {
        return 302 /dashboard.html;
    }

    location /api {
        api write=on;
    }
}

Erstellen des Replikationscontrollers

Jetzt können wir den Replikationscontroller mit folgendem Befehl erstellen:

$ kubectl create -f nginxplus-rc.yaml

Um zu überprüfen, ob der NGINX Plus-Pod erstellt wurde, führen wir folgenden Befehl aus:

$ kubectl get pods
NAME                 READY     STATUS    RESTARTS   AGE
nginxplus-rc-0ts5t   1/1       Running   0          17s

Wir führen Kubernetes in einer lokalen Vagrant-Umgebung aus. Daher wissen wir, dass die externe IP-Adresse unseres Nodes 10.245.1.3 lautet, und verwenden diese Adresse im weiteren Verlauf dieses Beispiels. Wenn Sie Kubernetes bei einem Cloud-Anbieter ausführen, können Sie die externe IP-Adresse Ihres Nodes mit folgendem Befehl ermitteln:

$ kubectl get nodes node-name -o json | grep -i externalIP -A 1                "type": "ExternalIP",
                "address": XXX.XXX.XXX.XXX

Wenn Sie Ihre Umgebung in einer Cloud betreiben, richten Sie unbedingt eine Firewallregel ein, die es dem NGINX Plus-Knoten ermöglicht, eingehenden Datenverkehr anzunehmen. Weitere Informationen finden Sie in der Dokumentation Ihres Cloud-Anbieters.

Wir können überprüfen, ob unser NGINX Plus-Pod betriebsbereit ist, indem wir das Dashboard zur Live-Aktivitätsüberwachung von NGINX Plus aufrufen. Dieses ist über Port 8080 unter der externen IP-Adresse des Knotens verfügbar (in unserem Fall also unter http://10.245.1.3:8080/dashboard.html). Wenn wir das Dashboard zu diesem Zeitpunkt aufrufen, sehen wir jedoch keine Server für unseren Dienst, da wir den Dienst noch nicht erstellt haben.

Erstellen eines einfachen Kubernetes-Dienstes

Nun ist es an der Zeit, einen Kubernetes-Service zu erstellen. Unser Service besteht aus zwei Webservern, die jeweils eine Webseite mit Informationen über den Container bereitstellen, in dem sie ausgeführt werden.

Erstellen des Replikationscontrollers für den Dienst

Zunächst erstellen wir einen Replikationscontroller, damit Kubernetes sicherstellt, dass die angegebene Anzahl von Webserver-Replikaten (Pods) im Cluster stets ausgeführt wird. Hier ist die Deklarationsdatei (webapp-rc.yaml):

apiVersion: v1kind: ReplicationController
metadata:
  name: webapp-rc
spec:
  replicas: 2
  selector:
    app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: hello
        image: nginxdemos/hello 
        ports:
        - containerPort: 80

Unser Controller besteht aus zwei Webservern. Wir deklarieren einen Controller, der aus Pods mit jeweils einem einzelnen Container besteht und Port 80 bereitstellt. Das Image nginxdemos/hello wird von Docker Hub heruntergeladen.

Um den Replikationscontroller zu erstellen, führen wir den folgenden Befehl aus:

$ kubectl create -f webapp-rc.yaml

Um zu überprüfen, ob unsere Pods erstellt wurden, können wir den folgenden Befehl ausführen. Wir verwenden den Label-Selektor app=webapp, um nur die Pods abzurufen, die im vorherigen Schritt vom Replikationscontroller erstellt wurden:

$ kubectl get pods -l app=webapp
NAME             READY     STATUS    RESTARTS   AGE
webapp-rc-544f1   1/1       Running   0          2m
webapp-rc-uk6pm   1/1       Running   0          2m

Erstellen des Dienstes

Als Nächstes erstellen wir einen Service für die von unserem Replikationscontroller erstellten Pods. Wir definieren den Service in der folgenden Datei (webapp-service.yaml):

apiVersion: v1kind: Service
metadata:
  name: webapp-svc
spec:
  clusterIP: None
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: webapp

Hier deklarieren wir einen speziellen Headless Service, indem wir das Feld ClusterIP auf None setzen. Bei diesem Servicetyp wird keine Cluster-IP-Adresse zugewiesen, und der Service ist nicht über den Kube-Proxy verfügbar. Eine DNS-Abfrage an den Kubernetes-DNS-Dienst liefert mehrere A-Einträge zurück (die IP-Adressen unserer Pods).

Außerdem deklarieren wir den Port, über den NGINX Plus eine Verbindung zu den Pods herstellt. Neben den Nummern für den Port und den Zielport geben wir auch den Namen (http) und das Protokoll (TCP) an. Diese Werte verwenden wir in der NGINX Plus-Konfigurationsdatei, in der wir NGINX Plus anweisen, die Portnummern der Pods über DNS mithilfe von SRV-Einträgen abzurufen.

Indem wir das Feld „selector“ auf „app: webapp“ setzen, legen wir fest, welche Pods zum Service gehören, nämlich die von unserem NGINX-Replikationscontroller erstellten Pods (definiert in „webapp-rc.yaml“).

Wir führen den folgenden Befehl aus, der den Service erstellt:

$ kubectl create -f webapp-service.yaml

Wenn wir nun die Dashboard-Seite aktualisieren und oben rechts auf die Registerkarte „Upstreams“ klicken, sehen wir die beiden hinzugefügten Server.

Wir können auch überprüfen, ob NGINX Plus den Datenverkehr auf die Pods des Dienstes verteilt. Ist dies der Fall, zeigt uns die Seite beim Aufrufen von http://10.245.1.3/webapp/ in einem Browser Informationen über den Container an, in dem der Webserver ausgeführt wird, beispielsweise den Hostnamen und die IP-Adresse.

Wenn wir diese Seite mehrmals aktualisieren und uns das Status-Dashboard ansehen, sehen wir, wie die Anfragen auf die beiden Upstream-Server verteilt werden.

Skalieren des Kubernetes-Dienstes

[Redaktion – Dieser Abschnitt wurde aktualisiert und verwendet nun die NGINX Plus API, die das ursprünglich verwendete separate Statusmodul ersetzt und als veraltet kennzeichnet.]

Fügen wir unserem Service nun zwei weitere Pods hinzu und stellen wir sicher, dass die NGINX Plus-Konfiguration erneut automatisch aktualisiert wird. Mit diesem Befehl ändern wir die Anzahl der Pods auf vier, indem wir den Replikationscontroller skalieren:

$ kubectl scale rc webapp-rc --replicas=4
scaled

Um zu überprüfen, ob NGINX Plus neu konfiguriert wurde, könnten wir erneut einen Blick auf das Dashboard werfen. Dieses Mal verwenden wir jedoch stattdessen die NGINX Plus API. Wir führen den folgenden Befehl aus, wobei 10.245.1.3 die externe IP-Adresse unseres NGINX Plus-Knotens und 3 die Version der NGINX Plus API ist. Um die JSON-Ausgabe übersichtlich zu formatieren, leiten wir sie an jq weiter.

$ curl -s 10.245.1.3:8080/api/3/http/upstreams/backend/servers | jq{
  "peers": [
    {
      "id": 1,
      "server": "10.0.0.1:80",
      "backup": false,
      "weight": 1,
      "state": "unhealthy",
      "active": 0,
      "requests": 1,
      "responses": {
        "1xx": 0,
        "2xx": 0,
        "3xx": 0,
        "4xx": 0,
        "5xx": 0,
        "total": 0
      },
      "sent": 0,
      "received": 0,
      "fails": 0,
      "unavail": 0,
      "health_checks": {
        "checks": 1,
        "fails": 1,
        "unhealthy": 1,
        "last_passed": false
      },
      "downtime": 33965,
      "downstart": 1445378182275,
      "selected": 1445378131000
    },
    {
      "id": 2,
      "server": "10.246.1.6:80",
      ...
    },
    {
      "id": 3,
      "server": "10.246.3.2:80",
       ...
    {
      "id": 4,
      "server": "10.0.0.2:80",
      ...
    }
  ],
  "keepalive": 0
}

Das peers-Array in der JSON-Ausgabe enthält genau vier Elemente, eines für jeden Webserver.

Reduzieren wir nun die Anzahl der Pods von vier auf einen und überprüfen wir den Status von NGINX Plus erneut:

$ kubectl scale rc webapp-rc --replicas=1scaled

$ curl -s 10.245.1.3:8080/api/3/http/upstreams/backend/servers | jq

Jetzt enthält das peers-Array in der JSON-Ausgabe nur noch ein Element (die Ausgabe entspricht der des Peers mit der ID 1 im vorherigen Beispielbefehl).

Nachdem NGINX Plus nun eingerichtet ist und läuft, können wir seine erweiterten Funktionen nutzen, darunter Sitzungspersistenz, SSL/TLS-Terminierung, Anfrageweiterleitung, erweitertes Monitoring und mehr.

Zusammenfassung

Dank der in NGINX Plus verfügbaren Optionen zur dynamischen Neukonfiguration lässt sich NGINX Plus problemlos in Kubernetes integrieren: entweder programmgesteuert über eine API oder vollständig mittels DNS. Der Einsatz von NGINX Plus zur Bereitstellung von Kubernetes-Diensten im Internet bietet zahlreiche Funktionen, die den derzeit in Kubernetes integrierten Lösungen für den Lastenausgleich fehlen.

Um zu erfahren, wie NGINX Plus mit Kubernetes zusammenarbeitet, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihren Anwendungsfall zu besprechen.

Über den Autor

Michael Pleshakov

Weitere Blogbeiträge von Michael Pleshakov