So richten Sie NGINX Ingress Controller auf AWS-Clustern ein

TL; DR Kopieren Sie einfach die Befehle und fügen Sie sie ein, um einen voll funktionsfähigen NGINX-Controller in einem beliebigen AWS Kubernetes-Cluster zu erhalten

Ingress Controller sind die Gateway-Manager für den Netzwerkverkehr, der in Dienste eintritt, die auf Ihren Kubernetes-Clustern ausgeführt werden. Sie entscheiden, wie der Datenverkehr in den Cluster geleitet und wie er beim Eintritt in den Cluster umgewandelt wird.

Es ist wichtig, die erste Aussage zu beachten, die ich oben gemacht habe.

Ingress Controller sind die Gateway-Manager für den Netzwerkverkehr

Der Grund, warum ich Manager hervorgehoben habe, ist, dass er nur verwaltet, wie Datenverkehr über das Gateway eingeht. Es ist nicht das Gateway selbst.

Lassen Sie uns dies anhand eines Beispiels verstehen.

Stellen Sie sich ein AWS-Setup mit einer EC2-Instanz vor, die einen öffentlich zugänglichen Elastic Load Balancer (ELB) unterstützt. Das Gateway für den Verkehr wäre in diesem Fall die ELB. Der Gateway-Manager ist die Entität, die den ELB konfiguriert und ausführt.

Nginx ist eine großartige Wahl für den Reverse-Proxy von Kubernetes

Hinweis: Ich habe das Kurzformat verwendet, um Kubernetes-Ressourcen darzustellen. Es ist leichter für die Augen. Weitere Informationen dazu finden Sie hier.

Load Balancer-Planung

Es gibt viele Möglichkeiten, einen Lastenausgleich für einen Cluster bereitzustellen. Mit Kubernetes können Sie es automatisieren und programmieren, damit es genau Ihren Anforderungen entspricht. Im Allgemeinen wird eines der folgenden beiden Modelle verwendet:

  1. Richten Sie einen Lastenausgleich auf Cluster-Ebene ein und verwenden Sie SNI oder pfadbasiertes Routing für Dienste
  2. Richten Sie einen Lastenausgleich für jeden Dienst ein, der ihn benötigt

Der erste Ansatz ist der in diesem Blog-Beitrag verfolgte. Ich stelle fest, dass die meisten Teams, die den Load Balancer warten, nicht mit denen identisch sind, die Anwendungen verwalten. Der erste Ansatz funktioniert für solche Szenarien besser.

Verwaltung auf AWS Kubernetes-Clustern

In diesem Blog-Beitrag verwenden wir den offiziellen nginx-Ingress-Controller, der sich in diesem Repository befindet. Dies ist eine äußerst vielseitige und konfigurierbare Version des Nginx Ingress Controllers. Es kann so konfiguriert werden, dass Nginx selbst konfiguriert werden kann.

Dieser Ingress-Controller erstellt zunächst eine ELB-Instanz für den Cluster. Mit dieser Eigenschaft können wir den Nginx Ingress Controller einfach an Route53 anschließen.

Lassen Sie uns dies verstehen, indem Sie einen voll funktionsfähigen nginx-Ingress-Controller und Ingress-Instanzen einrichten.

Einrichtung des NGINX Ingress Controllers

Erstellen Sie zunächst einen Namespace, in dem der Ingress Controller ausgeführt werden soll

$ kubectl create -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/namespace.yaml

Erstellen Sie dann die Clusterrolle und die Rolle für den Nginx Ingress Controller

$ kubectl create -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/rbac.yaml

Dadurch werden die Clusterrolle und die Rolle für den Ingress-Controller erstellt. Schreiben Sie dann eine Konfigurationsdatei zum Konfigurieren Ihres Nginx-Proxys

config_map:
  Daten:
    Client-Body-Buffer-Größe: 32M
    hsts: "true"
    Proxy-Körpergröße: 1G
    Proxy-Pufferung: "false"
    Proxy-Lese-Timeout: "600"
    Proxy-Sende-Timeout: "600"
    Server-Token: "false"
    SSL-Weiterleitung: "false"
    Upstream-Keepalive-Verbindungen: "50"
    use-proxy-protocol: "true"
  Etiketten:
    App: Ingress-Nginx
  Name: Nginx-Konfiguration
  Namespace: ingress-nginx
  Version: v1
---
config_map:
  name: tcp-services
  Namespace: ingress-nginx
  Version: v1
---
config_map:
  name: udp-services
  Namespace: ingress-nginx
  Version: v1

Beachten Sie die oben eingestellte Konfiguration. Dies ist eine Standardkonfiguration, die für uns gut funktioniert hat.

Es wird empfohlen, HTTP Strict Transport Security (hsts) zu verwenden. Dies wird zusammen mit SSL-Umleitungen verwendet, um HTTP-Anforderungen an HTTPS umzuleiten. Dies wird allgemein als sicherer angesehen. Es wird empfohlen, es sei denn, Ihr Dienst muss SSL selbst beenden.

Die andere wichtige Option oben ist das Use-Proxy-Protokoll. Da ich einen L4-ELB-Loadbalancer einrichten werde (der SRC-IP, SRC-Port, SRC-Protokolle und andere möglicherweise wichtige Informationen nicht an die dahinter stehenden Dienste weiterleitet), bietet diese Option einen Mechanismus zum Weiterleiten dieser L7-Header.

Lassen Sie uns diese Konfigurationskarte erstellen

$ short -k -f configmap.short.yaml> configmap.yaml
$ kubectl create -f configmap.yaml

Jetzt, da die Konfiguration verwendet werden kann, können wir mit der Erstellung des Standard-Backends beginnen. Das Standard-Backend fungiert als Allround-Service. Es wird immer dann weitergeleitet, wenn eine unbekannte URL von diesem Proxy angefordert wird (d. H. Dem Nginx-Proxy, den wir ausführen).

$ kubectl create -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/default-backend.yaml

Dadurch wird ein Pod und ein entsprechender Service erstellt, der als „Allrounder“ fungiert, wenn eine Anforderung für eine nicht verfügbare URL erfolgt.

Jetzt werden wir die Nginx-Proxy-Pods starten, die den Datenverkehr an das Standard-Backend weiterleiten, bis eine Eingangsregel hinzugefügt wird.

kubectl create -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/with-rbac.yaml

Wir sind fast fertig. Der Proxy ist vorhanden und läuft. Um jedoch Datenverkehr von außerhalb des Clusters unter Verwendung einer einzelnen URL weiterzuleiten, müssen Sie eine ELB-Instanz erstellen. Dies kann durch Erstellen eines Kubernetes-Dienstes vom Typ Loadbalancer erfolgen.

apiVersion: v1
Art: Service
Metadaten:
  Anmerkungen:
    service.beta.kubernetes.io/aws-load-balancer-backend-protokoll: tcp
    service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "3600"
    service.beta.kubernetes.io/aws-load-balancer-proxy-protokoll: '*'
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn: aws: acm: us-east-1: 1234567: certificate / 1234294-232-4f89-bca8
    service.beta.kubernetes.io/aws-load-balancer-ssl-ports: https
  Etiketten:
    k8s-addon: ingress-nginx.addons.k8s.io
  Name: Ingress-Nginx
  Namespace: ingress-nginx
Spezifikation:
  externalTrafficPolicy: Cluster
  Häfen:
  - Name: https
    Port: 443
    Protokoll: TCP
    targetPort: http
  - Name: http
    Hafen: 80
    Protokoll: TCP
    targetPort: http
  Wähler:
    App: Ingress-Nginx
  Typ: LoadBalancer

Beachten Sie, dass ich ein SSL-Zertifikat festgelegt habe (siehe oben). Dies ist das Zertifikat zum Beenden von SSL und sollte zu der Domain gehören, die Sie besitzen. Wir werden später in diesem Artikel sehen, wie der Verkehr von dieser Domain zu bestimmten Diensten weitergeleitet wird. Für dieses Beispiel betrachten wir diese Domäne als:

kube-example.com

Mit AWS Certificate Manager können Sie ein Zertifikat für diese Domain erstellen. Notieren Sie sich nach der Erstellung den Ordner für das Zertifikat und verwenden Sie diesen hier, um SSL in der ELB zu beenden. Jetzt stellen wir diesen Loadbalancer-Dienst bereit

$ short -k -f nginx-service.short.yaml> nginx-service.yaml
$ kubectl erstelle -f nginx-service.yaml

Der Cluster verfügt über einen voll funktionsfähigen Nginx-Load-Balancer, der von ELB bereitgestellt wird.

Route 53 einrichten und Verkehr umleiten

Beachten Sie, dass dieser Teil für einfache Tests nicht erforderlich ist. Sie können die öffentlichen ELB-URLs verwenden, um die Routing-Funktionen zu testen.

Nachdem die ELB nun ausgeführt wird, können Sie in route53 eine Domäne / Unterdomäne konfigurieren, die auf diesen Lastenausgleich verweist. Eine Anleitung dazu finden Sie hier.

Nach der Einrichtung können Sie mithilfe von Eingangsressourcen Dienste erstellen und Datenverkehr auf bestimmte Pfade umleiten.

Lassen Sie uns dies anhand eines Beispiels verstehen. Kurz zusammengefasst heißt die Domain, mit der wir arbeiten, kube-example.com

Betrachten Sie das Beispiel, in dem das Grafana-Dashboard für Ihren Kubenretes-Cluster im Pfad / Monitor angezeigt wird. Dies kann erreicht werden, indem eine Eingangsressource erstellt wird:

Eintritt:
  Anmerkungen:
    ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/cors-allow-credentials: "true"
    nginx.ingress.kubernetes.io/cors-allow-headers: Autorisierung, Herkunft, Akzeptieren
    nginx.ingress.kubernetes.io/cors-allow-methods: GET, OPTIONS
    nginx.ingress.kubernetes.io/cors-allow-origin: kube-example.com/monitor
    nginx.ingress.kubernetes.io/enable-cors: "true"
  name: kubernetes-grafana-ingress
  Namespace: Kubesystem
  Regeln:
  - Host: kube-example.com
    Pfade:
    - Pfad: / monitor
      Hafen: 80
      service: monitoring-grafana
  tls:
  - Gastgeber:
    - kube-example.com
  version: extensions / v1beta1

Beachten Sie die hervorgehobene Anmerkung. Diese Anmerkung weist ingress an, den an grafana gesendeten Pfad neu zu schreiben. Die eingehende Anfrage wird wie unten gezeigt umgeleitet.

Welche Benutzeranforderungen: kube-example.com/monitor
Was Grafana bekommt: kube-example.com/

Auch Grafana benötigt CORS-Unterstützung. Die Konfiguration, um dies hinzuzufügen, ist in den Ingress-Anmerkungen oben gezeigt.

Fazit

Diese Konfiguration von nginx ingress kann verwendet werden, um Ihre Kubernetes-Dienste zu optimieren und der Welt zugänglich zu machen.

Es gibt viel mehr Konfigurationsmöglichkeiten für Nginx und es müssen viele Blog-Beiträge erklärt werden. Wenn Sie an allen interessanten Möglichkeiten zur Konfiguration von nginx interessiert sind, kommentieren Sie dies bitte unten. Ich erstelle darauf eine Blog-Serie.

Bleib dran für noch mehr Kubernetes Tieftauchgänge!