Network Load Balancing in Amazon EKS - Amazon EKS
Erstellen eines Network Load Balancers(Optional) Bereitstellen einer Beispielanwendung

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.

Network Load Balancing in Amazon EKS

Das Load Balancing des Netzwerkverkehrs erfolgt auf L4 des OSI-Modells. Um den Anwendungsdatenverkehr auf auszugleichenL7, stellen Sie eine bereitKubernetesingress, die 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 Arten von Load Balancing finden Sie unter Elastic Load Balancing-Funktionen auf der - AWS Website.

Wenn Sie einen Kubernetes Service vom Typ erstellenLoadBalancer, erstellt der Load Balancer-Controller des AWS Cloud-Anbieters 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 Balancers für AWS Cloud-Anbieter finden Sie unter AWS Load Balancer-Controller für Cloud-Anbieter in der -KubernetesDokumentation. Seine Verwendung wird in diesem Thema nicht behandelt.

Wir empfehlen die Verwendung der Version 2.7.1 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, aber keine AWS Classic Load Balancer. Im Rest dieses Themas geht es um die Verwendung des - AWS Load BalancerControllers.

Ein AWS Network Load Balancer kann den Netzwerkverkehr auf ausgleichen, der auf Amazon EC2-IP- und Instance-Zielen oder auf AWS Fargate IP-Zielen Pods bereitgestellt wird. 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 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 Was ist die AWS Load Balancer Controller?. Wir empfehlen Version 2.7.1 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 Controller verwenden, müssen Subnetze wie folgt markiert werden. Bei Verwendung der Version 2.1.2 oder höher ist dieses Tag optional. Möglicherweise möchten Sie ein Subnetz markieren, wenn mehrere Cluster in derselben VPC ausgeführt werden, oder mehrere AWS Services, die Subnetze in einer VPC gemeinsam nutzen, und möchten mehr Kontrolle darüber haben, wo Load Balancer 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 my-cluster mit Ihrem Clusternamen.

    • 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 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. Auf diese Weise 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 Amazon-EKS- AWS 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 über die Amazon-EKS- AWS AWS CloudFormation -VPC-Vorlagen finden Sie unter Erstellen einer 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 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üssel – kubernetes.io/role/elb

      • Wert – 1

    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. Service-Anmerkungen unterscheiden sich bei Verwendung der AWS Load Balancer Controller als bei Verwendung des Load Balancer-Controllers des AWS Cloud-Anbieters. Ü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

  • Für jeden Network Load Balancer, den Sie erstellen, fügt Amazon EKS der Sicherheitsgruppe des Knotens für Clientdatenverkehr 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 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 Network Load Balancer. Sie können einen ALB für mehrere Eingänge freigeben. Weitere Informationen dazu 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 1 024 Backend-Pods unterstützen. Jeder Pod hat seine eigene eindeutige IP-Adresse.

  • 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 Load Balancer-Controller des AWS Cloud-Anbieters erstellt wurden, kann zu mehreren Network Load Balancern 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.

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 -KubernetesDokumentation.

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 bewirktAWS Load Balancer Controller, dass der und nicht der Load Balancer-Controller des AWS Cloud-Anbieters 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 Load Balancer in jedem Subnetz in der VPC Ihres Clusters starten, einschließlich Subnetze, die beim Erstellen 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.

Instance targets

Der Load Balancer-Controller des AWS Cloud-Anbieters erstellt Network Load Balancer 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, sie anstelle des Load Balancer-Controllers des AWS Cloud-Anbieters 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 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 Load Balancer-Controller des AWS Cloud-Anbieters 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

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 Was ist die AWS Load Balancer Controller?. Wir empfehlen Version 2.7.1 oder höher.

So stellen Sie eine Beispielanwendung bereit

  1. Wenn Sie für 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.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 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

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

  5. Öffnen Sie 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 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 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

    Eine Beispielausgabe sieht wie folgt aus.

    <!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