Einheit 3.3: Lastverteilung - Ebene 7 (Anwendung)

Einführung

Ein Layer-7-Balancer ist der Punkt, an dem das Netzwerk aufhört, Pakete weiterzuleiten, und beginnt, Anfragen zu lesen. Genau diese Entscheidung regelt diese Einheit: Ob Ihr Edge-Netzwerk HTTP (Hosts, Pfade, Header, Methoden) hinreichend verstehen muss, um darauf basierend zu routen, oder ob es lediglich TCP-Verbindungen über einen Pool verteilen muss. Der IONOS CLOUD Managed Application Load Balancer (ALB) ist die optionale Lösung mit Inhaltsverständnis. Er ist auch der Ort, an dem die Plattform ein Produkt ersetzt, das sie nicht selbst anbietet, nämlich ein verwaltetes API-Gateway, indem sie stattdessen Routing-Regeln bereitstellt. Diese Einheit beginnt bei dieser Routing-Entscheidung und ihren Auswirkungen auf Zertifikate und Kosten und schließt mit dem Aufbau des öffentlichen ALB ab, der die Anwendungsebene von FinCorp im Data Center Designer frontet und auf dem öffentlichen Edge-LAN sitzt, das in Einheit 3.1 eingerichtet wurde.

1. Wenn Layer 7 seinen Platz verdient

Der Managed Application Load Balancer verteilt eingehenden Traffic auf Anwendungsebene an Ziele basierend auf benutzerdefinierten Richtlinien und arbeitet auf Layer 7 des OSI-Modells. Der Network Load Balancer (NLB), behandelt in Einheit 3.4, arbeitet auf Layer 4. Die offiziellen Richtlinien ziehen eine klare Grenze: Wenn Ihre Balancing-Logik HTTP-Anfragen und deren Attribute verarbeiten muss, verwenden Sie den ALB; wenn die Routing-Leistung entscheidend ist und die Logik auf Layer 4 bleiben kann, leiten Sie TCP-Traffic mit dem NLB weiter.

Der ALB verdient seinen Platz, wenn Sie basierend auf dem Inhalt der Anfrage und nicht auf der Verbindung routen. Seine Weiterleitungsregeln unterstützen pfadbasiertes, hostnamenbasiertes, Query-String-basiertes, headerbasiertes, methodenbasiertes, cookiebasiertes, Quell-IP-basiertes Routing, URL-Umleitungen sowie statische oder feste Antwort-Routings. Ein öffentlicher Einstiegspunkt kann daher /api an eine Zielgruppe und /static an eine andere senden, zwei Hostnamen von einer IP bereitstellen oder während der Wartung eine feste 503-Antwort zurückgeben, wobei alle diese Entscheidungen für einen Layer-4-Balancer unsichtbar sind. Der Nachteil besteht darin, dass jede Anfrage geparst und abgeglichen wird, weshalb der NLB für Fälle reserviert ist, in denen diese Arbeit verschwendet wäre: Ende-zu-Ende-verschlüsselter Traffic, den der Balancer nicht entschlüsseln sollte, oder jegliches Nicht-HTTP-Protokoll. Die regulierte Anwendung von FinCorp ist HTTP-basiert, mit einem Kundenportal und einer API-Oberfläche, die einen Hostnamen und ein Zertifikat teilen, daher ist Layer 7 der richtige Einstiegspunkt; die private Datenbankschicht bleibt auf Layer 4. Dies ist die geschichtete Form von öffentlichem Layer 7 zu privatem Layer 4 aus Einheit 1.2.

Drei Plattformgrenzen bestimmen, wie Sie den ALB absichern und dimensionieren, und alle drei sind Designeingaben und keine Mängel:

• Der ALB hat keine IP-Allowlists und keine Network Security Group. Wie in Einheit 3.2 festgelegt, sind NSGs und NIC-Firewalls nur auf Server-NICs auf VDC-Ebene gebunden und gelten nicht für die verwalteten Balancer. Die Filterung gehört daher zu den Zielen: Firewall-Regeln auf den Backend-NICs plus Anwendungslogik, wobei die Datenschicht topologisch unerreichbar gehalten wird.
• Der ALB bietet keine Quell-NAT für Zielverbindungen, ist also kein Ausgangspfad. Private Workloads erreichen das Internet über das NAT Gateway in Einheit 3.6.
• IPv6 hat dokumentierte Einschränkungen auf dem ALB, daher behandeln Sie den öffentlichen Listener als IPv4-Endpunkt auf einer reservierten öffentlichen IPv4-Adresse und planen Sie jede IPv6-Exposition separat.

Es gibt kein IONOS CLOUD API Gateway Produkt. Der Ersatz der Plattform ist genau der Mechanismus, den diese Einheit aufbaut: ALB-Weiterleitungsregeln übernehmen grobes Inhalts-Routing (Pfad- und Host-Regeln, Umleitungen, feste Antworten) am Rand, und ein In-Cluster-Ingress-Controller übernimmt feinere, anwendungsaware-Routing innerhalb eines Kubernetes-Clusters dahinter. Sie setzen das API-Gateway-Verhalten aus einem verwalteten Balancer plus In-Cluster-Ingress zusammen, anstatt ein einzelnes Gateway-Produkt zu provisionieren.

2. Die drei erforderlichen Komponenten und die Kosten der Regeln

Jeder ALB benötigt mindestens einen Listener, eine Weiterleitungsregel und eine Zielgruppe. Das Verständnis dafür, was jede Komponente bewirkt und was sie kostet, ist der Schlüssel, um ein Layer-7-Design schlank zu halten.

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 Source IP. Die Gewichtung pro Ziel (ein Gewicht im Bereich 1 bis 256) ermöglicht es, die Verteilung zu beeinflussen. Dies ist der Mechanismus für einen gewichteten Canary auf Layer 7.

Die Komponenten sind hierarchisch aufgebaut, und genau in dieser Hierarchie ist die Disziplin bei den Regeln entscheidend. Ein Listener enthält Weiterleitungsregeln; eine Weiterleitungsregel enthält eine geordnete Menge von HTTP-Regeln; die Anfrage wird nacheinander mit den Regeln abgeglichen und fällt auf eine Standardaktion zurück, wenn keine Regel zutrifft. Daher sollten die spezifischsten Regeln zuerst und die Fang-alle-Regel zuletzt platziert werden, mit einer klaren Standardaktion pro Listener (häufig eine Weiterleitung zur primären Zielgruppe oder eine feste Antwort).

Halten Sie den Regelsatz aus einem Grund schlank, der über die Klarheit hinausgeht: Regeln und Listener sind die verwaltete Oberfläche des ALB, und ein unübersichtlicher Satz ist eine operative Schwachstelle. Ein ALB ist auf 10 Listener begrenzt und ein Vertrag auf 5 ALBs, daher ist die Ressource bewusst begrenzt. Die Disziplin besteht darin, Routing mit der geringstmöglichen Anzahl korrekter Regeln auszudrücken, feingranuläres Routing in den In-Cluster-Ingress zu verlagern, wo es hingehört, und Zielgruppen über Regeln hinweg wiederverwendbar zu gestalten, anstatt sie zu duplizieren.

3. TLS-Terminierung und Zertifikatsbeschaffung

Der ALB führt TLS-Offloading durch: Er terminiert TLS am Listener, sodass die Backend-Verbindung als Klartext-HTTP aufgebaut werden kann. Dies ist das übliche Layer-7-Muster und der Grund, warum das Zertifikat auf dem ALB und nicht auf den Zielen platziert wird. Der ALB unterstützt auch SNI, sodass ein Listener das richtige Zertifikat für mehrere Hostnamen bereitstellen kann. (Wenn das Backend das Zertifikat beibehalten muss und der Balancer nicht entschlüsseln darf, handelt es sich um den Layer-4-Fall aus Einheit 3.4, nicht um eine ALB-Konfiguration.)

Die Zertifikatsanforderungen sind spezifisch und stellen den Teil dar, der bei einem ersten Bereitstellungsversuch am wahrscheinlichsten fehlschlägt. Beschaffen Sie das Zertifikat daher gezielt. Der ALB erfordert genau ein Blattzertifikat (Endzertifikat), und der Schlüssel muss RSA sein. Gemäß der Dokumentation vom 2026-06 dürfen Zwischen- und Wurzel-CA-Zertifikate zusammen mit dem Blattzertifikat in derselben Datei enthalten sein, sodass eine vollständige Kette nun zulässig ist; abgelehnt wird die Bereitstellung nur von CA-Zertifikaten oder von mehr als einem Blattzertifikat. Der öffentliche Schlüssel des Blattzertifikats muss zum bereitgestellten privaten Schlüssel passen, und der private Schlüssel muss ein einzelner RSA-Schlüssel im Format PKCS#1 (RSA PRIVATE KEY) oder PKCS#8 (PRIVATE KEY) sein.

Der Certificate Manager bietet zwei Wege, von denen nur einer den ALB versorgt. Der ALB verwendet ausschließlich importierte Zertifikate: Sie laden das Zertifikat, die Kette und den privaten Schlüssel als PEM hoch und hängen die resultierende Ressource am Listener an. Der Auto-Zertifikat-Weg (ACME), der automatisch über einen Anbieter wie Let's Encrypt erneuert wird und erfordert, dass die DNS-Zone der Domain in IONOS Cloud DNS gehostet wird, listet CDN als seinen nachgelagerten Verbraucher, nicht den ALB. Sie können sich daher nicht auf verwaltetes ACME-Erneuern für einen ALB-Listener verlassen; Sie importieren ein PEM-Zertifikat und sind für dessen Rotation verantwortlich. Daraus folgt eine Einschränkung: Bei einem importierten Zertifikat wird der private Schlüssel bei der Erstellung festgelegt und kann nicht bearbeitet werden. Rotation bedeutet daher, eine neue Zertifikatsressource zu erstellen und den Listener neu zu verweisen, nicht den Schlüssel an Ort und Stelle zu bearbeiten. Integrieren Sie dies in das Erneuerungs-Runbook. Für FinCorp teilen sich das Portal und die API einen Hostnamen und ein importiertes RSA-Blatt-PEM-Zertifikat, das am ALB terminiert wird, und die Erneuerung ist ein kalendergesteuerter Wechsel.

Implementierungsanleitung für DCD

Sie erstellen den öffentlichen Layer-7-Einstiegspunkt für die Anwendungsschicht von FinCorp: einen öffentlichen ALB im Edge-LAN aus Einheit 3.1, mit einem HTTPS-Listener, der TLS terminiert, einer Zielgruppe, die auf die Anwendungsserver zeigt, einer pfadbasierten Weiterleitungsregel und einem HTTP-Health-Check. Damit wird die öffentliche Seite der geschichteten Architektur umgesetzt und die Hälfte der Kante für den API-Gateway-Ersatz bereitgestellt.

Bauziel: Erstellen Sie einen öffentlichen Layer-7-Load Balancer mit einem HTTPS-Listener, einer Zielgruppe, einer Pfadregel und einem Health-Check.

Voraussetzungen: Eine reservierte öffentliche IPv4-Adresse aus IP Management (ein öffentlicher ALB benötigt mindestens eine Listener-IP), die Topologie mit drei LANs und die Anwendungsserver aus Einheit 3.1 sowie ein importiertes PEM-Zertifikat im Certificate Manager (ein einzelnes RSA-Blatt, optionale Kette, passender RSA-Privatschlüssel) für den HTTPS-Listener.

Schritte (im Data Center Designer):

1. Erstellen Sie zuerst die Zielgruppe. Gehen Sie zu Menü > Netzwerkdienste > Zielgruppen und wählen Sie Erstellen. Geben Sie einen Namen ein und wählen Sie einen Algorithmus (Round Robin ist die Standardoption; Least Connections, Random und Source IP sind die Alternativen).
2. Fügen Sie in der Zielgruppe Ziele im Registerblatt Targets hinzu: Geben Sie für jeden Anwendungsserver dessen IP und den Backend-Port ein, auf dem der Dienst lauscht (der Backend kann Klartext-HTTP sein, da der ALB TLS terminiert). Setzen Sie ein Gewicht pro Ziel (1 bis 256), wenn Sie die Verteilung gewichten möchten, beispielsweise für einen gewichteten Canary-Test.
3. Fügen Sie den Health-Check im Registerblatt Connection der Zielgruppe hinzu. Für einen HTTP-Check setzen Sie den Pfad (Standard /), die Methode und den Abgleichstyp (Status Code oder Response Body mit optionalem regulärem Ausdruck oder Verneinung). Beachten Sie, dass ein HTTP-Health-Check nicht konfiguriert werden darf, wenn Sie gRPC- oder WebSocket-Unterstützung für diese Gruppe verwenden möchten.
4. Platzieren Sie den ALB: Ziehen Sie im Rechenzentrums-Workspace einen Load Balancer vom Typ Application auf die Leinwand.
5. Verbinden Sie seine Schnittstellen: Hängen Sie die nördliche Schnittstelle an Internet Access (den öffentlichen Rand) und die südliche Schnittstelle an das LAN der Anwendungsschicht, das die Ziele enthält. Nur öffentliche Load Balancer benötigen eine öffentliche IP und eine Internetanbindung; ein privater ALB benötigt keine öffentliche IP.
6. Konfigurieren Sie den Listener als HTTPS: Weisen Sie die reservierte öffentliche IP als Listener-IP zu, setzen Sie den Listener-Port (443 für HTTPS) und verknüpfen Sie das importierte PEM-Zertifikat aus dem Certificate Manager, damit der ALB TLS an diesem Listener terminiert.
7. Fügen Sie die Weiterleitungsregel im Registerblatt Forwarding rules hinzu: Benennen Sie sie, bestätigen Sie das Protokoll, setzen Sie die Listener-IP und den Port und prü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 Forward-Regel hinzu, die den spezifischen Pfad (zum Beispiel /api) abgleicht und auf die Zielgruppe aus Schritt 1 zeigt; ordnen Sie die spezifischsten Regeln zuerst. Setzen Sie dann eine Standardaktion (eine Weiterleitung zur primären Zielgruppe oder eine statische Festantwort) für Verkehr, der keine spezifische Regel erfüllt.
9. Stellen Sie die Änderungen bereit. Der ALB validiert das Zertifikat während der Bereitstellung, daher schlägt ein Zertifikat, das kein einzelnes passendes RSA-Blatt ist, hier fehl, statt stillschweigend zu scheitern.

Häufige Fehler:

• Die öffentliche IP wird nicht zuerst reserviert. Ein öffentlicher ALB benötigt mindestens eine Listener-IP aus IP Management, bevor der Listener konfiguriert werden kann; reservieren Sie sie vor dem Aufbau.
• Erwartung eines verwalteten ACME-Wechsels am ALB. Der ALB verwendet nur importierte PEM-Zertifikate; der Auto Certificate (ACME)-Pfad versorgt das CDN, nicht den ALB. Planen Sie die Zertifikatsrotation daher als manuelle, kalendergesteuerte Aufgabe.
• Vergessen, dass der importierte Privatschlüssel unveränderlich ist. Rotation bedeutet ein neues Zertifikatsobjekt und eine Neuverknüpfung des Listeners, niemals eine Schlüsseländerung an Ort und Stelle.
• Versuch, den ALB mit einer Allowlist oder NSG einzuschränken. Der ALB hat beides nicht; legen Sie Firewall-Regeln auf den Ziel-NICs an und verlassen Sie sich auf die Topologie, um die Datenschicht unzugänglich zu halten.
• Die Reihenfolge der Regeln dem Zufall überlassen. HTTP-Regeln werden in Reihenfolge abgeglichen, mit einer Durchlauf-Standardaktion; setzen Sie spezifische Regeln über die Fang-alle-Regel und setzen Sie genau eine klare Standardaktion.
• Konfiguration eines HTTP-Health-Checks für eine Gruppe, die für gRPC oder WebSocket gedacht ist. Die Dokumentation verbietet die Kombination ausdrücklich; wählen Sie den Health-Check passend zum Protokoll der Gruppe.
• Behandlung des ALB als Ausgangspfad. Er stellt keine Source NAT für Ziele bereit; privater Ausgangsverkehr läuft über das NAT Gateway in Einheit 3.6.

Zusammenfassung

Der Managed Application Load Balancer ist der inhaltsbewusste Edge: Wählen Sie ihn, wenn die Routenfindung HTTP-Hosts, Pfade, Header oder Methoden lesen muss, und überlassen Sie das reine Verteilen von Verbindungen dem Layer-4 NLB. Seine drei Komponenten (Listener, Weiterleitungsregel, Zielgruppe) bilden einen geordneten, standardmäßig hinterlegten Routing-Baum, den Sie bewusst schlank halten, da Regeln und Listener die begrenzte, verwaltete Oberfläche der Ressource sind. TLS wird am Listener mit einem importierten RSA-Leaf-PEM-Zertifikat beendet (verwaltetes ACME gilt hier nicht), Filterung gehört zu den Zielen und nicht zu einem Load Balancer, der keine NSG oder Allowlist besitzt, und der ALB zusammen mit dem In-Cluster-Ingress ersetzt das API-Gateway, das die Plattform nicht anbietet.

Wichtige Punkte:

• Verwenden Sie den ALB, wenn die Auslastungsverteilung HTTP-Attribute verarbeiten muss; verwenden Sie den NLB, wenn die Arbeit auf Layer 4 bleiben kann oder wenn Ende-zu-Ende-Verschlüsselung das Backend erreichen muss.
• Jeder ALB benötigt mindestens einen Listener (1 bis 10 pro ALB), eine Weiterleitungsregel und eine Zielgruppe; ein Vertrag ist auf 5 ALBs begrenzt.
• Der ALB beendet TLS (TLS-Offloading) und unterstützt SNI; die Backend-Verbindung kann HTTP im Klartext sein.
• Zertifikate müssen ein einzelnes RSA-Leaf in PEM sein (eine vollständige Kette ist jetzt zulässig, nur CA oder mehrere Leaf-Zertifikate werden abgelehnt), importiert über den Certificate Manager; der ALB nutzt den verwalteten ACME Auto Certificate-Pfad nicht, und der importierte private Schlüssel kann nach der Erstellung nicht bearbeitet werden.
• Der ALB bietet keine IP-Allowlists und keine NSG und stellt kein Source NAT bereit; Filterung gehört zu den Zielen und der Ausgangsverkehr läuft über das NAT Gateway.
• Die API-Gateway-Ersatzlösung besteht aus ALB-Pfad- und Host-Regeln am Edge sowie In-Cluster-Ingress innerhalb des Clusters, schlank gehalten, um die Regel- und Listener-Oberfläche zu kontrollieren.

Wichtige Begriffe:

• TLS-Offloading (Terminierung): Der ALB entschlüsselt TLS am Listener, um den HTTP-Request lesen und routen zu können, und leitet ihn über HTTP im Klartext an die Backends weiter; deshalb befindet sich das Zertifikat auf dem ALB.
• Weiterleitungsregel und HTTP-Regel: Eine Weiterleitungsregel, die an einen Listener gebunden ist, enthält eine geordnete Menge von HTTP-Regeln (Forward, Redirect, Static); Anfragen werden in der Reihenfolge abgeglichen und fallen auf eine Standardaktion zurück.
• Zielgruppe: Eine wiederverwendbare Gruppe registrierter Ziele (IP plus Port) mit einem Algorithmus, Gewichten pro Ziel und einem Health Check, den der ALB durchführt, sobald die Gruppe an eine Weiterleitungsregel gebunden ist.

Weitere Lektüre

• Einheit 3.1: VDC-Topologie und Segmentierung (das Edge-LAN und die reservierte öffentliche IP, von denen dieser Build abhängt)
• Einheit 3.2: Netzwerksicherheit: Firewall und Security Groups (warum Filterung an Ziel-NICs gebunden wird, nicht an den ALB)
• Einheit 3.4: Lastverteilung - Layer 4 (Netzwerk) (der private Balancer, der die geschichtete Struktur vervollständigt)
• Einheit 6.2: Bereitstellung eines öffentlichen Clusters (die In-Cluster-Ingress-Hälfte des API-Gateway-Ersatzes)