Weiterleitung von TCP- und UDP-Datenverkehr mit Network Load Balancers - Amazon EKS
VoraussetzungenÜberlegungenErstellen eines Network Load Balancers(Optional) Bereitstellen einer Beispielanwendung

Unterstützung für die Verbesserung dieser Seite beitragen

Um zu diesem Benutzerhandbuch beizutragen, klicken Sie auf den Link Diese Seite auf GitHub bearbeiten, der sich im rechten Bereich jeder Seite befindet.

Weiterleitung von TCP- und UDP-Datenverkehr mit Network Load Balancers

Anmerkung

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

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 Anwendungen und HTTP-Datenverkehr mit Application Load Balancers weiterleiten. Weitere Informationen zu den Unterschieden zwischen den beiden Lastenverteilungen 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.

Wir empfehlen die Verwendung der Version 2.7.2 oder höher von AWS Load Balancer Controller anstelle des Load Balancer Controllers für AWS-Cloud-Anbieter. Der AWS Load Balancer Controller erstellt AWS Network Load Balancer, erstellt 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 Netzwerk-Datenverkehr auf Pods laden, die in Amazon-EC2-IP- und -Instance-Zielen, auf AWS-Fargate-IP-Zielen oder auf Amazon EKS Hybrid Nodes als IP-Zielen bereitgestellt werden. Weitere Informationen zum AWS-Load-Balancer-Controller finden Sie unter GitHub.

Voraussetzungen

Bevor Sie den Netzwerkverkehr mit dem AWS-Lastenverteilungs-Controller ausgleichen können, müssen folgende Voraussetzungen erfüllt sein.

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

  • Lassen Sie den AWS-Load-Balancer-Controller in Ihrem Cluster bereitstellen. Weitere Informationen finden Sie unter Weiterleitung von Internet-Datenverkehr mit AWS Load Balancer Controller. Wir empfehlen Version 2.7.2 oder höher.

  • Mindestens ein Subnetz. Werden in einer Availability Zone mehrere markierte Subnetze gefunden, wählt der Controller das erste Subnetz, dessen Subnetz-ID lexikografisch an erster Stelle steht. Das Subnetz muss mindestens acht verfügbare IP-Adressen aufweisen.

  • Wenn Sie die Version 2.1.1 oder früher des AWS Load Balancer Controllers 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 Annotation 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 Load Balancern verwenden. In diesem Fall können Sie die folgenden Anforderungen für das Tagging privater und öffentlicher Subnetze überspringen Ersetzen Sie den cluster-name durch Ihren Cluster-Namen.

    • Schlüssel – kubernetes.io/cluster/<my-cluster>

    • Wert – shared 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 Annotation 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. Dadurch wissen Kubernetes und der AWS-Load-Balancer-Controller, dass die Subnetze für interne Load Balancer verwendet werden können. Wenn Sie eksctl oder eine Vorlage für Amazon EKS AWS AWS CloudFormation zum Erstellen Ihrer VPC nach dem 26. März 2020 verwenden, werden die Subnetze entsprechend gekennzeichnet, wenn sie erstellt werden. Weitere Informationen über die AWS AWS-CloudFormation-VPC-Vorlagen für Amazon EKS finden Sie unter Erstellung einer Amazon VPC für Ihren Amazon-EKS-Cluster.

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

      • Wert – 1

    • Ö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 Vorlage für Amazon EKS AWS CloudFormation zum Erstellen Ihrer VPC nach dem 26. März 2020 verwenden, werden die Subnetze entsprechend gekennzeichnet, wenn sie erstellt werden. Weitere Informationen über die AWS-CloudFormation-VPC-Vorlagen für Amazon EKS finden Sie unter Erstellung einer Amazon VPC für Ihren Amazon-EKS-Cluster.

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

      • Wert – 1

    Wenn die Tags für Subnetz-Rollen nicht explizit hinzugefügt werden, prüft der Kubernetes-Service-Controller die Routing-Tabelle 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 Rollen-Tags hinzufügen. Der AWS Load Balancer Controller untersucht keine Routing-Tabellen 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. Service-Anmerkungen unterscheiden sich bei Verwendung des AWS-Lastenverteilungs-Controllers als bei Verwendung des AWS-Cloud-Provider-Lastenverteilungs-Controllers. Stellen Sie sicher, dass Sie die Anmerkungen für den AWS-Lastenverteilungs-Controller vor der Bereitstellung von Services überprüfen.

  • Bei Verwendung des Amazon-EKS-VPC-CNI-Plugins für Kubernetes kann der AWS Load Balancer Controller die Lastenverteilung zu Amazon-EC2-IP- oder -Instance-Zielen und Fargate-IP-Zielen vornehmen. Bei Verwendung von Alternativen kompatiblen CNI-Plugins kann der Controller die Last nur auf Instance-Ziele ausgleichen, es sei denn, Sie führen das Load Balancing in Amazon EKS Hybrid Nodes durch. Bei Hybridknoten kann der Controller die IP-Ziele ausgleichen. 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 Annotation 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 Beispielwerte durch die Allocation IDs Ihrer Elastic-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 unter Ressourcen-Tags in der AWS-Load-Balancer-Controller-Dokumentation.

    service.beta.kubernetes.io/aws-load-balancer-eip-allocations: eipalloc-xxxxxxxxxxxxxxxxx,eipalloc-yyyyyyyyyyyyyyyyy

  • Für jeden Network Load Balancer, den Sie erstellen, fügt Amazon EKS der Sicherheitsgruppe des Knotens für Client-Datenverkehr eine eingehende Regel und für jedes Load-Balancer-Subnetz in der VPC für Integritätsprüfungen eine Regel hinzu. Bereitstellung eines Dienstes vom TypLoadBalancerkann fehlschlagen, wenn Amazon EKS versucht, Regeln zu erstellen, die das Kontingent für die maximal zulässige Anzahl von Regeln für eine Sicherheitsgruppe überschreiten. Weitere Informationen dazu 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 dazu 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 dazu finden Sie unter Add-ons auf GitHub.

    • Verwenden Sie einen Eingang anstelle eines Services vom Typ LoadBalancer, um Datenverkehr an Ihren Service zu senden. Der AWS-Application-Load-Balancer erfordert weniger Regeln als der Network Load Balancer. Sie können einen ALB für mehrere Eingänge freigeben. Weitere Informationen finden Sie unter Anwendungen und HTTP-Datenverkehr mit Application Load Balancers weiterleiten. Sie können einen Network Load Balancer nicht über mehrere Services hinweg freigeben.

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

  • Wenn Ihre Pods unter Windows in einem Amazon-EKS-Cluster ausgeführt werden, kann ein einzelner Service mit einem Load Balancer bis zu 1024 Backend-Pods unterstützen. Jeder Pod hat seine eigene eindeutige IP-Adresse.

  • Es wird empfohlen, nur neue Network Load Balancer mit dem AWS Load Balancer-Controller 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 Netzwerk-Load-Balancer mit IP- oder Instance-Zielen erstellen.

Network Load Balancer erstellen – IP-Ziele

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

    Um einen Lastausgleichsdienst zu erstellen, der IP-Ziele verwendet, fügen Sie die folgende Anmerkung zu einem Dienstmanifest hinzu und stellen Sie den Dienst bereit. Der external-Wert für aws-load-balancer-type bewirkt, dass der AWS-Lastenverteilungs-Controller und nicht der AWS-Cloud-Provider-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 auf IPv6 Pods durchführen, fügen Sie die folgende Annotation 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 Load Balancer 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 die Lastenverteilung 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.

Network Load Balancer erstellen – Instance-Ziele

  • 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 Instance-Ziele für Network Load Balancer mit Pods verwenden, die in 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 Service-Spezifikation ü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 die Lastenverteilung 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

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

  • Lassen Sie den AWS-Load-Balancer-Controller in Ihrem Cluster bereitstellen. Weitere Informationen finden Sie unter Weiterleitung von Internet-Datenverkehr mit AWS Load Balancer Controller. Wir empfehlen Version 2.7.2 oder höher.

    1. Wenn Sie für Fargate bereitstellen, stellen Sie sicher, dass Sie über ein verfügbares privates Subnetz in Ihrer VPC verfügen, 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-Managementkonsole die gleichen Werte für name und namespace verwenden, die im Befehl enthalten sind. Ersetzen Sie die Beispielwerte durch Ihre eigenen Werte.

      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.23
          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 in 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

      Eine Beispielausgabe sieht wie folgt aus.

      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 and xxxxxxxxxx-xxxxxxxxxxxxxxxx unterscheiden sich von der Beispiel-Ausgabe (sie werden für Ihre Load Balancer eindeutig sein) und us-west-2 kann für Sie unterschiedlich sein, je nachdem, in welcher AWS-Region sich Ihr Cluster befindet.

    5. Öffnen Sie die Amazon-EC2-AWS-Managementkonsole. 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 mit dem Namen k8s-default-samplese-xxxxxxxxxx , wenn Ihre Ausgabe mit der vorigen Ausgabe übereinstimmte. Der Zieltyp ist IP, weil dies im Beispiel-Manifest des Services 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 Service, 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

      Eine Beispielausgabe sieht wie folgt aus.

      <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

    8. Wenn Sie mit der Beispiel-Bereitstellung, dem Service und Namespace fertig sind, entfernen Sie sie.

      kubectl delete namespace nlb-sample-app