Weiterleiten von Anwendungen und HTTP Datenverkehr mit Application Load Balancers

Anmerkung

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

• Einen Beispiel-Load Balancer-Workload im EKS automatischen Modus bereitstellen

• Erstellen Sie einen IngressClass , um einen Application Load Balancer zu konfigurieren

Wenn Sie eine erstellen Kubernetes ingress, 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 im Kubernetes Dokumentation. ALBskann verwendet werden mit Pods die auf Knoten oder in AWS Fargate bereitgestellt werden. Sie können eine ALB in öffentlichen oder privaten Subnetzen bereitstellen.

Der Anwendungsdatenverkehr ist je nach OSI Modell ausgewogen. L7 Für den Lastenausgleich des L4 Netzwerkverkehrs setzen Sie ein Kubernetes servicedes LoadBalancer Typs. Dieser Typ stellt einen AWS Network Load Balancer bereit. Weitere Informationen finden Sie unter Route 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.

• Haben Sie den AWS Load Balancer Controller auf Ihrem Cluster bereitgestellt. 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. Das Tool AWS Load Balancer Controller wählt ein Subnetz aus jeder Availability Zone 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üssel – kubernetes.io/cluster/<my-cluster>

  • Wert – shared oder owned

• Wenn Sie das verwenden AWS Load Balancer Controller Version 2.1.1 oder früher, Subnetze müssen im folgenden Format markiert 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 im selben Cluster ausgeführt werdenVPC, oder Sie haben mehrere AWS Dienste, die sich Subnetze in einem teilen. VPC 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 Dienst- 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 Kubernetes und der AWS Load Balancer-Controller verwendet diese Subnetze direkt, um den Load Balancer zu erstellen. Die folgenden Tags sind nicht erforderlich.

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

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

    • Wert – 1

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

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

    • Wert – 1

  Wenn die Subnetz-Rollen-Tags nicht explizit hinzugefügt werden, Kubernetes Service Controller untersucht die Routing-Tabelle Ihrer VPC Cluster-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. Das Tool 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 AWS Load Balancer Controller erstellt ALBs und die erforderlichen unterstützenden AWS Ressourcen, wann immer ein Kubernetes Die Eingangsressource wird auf dem Cluster mit der kubernetes.io/ingress.class: alb Anmerkung erstellt. Die Eingangsressource konfiguriert die Weiterleitung HTTP oder HTTPS den ALB Datenverkehr an einen anderen Pods innerhalb des Clusters. Um sicherzustellen, dass Ihre Eingangsobjekte das verwenden AWS Load Balancer Controller, fügen Sie die folgende Anmerkung zu Ihrem Kubernetes Eingangsspezifikation. Weitere Informationen finden Sie in der Ingress-Spezifikation auf GitHub.

  annotations:
      kubernetes.io/ingress.class: alb

  Anmerkung

  Wenn Sie einen Lastenausgleich durchführen auf IPv6 Pods, fügen Sie Ihrer Eingangsspezifikation 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

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

  • Instanz — Registriert Knoten in Ihrem Cluster als Ziele für dieALB. Der Datenverkehr, der den erreicht, ALB wird NodePort für Ihren Service weitergeleitet und dann per Proxy an Ihren Pods. Dies ist der Standard-Verkehrsmodus. Sie können ihn auch explizit mit der alb.ingress.kubernetes.io/target-type: instance-Anmerkung angeben.

    Anmerkung

    Ihre Kubernetes Der Dienst muss den Typ NodePort oder "LoadBalancer" angeben, um diesen Verkehrsmodus verwenden zu können.

  • IP — Registriert Pods als Ziele für dieALB. Der Verkehr, der die erreicht, ALB wird direkt weitergeleitet an Pods für Ihren Service. 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 laufen auf Fargate- oder Amazon EKS Hybrid Nodes.

• Um ein vom Controller ALBs erstelltes Tag hinzuzufügen, fügen Sie dem Controller die folgende Anmerkung hinzu:alb.ingress.kubernetes.io/tags. Für eine Liste aller verfügbaren Anmerkungen, die von der unterstützt werden AWS Load Balancer Controller, siehe Ingress-Anmerkungen auf GitHub.

• Ein Upgrade oder Downgrade der ALB Controller-Version kann zu grundlegenden Änderungen bei Funktionen führen, die darauf basieren. Weitere Informationen zu den wichtigsten Änderungen, die in den einzelnen Versionen eingeführt werden, finden Sie in den ALBController-Versionshinweisen unter GitHub.

Wiederverwendung ALBs mit Ingress-Gruppen

Sie können einen Application Load Balancer für mehrere Dienstressourcen gemeinsam nutzen, indem Sie. IngressGroups

Um einen Ingress einer Gruppe beizutreten, fügen Sie die folgende Anmerkung zu einer Kubernetes Spezifikation der Eingangsressource.

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 einer einzigenALB. 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

Potenzielles Sicherheitsrisiko

Geben Sie nur dann eine Eingangsgruppe für einen Ingress an, wenn alle Kubernetes Benutzer, die RBAC berechtigt sind, Eingangsressourcen zu erstellen oder zu ändern, befinden sich innerhalb derselben Vertrauensgrenze. Wenn Sie die Anmerkung mit einem Gruppennamen hinzufügen, werden andere Kubernetes Benutzer können ihre Eingänge so erstellen oder ändern, dass sie derselben Eingangsgruppe 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

• Mindestens ein öffentliches oder privates Subnetz in Ihrem Cluster. VPC

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

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

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 AWS Load Balancer Controller erzeugt AWS ALB als Ergebnis des Eingangsobjekts ein. Führen Sie die Schritte für den Subnetztyp aus, in dem Sie die Bereitstellung durchführen.

   1. Wenn Sie die Bereitstellung in Pods Fahren Sie in einem Cluster, den Sie mit der IPv6 Familie erstellt haben, 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 durchführen Pods Führen Sie in einem Cluster, den Sie mit der IPv6Familie erstellt haben, 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 einen internen Lastenausgleich durchführen Pods, anstatt mit dem Internet verbunden Pods, ändere die Zeile, in der alb.ingress.kubernetes.io/scheme: internet-facing es heißt 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 den AWS Load Balancer Controller Logs. 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 die Installation in einem öffentlichen Subnetz durchgeführt haben, öffnen Sie einen Browser und wechseln Sie zur ADDRESS URL vorherigen Befehlsausgabe, um die Beispielanwendung zu sehen. 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 innerhalb Ihres Subnetzes aus aufrufenVPC, z. B. von einem Bastion-Host aus. Weitere Informationen finden Sie unter Linux-Bastion-Hosts in AWS.

   

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

📝 Bearbeiten Sie diese Seite auf GitHub