Application Load Balancing auf Amazon EKS - Amazon EKS

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.

Application Load Balancing auf Amazon EKS

Wenn Sie eine Kubernetes-ingress erstellen, wird ein AWS Application Load Balancer (ALB) bereitgestellt, der den Last des Anwendungsverkehrs verteilt. Weitere Informationen hierzu finden Sie unter Was ist ein Application Load Balancer? im Benutzerhandbuch für Application Load Balancer und Ingress in der Kubernetes-Dokumentation. ALBs können mit Pods verwendet werden, die auf Knoten oder 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 Network Load Balancing in Amazon EKS. Weitere Informationen zu den Unterschieden zwischen den beiden Load-Balancing-Arten finden Sie unter Elastic-Load-Balancing-Features auf der AWS-Website.

Voraussetzungen

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

  • Einen vorhandenen Cluster haben. Falls Sie keinen bestehenden Cluster haben, siehe Erste Schritte mit Amazon EKS. Wenn Sie die Version eines vorhandenen Clusters aktualisieren müssen, finden Sie unter Aktualisieren einer Amazon-EKS-Cluster-Kubernetes-Version.

  • Stellen Sie den AWS Load Balancer Controller in Ihrem Cluster bereit. Weitere Informationen finden Sie unter Installieren des AWS Load Balancer Controller-Add-ons. Wir empfehlen Version 2.5.4 oder höher.

  • Mindestens zwei Subnetze in verschiedenen Availability Zones. Der 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 an den Worker-Knoten angehängte Sicherheitsgruppen verwenden, muss genau eine Sicherheitsgruppe wie folgt gekennzeichnet werden. Ersetzen Sie my-cluster durch Ihren Clusternamen.

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

    • Wertshared oder owned

  • Wenn Sie die AWS Load Balancer Controller-Version 2.1.1 oder früher verwenden, müssen Subnetze im folgenden Format markiert werden. Wenn Sie Version 2.1.2 oder höher verwenden, ist die Markierung 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 mehrere AWS-Dienste, die Subnetze in einer VPC gemeinsam nutzen. 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 gilt, es sei denn, Sie geben Subnetz-IDs explizit als Anmerkung zu einem Dienst- oder Ingress-Objekt an. Angenommen, Sie stellen Load Balancer bereit, indem Sie Subnetz-IDs explizit als Anmerkung zu einem Service- oder Ingress-Objekt 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. Dies ist so, dass Kubernetes und die AWS Load Balancer Controller wissen, dass die Subnetze für interne Lastausgleichsdienste verwendet werden können. Wenn Sie eksctl oder eine Amazon-EKS-AWS CloudFormation-Vorlage verwenden, um Ihre VPC nach dem 26. März 2020 zu erstellen, werden die Subnetze bei der Erstellung entsprechend markiert. Weitere Informationen zu den Amazon-EKS-AWS CloudFormation-VPC-Vorlagen finden Sie unter Erstellen einer VPC für Ihren Amazon-EKS-Cluster.

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

      • Wert1

    • Ö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 eksctl oder eine Amazon-EKS-AWS CloudFormation-Vorlage verwenden, um Ihre VPC nach dem 26. März 2020 zu erstellen, werden die Subnetze bei der Erstellung entsprechend markiert. Weitere Informationen zu den Amazon-EKS-AWS CloudFormation-VPC-Vorlagen finden Sie unter Erstellen einer 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-Dienst-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 Routing-Tabellen. Außerdem müssen die Tags privat und öffentlich für eine erfolgreiche automatische Erkennung vorhanden sein.

Überlegungen
  • Der Load-Balancer-Controller von AWS erstellt ALBs und die erforderlichen unterstützenden AWS-Ressourcen, wenn eine Kubernetes-Eingangsressource im Cluster mit der Anmerkung kubernetes.io/ingress.class: alb erstellt wird. 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 AWS Load Balancer Controller verwenden, fügen Sie die folgende Anmerkung zu Ihrer Kubernetes-Spezifikation für eingehenden Datenverkehr 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 Anmerkung 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 Datenverkehrsmodi.

    • 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 auf Fargate ausgeführt werden.

  • Um vom Controller erstellte ALBs mit Tags zu versehen, fügen Sie dem Controller die folgende Anmerkung hinzu: alb.ingress.kubernetes.io/tags. Eine Liste aller verfügbaren Anmerkungen, die vom AWS Load 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.

So teilen Sie einen Application Load Balancer über mehrere Service-Ressourcen mit 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 Ingress-Ressourcen keiner Ingress-Gruppe an.

Warnung

Potenzielles 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

Voraussetzungen
  • Mindestens ein öffentliches oder privates Subnetz in Ihrer Cluster-VPC.

  • Stellen Sie den AWS Load Balancer Controller in Ihrem Cluster bereit. Weitere Informationen finden Sie unter Installieren des AWS Load Balancer Controller-Add-ons. Wir empfehlen Version 2.5.4 oder höher.

Bereitstellen einer Beispielanwendung

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

  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 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, mit der überprüft werden kann, ob der AWS Load Balancer Controller bedingt durch ein Objekt für eingehenden Datenverkehr einen AWS-ALB erstellt. Führen Sie die Schritte für den Typ des Subnetzes aus, in dem Sie bereitstellen.

    1. Wenn Sie auf 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.5.4/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.5.4/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 auf Pods in einem Cluster bereitstellen, den Sie mit der IPv6-Familie erstellt haben, fahren Sie mit den nächsten Schritten fort.

      1. Laden Sie das Manifest herunter.

        curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.5.4/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 auf interne Pods anstelle von Internet-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 erstellt wurde, führen Sie den folgenden Befehl aus, um die AWS Load 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
  4. 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
  5. 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.5.4/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