Wählen Sie Ihre Cookie-Einstellungen aus

Wir verwenden essentielle Cookies und ähnliche Tools, die für die Bereitstellung unserer Website und Services erforderlich sind. Wir verwenden Performance-Cookies, um anonyme Statistiken zu sammeln, damit wir verstehen können, wie Kunden unsere Website nutzen, und Verbesserungen vornehmen können. Essentielle Cookies können nicht deaktiviert werden, aber Sie können auf „Anpassen“ oder „Ablehnen“ klicken, um Performance-Cookies abzulehnen.

Wenn Sie damit einverstanden sind, verwenden AWS und zugelassene Drittanbieter auch Cookies, um nützliche Features der Website bereitzustellen, Ihre Präferenzen zu speichern und relevante Inhalte, einschließlich relevanter Werbung, anzuzeigen. Um alle nicht notwendigen Cookies zu akzeptieren oder abzulehnen, klicken Sie auf „Akzeptieren“ oder „Ablehnen“. Um detailliertere Entscheidungen zu treffen, klicken Sie auf „Anpassen“.

Weiterleiten von Anwendungs- und HTTP-Verkehr mit Application Load Balancers

Fokusmodus
Weiterleiten von Anwendungs- und HTTP-Verkehr mit Application Load Balancers - Amazon EKS

Hilf mit, diese Seite zu verbessern

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.

Wenn Sie zu diesem Benutzerhandbuch beitragen möchten, 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.

Hilf mit, diese Seite zu verbessern

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.

Wenn Sie zu diesem Benutzerhandbuch beitragen möchten, 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.

Anmerkung

Neu: Der automatische Modus von Amazon EKS automatisiert Routineaufgaben für den Lastenausgleich. 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 Weiterleiten von TCP- und UDP-Verkehr 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.

  • Einen vorhandenen Cluster haben. Wenn Sie noch keinen Cluster haben, finden Sie weitere Informationen unterErste Schritte mit Amazon EKS. Wenn Sie die Version eines vorhandenen Clusters aktualisieren müssen, finden Sie unter Aktualisieren Sie den vorhandenen Cluster auf die neue Kubernetes-Version.

  • Lassen Sie den AWS Load Balancer Controller auf Ihrem Cluster bereitstellen. Weitere Informationen finden Sie unter Internetverkehr mit 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 Sicherheitsgruppen verwenden, die an den Worker-Knoten angehängt sind, muss genau eine Sicherheitsgruppe wie folgt gekennzeichnet werden. Ersetzen Sie my-cluster mit Ihrem Clusternamen.

    • Schlüsselkubernetes.io/cluster/<my-cluster>

    • Wertshared 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 das Taggen 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 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üsselkubernetes.io/cluster/<my-cluster>

    • Wertshared 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 unterErstellen Sie eine Amazon VPC für Ihren Amazon EKS-Cluster.

      • Schlüsselkubernetes.io/role/internal-elb

      • Wert1

    • Öffentliche Subnetze – Muss im folgenden Format markiert werden. 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 aus (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 unterErstellen Sie eine Amazon VPC für Ihren Amazon EKS-Cluster.

      • Schlüsselkubernetes.io/role/elb

      • Wert1

    Wenn die Subnetz-Rollen-Tags nicht explizit hinzugefügt werden, untersucht der Kubernetes Service Controller die Routentabelle Ihrer Cluster-VPC-Subnetze. Dadurch wird festgestellt, ob das Subnetz privat oder öffentlich ist. Wir empfehlen, dass Sie sich nicht auf dieses Verhalten 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 Ingress-Ressource konfiguriert den ALB so, dass er HTTP- oder HTTPS-Verkehr an verschiedene Pods innerhalb des Clusters weiterleitet. 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 einen Load-Balancing für IPv6 Pods durchführen, fügen Sie Ihrer Ingress-Spezifikation die folgende Anmerkung 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 das ALB erreicht, wird NodePort für Ihren Dienst weitergeleitet 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-Dienst muss den Typ NodePort oder "LoadBalancer" angeben, um diesen Verkehrsmodus verwenden zu können.

    • IP – Registriert Pods als Ziele für den ALB. Der Datenverkehr, der den ALB erreicht, wird für Ihren Dienst direkt an die 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 auf Fargate- oder Amazon EKS-Hybridknoten ausgeführt werden.

  • Um ein vom Controller ALBs erstelltes Tag hinzuzufügen, 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 für mehrere Dienstressourcen gemeinsam nutzen, indem Sie. IngressGroups

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 Eingangsressourcen keiner Eingangsgruppe an.

Warnung

Potenzielles Sicherheitsrisiko

Geben Sie nur dann eine Eingangsgruppe für einen Ingress an, wenn sich alle Kubernetes-Benutzer, die über die RBAC-Berechtigung zum Erstellen oder Ändern von Eingangsressourcen verfügen, innerhalb derselben Vertrauensgrenze befinden. 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. Sie können keine doppelten Bestellnummern für mehrere Eingänge haben.

(Optional) Bereitstellen einer Beispielanwendung

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

  1. Wenn Sie nicht in Fargate bereitstellen, überspringen Sie diesen Schritt. Wenn Sie in Fargate bereitstellen, erstellen Sie ein Fargate-Profil. Sie können das Profil erstellen, indem Sie den folgenden Befehl ausführen oder in AWS Management Console die gleichen Werte für name und namespace verwenden, die im Befehl enthalten sind. Ersetzen Sie das example values durch Ihr eigenes.

    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 Subnetztyp aus, in dem Sie die Bereitstellung durchführen.

    1. Wenn Sie die Bereitstellung auf Pods in einem Cluster durchführen, 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.11.0/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.11.0/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, führen Sie die folgenden Schritte aus.

      1. Laden Sie das Manifest herunter.

        curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.11.0/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 für interne Pods und nicht für Pods mit Internetzugriff durchführen, ändern Sie die Zeile mit der alb.ingress.kubernetes.io/scheme: internet-facing Aufschrift alb.ingress.kubernetes.io/scheme: internal

      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 Sie nichts sehen, aktualisieren Sie Ihren Browser und versuchen Sie es erneut. Wenn Sie die Bereitstellung in einem privaten Subnetz durchgeführt haben, müssen Sie die Seite von einem Gerät in Ihrer VPC aus aufrufen, z. B. von einem Bastion-Host aus. 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.11.0/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
DatenschutzNutzungsbedingungen für die WebsiteCookie-Einstellungen
© 2025, Amazon Web Services, Inc. oder Tochtergesellschaften. Alle Rechte vorbehalten.