Anwendungslastenverteilung auf Amazon EKS - Amazon EKS

Anwendungslastenverteilung 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 Netzwerklastenausgleich auf Amazon EKS. Weitere Informationen zu den Unterschieden zwischen den beiden Lastenverteilungen finden Sie unter Elastic-Load-Balancing-Funktionen auf der AWS-Website.

Prerequisites

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 vorhandenen Cluster haben, finden Sie unter Erste Schritte mit Amazon EKS weitere Informationen. Wenn Sie die Version eines vorhandenen Clusters aktualisieren müssen, finden Sie unter Aktualisieren eines Clusters weitere Informationen.

  • Der auf Ihrem Cluster bereitgestellte AWS-Lastenverteilungs-Controller. Weitere Informationen finden Sie unter AWS-Lastenverteilungs-Controller.

  • Mindestens zwei Subnetze in verschiedenen Availability Zones. Der AWS-Lastenverteilungs-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.

    Wenn Sie mehrere an den Worker-Knoten angehängte Sicherheitsgruppen verwenden, muss genau eine Sicherheitsgruppe wie folgt gekennzeichnet werden. Ersetzen Sie cluster-name durch Ihren Clusternamen.

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

    • Wertshared oder owned

  • Wenn Sie die AWS-Lastenverteilungs-Controller-Version v2.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 Lastenverteilungen für jeden Cluster bereitgestellt werden. Ersetzen Sie cluster-name durch Ihren Clusternamen.

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

    • 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 Lastenverteilungen bereit, indem Sie Subnetz-IDs explizit als Anmerkung zu einem Service- oder Ingress-Objekt angeben. In dieser Situation verwenden Kubernetes und derAWS-Lastenverteilungs-Controller diese Subnetze direkt, um die Lastenverteilung zu erstellen, und die folgenden Tags sind nicht erforderlich.

    • Private Subnetze – Muss im folgenden Format gekennzeichnet werden. Damit wissen Kubernetes und der AWS-Lastenverteilungs-Controller, dass die Subnetze für interne Lastenverteilung 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 – Muss im folgenden Format markiert werden. So erkennt Kubernetes, dass nur die Subnetze verwendbar sind, die für externe Lastenverteilung 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-Lastenverteilungs-Controller untersucht keine Routing-Tabellen. Außerdem müssen die Tags privat und öffentlich für eine erfolgreiche automatische Erkennung vorhanden sein.

Considerations

  • Der AWS-Lastenverteilungs-Controller erstellt ALBs und die erforderlichen unterstützenden AWS-Ressourcen, wenn eine Kubernetes-Ingress-Ressource im Cluster mit der kubernetes.io/ingress.class: alb-Annotation 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-Lastenverteilungs-Controller verwenden, fügen Sie die folgende Anmerkung zu Ihrer Kubernetets-Spezifikation für eingehenden Datenverkehr hinzu. Weitere Informationen finden Sie unter Ingress-Spezifikation auf GitHub.

    annotations: kubernetes.io/ingress.class: alb
  • Der AWS-Lastenverteilungs-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 NodePort- oder „Lastenausgleich“-Typen 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 Annotationen, die vom AWS-Lastenverteilungs-Controller unterstützt werden, finden Sie unter Ingress-Annotationen auf GitHub.

  • Ein Upgrade oder Downgrade der ALB-Controller-Version kann zu einer Unterbrechung der Abwärtskompatibilität für Funktionen 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 Aplication Load Balancer über mehrere Ingress-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.

So stellen Sie eine Beispielanwendung bereit

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

  1. Wenn Sie Fargate bereitstellen, erstellen Sie ein Fargate-Profil. Wenn Sie keine Bereitstellung für Fargate durchführen, überspringen Sie diesen Schritt. 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.

    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-Lastenverteilungs-Controller bedingt durch ein Objekt für eingehenden Datenverkehr einen AWS-ALB erstellt.

    kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.2.0/docs/examples/2048/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

    Ausgabe:

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

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

    kubectl logs -n kube-system deployment.apps/aws-load-balancer-controller
  4. Ö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.

    
                    2048-Beispielanwendung
  5. Wenn Sie mit dem Experimentieren mit Ihrer Beispielanwendung fertig sind, löschen Sie sie, indem Sie die folgenden Befehle ausführen.

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