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.

Lastausgleich

Load Balancer empfangen eingehenden Datenverkehr und verteilen ihn auf Ziele der vorgesehenen Anwendung, die in einem EKS-Cluster gehostet werden. Dies verbessert die Widerstandsfähigkeit der Anwendung. Bei der Bereitstellung in einem EKS-Cluster erstellt und verwaltet der AWS Load Balancer-Controller AWS Elastic Load Balancer für diesen Cluster. Wenn ein Kubernetes-Service dieses Typs erstellt LoadBalancer wird, erstellt der AWS Load Balancer Controller einen Network Load Balancer (NLB), der den empfangenen Datenverkehr auf Ebene 4 des OSI-Modells ausgleicht. Während der Erstellung eines Kubernetes Ingress-Objekts erstellt der AWS Load Balancer Controller einen Application Load Balancer (ALB), der den Datenverkehr auf Ebene 7 des OSI-Modells ausgleicht.

Auswahl des Load Balancer-Typs

Das AWS Elastic Load Balancing (ELB) -Portfolio unterstützt die folgenden Load Balancer: Application Load Balancer (ALB), Network Load Balancer (NLB), Gateway Load Balancer (GWLB) und Classic Load Balancer (CLB). Dieser Abschnitt über bewährte Methoden konzentriert sich auf ALB und NLB, die beiden, die für EKS-Cluster am relevantesten sind.

Die Hauptüberlegung bei der Auswahl des Load Balancer-Typs sind die Workload-Anforderungen.

Ausführlichere Informationen und als Referenz für alle AWS Load Balancer finden Sie unter Produktvergleiche

Wählen Sie den Application Load Balancer (ALB), wenn Ihre Arbeitslast HTTP/HTTPS

Wenn für einen Workload ein Load Balancing auf Ebene 7 des OSI-Modells erforderlich ist, kann der AWS Load Balancer Controller zur Bereitstellung eines ALB verwendet werden. Die Bereitstellung wird im folgenden Abschnitt behandelt. Der ALB wird von der bereits erwähnten Ingress-Ressource gesteuert und konfiguriert und leitet den HTTP- oder HTTPS-Verkehr an verschiedene Pods innerhalb des Clusters weiter. Das ALB bietet Kunden die Flexibilität, den Routing-Algorithmus für den Anwendungsverkehr zu ändern. Der Standard-Routing-Algorithmus ist Round-Robin-Algorithmus, wobei der Routing-Algorithmus für die am wenigsten ausstehenden Anfragen ebenfalls eine Alternative darstellt.

Wählen Sie den Network Load Balancer (NLB), wenn es sich bei Ihrem Workload um TCP handelt oder wenn Ihr Workload die Quell-IP-Erhaltung der Clients erfordert

Ein Network Load Balancer arbeitet auf der vierten Ebene (Transport) des Open Systems Interconnection (OSI) -Modells. Er eignet sich für TCP- und UDP-basierte Workloads. Network Load Balancer behält standardmäßig auch die Quell-IP-Adresse der Clients bei, wenn der Datenverkehr dem Pod präsentiert wird.

Wählen Sie den Network Load Balancer (NLB), wenn Ihr Workload DNS nicht nutzen kann

Ein weiterer wichtiger Grund für die Verwendung des NLB ist, wenn Ihre Kunden DNS nicht nutzen können. In diesem Fall ist der NLB möglicherweise besser für Ihre Arbeitslast geeignet, da die IPs auf einem Network Load Balancer statisch sind. Clients wird zwar empfohlen, DNS für die Auflösung von Domainnamen in IP-Adressen zu verwenden, wenn sie eine Verbindung zu Load Balancern herstellen, aber wenn die Anwendung eines Clients die DNS-Auflösung nicht unterstützt und nur fest codierte IPs akzeptiert, ist ein NLB besser geeignet, da die IPs statisch sind und für die gesamte Lebensdauer des NLB unverändert bleiben.

Bereitstellung von Load Balancern

Nachdem der für Ihre Workloads am besten geeignete Load Balancer ermittelt wurde, haben Kunden eine Reihe von Optionen für die Bereitstellung eines Load Balancers.

Stellen Sie Load Balancer bereit, indem Sie den AWS Load Balancer Controller bereitstellen

Es gibt zwei wichtige Methoden zur Bereitstellung von Load Balancern innerhalb eines EKS-Clusters.

Standardmäßig gleicht der Kubernetes Service Controller, auch bekannt als In-Tree-Controller, den Typ der Kubernetes Service-Ressource ab. LoadBalancer Dieser Controller ist in die AWS Cloud Provider-Komponente integriert, die als Kubernetes Cloud Controller Manager fungiert. https://kubernetes.io/docs/concepts/architecture/cloud-controller/

Die Konfiguration des bereitgestellten Elastic Load Balancers wird durch Anmerkungen gesteuert, die dem Kubernetes Service-Manifest hinzugefügt werden müssen. Die Anmerkungen, die vom Service Controller und vom AWS Load Balancer Controller verwendet werden, sind unterschiedlich.

Der Service Controller ist veraltet und erhält derzeit nur kritische Bugfixes. Wenn Sie einen Kubernetes-Service des Typs erstellen LoadBalancer, erstellt der Service Controller standardmäßig einen AWS-CLB, kann aber auch AWS-NLB erstellen, wenn Sie die richtige Anmerkung verwenden. Es ist erwähnenswert, dass Service Controller keine Kubernetes Ingress-Ressourcen unterstützt und auch IPv6 nicht unterstützt.

Wir empfehlen, den AWS Load Balancer Controller in Ihren EKS-Clustern zu verwenden, um Kubernetes Service- und Ingress-Ressourcen abzugleichen. Sie müssen die richtigen Anmerkungen in Ihrem Kubernetes Service- oder Ingress-Manifest verwenden, damit AWS Load Balancer Controller den Abgleichprozess übernimmt. (anstelle von Service Controller)

Wenn Sie den EKS-Auto-Modus verwenden, wird Ihnen der AWS Load Balancer Controller automatisch zur Verfügung gestellt; eine Installation ist nicht erforderlich.

Wählen Sie Load Balancer Target-Type

Registrieren Sie Pods als Ziele mithilfe von IP Target-Type

Ein AWS Elastic Load Balancer: Network & Application sendet empfangenen Datenverkehr an registrierte Ziele in einer Zielgruppe. Für einen EKS-Cluster gibt es zwei Arten von Zielen, die Sie in der Zielgruppe registrieren können: Instance und IP. Welcher Zieltyp verwendet wird, hat Auswirkungen darauf, was registriert wird und wie der Datenverkehr vom Load Balancer zum Pod weitergeleitet wird. Standardmäßig registriert der AWS Load Balancer-Controller Ziele mit dem Typ „Instance“, und dieses Ziel ist die IP des Worker Nodes. Dies beinhaltet NodePort folgende Implikationen:

Wenn Sie den Zieltyp dagegen wie von uns empfohlen als „IP“ konfigurieren, hat das folgende Auswirkungen:

Um ein AWS Elastic Load Balancing zu erstellen, das IP-Ziele verwendet, fügen Sie Folgendes hinzu:

Konfiguration von Load Balancer-Integritätsprüfungen

Kubernetes bietet zwar seine eigenen Mechanismen zur Zustandsprüfung (weitere Informationen finden Sie im nächsten Abschnitt), wir empfehlen jedoch, ELB-Zustandsprüfungen als ergänzenden Schutz zu implementieren, der außerhalb der Kubernetes-Steuerungsebene funktioniert. Diese unabhängige Ebene überwacht Ihre Anwendung weiterhin, auch wenn:

Für kritische Workloads, die in den oben genannten Szenarien maximale Verfügbarkeit und beschleunigte Wiederherstellung erfordern, bieten ELB-Health-Checks ein unverzichtbares Sicherheitsnetz, das parallel zu den nativen Mechanismen von Kubernetes funktioniert und diese nicht ersetzt.

Um Zustandsprüfungen auf Ihrem ELB zu konfigurieren und zu optimieren, müssen Sie Anmerkungen in Ihrem Kubernetes-Service- oder Ingress-Manifest verwenden, die von Service Controller oder AWS Load Balancer Controller abgeglichen würden.

Verfügbarkeit und Pod-Lebenszyklus

Während eines Anwendungsupgrades müssen Sie sicherstellen, dass Ihre Anwendung immer verfügbar ist, um Anfragen zu verarbeiten, damit es bei Benutzern nicht zu Ausfallzeiten kommt. Eine häufige Herausforderung in diesem Szenario ist die Synchronisierung des Verfügbarkeitsstatus Ihrer Workloads zwischen der Kubernetes-Ebene und der Infrastruktur, beispielsweise externen Load Balancern. In den nächsten Abschnitten werden die bewährten Methoden zur Bewältigung solcher Szenarien vorgestellt.

Verwenden Sie Gesundheitschecks

Kubernetes führt standardmäßig die Prozessintegritätsprüfung durch, bei der der Kubelet-Prozess auf dem Knoten überprüft, ob der Hauptprozess des Containers läuft oder nicht. Wenn nicht, wird dieser Container standardmäßig neu gestartet. Sie können Kubernetes-Tests jedoch auch so konfigurieren, dass sie erkennen, wann ein Container-Prozess läuft, sich aber in einem Deadlock-Zustand befindet, oder ob eine Anwendung erfolgreich gestartet wurde oder nicht. Sonden können auf den Mechanismen Exec, Grpc, HttpGet und TCPSocket basieren. https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#probe-check-methods Je nach Typ und Ergebnis der Sonde kann der Container neu gestartet werden.

Weitere Informationen zur Abfolge der Ereignisse im Pod-Erstellungsprozess finden Sie im Abschnitt „Pod-Erstellung“ im Anhang unten.

Verwenden Sie Bereitschaftstests

Wenn alle Container in einem Pod laufen, wird der Pod-Zustand standardmäßig als „Bereit“ betrachtet. Die Anwendung ist jedoch möglicherweise immer noch nicht in der Lage, Kundenanfragen zu verarbeiten. Beispielsweise muss die Anwendung möglicherweise einige Daten oder Konfigurationen von einer externen Ressource abrufen, um Anfragen verarbeiten zu können. In einem solchen Zustand möchten Sie die Anwendung weder beenden noch Anfragen an sie weiterleiten. https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probesMit der Bereitschaftsprüfung können Sie sicherstellen, dass der Pod nicht als „Bereit“ eingestuft wird. Das bedeutet, dass er dem EndpointSlice Objekt erst hinzugefügt wird, wenn das Ergebnis der Prüfung vorliegtsuccess. Fällt die Sonde im weiteren Verlauf der Leitung jedoch aus, wird der Pod aus dem EndpointSlice Objekt entfernt. Sie können im Pod-Manifest für jeden Container eine Bereitschaftsprüfung konfigurieren. kubeletEin Prozess auf jedem Knoten führt den Bereitschaftstest für die Container auf diesem Knoten aus.

Verwenden Sie Pod Readiness Gates

Ein Aspekt der Bereitschaftsprüfung ist die Tatsache, dass sie keinen externen feedback/influence Mechanismus enthält. Der Kubelet-Prozess auf dem Knoten führt die Sonde aus und definiert den Status der Sonde. Dies hat keine Auswirkungen auf die Anfragen zwischen den Microservices selbst auf der Kubernetes-Ebene (Ost-West-Traffic), da der EndpointSlice Controller die Liste der Endpunkte (Pods) immer auf dem neuesten Stand hält. Warum und wann bräuchtest du dann einen externen Mechanismus?

Wenn Sie Ihre Anwendungen mithilfe von Kubernetes Service vom Typ Load Balancer oder Kubernetes Ingress (für Nord-Süd-Verkehr) verfügbar machen, muss die Liste der Pod-IPs für den jeweiligen Kubernetes Service an den externen Infrastruktur-Load Balancer weitergegeben werden, sodass der Load Balancer auch über aktuelle Listenziele verfügt. AWS Load Balancer Controller schließt hier die Lücke. Wenn Sie AWS Load Balancer Controller und Leverage verwendentarget group: IP, erhält auch kube-proxy der AWS Load Balancer Controller ein Update (viawatch) und kommuniziert dann mit der ELB-API, um die Pod-IP zu konfigurieren und mit der Registrierung als Ziel auf dem ELB zu beginnen.

Wenn Sie eine Bereitstellung fortlaufend aktualisieren, werden neue Pods erstellt, und sobald der Zustand eines neuen Pods „Bereit“ ist, wird ein old/existing Pod beendet. Während dieses Vorgangs wird das EndpointSlice Kubernetes-Objekt schneller aktualisiert als die Zeit, die der ELB benötigt, um die neuen Pods als Ziele zu registrieren, siehe Zielregistrierung. Für kurze Zeit könnte es zu einem Statuskonflikt zwischen der Kubernetes-Ebene und der Infrastrukturebene kommen, wodurch Client-Anfragen gelöscht werden könnten. Während dieser Zeit wären innerhalb der Kubernetes-Ebene neue Pods bereit, Anfragen zu verarbeiten, aber aus ELB-Sicht sind sie das nicht.

Pod Readiness Gates ermöglicht es Ihnen, zusätzliche Anforderungen zu definieren, die erfüllt sein müssen, bevor die Pod-Bedingung als „Bereit“ betrachtet wird. Im Fall von AWS ELB überwacht der AWS Load Balancer Controller den Status des Ziels (des Pods) auf dem AWS ELB. Sobald die Zielregistrierung abgeschlossen ist und der Status auf „Gesund“ wechselt, aktualisiert der Controller den Zustand des Pods auf „Bereit“. Bei diesem Ansatz beeinflussen Sie den Zustand des Pods auf der Grundlage des Status des externen Netzwerks, der dem Zielstatus auf dem AWS ELB entspricht. Pod Readiness Gates ist in fortlaufenden Aktualisierungsszenarien von entscheidender Bedeutung, da Sie so verhindern können, dass bei der fortlaufenden Aktualisierung einer Bereitstellung alte Pods beendet werden, bis die neu erstellten Pods auf dem AWS-ELB den Zielstatus „Fehlerfrei“ annehmen.

Ordnungsgemäßes Herunterfahren von Anwendungen

Ihre Anwendung sollte auf ein SIGTERM-Signal reagieren und den ordnungsgemäßen Shutdown starten, damit es bei den Clients nicht zu Ausfallzeiten kommt. Das bedeutet, dass Ihre Anwendung Bereinigungsprozeduren wie das Speichern von Daten, das Schließen von Dateideskriptoren, das Schließen der Datenbankverbindungen, das reibungslose Abschließen von Anfragen während des Fluges und das Beenden des Pods rechtzeitig beenden sollte. Sie sollten die Kulanzzeit so lang einstellen, dass die Bereinigung abgeschlossen werden kann. Informationen zur Reaktion auf das SIGTERM-Signal finden Sie in den Ressourcen der jeweiligen Programmiersprache, die Sie für Ihre Anwendung verwenden.

Wenn Ihre Anwendung nach Erhalt eines SIGTERM-Signals nicht ordnungsgemäß heruntergefahren werden kann oder wenn sie das Signal ignores/does nicht empfängt, können Sie stattdessen den PreStop Hook nutzen, um ein ordnungsgemäßes Herunterfahren der Anwendung einzuleiten. Der Prestop-Hook wird unmittelbar vor dem Senden des SIGTERM-Signals ausgeführt und kann beliebige Operationen ausführen, ohne dass diese Operationen im Anwendungscode selbst implementiert werden müssen.

Die gesamte Abfolge der Ereignisse ist in der folgenden Abbildung dargestellt. Hinweis: Unabhängig vom Ergebnis des ordnungsgemäßen Herunterfahrens der Anwendung oder dem Ergebnis des PreStop Hooks werden die Anwendungscontainer schließlich am Ende der Kulanzperiode über SIGKILL beendet.

Weitere Informationen zur Abfolge der Ereignisse beim Pod-Löschvorgang finden Sie im Abschnitt zum Löschen von Pods im Anhang weiter unten.

Behandeln Sie die Kundenanfragen ordnungsgemäß

Die Reihenfolge der Ereignisse beim Löschen von Pods unterscheidet sich von der Pod-Erstellung. Wenn ein Pod erstellt wird, wird die Pod-IP in der Kubernetes-API kubelet aktualisiert, und erst dann wird das EndpointSlice Objekt aktualisiert. Wenn andererseits ein Pod beendet wird, benachrichtigt die Kubernetes-API sowohl das Kubelet als auch den Controller gleichzeitig. EndpointSlice Untersuchen Sie sorgfältig das folgende Diagramm, das die Abfolge der Ereignisse zeigt.

Die Art und Weise, wie sich der Status vom API-Server bis hin zu den oben erläuterten Iptables-Regeln auf den Knoten ausbreitet, schafft eine interessante Rennbedingung. Weil die Wahrscheinlichkeit hoch ist, dass der Container das SIGKILL-Signal viel früher empfängt als der Kube-Proxy auf jedem Knoten die lokalen Iptables-Regeln aktualisiert. In einem solchen Fall sind zwei erwähnenswerte Szenarien zu nennen:

Wenn Sie die Kulanzzeit in der Pod-Spezifikation lang genug festlegen, kann dieses Problem gelöst werden. Abhängig von der Übertragungsverzögerung und der Anzahl der tatsächlichen Client-Anfragen ist es jedoch schwierig, die Zeit vorherzusagen, die die Anwendung benötigt, um die Verbindungen ordnungsgemäß zu schließen. Daher ist der nicht so perfekte, aber praktikabelste Ansatz hier, einen PreStop Hook zu verwenden, um das SIGTERM-Signal zu verzögern, bis die iptables-Regeln aktualisiert sind, um sicherzustellen, dass keine neuen Client-Anfragen an die Anwendung gesendet werden, sondern nur bestehende Verbindungen weiterlaufen. PreStop Hook kann ein einfacher Exec-Handler sein wie. sleep 10

Das oben genannte Verhalten und die Empfehlung gelten gleichermaßen, wenn Sie Ihre Anwendungen mit Load Balancer vom Typ Kubernetes Service oder Kubernetes Ingress (für Nord-Süd-Verkehr) mithilfe von AWS Load Balancer Controller und Leverage bereitstellen. target group: IP Denn genau wie kube-proxy der AWS Load Balancer Controller erhält auch der Controller ein Update (per Watch) für das EndpointSlice Objekt und kommuniziert dann mit der ELB-API, um mit der Abmeldung der Pod-IP vom ELB zu beginnen. Je nach Auslastung der Kubernetes-API oder der ELB-API kann dies jedoch auch einige Zeit dauern, und der SIGTERM wurde möglicherweise schon vor langer Zeit an die Anwendung gesendet. Sobald der ELB mit der Abmeldung des Ziels beginnt, hört er auf, Anfragen an dieses Ziel zu senden, sodass die Anwendung keine neuen Anfragen erhält. Außerdem beginnt der ELB mit einer Verzögerung bei der Abmeldung, die standardmäßig 300 Sekunden beträgt. Während des Abmeldevorgangs ist das Ziel der draining Ort, an dem der ELB im Grunde darauf wartet, dass die Verbindungen zu diesem Ziel während des requests/existing Fluges leer sind. Sobald die Verzögerung bei der Abmeldung abgelaufen ist, wird das Ziel nicht genutzt und alle Anfragen an dieses Ziel während des Fluges werden zwangsweise gelöscht.

Verwenden Sie das Budget für Pod-Unterbrechungen

Konfigurieren Sie ein Pod Disruption Budget (PDB) für Ihre Anwendungen. PDB begrenzt die Anzahl der Pods einer replizierten Anwendung, die aufgrund von freiwilligen Unterbrechungen gleichzeitig ausgefallen sind. https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#voluntary-and-involuntary-disruptions Es stellt sicher, dass eine Mindestanzahl oder ein Prozentsatz von Pods in einem oder Deployment verfügbar bleiben. StatefulSet Beispielsweise muss eine quorumbasierte Anwendung sicherstellen, dass die Anzahl der ausgeführten Replikate niemals unter die für ein Quorum erforderliche Anzahl sinkt. Oder ein Web-Frontend könnte sicherstellen, dass die Anzahl der Replikate, die die Last verarbeiten, niemals unter einen bestimmten Prozentsatz der Gesamtzahl fällt. PDB schützt die Anwendung vor Aktionen wie dem Löschen von Knoten oder der Einführung neuer Versionen von Deployments. Beachten Sie, dass PDBs die Anwendung nicht vor ungewollten Unterbrechungen wie einem Ausfall des Node-Betriebssystems oder dem Verlust der Netzwerkkonnektivität schützen. Weitere Informationen finden Sie in der Dokumentation zur Festlegung eines Störungsbudgets für Ihre Anwendung in der Kubernetes-Dokumentation.

Referenzen

Anhang

Erstellung von Pods

Es ist unerlässlich, die Abfolge der Ereignisse in einem Szenario zu verstehen, in dem ein Pod bereitgestellt wird healthy/ready und dann Kundenanfragen entgegennimmt und verarbeitet. Lassen Sie uns über die Abfolge der Ereignisse sprechen.

Pod löschen

Genau wie bei der Pod-Erstellung ist es unerlässlich, die Reihenfolge der Ereignisse beim Löschen von Pods zu verstehen. Lassen Sie uns über die Abfolge der Ereignisse sprechen.