Netzwerklastenausgleich auf Amazon EKS - Amazon EKS

Netzwerklastenausgleich auf Amazon EKS

Das Load Balancing des Netzwerkverkehrs erfolgt auf L4 des OSI-Modells. Um den Anwendungsdatenverkehr auf L7 auszugleichen, setzen Sie einen Kubernetes ingress ein, der einen AWS-Application-Load-Balancer bereitstellt. Weitere Informationen finden Sie unter Application Load Balancing auf Amazon EKS. Weitere Informationen zu den Unterschieden zwischen den beiden Load-Balancing-Arten finden Sie unter Elastic-Load-Balancing-Funktionen auf der AWS-Website.

Wenn Sie ein Kubernetes Service vom Typ LoadBalancer erstellen, erstellt der Load-Balancer-Controller für AWS Cloud-Anbieter standardmäßig AWS Classic Load Balancer, kann aber auch AWS Network Load Balancer erstellen. Dieser Controller erhält in Zukunft nur kritische Fehlerbehebungen. Weitere Informationen zur Verwendung des Load Balancer für AWS-Cloud-Anbieter finden Sie unter Load Balancer-Controller für AWS-Cloud-Anbieter in der Kubernetes-Dokumentation. Seine Verwendung wird in diesem Thema nicht behandelt.

Für neue Services, die in Clustern der Version 1.19 oder höher bereitgestellt werden, empfehlen wir die Verwendung der Version 2.4.2 oder höher von Installieren des AWS Load Balancer Controller-Add-ons anstelle des Load Balancer Controllers für AWS-Cloud-Anbieter. Bei einer früheren Clusterversion als 1.19 empfehlen wir die Verwendung der Version 2.3.1 des Controllers. Der AWS Load Balancer Controller erstellt AWS-Network-Load-Balancer, aber keine AWS-Classic-Load-Balancer. Im weiteren Thema geht es um die Verwendung des AWS-Load-Balancer-Controllers.

Ein AWS Network Load Balancer kann den Netzwerkverkehr auf pods laden, die auf Amazon-EC2-IP- und -Instance-Zielen oder auf AWS Fargate-IP-Zielen bereitgestellt werden. Weitere Informationen zum AWS-Load-Balancer-Controller finden Sie unter GitHub.

Voraussetzungen

Bevor Sie mit AWS Load Balancer Controller ein Load Balancing des Netzwerkverkehrs durchführen können, müssen folgende Voraussetzungen erfüllt sein.

  • Einen vorhandenen Cluster haben. Falls Sie keinen vorhandenen Cluster haben, finden Sie unter 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 die Version 2.4.2 oder höher für Cluster der Version 1.19 oder höher. Bei einer früheren Clusterversion als 1.19 empfehlen wir die Verwendung der Controller-Version 2.3.1.

  • Mindestens ein Subnetz. Wenn mehrere getaggte Subnetze in einer Availability Zone gefunden werden, wählt der Controller das erste Subnetz aus, dessen Subnetz-ID zuerst lexikografisch kommt. Das Subnetz muss mindestens acht verfügbare IP-Adressen aufweisen.

  • Wenn Sie die Version 2.1.1 oder früher des AWS Load Balancer Controller verwenden, müssen Subnetze wie folgt markiert werden. Bei Verwendung der Version 2.1.2 oder höher ist dieses Tag optional. Sie können ein Subnetz mit Tags versehen, wenn mehrere Cluster in derselben VPC ausgeführt werden, oder mehrere AWS-Dienste, die Subnetze in einer VPC gemeinsam nutzen und mehr Kontrolle darüber wünschen, wo Lastausgleichsdienste für jeden Cluster bereitgestellt werden. Wenn Sie Subnetz-IDs explizit als Anmerkung für ein Service-Objekt angeben, werden Kubernetes und die AWS Load Balancer Controller diese Subnetze direkt verwenden, um den Load Balancer zu erstellen. Subnetz-Tagging ist nicht erforderlich, wenn Sie diese Methode für die Bereitstellung von Lastausgleichsdiensten verwenden und Sie die folgenden Anforderungen für private und öffentliche Subnetz-Tagging überspringen können. Ersetzen Sie cluster-name mit Ihrem Clusternamen.

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

    • Wertshared oder owned

  • Ihre öffentlichen und privaten Subnetze müssen die folgenden Anforderungen erfüllen, es sei denn, Sie geben Subnetz-IDs explizit als Anmerkung für ein Service- oder Ingress-Objekt an. Wenn Sie Load Balancer bereitstellen, indem Sie Subnetz-IDs explizit als Anmerkung für ein Service- oder Ingress-Objekt angeben, werden Kubernetes und die AWS Load Balancer Controller diese Subnetze direkt verwenden, 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-AWS CloudFormation-Vorlage zum Erstellen Ihrer VPC nach dem 26. März 2020 verwenden, werden die Subnetze entsprechend markiert, wenn sie erstellt werden. Weitere Informationen über die Amazon-EKS-AWS-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. Sie müssen öffentliche Subnetze in Ihrer VPC entsprechend kennzeichnen, so dass Kubernetes nur diese Subnetze für externe Load Balancer verwendet und kein öffentliches Subnetz in jeder Availability Zone wählt (in lexikographischer Reihenfolge nach Subnetz-ID): Wenn Sie eksctl oder eine Amazon-EKS-AWS CloudFormation-Vorlage zum Erstellen Ihrer VPC nach dem 26. März 2020 verwenden, werden die Subnetze entsprechend markiert, wenn sie erstellt werden. Weitere Informationen über die 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 Subnetzrollen-Tags nicht explizit hinzugefügt werden, prüft der Kubernetes-Dienstcontroller die Routingtabelle der Cluster-VPC-Subnetze, um festzustellen, ob das Subnetz privat oder öffentlich ist. Es wird empfohlen, dass Sie sich nicht auf dieses Verhalten verlassen und stattdessen explizit die privaten oder öffentlichen Rollentags hinzufügen. Der AWS Load Balancer Controller untersucht keine Routentabellen und erfordert, dass die privaten und öffentlichen Tags für eine erfolgreiche automatische Erkennung vorhanden sind.

Überlegungen

  • Die Konfiguration Ihres Load Balancers wird durch Anmerkungen gesteuert, die zu dem Manifest für Ihren Service hinzugefügt werden. Die Service-Anmerkungen unterscheiden sich bei Verwendung des AWS Load Balancer Controller im Vergleich zum AWS-Cloud-Provider-Load-Balancer-Controller. Überprüfen Sie die Anmerkungen für den AWS Load Balancer Controller vor der Bereitstellung von Services.

  • Bei Verwendung des Amazon VPC CNI plugin for Kubernetes kann der AWS Load Balancer Controller das Load Balancing zu Amazon-EC2-IP- oder -Instance-Zielen und Fargate-IP-Zielen vornehmen. Bei Verwendung von Alternativen kompatiblen CNI-Plugins kann der Controller nur das Load Balancing zu Instance-Zielen vornehmen. Weitere Informationen zu Network Load Balancer-Zieltypen finden Sie unter Zieltyp im Benutzerhandbuch für Network Load Balancers.

  • Wenn Sie dem Load Balancer Tags hinzufügen möchten, wenn oder nachdem er erstellt wurde, fügen Sie die folgende Anmerkung in Ihre Service-Spezifikation ein. Weitere Informationen finden Sie unter AWS-Ressourcen-Tags in der AWS Load Balancer Controller-Dokumentation.

    service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags
  • Sie können Elastic IP-Adressen zum Network Load Balancer hinzufügen, indem Sie die folgende Anmerkung hinzufügen. Ersetzen Sie die example-values mit den Allocation IDs Ihrer elastischen IP-Adressen. Die Anzahl der Allocation IDs muss mit der Anzahl der Subnetze übereinstimmen, die für den Load Balancer verwendet werden. Weitere Informationen finden Sie in der Dokumentation zu AWS Load Balancer Controller.

    service.beta.kubernetes.io/aws-load-balancer-eip-allocations: eipalloc-xxxxxxxxxxxxxxxxx,eipalloc-yyyyyyyyyyyyyyyyy
  • Amazon EKS fügt der Sicherheitsgruppe des Knotens eine eingehende Regel für den Client-Datenverkehr und eine Regel für jedes Load Balancer-Subnetz in der VPC für Zustandsprüfungen für jeden von Ihnen erstellten Network Load Balancer hinzu. Bereitstellung eines Dienstes vom Typ LoadBalancer kann fehlschlagen, wenn Amazon EKS versucht, Regeln zu erstellen, die das Kontingent für die maximale Anzahl von Regeln überschreiten, die für eine Sicherheitsgruppe zulässig sind. Weitere Informationen finden Sie im Abschnitt Sicherheitsgruppe in Amazon VPC-Kontingenten im Amazon VPC-Benutzerhandbuch. Berücksichtigen Sie die folgenden Optionen, um die Wahrscheinlichkeit zu minimieren, dass die maximale Anzahl von Regeln für eine Sicherheitsgruppe überschritten wird:

    • Fordern Sie eine Erhöhung Ihrer Regeln pro Sicherheitsgruppenkontingent an. Weitere Informationen finden Sie unter Beantragen einer Kontingenterhöhung im Service-Quotas-Benutzerhandbuch.

    • Verwenden Sie IP-Ziele anstelle von Instance-Zielen. Mit IP-Zielen können Sie Regeln für dieselben Zielports freigeben. Sie können Load-Balancer-Subnetze manuell mit einer Anmerkung angeben. Weitere Informationen finden Sie unter Add-ons auf GitHub.

    • Verwenden Sie einen Ingress anstelle eines Services vom Typ LoadBalancer, um Datenverkehr an Ihren Service zu senden. Der AWS Application Load Balancer erfordert weniger Regeln als Network Load Balancer. Sie können einen ALB für mehrere Ingresses freigeben. Weitere Informationen finden Sie unter Application Load Balancing auf Amazon EKS. Sie können einen Network Load Balancer nicht für mehrere Services freigeben.

    • Stellen Sie Ihre Cluster für mehrere Konten bereit.

  • Wenn Ihre pods unter Windows ausgeführt werden, kann in einem Amazon-EKS-Cluster ein einzelner Dienst mit einem Load Balancer bis zu 64 Backend-pods unterstützen. Jeder pod hat seine eigene eindeutige IP-Adresse. Dies ist eine Einschränkung des Windows-Betriebssystems auf den Amazon-EC2-Knoten.

  • Es wird empfohlen, mit dem AWS Load Balancer Controller nur neue Network Load Balancer zu erstellen. Der Versuch, vorhandene Network Load Balancer zu ersetzen, die mit dem AWS-Cloud-Provider-Controller erstellt wurden, kann zu mehreren Network Load Balancers führen, die Anwendungsausfallzeiten verursachen können.

Erstellen eines Network Load Balancers

Sie können einen Network Load Balancer mit IP- oder Instance-Zielen erstellen.

IP targets

Sie können IP-Ziele mit pods verwenden, die auf Amazon-EC2-Knoten oder Fargate bereitgestellt werden. Ihr Kubernetes-Service muss als Typ LoadBalancer erstellt werden. Weitere Informationen finden Sie unter Typ LoadBalancer in der Kubernetes-Dokumentation.

Um einen Load Balancer zu erstellen, der IP-Ziele verwendet, fügen Sie die folgende Anmerkung zu einem Service-Manifest hinzu und stellen Sie den Dienst bereit. Der external-Wert für aws-load-balancer-type bewirkt, dass der AWS Load Balancer Controller und nicht der AWS-Cloud-Provider-Load-Balancer-Controller den Network Load Balancer erstellt. Sie können ein Beispiel-Service-Manifest mit den Anmerkungen anzeigen.

service.beta.kubernetes.io/aws-load-balancer-type: "external" service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"
Anmerkung

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

service.beta.kubernetes.io/aws-load-balancer-ip-address-type: dualstack

Network Load Balancer werden standardmäßig mit dem internal aws-load-balancer-scheme erstellt. Sie können Network Lastenverteilung in jedem Subnetz in der VPC Ihres Clusters starten, einschließlich Subnetze, die bei der Erstellung Ihres Clusters nicht angegeben wurden.

Kubernetes untersucht die Routing-Tabelle auf Ihre Subnetze, um zu identifizieren, ob sie öffentlich oder privat sind. Öffentliche Subnetze verfügen über einen direkten Zugang zum Internet über ein Internet-Gateway, nicht aber private Subnetze.

Wenn Sie einen Network Load Balancer in einem öffentlichen Subnetz erstellen möchten, um das Load Balancing auf Amazon-EC2-Knoten vorzunehmen (Fargate kann nur privat sein), geben Sie internet-facing mit folgender Anmerkung an:

service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
Anmerkung

Aus Gründen der Abwärtskompatibilität wird service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip" weiterhin unterstützt. Wir empfehlen jedoch die Verwendung der vorherigen Anmerkungen für neue Load Balancer anstelle von service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip".

Wichtig

Bearbeiten Sie die Anmerkungen nicht, nachdem Sie Ihren Service erstellt haben. Wenn Sie es ändern müssen, löschen Sie das Service-Objekt und erstellen es erneut mit dem gewünschten Wert für diese Anmerkung.

Instance targets

Der AWS-Cloud-Provider-Load-Balancer-Controller erstellt Network Load Balancers nur mit Instance-Zielen. Version 2.2.0 und höher des AWS-Load-Balancing-Controllers erstellt Network Load Balancer auch mit Instance-Zielen. Wir empfehlen, ihn anstelle des AWS-Cloud-Provider-Load-Balancer-Controllers zu verwenden, um neue Network Load Balancer zu erstellen. Sie können Network Load Balancer-Instance-Ziele mit pods verwenden, die auf Amazon-EC2-Knoten bereitgestellt werden, jedoch nicht in Fargate. Um den Netzwerkverkehr über pods auszugleichen, die in Fargate bereitgestellt werden, müssen Sie IP-Ziele verwenden.

Um einen Network Load Balancer in einem privaten Subnetz bereitzustellen, muss Ihre Dienstspezifikation über die folgenden Anmerkungen verfügen. Sie können ein Beispiel-Service-Manifest mit den Anmerkungen anzeigen. Der external-Wert für aws-load-balancer-type bewirkt, dass der AWS-Load-Balancer-Controller und nicht der AWS-Cloud-Provider-Controller den Network Load Balancer erstellt.

service.beta.kubernetes.io/aws-load-balancer-type: "external" service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "instance"

Network Load Balancer werden standardmäßig mit dem internal aws-load-balancer-scheme erstellt. Für interne Network Load Balancer muss Ihr Amazon-EKS-Cluster so konfiguriert werden, dass er mindestens ein privates Subnetz in Ihrer VPC verwendet. Kubernetes untersucht die Routing-Tabelle auf Ihre Subnetze, um zu identifizieren, ob sie öffentlich oder privat sind. Öffentliche Subnetze verfügen über einen direkten Zugang zum Internet über ein Internet-Gateway, nicht aber private Subnetze.

Wenn Sie einen Network Load Balancer in einem öffentlichen Subnetz erstellen möchten, um das Load Balancing auf Amazon-EC2-Knoten vorzunehmen, geben Sie internet-facing mit folgender Anmerkung an:

service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
Wichtig

Bearbeiten Sie die Anmerkungen nicht, nachdem Sie Ihren Service erstellt haben. Wenn Sie es ändern müssen, löschen Sie das Service-Objekt und erstellen es erneut mit dem gewünschten Wert für diese Anmerkung.

(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.4.2 oder höher.

So stellen Sie eine Beispielanwendung bereit

  1. Wenn Sie auf Fargate bereitstellen, stellen Sie sicher, dass Sie ein verfügbares privates Subnetz in Ihrer VPC haben, und 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. Ersetzen Sie das example values durch Ihr eigenes.

    eksctl create fargateprofile \ --cluster my-cluster \ --region region-code \ --name nlb-sample-app \ --namespace nlb-sample-app
  2. Bereitstellen einer Beispielanwendung

    1. Erstellen Sie einen Namespace für die Anwendung.

      kubectl create namespace nlb-sample-app
    2. Speichern Sie den folgenden Inhalt in einer Datei mit dem Namen sample-deployment.yaml auf Ihrem Computer.

      apiVersion: apps/v1 kind: Deployment metadata: name: nlb-sample-app namespace: nlb-sample-app spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: public.ecr.aws/nginx/nginx:1.21 ports: - name: tcp containerPort: 80
    3. Wenden Sie die Manifestdatei auf Ihren Cluster an.

      kubectl apply -f sample-deployment.yaml
  3. Erstellen Sie einen Service mit einem zum Internet offenen Network Load Balancer, der Load Balancing auf IP-Ziele vornimmt.

    1. Speichern Sie den folgenden Inhalt in einer Datei mit dem Namen sample-service.yaml auf Ihrem Computer. Wenn Sie auf Fargate-Knoten bereitstellen, entfernen Sie die service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing-Zeile.

      apiVersion: v1 kind: Service metadata: name: nlb-sample-service namespace: nlb-sample-app annotations: service.beta.kubernetes.io/aws-load-balancer-type: external service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing spec: ports: - port: 80 targetPort: 80 protocol: TCP type: LoadBalancer selector: app: nginx
    2. Wenden Sie die Manifestdatei auf Ihren Cluster an.

      kubectl apply -f sample-service.yaml
  4. Stellen Sie sicher, dass der Service bereitgestellt wurde.

    kubectl get svc nlb-sample-service -n nlb-sample-app

    Die Beispielausgabe lautet wie folgt.

    NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE sample-service LoadBalancer 10.100.240.137 k8s-nlbsampl-nlbsampl-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb.region-code.amazonaws.com 80:32400/TCP 16h
    Anmerkung

    Die Werte für 10.100.240.137 und xxxxxxxxxx-xxxxxxxxxxxxxxxx werden anders aussehen als in der Beispielausgabe (sie sind für Ihr Load Balancing spezifisch). Zudem kann us-west-2 je nachdem, in welcher AWS-Region sich Ihr Cluster befindet, anders aussehen.

  5. Öffnen Sie die Amazon-EC2-AWS Management Console. Wählen Sie Target Groups (Zielgruppen) unter Load Balancing (Lastausgleich) im linken Navigationsbereich aus. Wählen Sie in der Spalte Name den Namen der Zielgruppe aus, wobei der Wert in der Spalte Load Balancer einem Teil des Namens in der EXTERNAL-IP-Spalte der Ausgabe im vorherigen Schritt entspricht. Sie wählen beispielsweise die Zielgruppe k8s-default-samplese-xxxxxxxxxx, wenn Ihre Ausgabe die gleiche wie die obige Ausgabe war. Der Zieltyp ist IP, da dies im Beispieldienstbereitstellungsmanifest angegeben wurde.

  6. Wählen Sie Ihre Zielgruppe und danach die Registerkarte Ziele aus. Unter Registrierte Ziele sollten Sie drei IP-Adressen der drei Replikate sehen, die in einem vorherigen Schritt bereitgestellt wurden. Warten Sie, bis der Status aller Ziele fehlerfrei ist, bevor Sie fortfahren. Möglicherweise dauert es ein paar Minuten, bis alle Ziele healthy sind. Die Ziele können sich in einem unhealthy-Zustand befinden, bevor sie in einen healthy-Zustand wechseln.

  7. Senden Sie Datenverkehr an den Dienst, indem Sie xxxxxxxxxx-xxxxxxxxxxxxxxxx und us-west-2 durch die Werte ersetzen, die in der Ausgabe für einen vorherigen Schritt für EXTERNAL-IP zurückgegeben wurden. 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.

    curl k8s-default-samplese-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb.region-code.amazonaws.com

    Die Beispielausgabe lautet wie folgt.

    <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> ...
  8. Wenn Sie mit der Beispielbereitstellung, dem Dienst und Namespace fertig sind, entfernen Sie sie.

    kubectl delete namespace nlb-sample-app