Einheit 3.3: Lastverteilung - Layer 7 (Anwendung)

Einführung

Ein Layer-7-Lastenausgleich ist der Punkt, an dem das Netzwerk aufhört, Pakete zu versenden, und beginnt, Anfragen zu lesen. Diese Einheit regelt die Entscheidung, ob Ihr Edge die HTTP (Hosts, Pfade, Header, Methoden) gut genug verstehen muss, um darauf zu routen, oder ob es nur TCP-Verbindungen über einen Pool verteilen muss. Der IONOS Managed Application Load Balancer (ALB) ist die inhaltsbewusste Option und es ist auch der Punkt, an dem die Plattform ein Produkt ersetzt, das sie nicht verkauft, ein gemanagtes API Gateway, indem sie Routing-Regeln anstelle dessen bereitstellt. Diese Einheit beginnt bei dieser Routing-Entscheidung und ihren Zertifikats- und Kostenfolgen und endet damit, den öffentlichen ALB aufzubauen, der FinCorps Anwendungsebene im Data Center Designer vorsteht und auf dem öffentlichen Edge LAN sitzt, das in Einheit 3.1 eingerichtet wurde.

1. Wenn Layer 7 seinen Platz verdient

Das Managed Application Load Balancer verteilt den eingehenden Anwendungs-Layer-Datenverkehr auf Ziele basierend auf benutzerdefinierten Richtlinien und arbeitet auf Layer 7 des OSI-Modells. Der Netzwerk-Load Balancer (NLB), der in Einheit 3.4 behandelt wird, arbeitet auf Layer 4. Die offiziellen Richtlinien ziehen eine klare Grenze: wenn Ihre Ausgleichslogik HTTP-Anfragen und ihre Attribute verarbeiten muss, verwenden Sie den ALB; wenn die Routing-Leistung kritisch ist und die Logik auf Layer 4 bleiben kann, routen Sie TCP-Datenverkehr mit dem NLB.

Der ALB verdient seinen Platz, wenn Sie auf der Grundlage des Inhalts der Anfrage und nicht der Verbindung routen. Seine Weiterleitungsregeln unterstützen pfadbasiertes, hostname-basiertes, query-string-basiertes, header-basiertes, methodenbasiertes, cookie-basiertes, Quell-IP-basiertes, URL-Weiterleitungs- und statisches oder festes Antwort-Routing. Ein öffentlicher Einstiegspunkt kann daher /api an eine Zielgruppe und /static an eine andere senden, zwei Hostnames von einem IP bedienen oder während der Wartung eine feste 503-Antwort zurückgeben, alle Entscheidungen, auf die ein Layer-4-Lastenausgleich blind ist. Der Kompromiss besteht darin, dass jede Anfrage analysiert und gematcht wird, was der Grund ist, warum der NLB für Fälle reserviert ist, in denen diese Arbeit verschwendet wird: Ende-zu-Ende-verschlüsselten Datenverkehr, den der Lastenausgleich nicht entschlüsseln sollte, oder jedes nicht-HTTP-Protokoll. Die regulierte Anwendung von FinCorp ist HTTP-fronted, mit einem Kundenportal und einer API-Oberfläche, die einen Hostnamen und ein Zertifikat teilen, sodass Layer 7 die richtige Kante ist; die private Datenbank-Ebene bleibt auf Layer 4. Dies ist die geschichtete öffentliche-L7-zu-private-L4-Form aus Einheit 1.2.

Drei Plattform-Grenzen prägen, wie Sie den ALB sichern und dimensionieren, und alle drei sind Design-Eingaben und keine Fehler:

• Der ALB hat keine IP-Zulassung und keine Netzwerk-Sicherheitsgruppe. Wie in Einheit 3.2 festgestellt wurde, binden NSGs und NIC-Feuerwände an Server-NICs auf der VDC-Ebene und gelten nicht für die gemanagten Lastenausgleiche. Die Filterung gehört daher auf die Ziele: Firewall-Regeln auf den Backend-NICs plus Anwendungslogik, wobei die Daten-Ebene durch die Topologie unerreichbar bleibt.
• Der ALB bietet keine Quell-NAT für Ziel-Verbindungen, sodass er kein Egress-Pfad ist. Private Workloads erreichen das Internet über das NAT-Gateway in Einheit 3.6.
• IPv6 hat dokumentierte Einschränkungen für den ALB, sodass Sie den öffentlichen Listener als IPv4-Endpunkt auf einer reservierten öffentlichen IPv4-Adresse behandeln und jede IPv6-Exposition separat planen sollten.

Es gibt kein IONOS API Gateway-Produkt. Der Plattform-Ersatz ist genau der Mechanismus, den diese Einheit aufbaut: ALB-Weiterleitungsregeln tragen grobe Inhalts-Routing (Pfad- und Host-Regeln, Weiterleitungen, feste Antworten) an der Kante und ein In-Cluster-Ingress-Controller trägt feinere, anwendungsbewusste Routing innerhalb eines Kubernetes Cluster dahinter. Sie komponieren das API-Gateway-Verhalten aus einem gemanagten Lastenausgleich plus In-Cluster-Ingress anstelle der Bereitstellung eines einzelnen Gateway-Produkts.

2. Die drei erforderlichen Komponenten und die Kosten von Regeln

Jeder Application Load Balancer (ALB) benötigt mindestens einen Listener, eine Weiterleitungsregel und eine Zielgruppe. Das Verständnis dessen, was jede Komponente tut und was jede kostet, ist entscheidend, um ein schlankes Design auf Layer 7 zu erhalten.

Die folgende Tabelle fasst die drei Komponenten und ihre Rollen zusammen.

Der Standard-Lastverteilungsalgorithmus ist Round Robin; die verfügbaren Algorithmen sind Round Robin, Least Connections, Random und Quell-IP. Die pro-Ziel-Gewichtung (ein Gewicht im Bereich 1 bis 256) ermöglicht es Ihnen, die Verteilung zu beeinflussen, was der Mechanismus für eine gewichtete Canary auf Layer 7 ist.

Die Komponenten komponieren sich hierarchisch, und diese Hierarchie ist der Ort, an dem die Disziplin der Regeln wichtig ist. Ein Listener enthält Weiterleitungsregeln; eine Weiterleitungsregel enthält eine geordnete Menge von HTTP-Regeln; die Anfrage entspricht den Regeln in der Reihenfolge und fällt durch zu einer Standardaktion, wenn keine entspricht. Sie platzieren also die spezifischsten Regeln zuerst und die Fang-Regel zuletzt, mit einer klaren Standardaktion pro Listener (oft ein Weiterleiten an die primäre Zielgruppe oder eine feste Antwort).

Halten Sie die Regelmenge lean, aus Gründen, die über Klarheit hinausgehen: Regeln und Listener sind die gemanagte Oberfläche des ALB, und eine ausufernde Menge ist eine betriebliche Haftung. Ein ALB ist auf 10 Listener und ein Vertrag auf 5 ALBs begrenzt, sodass die Ressource bewusst begrenzt ist. Die Disziplin besteht darin, die Routing mit den wenigensten korrekten Regeln auszudrücken, fein granulierte Routing in die Ingress-Cluster-Eingabe zu verschieben, wohin es gehört, und Zielgruppen über Regeln hinweg wiederzuverwenden, anstatt sie zu duplizieren.

3. TLS-Beendigung und Zertifikatbeschaffung

Der ALB führt TLS-Entlastung durch: Er beendet TLS am Listener, sodass die Backend-Verbindung eine Klartext-HTTP-Verbindung sein kann. Dies ist das normale Muster der Schicht 7 und der Grund, warum das Zertifikat auf dem ALB und nicht auf den Zielen liegt. Der ALB unterstützt auch SNI, sodass ein Listener das richtige Zertifikat für mehrere Hostnamen präsentieren kann. (Wenn die Backend-Verbindung das Zertifikat behalten und der Lastenausgleich nicht entschlüsseln muss, handelt es sich um den Fall der Schicht 4 in Einheit 3.4, nicht um eine ALB-Konfiguration.)

Die Zertifikatsbeschränkungen sind spezifisch und sind der Teil, der am wahrscheinlichsten einen ersten Bereitstellungsversuch fehlschlagen lässt, daher sollte das Zertifikat bewusst beschafft werden. Der ALB erfordert genau ein Blattzertifikat (Endentitätszertifikat) und der Schlüssel muss RSA sein. Ab der Dokumentation von 2026-06 dürfen Zwischen- und Root-CA-Zertifikate zusammen mit dem Blattzertifikat in derselben Datei enthalten sein, sodass jetzt eine vollständige Zertifikatskette zugelassen ist; was abgelehnt wird, ist die Bereitstellung nur von CA-Zertifikaten oder mehr als eines Blattzertifikats. Der öffentliche Schlüssel des Blattzertifikats muss mit dem bereitgestellten privaten Schlüssel übereinstimmen, und der private Schlüssel muss ein einzelner RSA-Schlüssel im PKCS#1- (RSA PRIVATE KEY) oder PKCS#8- (PRIVATE KEY) Format sein.

Das Certificate Manager bietet zwei Pfade an, und nur einer speist den ALB. Der ALB verbraucht nur importierte Zertifikate: Sie laden das Zertifikat, die Zertifikatskette und den privaten Schlüssel als PEM hoch und binden die resultierende Ressource an den Listener. Der Auto-Zertifikatspfad (ACME), der automatisch durch einen Anbieter wie Let's Encrypt erneuert wird und erfordert, dass die DNS-Zone der Domäne in IONOS Cloud DNS gehostet wird, listet CDN als nachgelagerten Verbraucher auf, nicht den ALB. Sie können sich also nicht auf die verwaltete ACME-Erneuerung für einen ALB-Listener verlassen; Sie importieren ein PEM-Zertifikat und sind für dessen Rotation verantwortlich. Eine Beschränkung folgt: Bei einem importierten Zertifikat ist der private Schlüssel bei der Erstellung festgelegt und kann nicht bearbeitet werden, sodass die Rotation die Erstellung einer neuen Zertifikatsressource und die erneute Verbindung zum Listener bedeutet, nicht die Bearbeitung des Schlüssels vor Ort. Bauen Sie dies in das Erneuerungshandbuch ein. Für FinCorp teilen sich das Portal und API einen Hostnamen und ein importiertes RSA-Blatt-PEM-Zertifikat, das am ALB beendet wird, und die Erneuerung ist ein kalendergesteuerter Austausch.

DCD Implementierung Schritt-für-Schritt

Sie werden den öffentlichen Layer-7-Eintragspunkt für die Anwendungsebene von FinCorp erstellen: einen öffentlichen ALB am Rand von LAN aus Einheit 3.1, mit einem HTTPS-Hörer, der TLS beendet, einer Zielgruppe, die auf die Anwendungsserver zeigt, einer pfadbasierten Weiterleitungsregel und einem HTTP-Integritätscheck. Dies realisiert das öffentliche Ende der geschichteten Architektur und gibt der API-Gateway-Substitution ihre Randhälfte.

Ziel: Erstellen Sie einen öffentlichen Layer-7-Lastenausgleich mit einem HTTPS-Hörer, Zielgruppe, Pfadregel und Integritätscheck.

Voraussetzungen: Eine reservierte öffentliche IPv4-Adresse von IP-Verwaltung (ein öffentlicher ALB erfordert mindestens einen Hörer IP), die dreifache LAN-Topologie und die Anwendungsserver aus Einheit 3.1 sowie ein importiertes PEM-Zertifikat im Certificate Manager (einzelnes RSA-Blatt, optionaler Chain, übereinstimmender RSA-Privatschlüssel) für den HTTPS-Hörer.

Schritte (im Data Center Designer):

1. Erstellen Sie die Zielgruppe zuerst. Gehen Sie zu Menü > Netzwerkdienste > Zielgruppen und wählen Sie Erstellen. Geben Sie ihr einen Namen und wählen Sie einen Algorithmus (Round Robin ist der Standard; Least Connections, Random und Source IP sind die Alternativen).
2. Fügen Sie in der Zielgruppe Ziele im Reiter Ziele hinzu: für jeden Anwendungsserver geben Sie seine IP-Adresse und den Hintergrundport ein, auf dem der Dienst hört (der Hintergrund kann ein einfacher HTTP-Text sein, da der ALB TLS beendet). Legen Sie ein pro-Ziel-Gewicht (1 bis 256) fest, wenn Sie die Verteilung beeinflussen möchten, beispielsweise für ein gewichteter Canary.
3. Fügen Sie den Integritätscheck im Reiter Verbindung der Zielgruppe hinzu. Für einen HTTP-Check legen Sie den Pfad (Standard /), die Methode und den Übereinstimmungstyp (Statuscode oder Antworttext mit einem optionalen regulären Ausdruck oder Negation) fest. Beachten Sie, dass ein HTTP-Integritätscheck nicht konfiguriert werden darf, wenn Sie gRPC- oder WebSocket-Unterstützung für diese Gruppe verwenden möchten.
4. Platzieren Sie den ALB: im Rechenzentrum-Arbeitsbereich ziehen Sie ein Load Balancer des Typs Anwendung auf die Zeichenfläche.
5. Verbinden Sie seine Schnittstellen: binden Sie die nördliche Schnittstelle an den Internetzugang (den öffentlichen Rand) und die südliche Schnittstelle an die Anwendungsebene-LAN, die die Ziele enthält. Nur öffentliche Lastenausgleichsgeräte erfordern eine öffentliche IP-Adresse und internetfähige Konnektivität; ein privater ALB benötigt keine öffentliche IP-Adresse.
6. Konfigurieren Sie den Hörer als HTTPS: weisen Sie die reservierte öffentliche IP-Adresse als Hörer-IP-Adresse zu, legen Sie den Hörerport (443 für HTTPS) fest und ordnen Sie das importierte PEM-Zertifikat aus dem Certificate Manager zu, damit der ALB TLS an diesem Hörer beendet.
7. Fügen Sie die Weiterleitungsregel im Reiter Weiterleitungsregeln hinzu: benennen Sie sie, bestätigen Sie das Protokoll, legen Sie die Hörer-IP-Adresse und den Port fest und überprüfen Sie den Client-Timeout (der dokumentierte Standardwert beträgt 50000 ms).
8. Fügen Sie die HTTP-Regeln unter der Weiterleitungsregel hinzu. Fügen Sie eine Weiterleitungsregel hinzu, die den spezifischen Pfad (z. B. /api) entspricht und auf die Zielgruppe aus Schritt 1 zeigt; ordnen Sie die spezifischsten Regeln zuerst. Legen Sie dann eine Standardaktion (eine Weiterleitung an die primäre Zielgruppe oder eine statische feste Antwort) für den Datenverkehr fest, der keine spezifische Regel entspricht.
9. Stellen Sie die Änderungen bereit. Der ALB überprüft das Zertifikat während der Bereitstellung, sodass ein Zertifikat, das kein einzelnes übereinstimmendes RSA-Blatt ist, hier fehlschlagen wird, anstatt stillschweigend.

Häufige Fehler:

• Die öffentliche IP-Adresse nicht zuerst zu reservieren. Ein öffentlicher ALB benötigt mindestens einen Hörer IP von IP-Verwaltung, bevor Sie den Hörer konfigurieren können; reservieren Sie ihn vor dem Bau.
• Eine verwaltete ACME-Erneuerung auf dem ALB zu erwarten. Der ALB verbraucht nur importierte PEM-Zertifikate; der Auto-Zertifikatspfad (ACME) speist CDN, nicht den ALB, also planen Sie die Zertifikatsrotation als manuelle, kalendergesteuerte Aufgabe.
• Zu vergessen, dass der importierte private Schlüssel unveränderlich ist. Rotation bedeutet eine neue Zertifikatressource und erneutes Zuweisen des Hörers, nie eine Änderung des Schlüssels vor Ort.
• Versuchen, den ALB mit einer Zulassungsliste oder NSG zu sperren. Der ALB hat keine; legen Sie Firewall-Regeln auf die Ziel-NICs und verlassen Sie sich auf die Topologie, um die Datenebene unerreichbar zu halten.
• Die Reihenfolge der Regeln dem Zufall zu überlassen. HTTP-Regeln entsprechen in der Reihenfolge mit einem Standardfall; legen Sie spezifische Regeln über den Catch-all und setzen Sie genau eine klare Standardaktion.
• Konfigurieren eines HTTP-Integritätschecks in einer Gruppe, die für gRPC oder WebSocket vorgesehen ist. Die Dokumentation verbietet dies ausdrücklich; wählen Sie den Integritätscheck, der dem Protokoll der Gruppe entspricht.
• Den ALB als Ausgangspfad zu behandeln. Er bietet keinen Quell-NAT für Ziele; privater Ausgang erfolgt durch das NAT-Gateway in Einheit 3.6.

Zusammenfassung

Das Managed Application Load Balancer ist die inhaltsbewusste Kante: wählen Sie es, wenn die Weiterleitung HTTP-Hosts, Pfade, Header oder Methoden lesen muss, und überlassen Sie die reine Verbindungsaufteilung dem Layer-4-NLB. Seine drei Komponenten (Hörer, Weiterleitungsregel, Zielgruppe) bilden einen geordneten, standardmäßig unterstützten Routing-Baum, den Sie absichtlich schlank halten, da Regeln und Hörer die begrenzte, gemanagte Oberfläche der Ressource sind. Das TLS wird am Hörer auf einem importierten RSA-Blatt-PEM-Zertifikat beendet (das gemanagte ACME gilt hier nicht), die Filterung gehört auf die Ziele und nicht auf einen Lastenausgleich, der keine NSG oder Whitelist hat, und der ALB plus Ingress-Cluster ersetzen zusammen den API Gateway, den die Plattform nicht anbietet.

Wichtige Punkte:

• Verwenden Sie den ALB, wenn die Ausgleichslogik HTTP-Attribute verarbeiten muss; verwenden Sie den NLB, wenn die Arbeit auf Layer 4 bleiben kann oder wenn die Ende-zu-Ende-Verschlüsselung den Backend-Server erreichen muss.
• Jeder ALB benötigt mindestens einen Hörer (1 bis 10 pro ALB), eine Weiterleitungsregel und eine Zielgruppe; ein Vertrag ist auf 5 ALBs begrenzt.
• Der ALB beendet das TLS (TLS-Offloading) und unterstützt SNI; die Backend-Verbindung kann eine Klartext-HTTP-Verbindung sein.
• Zertifikate müssen ein einzelnes RSA-Blatt in PEM sein (eine vollständige Kette ist jetzt erlaubt, CA-only oder multi-Blatt wird abgelehnt), das über den Certificate Manager importiert wird; der ALB nutzt den gemanagten ACME-Auto-Zertifikatspfad nicht, und der importierte private Schlüssel kann nach der Erstellung nicht bearbeitet werden.
• Der ALB hat keine IP-Whitelist und keine NSG und bietet keine Quell-NAT; die Filterung gehört auf die Ziele und der Ausgang geht durch das NAT-Gateway.
• Der API-Gateway-Ersatz ist ALB-Pfad- und Host-Regel an der Kante plus Ingress-Cluster innerhalb des Cluster, das schlank gehalten wird, um die Regel- und Hörer-Oberfläche zu kontrollieren.

Wichtige Begriffe:

• TLS-Offloading (Beendigung): der ALB entschlüsselt das TLS am Hörer, so dass er die HTTP-Anfrage lesen und weiterleiten kann, und leitet sie an die Backends über eine Klartext-HTTP-Verbindung weiter; dies ist der Grund, warum das Zertifikat auf dem ALB liegt.
• Weiterleitungsregel und HTTP-Regel: eine Weiterleitungsregel, die an einen Hörer gebunden ist, enthält eine geordnete Menge von HTTP-Regeln (Weiterleiten, Umleiten, Statisch); Anfragen werden in der Reihenfolge abgeglichen und fallen auf eine Standardaktion zurück.
• Zielgruppe: eine wiederverwendbare Gruppe von registrierten Zielen (IP plus Port) mit einem Algorithmus, pro-Ziel-Gewichten und einer Gesundheitsprüfung, die der ALB durchführt, sobald die Gruppe an eine Weiterleitungsregel gebunden ist.

Weitere Lektüre

• Einheit 3.1: VDC-Topologie und Segmentierung (der Rand LAN und reservierte öffentliche IP, auf die dieser Build angewiesen ist)
• Einheit 3.2: Netzwerksicherheit: Firewall und Sicherheitsgruppen (warum die Filterung an Ziel-NICs und nicht an den ALB gebunden ist)
• Einheit 3.4: Lastverteilung - Schicht 4 (Netzwerk) (der private Lastverteiler, der die geschichtete Form vervollständigt)
• Einheit 6.2: Bereitstellung eines öffentlichen Cluster (die Ingress-Hälfte des API-Gateway-Ersatzes innerhalb von Cluster)