Direkt zum Inhalt

Wie konfiguriere und behebe ich den Ingress NGINX Controller in Amazon EKS?

Lesedauer: 7 Minute
0

Ich möchte den Ingress NGINX Controller für Kubernetes auf einem Amazon Elastic Kubernetes Service (Amazon EKS)-Cluster einrichten. Ich möchte auch Probleme beheben.

Kurzbeschreibung

Der Ingress NGINX Controller stellt Pods bereit, konfiguriert und verwaltet Pods, die Instances von NGINX, einem Open-Source-HTTP- und Reverse-Proxy-Server, enthalten. Diese Pods werden über die Serviceressource des Controllers verfügbar gemacht. Die Serviceressource empfängt den Datenverkehr für die relevanten Anwendungen, die Kubernetes-Ingress- und Serviceressourcen repräsentieren. Weitere Informationen findest du unter Ingress NGINX Controller auf der GitHub-Website und NGINX auf der NGINX-Website.

Lösung

Optional: Installiere Helm. Weitere Informationen findest du unter Helm installieren auf der Helm-Website. Helm ist nicht erforderlich, wenn du ein YAML-Manifest verwendest, um den Ingress NGINX Controller zu installieren.

Optional: Installiere den AWS-Load-Balancer-Controller. Dieser Controller ist erforderlich, damit du den Zielgruppen-Zieltyp des Network Load Balancer auf den IP-Zieltyp konfigurieren kannst. Der IP-Zieltyp registriert die Pod-IPs des Ingress NGINX Controllers für die Zielgruppe. Der Instance-Zieltyp verwendet den Ingress-NGINX-Controller-Service auf NodePort, um die Instance zu registrieren.

Installieren des Ingress INGINX Controllers

Verwende eine der folgenden Methoden, um den Ingress NGINX Controller in einem Kubernetes-Cluster zu installieren:

Verwende die YAML-Manifestdatei, die alle verschiedenen Komponenten definiert. Verwende kubectl, um die Ressourcen im Manifest zu erstellen.

-oder-

Verwende Helm, um den Ingress NGINX Controller über das Repository-Diagramm des Projekts bereitzustellen.

Du kannst den Ingress NGINX Controller extern entweder über einen AWS Classic Load Balancer oder einen AWS Network Load Balancer verfügbar machen. Standardmäßig machen beide Methoden den Controller über einen Classic Load Balancer mit Internetzugriff verfügbar.

Helm verwenden, um den Ingress NGINX Controller bereitzustellen

Verwende den entsprechenden Befehl, um den Controller einzurichten und verfügbar zu machen:

Classic Load Balancer mit Internetzugriff

helm upgrade --install ingress-nginx \
--repo https://kubernetes.github.io/ingress-nginx \
--namespace ingress-nginx \
--create-namespace \
ingress-nginx

Interner Classic Load Balancer

Du musst dem Kubernetes-Service, der den Ingress NGINX Controller verfügbar macht, die folgende Anmerkung hinzufügen:

service.beta.kubernetes.io/aws-load-balancer-internal: true

Beispiel:

Network Load Balancer mit Internetzugriff

Um den Load Balancer von Classic auf Network zu ändern, füge die folgende Anmerkung hinzu:

service.beta.kubernetes.io/aws-load-balancer-type: nlb

Beispiel:

helm upgrade --install ingress-nginx \
--repo https://kubernetes.github.io/ingress-nginx \
--namespace ingress-nginx \
--create-namespace \
--set controller.service.annotations."service\.beta\.kubernetes\.io/aws-load-balancer-type"="nlb" \
ingress-nginx

Interner Netzwerk-Load-Balancer

Um einen internen Network Load Balancer bereitzustellen, füge die folgenden Anmerkungen hinzu:

service.beta.kubernetes.io/aws-load-balancer-type: nlb

service.beta.kubernetes.io/aws-load-balancer-internal: true

Beispiel:

helm upgrade --install ingress-nginx \
--repo https://kubernetes.github.io/ingress-nginx \
--namespace ingress-nginx \
--create-namespace \
--set controller.service.annotations."service\.beta\.kubernetes\.io/aws-load-balancer-type"="nlb" \
--set controller.service.annotations."service\.beta\.kubernetes\.io/aws-load-balancer-internal"="true" \
ingress-nginx

Network Load Balancer im IP-Modus über den AWS Load Balancer Controller

Auf dem Cluster muss der AWS Load Balancer Controller installiert sein. Weitere Informationen findest du unter AWS Load Balancer Controller auf der GitHub-Website.

Verwende die folgende Anmerkung, um sicherzustellen, dass der AWS Load Balancer Controller die Bereitstellung des Network Load Balancer übernimmt:

service.beta.kubernetes.io/aws-load-balancer-type: external

Standardmäßig erstellt das System einen internen Network Load Balancer. Du kannst jedoch die folgende Anmerkung hinzufügen, um einen Network Load Balancer mit Internetzugriff mit dem IP-Zielgruppen-Zieltyp zu erstellen:

service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing

Beispiel:

helm upgrade --install ingress-nginx \
--repo https://kubernetes.github.io/ingress-nginx \
--namespace ingress-nginx \
--create-namespace \
--set controller.service.annotations."service\.beta\.kubernetes\.io/aws-load-balancer-type"="external" \
--set controller.service.annotations."service\.beta\.kubernetes\.io/aws-load-balancer-scheme"="internet-facing" \
ingress-nginx

kubectl- und YAML-Manifestdateien verwenden

Lade die YAML-Manifestdatei herunter. Mit dem folgenden Befehl wird Ingress NGINX Controller Version 1.11.2 heruntergeladen:

curl -Lo ingress-nginx.yaml https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.11.2/deploy/static/provider/cloud/deploy.yaml

Hinweis: Du kannst den Wert durch andere Controller-Versionen ersetzen. Weitere Informationen findest du unter Tags auf der GitHub-Website. In einigen Fällen musst du den Kubernetes-Load-Balancer-Service ingress-nginx-controller mit Anmerkungen versehen, um den Typ und die Eigenschaften des Load Balancers zu ändern, den das System bereitstellt.

Beispiel:

curl -Lo ingress-nginx.yaml https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.11.2/deploy/static/provider/cloud/deploy.yaml

Classic Load Balancer mit Internetzugriff

Du kannst das Manifest ohne Änderungen auf den Cluster anwenden. Führe den folgenden Befehl aus:

kubectl apply -f ingress-nginx.yaml

Interner Classic Load Balancer

Führe die folgenden Schritte aus:

  1. Ändere das YAML-Manifest, um einen Abschnitt mit Anmerkungen hinzuzufügen, der die folgende Anmerkung angibt:
    service.beta.kubernetes.io/aws-load-balancer-internal: true
    Beispiel:

    ...
    apiVersion: v1
    kind: Service
    metadata:
      ...
      name: ingress-nginx-controller
      namespace: ingress-nginx
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-internal: true
      ...
    type: LoadBalancer
    ...
  2. Führe den folgenden Befehl aus, um das Manifest auf deinen Cluster anzuwenden:

    kubectl apply -f ingress-nginx.yaml

Network Load Balancer mit Internetzugriff

  1. Verwende die folgende Anmerkung, um einen Network Load Balancer zu erstellen:
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
    Beispiel:

    ...
    apiVersion: v1
    kind: Service
    metadata:
      ...
      name: ingress-nginx-controller
      namespace: ingress-nginx
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-type: nlb
      ...
    type: LoadBalancer
    ...
  2. Führe den folgenden Befehl aus, um das Manifest auf deinen Cluster anzuwenden:
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
    Beispiel:

    kubectl apply -f ingress-nginx.yaml

Interner Netzwerk-Load-Balancer:

  1. Verwende die folgenden Anmerkungen zusammen, um einen internen Network Load Balancer zu erstellen:
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
    service.beta.kubernetes.io/aws-load-balancer-internal: true
    Beispiel:

    ...
    apiVersion: v1
    kind: Service
    metadata:
      ...
      name: ingress-nginx-controller
      namespace: ingress-nginx
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-type: nlb
        service.beta.kubernetes.io/aws-load-balancer-internal: true
      ...
    type: LoadBalancer
    ...
  2. Führe den folgenden Befehl aus, um das Manifest auf deinen Cluster anzuwenden:

    kubectl apply -f ingress-nginx.yaml

Network Load Balancer im IP-Modus über den AWS Load Balancer Controller

  1. Installiere den AWS Load Balancer Controller im Cluster. Weitere Informationen findest du unter AWS Load Balancer Controller auf der GitHub-Website. Verwende die folgende Anmerkung, um den AWS Load Balancer Controller zu veranlassen, einen Network Load Balancer bereitzustellen:

    service.beta.kubernetes.io/aws-load-balancer-type: external
  2. Standardmäßig erstellt das System einen internen Network Load Balancer. Füge die folgende Anmerkung hinzu, um einen Network Load Balancer mit Internetzugriff mit dem Zielgruppen-Zieltyp als IP zu erstellen:
    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
    Beispiel:

    apiVersion: v1
    kind: Service
    metadata:
      ...
      name: ingress-nginx-controller
      namespace: ingress-nginx
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-type: external
        service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
      ...
    type: LoadBalancer
  3. Führe den folgenden Befehl aus, um das Manifest auf deinen Cluster anzuwenden:

    kubectl apply -f ingress-nginx.yaml

Probleme beheben

Weitere Informationen findest du unter Troubleshooting (Problembehandlung) auf der GitHub-Website.

Subnetzfehler

Wenn der Network Load Balancer das Subnetz nicht automatisch erkennen kann, erhältst du möglicherweise die folgende Fehlermeldung:

„Reconciler error","controller":"ingress",...,"error":"couldn't auto-discover subnets: unable to resolve at least one subnet“

Der AWS Load Balancer Controller verwendet Subnetz-Tags, um automatisch Subnetze zu finden, die für Load Balancer verwendet werden können. Bei AWS Load Balancern benötigt der Controller mindestens zwei Subnetze in verschiedenen Availability Zones. Bei Network Load Balancern benötigt der Controller mindestens ein Subnetz. Für die automatische Erkennung musst du die Subnetze mit Tags versehen:

  • Kennzeichne öffentliche Subnetze mit dem Schlüssel kubernetes.io/role/elb. Stelle den Wert auf 1 ein.
  • Markiere private Subnetze mit dem Schlüssel kubernetes.io/role/internal-elb. Stelle den Wert auf 1 ein.
  • Wenn du AWS Load Balancer Controller Version 2.1.1 und früher verwendest, kennzeichne öffentliche und private Subnetze mit dem Schlüssel kubernetes.io/cluster/your-cluster-name. Setze den Wert auf owned (nicht eigenständig) oder shared (freigegeben).

Im Adressfeld wird „kubectl get“ oder „describe ingress“ nicht angezeigt

Wenn du den Befehl kubectl get ingress your-ingress-name ausführst, ist das Adressfeld möglicherweise leer. Oder kubectl describe ingress zeigt möglicherweise keine zugewiesene Adresse an. Ergreife in einem dieser Szenarien die folgenden Maßnahmen:

  • Beschreibe die Ingress-Ressource, um zu überprüfen, ob sie die richtige Anmerkung ingressClassName oder kubernetes.io/ingress.class verwendet. Der IngressClass-Name des Ingress NGINX Controllers muss mit dem Wert des ingressClassName-Felds oder der kubernetes.io/ingress.class-Anmerkung übereinstimmen. Wenn er nicht übereinstimmt, konfiguriere die IngressClass-Ressource des Ingress NGINX Controllers als einzige Standard-IngressClass für den Cluster. Weitere Informationen findest du unter Default IngressClass (Standard-IngressClass) auf der Kubernetes-Website.
  • Beschreibe die Ingress-Ressource, um festzustellen, ob den Ereignissen vom Ingress NGINX Controller Fehler hinzugefügt wurden. Wenn es keine Ereignisse gibt, haben die Ereignisse ihr Lebensdauer-Limit erreicht. Oder der Ingress NGINX Controller kann die Ingresses, gegen die er Maßnahmen ergreifen muss, nicht erkennen.
  • Führe den folgenden Befehl aus, um die Protokolle der Ingress-NGINX-Controller-Pods auf Role-Based Access Control (RBAC, rollenbasierte Zugriffskontrolle) oder andere damit zusammenhängende Fehler zu überprüfen:
    kubectl logs ingress-nginx-controller-pod-name -n ingress-nginx-namespace
    Hinweis: Ersetze ingress-nginx-controller-pod-name durch den Namen des Pods des Ingress NGINX Controllers. Ersetze ingress-nginx-namespace durch den Namen des Ingress-NGINX-Namespace.

Zugriffs- und Anforderungsprotokolle

Überprüfe das Standardprotokollformat für den Ingress NGINX Controller, um Informationen zu bestimmten Anforderungen und Antworten zu finden. Weitere Informationen dazu findest du unter Log format (Protokollformat) auf der GitHub-Website. Im folgenden Beispiel entspricht das Standardprotokollformat dem folgenden Beispielprotokoll. Es zeigt, dass die IP-Adresse und der Port des Backend-Ziels 192.168.114.102.80 ist und die HTTP-Antwort vom Backend-Ziel 200 ist.

192.168.116.133 - - \[24/Sep/2024:22:14:59 +0000\] "GET / HTTP/1.1" 200 45 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10\_15\_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36" 524 0.003 \[default-apache-service-80\] \[\] 192.168.114.102:80 45 0.003 200 ffe584bdeb28959241e8d8408cfc06e5

Ähnliche Informationen

Bereitstellung von Kubernetes-Anwendungen, Teil 3: Ingress Nginx Controller

AWS OFFICIALAktualisiert vor 2 Monaten