Anwendungen und HTTP-Datenverkehr mit Application Load Balancers weiterleiten - Amazon EKS
VoraussetzungenWiederverwendung mit Ingress-Gruppen ALBs (Optional) Bereitstellen einer Beispielanwendung

Unterstützung für die Verbesserung dieser Seite beitragen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link Diese Seite bearbeiten auf, der sich im rechten Bereich jeder Seite befindet.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Anwendungen und HTTP-Datenverkehr mit Application Load Balancers weiterleiten

Anmerkung

Neu: Amazon EKS Auto Mode automatisiert Routineaufgaben für den Lastausgleich. Weitere Informationen finden Sie unter:

Wenn Sie ein Kubernetes erstelleningress, wird ein AWS Application Load Balancer (ALB) bereitgestellt, der den Anwendungsdatenverkehr ausgleicht. Weitere Informationen finden Sie unter Was ist ein Application Load Balancer? im Application Load Balancers-Benutzerhandbuch und Ingress in der Kubernetes-Dokumentation. ALBs kann mit Pods verwendet werden, die auf Knoten oder in AWS Fargate bereitgestellt werden. Sie können einen ALB für öffentliche oder private Subnetze bereitstellen.

Der Anwendungsverkehr wird bei L7 des OSI-Modells ausgeglichen. Um den Netzwerkverkehr auf L4 auszugleichen, stellen Sie einen Kubernetes-service vom Typ LoadBalancer bereit. Dieser Typ stellt einen AWS Network Load Balancer bereit. Weitere Informationen finden Sie unter Weiterleitung von TCP- und UDP-Datenverkehr mit Network Load Balancers. Weitere Informationen zu den Unterschieden zwischen den beiden Arten von Load Balancing finden Sie auf der AWS Website unter Elastic Load Balancing Balancing-Funktionen.

Voraussetzungen

Bevor Sie den Anwendungsdatenverkehr auf eine Anwendung verteilen können, müssen Sie die folgenden Anforderungen erfüllen.

  • Ein Cluster ist vorhanden. Falls Sie keinen vorhandenen Cluster haben, siehe Erste Schritte mit Amazon EKS. Wenn Sie die Version eines vorhandenen Clusters aktualisieren müssen, finden Sie Informationen dazu unter Aktualisierung des vorhandenen Clusters auf die neue Kubernetes-Version.

  • Lassen Sie den AWS Load Balancer Controller auf Ihrem Cluster bereitstellen. Weitere Informationen finden Sie unter Internetverkehr mit dem AWS Load Balancer Controller weiterleiten. Wir empfehlen Version 2.7.2 oder höher.

  • Mindestens zwei Subnetze in verschiedenen Availability Zones. Der AWS Load Balancer Controller wählt aus jeder Availability Zone ein Subnetz aus. Wenn mehrere markierte Subnetze in einer Availability Zone gefunden werden, wählt der Controller das Subnetz aus, dessen Subnetz-ID lexikografisch an erster Stelle steht. Ein Subnetz muss jeweils mindestens acht verfügbare IP-Adressen aufweisen.

    Wenn Sie mehrere an den Worker-Knoten angefügte Sicherheitsgruppen verwenden, muss genau eine Sicherheitsgruppe wie folgt gekennzeichnet werden. Ersetzen Sie my-cluster mit Ihrem Clusternamen.

    • Schlüssel – kubernetes.io/cluster/<my-cluster>

    • Wert – shared oder owned

  • Wenn Sie die Load AWS Balancer Controller-Version 2.1.1 oder eine frühere Version verwenden, müssen Subnetze im folgenden Format gekennzeichnet werden. Wenn Sie Version 2.1.2 oder höher verwenden, ist die Kennzeichnung optional. Wir empfehlen jedoch, ein Subnetz zu markieren, falls einer der folgenden Fälle zutrifft. Sie haben mehrere Cluster, die in derselben VPC ausgeführt werden, oder Sie haben mehrere AWS Dienste, die sich Subnetze in einer VPC teilen. Oder Sie möchten mehr Kontrolle darüber haben, wo Load Balancer für jeden Cluster bereitgestellt werden. Ersetzen Sie my-cluster durch Ihren Clusternamen.

    • Schlüssel – kubernetes.io/cluster/<my-cluster>

    • Wert – shared oder owned

  • Ihre öffentlichen und privaten Subnetze müssen die folgenden Anforderungen erfüllen. Dies ist der Fall, es sei denn, Sie geben das Subnetz explizit IDs als Anmerkung zu einem Service- oder Eingangsobjekt an. Gehen Sie davon aus, dass Sie Load Balancer bereitstellen, indem Sie das Subnetz explizit IDs als Anmerkung zu einem Dienst- oder Eingangsobjekt angeben. In dieser Situation verwenden Kubernetes und der AWS Load Balancer-Controller diese Subnetze direkt, um den Load Balancer zu erstellen, und die folgenden Tags sind nicht erforderlich.

    • Private Subnetze – Müssen im folgenden Format markiert sein. Auf diese Weise wissen Kubernetes und der Load Balancer-Controller, dass die Subnetze für interne Load AWS Balancer verwendet werden können. Wenn Sie nach dem 26. März 2020 eine Amazon AWS CloudFormation EKS-Vorlage verwendeneksctl, um Ihre VPC zu erstellen, werden die Subnetze bei der Erstellung entsprechend gekennzeichnet. Weitere Informationen zu den Amazon AWS CloudFormation EKS-VPC-Vorlagen finden Sie unterErstellung einer Amazon VPC für Ihren Amazon-EKS-Cluster.

      • Schlüssel – kubernetes.io/role/internal-elb

      • Wert – 1

    • Öffentliche Subnetze – Müssen im folgenden Format markiert sein. So erkennt Kubernetes, dass nur die Subnetze verwendbar sind, die für externe Load Balancer angegeben wurden. Auf diese Weise wählt Kubernetes nicht in jeder Availability Zone ein öffentliches Subnetz (lexikografisch basierend auf ihrer Subnetz-ID). Wenn Sie nach dem 26. März 2020 eine Amazon AWS CloudFormation EKS-Vorlage verwendeneksctl, um Ihre VPC zu erstellen, werden die Subnetze bei der Erstellung entsprechend gekennzeichnet. Weitere Informationen zu den Amazon AWS CloudFormation EKS-VPC-Vorlagen finden Sie unterErstellung einer Amazon VPC für Ihren Amazon-EKS-Cluster.

      • Schlüssel – kubernetes.io/role/elb

      • Wert – 1

    Wenn die Subnetz-Rollen-Tags nicht explizit hinzugefügt werden, untersucht der Kubernetes-Service-Controller die Routing-Tabelle Ihrer Cluster-VPC-Subnetze. Dadurch wird festgestellt, ob das Subnetz privat oder öffentlich ist. Wir empfehlen, sich nicht auf dieses Verhalten zu verlassen. Fügen Sie stattdessen explizit die Rollen-Tags privat oder öffentlich hinzu. Der AWS Load Balancer Controller untersucht keine Routentabellen. Außerdem müssen die Tags privat und öffentlich für eine erfolgreiche automatische Erkennung vorhanden sein.

  • Der Load AWS Balancer Controller erstellt ALBs und die erforderlichen unterstützenden AWS Ressourcen, wenn eine Kubernetes-Eingangsressource auf dem Cluster mit der Anmerkung erstellt wird. kubernetes.io/ingress.class: alb Die Ressource für eingehenden Datenverkehr konfiguriert den ALB so, dass HTTP- oder HTTPS-Datenverkehr an verschiedene Pods im Cluster weitergeleitet wird. Um sicherzustellen, dass Ihre Ingress-Objekte den Load AWS Balancer Controller verwenden, fügen Sie Ihrer Kubernetes-Ingress-Spezifikation die folgende Anmerkung hinzu. Weitere Informationen finden Sie unter Ingress-Spezifikation auf GitHub.

    annotations:
    kubernetes.io/ingress.class: alb
    Anmerkung

    Wenn Sie Load Balancing für IPv6-Pods verwenden, fügen Sie die folgende Annotation zu Ihrer Ingress-Spezifikation hinzu. Load Balancing über IPv6 funktioniert nur auf IP-Ziele, nicht auf Instance-Ziele. Ohne diese Anmerkung verläuft das Load Balancing über IPv4.

    alb.ingress.kubernetes.io/ip-address-type: dualstack

  • Der AWS Load Balancer Controller unterstützt die folgenden Verkehrsmodi:

    • Instance – Registriert Knoten in Ihrem Cluster als Ziele für den ALB. Der Datenverkehr, der den ALB erreicht, wird für Ihren Service an NodePort und dann an Ihre Pods weitergeleitet. Dies ist der standardmäßige Datenverkehrsmodus. Sie können ihn auch explizit mit der alb.ingress.kubernetes.io/target-type: instance-Anmerkung angeben.

      Anmerkung

      Ihr Kubernetes-Service muss den Typ NodePort oder LoadBalancer angeben, um diesen Datenverkehrsmodus verwenden zu können.

    • IP – Registriert Pods als Ziele für den ALB. Der Datenverkehr, der den ALB erreicht, wird für Ihren Service direkt an Pods weitergeleitet. Sie müssen die alb.ingress.kubernetes.io/target-type: ip-Anmerkung angeben, um diesen Datenverkehrsmodus verwenden zu können. Der IP-Zieltyp ist erforderlich, wenn Ziel-Pods in Fargate oder Amazon EKS Hybrid Nodes ausgeführt werden.

  • Um ein vom Controller ALBs erstelltes Tag zu erstellen, fügen Sie dem Controller die folgende Anmerkung hinzu:alb.ingress.kubernetes.io/tags. Eine Liste aller verfügbaren Anmerkungen, die vom Load AWS Balancer Controller unterstützt werden, finden Sie unter Ingress-Anmerkungen auf. GitHub

  • Ein Upgrade oder Downgrade der ALB-Controller-Version kann zu einer Unterbrechung der Abwärtskompatibilität für Features führen, die darauf angewiesen sind. Weitere Informationen zu den Breaking Changes, die in jeder Version eingeführt werden, finden Sie in den Versionshinweisen zum ALB-Controller auf GitHub.

Wiederverwendung mit Ingress-Gruppen ALBs

Sie können einen Application Load Balancer über mehrere Service-Ressourcen hinweg mithilfe von IngressGroups gemeinsam nutzen.

Um einen Ingress einer Gruppe hinzuzufügen, fügen Sie die folgende Anmerkung zu einer Kubernetes-Ingress-Ressourcenspezifikation hinzu.

alb.ingress.kubernetes.io/group.name: my-group

Der Gruppenname muss:

  • Eine Länge von 63 oder weniger Zeichen haben.

  • Aus Kleinbuchstaben, Zahlen, - und . bestehen

  • Muss mit einer Zahl oder einem Buchstaben beginnen und enden.

Der Controller führt automatisch Ingress-Regeln für alle Ingresses in derselben Ingress-Gruppe zusammen. Es unterstützt sie mit einem einzigen ALB. Die meisten Anmerkungen, die auf einem Ingress definiert sind, gelten nur für die von diesem Ingress definierten Pfade. Standardmäßig gehören Ingress-Ressourcen keiner Ingress-Gruppe an.

Warnung

Potentielles Sicherheitsrisiko

Geben Sie nur dann eine Ingress-Gruppe für einen Ingress an, wenn alle Kubernetes-Benutzer mit RBAC-Berechtigung zum Erstellen oder Ändern von Ingress-Ressourcen innerhalb derselben Vertrauensgrenze liegen. Wenn Sie die Anmerkung mit einem Gruppennamen hinzufügen, können andere Kubernetes-Benutzer ihre Ingresses erstellen oder ändern, sodass sie derselben Ingress-Gruppe angehören. Dies kann zu unerwünschtem Verhalten führen, z. B. zum Überschreiben vorhandener Regeln durch Regeln mit höherer Priorität.

Sie können eine Reihenfolgennummer zu Ihrer Ingress-Ressource hinzufügen.

alb.ingress.kubernetes.io/group.order: '10'

Die Zahl kann 1-1000 sein. Die niedrigste Zahl für alle Ingresse in derselben Ingress-Gruppe wird zuerst ausgewertet. Alle Ingresses ohne diese Anmerkung werden mit dem Wert null bewertet. Doppelte Regeln mit einer höheren Nummer können Regeln mit einer niedrigeren Nummer überschreiben. Standardmäßig wird die Regelreihenfolge zwischen Ingressen innerhalb derselben Ingress-Gruppe lexikografisch basierend auf Namespace und Name bestimmt.

Wichtig

Stellen Sie sicher, dass jeder Ingress in derselben Ingress-Gruppe eine eindeutige Prioritätsnummer hat. In Ingresses dürfen keine doppelten Bestellnummern vorhanden sein.

(Optional) Bereitstellen einer Beispielanwendung

Sie können die Beispielanwendung auf einem Cluster ausführen, der EC2 Amazon-Knoten, Fargate Pods oder beides hat.

  1. Wenn Sie keine Bereitstellung für Fargate durchführen, überspringen Sie diesen Schritt. Wenn Sie Fargate bereitstellen, erstellen Sie ein Fargate-Profil. Sie können das Profil erstellen, indem Sie den folgenden Befehl ausführen oder in AWS-Managementkonsole die gleichen Werte für name und namespace verwenden, die im Befehl enthalten sind. Ersetzen Sie die Beispielwerte durch Ihre eigenen Werte.

    eksctl create fargateprofile \
    --cluster my-cluster \
    --region region-code \
    --name alb-sample-app \
    --namespace game-2048

  2. Stellen Sie das Spiel 2048 als Beispielanwendung bereit, um zu überprüfen, ob der Load AWS Balancer Controller als Ergebnis des AWS Eingangsobjekts eine ALB erstellt. Führen Sie die Schritte für den Typ des Subnetzes aus, in dem Sie bereitstellen.

    1. Wenn Sie in Pods in einem Cluster bereitstellen, den Sie mit der IPv6-Familie erstellt haben, fahren Sie mit dem nächsten Schritt fort.

      • Öffentlich::

      kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.14.1/docs/examples/2048/2048_full.yaml

      • Privat::

        1. Laden Sie das Manifest herunter.

          curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.14.1/docs/examples/2048/2048_full.yaml

        2. Bearbeiten Sie die Datei und suchen Sie die Zeile mit der Aufschrift alb.ingress.kubernetes.io/scheme: internet-facing.

        3. Ändern Sie internet-facing in internal und speichern Sie die Datei.

        4. Wenden Sie das Manifest auf Ihren Cluster an.

          kubectl apply -f 2048_full.yaml

    2. Wenn Sie die Bereitstellung auf Pods in einem Cluster durchführen, den Sie mit der IPv6 Familie erstellt haben, gehen Sie wie folgt vor.

      1. Laden Sie das Manifest herunter.

        curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.14.1/docs/examples/2048/2048_full.yaml

      2. Öffnen Sie die Datei in einem Editor und fügen Sie die folgende Zeile zu den Anmerkungen in der Ingress-Spezifikation hinzu.

        alb.ingress.kubernetes.io/ip-address-type: dualstack

      3. Wenn Sie den Lastenausgleich in interne Pods anstelle von internetfähige-Pods anwenden, ändern Sie die Zeile, die alb.ingress.kubernetes.io/scheme: internet-facing zu alb.ingress.kubernetes.io/scheme: internal angibt

      4. Speichern Sie die Datei.

      5. Wenden Sie das Manifest auf Ihren Cluster an.

        kubectl apply -f 2048_full.yaml

  3. Überprüfen Sie nach ein paar Minuten mit dem folgenden Befehl, ob die Ressource für eingehenden Datenverkehr erstellt wurde.

    kubectl get ingress/ingress-2048 -n game-2048

    Eine Beispielausgabe sieht wie folgt aus.

    NAME           CLASS    HOSTS   ADDRESS                                                                   PORTS   AGE
ingress-2048   <none>   *       k8s-game2048-ingress2-xxxxxxxxxx-yyyyyyyyyy.region-code.elb.amazonaws.com   80      2m32s
    Anmerkung

    Wenn Sie den Load Balancer in einem privaten Subnetz erstellt haben, wird dem Wert unter ADDRESS in der vorherigen Ausgabe internal- vorangestellt.

Wenn Ihr Ingress nach einigen Minuten nicht erfolgreich erstellt wurde, führen Sie den folgenden Befehl aus, um die Load AWS Balancer Controller-Protokolle anzuzeigen. Diese Protokolle können Fehlermeldungen enthalten, mit denen Sie Probleme mit Ihrer Bereitstellung diagnostizieren können.

kubectl logs -f -n kube-system -l app.kubernetes.io/instance=aws-load-balancer-controller

  1. Wenn Sie in einem öffentlichen Subnetz bereitgestellt haben, öffnen Sie einen Browser, und navigieren Sie zur ADDRESS-URL aus der vorherigen Befehlausgabe, um die Beispielanwendung anzuzeigen. Wenn nichts angezeigt wird, aktualisieren Sie Ihren Browser und versuchen Sie es erneut. Wenn Sie in einem privaten Subnetz bereitgestellt haben, müssen Sie die Seite von einem Gerät in Ihrer VPC aus anzeigen, z. B. von einem Bastion-Host. Weitere Informationen finden Sie unter Linux-Bastion-Hosts in AWS.

    2048-Beispielanwendung

  2. Wenn Sie mit dem Experimentieren mit Ihrer Beispielanwendung fertig sind, löschen Sie sie, indem Sie einen der folgenden Befehle ausführen.

    • Wenn Sie das Manifest angewendet haben, anstatt eine heruntergeladene Kopie anzuwenden, verwenden Sie den folgenden Befehl.

      kubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.14.1/docs/examples/2048/2048_full.yaml

    • Wenn Sie das Manifest heruntergeladen und bearbeitet haben, verwenden Sie den folgenden Befehl.

      kubectl delete -f 2048_full.yaml