Einführung in Network Load Balancer
Erfahren Sie, wie Network Load Balancer eine automatisierte Trafficverteilung von einem Einstiegspunkt auf mehrere Server in einem Backend-Set bereitstellen können.
Betriebsmodi
Network Load Balancer ist ein Load Balancing-Service, der auf Layer 3 und Layer 4 des Open Systems Interconnection-(OSI-)Modells ausgeführt wird. Dieser Service bietet die Vorteile von High Availability und bietet hohen Durchsatz bei gleichzeitig extrem niedriger Latenz. Sie haben drei Modi im Network Load Balancer, in denen Sie arbeiten können:
- NAT-(Full Network Address Translation-)Modus: Network Load Balancer übersetzt sowohl die Quell-IP-Adresse als auch die Ziel-IP-Adresse des Pakets, bevor er sie an das Backend sendet.
- Quellbeibehaltung-Modus: Network Load Balancer führt eine Ziel-NAT vom Network Load Balancer Listener (VIP) zur IP-Adresse des Backend-Servers durch. Die ursprünglichen IP-Adressen/Portinformationen der Quelle werden jedoch beibehalten, bevor sie an den Backend-Server gesendet werden.
- Transparenter Modus (Quell-/Zielbeibehaltung): Network Load Balancer ändert keine Informationen im Paket. Dieser Modus leitet die Pakete an die Backend-Server weiter und arbeitet effektiv als "Bump-in-the-Wire". In diesem Modus muss der Traffic mit einem VCN-Routingtabelleneintrag durch diesen geleitet werden.
In der folgenden Tabelle werden Fragen zu den Betriebsmodi des Network Load Balancers beantwortet.
| Modus | Andere Namen | Wo aktiviert? | Verwendet Clienttraffic den Listener? | Unterstützung für Public Network Load Balancer? | Unterstützung für private Network Load Balancer? |
|---|---|---|---|---|---|
| Vollständige NAT | Keine | Aktiviert, indem die beiden Modi "Beibehaltung des Quellheaders" und "Beibehaltung des Quellheaders/Zielheaders" deaktiviert werden. | Ja | Ja | Ja |
| Quellheader (IP/Port) beibehalten |
|
Wird über die Backend-Setkonfiguration (Erstellen oder Bearbeiten) aktiviert. | Ja | Ja | Ja |
| Quell-/Zielheader (IP/Port) beibehalten |
|
Wird auf der Seite "Network Load Balancer-Details" aktiviert. | Nr. | Nr. | Ja |
Network Load Balancer-Typen
Mit dem Flexible Network Load Balancer-Service können Sie einen öffentlichen oder privaten Network Load Balancer in Ihrem VCN erstellen. Ein öffentlicher Network Load Balancer hat eine öffentliche IP-Adresse, auf die über das Internet zugegriffen werden kann. Ein privater Network Load Balancer verfügt über eine IP-Adresse aus dem Hostsubnetz, die nur in Ihrem VCN sichtbar ist. Sie können mehrere Listener für eine IP-Adresse konfigurieren, um den Traffic auf Layer 4 (TCP/UDP/ICMP) zu verteilen. Öffentliche und private Load Balancer können Datentraffic an jeden Backend-Server im VCN weiterleiten.
Öffentlicher Network Load Balancer
Um Traffic aus dem Internet zuzulassen, erstellen Sie einen öffentlichen Network Load Balancer. Der Service weist dem Network Load Balancer eine öffentliche IP-Adresse zu, die als Einstiegspunkt für eingehenden Traffic dient. Verknüpfen Sie die öffentliche IP-Adresse über einen beliebigen DNS-Anbieter mit einem DNS-Anzeigenamen.
Ein öffentlicher Network Load Balancer kann regional oder Availability-Domain-spezifisch sein. Dieser Geltungsbereich wird vom Subnetz, in dem der Network Load Balancer erstellt wird, bestimmt. Ein öffentlicher Network Load Balancer, der in einem regionalen Subnetz erstellt wird, hat einen regionalen Geltungsbereich. Ein öffentlicher Network Load Balancer, der in einem Availability-Domain-spezifischen Subnetz erstellt wird, hat einen Availability-Domain-spezifischen Geltungsbereich. Network Load Balancer stellt High Availability und Zugänglichkeit sicher, selbst wenn eine der Availability-Domains ausfällt.
Sie können kein privates Subnetz für den öffentlichen Load Balancer angeben. Weitere Informationen finden Sie unter Öffentliche und private Subnetze im Vergleich.
Privater Network Load Balancer
Um den Network Load Balancer vom Internet zu isolieren und Ihre Sicherheitsstatusanforderungen zu vereinfachen, erstellen Sie einen privaten Network Load Balancer. Der Network Load Balancer weist diesem eine private IP-Adresse zu, die als Einstiegspunkt für eingehenden Traffic dient. Auf den Network Load Balancer kann nur über das jeweilige VCN zugegriffen werden, das das regionale Hostsubnetz enthält. Der Zugriff kann durch Ihre Sicherheitsregeln weiter eingeschränkt werden.
Ein privater Network Load Balancer kann regional oder Availability-Domainspezifisch sein. Dieser Geltungsbereich wird vom Subnetz, in dem der Network Load Balancer erstellt wird, bestimmt.
Erreichbarkeit der Network Load Balancer
Der Network Load Balancer reagiert nicht direkt auf ein Client-ICMP- oder TCP/UDP-Ping-Paket. Stattdessen leitet der Network Load Balancer das Paket gemäß der Load Balancing Policy an einen Backend-Server weiter. Der Backend-Server gibt dann eine Antwort an den Client zurück.
Nur private Network Load Balancer unterstützen das ICMP-Protokoll. Für den Network Load Balancer muss auch das Feature "Quell-/Zielheader (IP, Port) beibehalten" aktiviert sein. Wenn dieses Feature nicht aktiviert ist oder Sie einen öffentlichen Network Load Balancer verwenden, können Sie die Erreichbarkeit des Network Load Balancer über verfügbare Listener-Protokolle (TCP/UDP) prüfen.
Private Network Load Balancer mit VCN-Transitrouting als Routingziel für den nächsten Hop verwenden
Verwenden Sie mit VCN-Transitrouting einen privaten Network Load Balancer als privates IP-Routingziel für den nächsten Hop. Mit dieser Methode kann der Network Load Balancer als transparenter Bump-in-the-Wire-Load Balancer auf Layer 3 fungieren, an den Pakete entlang des Pfades zu ihrem endgültigen Ziel weitergeleitet werden. Transitrouting bezieht sich auf eine Netzwerktopologie, bei der Ihr On-Premise-Netzwerk über ein verbundenes virtuelles Cloud-Netzwerk (VCN) auf Oracle-Ressourcen oder -Services außerhalb dieses VCN zugreift. Verbinden Sie das On-Premise-Netzwerk über FastConnect oder Site-to-Site-VPN mit dem VCN, und konfigurieren Sie dann das VCN-Routing so, dass Traffic über das VCN an sein Ziel außerhalb des VCN übertragen wird. Weitere Informationen finden Sie unter Transitrouting in einem Hub-VCN.
Der Network Load Balancer leitet den Benutzertraffic über VCN-Routentabellen an die Firewallinstanzen weiter, die hinter dem Network Load Balancer im Hub-VCN gehostet werden. Dieser Benutzertraffic würde andernfalls von der Quelle direkt zum Ziel geleitet. In diesem Modus ändert der Network Load Balancer keine Eigenschaften des Clientpakets. Stattdessen behält er die Quell- und Ziel-IP-Headerinformationen bei. Mit dieser Methode können die Firewall-Appliances das ursprüngliche Clientpaket prüfen und Sicherheits-Policys anwenden, bevor sie es an die Anwendungs-Backend-Server in den Spoke-VCNs weiterleiten.
Im Folgenden wird die Network Load Balancer-Architektur dargestellt.
|
Ziel |
Ziel |
|---|---|
|
10.0.0.0/24 |
Flex-NLB VIP IP |
|
10.1.0.0/24 |
Flex-NLB VIP IP |
|
Ziel |
Ziel |
|---|---|
|
172.16.0.0/16 |
DRG |
|
Ziel |
Ziel |
|---|---|
|
0.0.0.0/0 |
IGW |
|
Ziel |
Ziel |
|---|---|
|
10.0.0.0/24 |
Hub Web LPG |
|
10.1.0.0/24 |
Hub DB LPG |
|
Ziel |
Ziel |
|---|---|
|
0.0.0.0/0 |
FW vertrauenswürdige Int IP |
Alle Network Load Balancer
Der Network Load Balancer verfügt über ein Backend-Set, um eingehenden Traffic an Ihre Compute-Instanzen weiterzuleiten. Das Backend-Set ist eine logische Entity, die Folgendes umfasst:
- Eine Liste der Backend-Server
- Eine Load Balancing Policy
- Eine Health Check Policy
Die mit einem Backend-Set verknüpften Backend-Server (Compute-Instanzen) können überall vorhanden sein, solange die zugehörigen Netzwerksicherheitsgruppen (NSGs), Sicherheitslisten und Routentabellen den beabsichtigten Trafficfluss zulassen.
Wenn Ihr VCN Netzwerksicherheitsgruppen (NSG) verwendet, können Sie den Load Balancer mit einer NSG verknüpfen. Eine NSG enthält ein Set von Sicherheitsregeln, die die zulässigen Typen von ein- und ausgehendem Traffic steuern. Die Regeln gelten nur für die Ressourcen in der Gruppe. Im Gegensatz dazu gelten die Regeln einer Sicherheitsliste für alle Ressourcen in jedem Subnetz, das die Liste verwendet. Weitere Informationen zu NSGs finden Sie unter Netzwerksicherheitsgruppen.
Wenn Sie vorzugsweise Sicherheitslisten für Ihr VCN verwenden, kann der Load Balancing-Service geeignete Sicherheitslistenregeln vorschlagen. Sie können diese auch selbst über den Networking-Service konfigurieren. Weitere Informationen finden Sie unter Sicherheitslisten. Ausführliche Informationen zum Vergleich von NSGs und Sicherheitslisten finden Sie unter Sicherheitsregeln.
Wir empfehlen, die Backend-Server auf alle Availability-Domains in der Region zu verteilen.
Nutzung privater IP-Adressen
Ein öffentlicher Network Load Balancer, der in einem öffentlichen Subnetz erstellt wird, nutzt eine private IP-Adresse aus dem Hostsubnetz.
Ein privater Network Load Balancer, der in einem einzelnen Subnetz erstellt wird, nutzt eine private IP-Adresse aus dem Hostsubnetz.
Network Load Balancer-Konzepte
- BACKEND-SERVER
- Anwendungsserver, der Inhalt als Antwort auf den eingehenden Clienttraffic generiert. Anwendungsserver werden in der Regel mit einer eindeutigen Kombination aus (privater) Overlay-IPv4-Adresse und Port identifiziert. Beispiel: 10.10.10.1:8080 und 10.10.10.2:8080. Weitere Informationen finden Sie unter Backend-Server für Network Load Balancer.Hinweis
Der Backend-Server kann nicht gleichzeitig als Client und Backend funktionieren, da er keinen Traffic zur virtuellen IP (VIP) des Network Load Balancer starten kann. - BACKEND-SET
- Eine logische Entity, die durch eine Liste von Backend-Servern, eine Load Balancing Policy und eine Health Check Policy definiert ist. Das Backend-Set legt fest, wie der Network Load Balancer Traffic an die Backend-Server verteilt. Weitere Informationen finden Sie unter Backend-Sets für Network Load Balancer.
- HEALTH CHECK
-
Ein Health Check ist ein Test, mit dem die Verfügbarkeit von Backend-Servern bestätigt wird. Bei einem Health Check kann es sich um eine Anforderung oder einen Verbindungsversuch handeln. Basierend auf einem von Ihnen angegebenen Zeitintervall wendet der Load Balancer die Health Check Policy an, um Backend-Server kontinuierlich zu überwachen. Wenn ein Server die Health-Check-Bedingungen nicht erfüllt, nimmt der Load Balancer den Server vorübergehend aus der Rotation. Sobald der Server die Health-Check-Bedingungen erfüllt, lässt ihn der Load Balancer wieder zurück in die Rotation.
Sie konfigurieren die Health Check Policy, wenn Sie ein Backend-Set erstellen. Sie können Health Checks auf TCP-, UDP- oder HTTP-Ebene für die Backend-Server konfigurieren.
- Bei Health Checks auf TCP-Ebene wird versucht, eine TCP-Verbindung mit den Backend-Servern herzustellen. Die Antwort wird anhand des Verbindungsstatus validiert.
- Bei Health Checks auf UDP-Ebene wird versucht, eine UDP-Verbindung mit den Backend-Servern herzustellen. Die Antwort wird anhand des Verbindungsstatus validiert.
- Bei Health Checks auf HTTP-Ebene werden Anforderungen über eine bestimmte URI an die Backend-Server gesendet. Die Reaktion wird anhand des Statuscodes oder der zurückgegebenen Entitydaten (Hauptteil) validiert.
Der Service stellt anwendungsspezifische Health-Check-Funktionen zur Verfügung, mit denen Sie die Verfügbarkeit erhöhen und das Wartungsfenster der Anwendung reduzieren können. Weitere Informationen zur Konfiguration eines Health Checks finden Sie unter Health Check Policys für Network Load Balancer.
- ZUSTAND
- Indikator, der den allgemeinen Zustand der Network Load Balancer und ihrer Komponenten angibt. Weitere Informationen finden Sie unter Zustand von Network Load Balancern.
- LISTENER
- Eine logische Entity, die die IP-Adresse des Network Load Balancers auf eingehenden Traffic prüft. Sie konfigurieren ein Protokoll und eine Portnummer für den Listener. Unterstützte Protokolle:
- UDP
- TCP
- UDP/TCP
- TCP/UDP/ICMP (nur privat)
- L3-IP
Hinweis
Private Network Load Balancer unterstützen das ICMP-Protokoll nur, wenn das Feature "Quell-/Zielheader (IP, Port) beibehalten" aktiviert ist. Weitere Informationen finden Sie unter Beibehalten von Backend-Setquellen in Network Load Balancer aktivieren. Weitere Informationen finden Sie unter Listener für Network Load Balancer.
- Network Load Balancing Policy
- Eine Network Load Balancing Policy gibt dem Network Load Balancer Anweisungen, wie der eingehende Traffic auf die Backend-Server verteilt werden soll. Gängige Load Balancer Policys:
- 5-Tupel-Hash
- 3-Tupel-Hash
- 2-Tupel-Hash
- Regionen und Availability-Domains
- Der Network Load Balancer-Service verwaltet Anwendungstraffic für alle Availability-Domains in einer Region . Eine Region ist ein bestimmter geografischer Bereich. Eine Availability-Domain umfasst mindestens ein Data Center innerhalb einer Region. Eine Region besteht aus mehreren Availability-Domains. Weitere Informationen finden Sie unter Regionen und Availability-Domains.
- SUBNETZ
- Eine Unterteilung, die Sie in einem virtuellen Cloud-Netzwerk (VCN) definieren, wie 10.0.0.0/24 und 10.0.1.0/24. Ein Subnetz besteht aus einem Bereich zusammenhängender IP-Adressen, die sich nicht mit anderen Subnetzen im VCN überschneiden. Sie geben für jedes Subnetz die jeweils geltenden Routing- und Sicherheitsregeln an. Weitere Informationen zu Subnetzen finden Sie unter VCN- und Subnetzverwaltung und Öffentliche IP-Adressenbereiche.
- TAGS
-
Sie können Ihre Ressourcen mit Tags versehen, um sie entsprechend Ihren Geschäftsanforderungen zu organisieren. Sie können Tags beim Erstellen einer Ressource zuweisen oder die Ressource später mit den gewünschten Tags aktualisieren. Allgemeine Informationen zum Zuweisen von Tags finden Sie unter Ressourcentags.
- Virtuelles Cloud-Netzwerk (VCN)
- Ein privates Netzwerk, das Sie in den Oracle-Data Centern mit Firewallregeln und spezifische Typen von Kommunikationsgateways einrichten können. Ein VCN deckt einen einzelnen, zusammenhängenden IPv4-CIDR-Block Ihrer Wahl in den zulässigen IP-Adressbereichen ab. Sie benötigen mindestens ein virtuelles Cloud-Netzwerk, bevor Sie einen Network Load Balancer starten können. Informationen zur Einrichtung virtueller Cloud-Netzwerke finden Sie unter Networking - Überblick.
- SICHTBARKEIT
- Gibt an, ob der Network Load Balancer öffentlich oder privat ist.
- ARBEITSANFORDERUNG
- Objekt, das den aktuellen Status einer Network Load Balancer-Anforderung meldet. Der Network Load Balancer verarbeitet Anforderungen asynchron. Jede Anforderung gibt eine Arbeitsanforderungs-ID (OCID) als Antwort zurück. Sie können das Arbeitsanforderungselement anzeigen, um den Status der Anforderung zu ermitteln. Weitere Informationen finden Sie unter Arbeitsanforderungen für Network Load Balancer.
Ressourcen-IDs
Die meisten Oracle Cloud Infrastructure-Ressourcentypen verfügen über eine eindeutige, von Oracle zugewiesene ID, die als Oracle Cloud-ID (OCID) bezeichnet wird. Informationen zum OCID-Format und zu weiteren Möglichkeiten zur Identifizierung Ihrer Ressourcen finden Sie unter Ressourcen-IDs.
Möglichkeiten für den Zugriff auf Oracle Cloud Infrastructure
Auf Oracle Cloud Infrastructure (OCI) können Sie über die Konsole (eine browserbasierte Schnittstelle), die REST-API oder die OCI-CLI zugreifen. Anweisungen zur Verwendung der Konsole, der API und der Befehlszeilenschnittstelle (CLI) sind in verschiedenen Themen in dieser Dokumentation enthalten. Eine Liste der verfügbaren SDKs finden Sie unter Software Development Kits und Befehlszeilenschnittstelle.
Ressourcen überwachen
Mit Metriken, Alarmen und Benachrichtigungen können Sie den Zustand, die Kapazität und die Performance von Oracle Cloud Infrastructure-Ressourcen überwachen. Weitere Informationen finden Sie unter Monitoring und Notifications.
Informationen zum Monitoring des Traffics, der durch den Network Load Balancer geleitet wird, finden Sie unter Network Load Balancer-Metriken.
Authentifizierung und Autorisierung
Jeder Service in Oracle Cloud Infrastructure kann zur Authentifizierung und Autorisierung für alle Schnittstellen (Konsole, SDK oder CLI und REST-API) in IAM integriert werden.
Ein Administrator in einer Organisation muss Gruppen , Compartments und Policys einrichten, die den Zugriffstyp sowie den Zugriff der Benutzer auf Services und Ressourcen steuern. Beispiel: Die Policys steuern, wer neue Benutzer erstellen, das Cloud-Netzwerk erstellen und verwalten, Instanzen erstellen, Buckets erstellen, Objekte herunterladen kann usw. Weitere Informationen finden Sie unter Identitätsdomains verwalten. Einzelheiten zum Schreiben von Policys für die einzelnen Services finden Sie in der Policy-Referenz.
Wenn Sie ein regulärer Benutzer sind (nicht ein Administrator), der die Oracle Cloud Infrastructure-Ressourcen verwenden muss, für die das Unternehmen verantwortlich ist, bitten Sie einen Administrator, eine Benutzer-ID für Sie einzurichten. Der Administrator kann festlegen, welche Compartments Sie verwenden können.
Limits für Network Load Balancer
Für jeden Load Balancer gelten die folgenden Konfigurationslimits:
- Eine IPv4-Adresse und eine IPv6-Adresse
- 50 Backend-Sets
- 512 Backend-Server pro Backend-Set
- 1.024 Backend-Server insgesamt
- 50 Listener
- Standardlimit von 330.000 nebenläufigen Verbindungen pro Availability-Domain
Eine Liste der jeweiligen Limits sowie Anweisungen dazu, wie Sie eine Erhöhung beantragen, finden Sie in den Servicelimits.
Erforderliche IAM-Policys
Um Oracle Cloud Infrastructure verwenden zu können, muss ein Administrator Mitglied einer Gruppe sein, der von einem Mandantenadministrator Sicherheitszugriff in einer Policy erteilt wurde. Dieser Zugriff ist unabhängig davon erforderlich, ob Sie die Konsole oder die REST-API mit einem SDK, einer CLI oder einem anderen Tool verwenden. Wenn Sie eine Nachricht erhalten, dass Sie keine Berechtigung haben oder nicht autorisiert sind, fragen Sie den Mandantenadministrator, welcher Zugriffstyp Ihnen erteilt wurde und in welchem Compartment Ihr Zugriff funktioniert.
Für Administratoren: Eine typische Policy, die Zugriff auf Load Balancer und deren Komponenten gewährt, finden Sie unter Verwalten von Load Balancern durch Netzwerkadministratoren zulassen.
Beachten Sie außerdem, dass eine Policy-Anweisung mit inspect load-balancers der angegebenen Gruppe die Berechtigung erteilt, alle Informationen zu den Load Balancern anzuzeigen. Weitere Informationen finden Sie unter Details zu Load Balancing.
Wenn Sie sich nicht mit Policys auskennen, finden Sie weitere Informationen unter Erste Schritte mit Policys und Allgemeine Policys.
Network Load Balancer Policys
Nach dem Erstellen eines Network Load Balancers können Sie Policys anwenden, um die Trafficverteilung auf die Backend-Server zu steuern. Siehe Network Load Balancer erstellen.
Der Network Load Balancer-Service unterstützt drei primäre Typen von Network Load Balancer Policys:
- 5-Tupel-Hash: Leitet eingehenden Traffic basierend auf dem 5-Tupel-Hash (Quell-IP und Quellport, Ziel-IP und Zielport, Protokoll) weiter. Dies ist die Standard-Policy für Network Load Balancer.Hinweis
Wenn das IP-Listener-Protokoll L3 ausgewählt ist, unterstützt der Load Balancer keine 5-Tupel-Hash-Policys. - 3-Tupel-Hash: Leitet eingehenden Traffic basierend auf dem 3-Tupel-Hash (Quell-IP, Ziel-IP, Protokoll) weiter.
- 2-Tupel-Hash: Leitet eingehenden Traffic basierend auf dem 2-Tupel-Hash (Quell-IP, Ziel-IP) weiter.
Die 5-Tupel-Hash-Policy stellt die Sessionaffinität innerhalb einer bestimmten TCP- oder UDP-Session bereit, bei der Pakete in derselben Session an denselben Backend-Server hinter dem Flexible Network Load Balancer geleitet werden. Verwenden Sie eine 3-Tupel- oder 2-Tupel-Network Load Balancing Policy, um die Sessionaffinität über die Lebensdauer einer bestimmten Session hinaus bereitzustellen.
Wenn die Verarbeitungslast oder -kapazität zwischen Backend-Servern variiert, können Sie jeden dieser Policy-Typen mit der Gewichtung von Backend-Servern verfeinern. Die Gewichtung bestimmt den Anteil der Anforderungen, die an die einzelnen Server weitergeleitet werden. Beispiel: Ein als 3 gewichteter Server empfängt dreimal so viele Verbindungen wie ein Server mit der Gewichtung 1. Sie ordnen Gewichtungen basierend auf beliebigen Kriterien zu, wie die Kapazität der einzelnen Server zum Traffic-Handling. Gewichtungswerte müssen zwischen 1 und 100 liegen.
Timeout bei Inaktivität von Verbindungen
Der Network Load Balancer verfolgt den Status aller TCP- und UDP-Datenflüsse, die ihn durchlaufen. Eine Kombination aus IP-Protokoll und Quell- und Ziel-IP-Adressen und -ports definiert einen Datenfluss. Der Datenfluss kann entfernt werden, wenn weder der Client noch der Server für einen längeren Zeitraum als der Inaktivitätstimeout Traffic empfängt. Alle TCP-Pakete, die nach dem Inaktivitätstimeout empfangen werden, werden gelöscht. Bei UDP-Datenströmen wird ein späteres Paket als neuer Datenfluss betrachtet und an einen neuen Backend-Server weitergeleitet.
Der Inaktivitätstimeout beträgt 6 Minuten für TCP-Datenflüsse und 2 Minuten für UDP-Datenflüsse. Sie können diese Zeiten beim Erstellen eines Listeners für einen Network Load Balancer und auch beim Bearbeiten eines vorhandenen Listeners anpassen. Weitere Informationen finden Sie unter Leerlaufzeit-Timeout eines Listeners ändern.
Logging
Network Load Balancing-Aktivitäten werden über die Flowlogs des virtuellen Cloud-Netzwerks (VCN) protokolliert. Weitere Informationen finden Sie unter VCN-Flowlogs.
Verschlüsselung
Der Network Load Balancer-Service ändert keinen Traffic, den er empfängt. Um also den Traffic zu sichern, der über den Network Load Balancer an die Backends gesendet wird, sind Sie für die Verschlüsselung der Anwendungen auf den Backends verantwortlich, die den Traffic empfangen. Um eine SSL-Beendigung in einen Load Balancer zu integrieren, verwenden Sie stattdessen den Load Balancer-Service.