Grundkonzepte des ALB

STACKIT Application Load Balancer (ALB) verteilt den Traffic effizient auf Ihre Services, erhöht die Zuverlässigkeit und vereinfacht die Skalierung. Der ALB arbeitet auf Layer 7 (Application Layer), sodass Sie Traffic anhand von Inhalten wie Pfaden, Headern und Hostnamen weiterleiten können. Der ALB unterstützt diese erweiterten Funktionen:

• Inhaltsbasiertes Routing
• Cookie-basierte Session-Persistenz
• TLS Offloading
• TLS Bridging

Jeder ALB läuft auf zwei leichtgewichtigen virtuellen Maschinen in einem Active/Passive-Cluster. Diese virtuellen Maschinen sind über mehrere Availability Zones verteilt. Dieses Design stellt eine hohe Verfügbarkeit und Fehlertoleranz sicher und reduziert das Risiko von Ausfällen, wenn Infrastruktur in einer einzelnen Zone ausfällt. Die Netzwerksicherheit wird automatisch über vorkonfigurierte Security Groups verwaltet, sodass Ihre Services ohne zusätzlichen Aufwand geschützt bleiben.

Erstellen Sie einen ALB mit der STACKIT Application Load Balancer API. Verbinden Sie Ihre Services, also virtuelle Maschinen oder Container, über ein STACKIT Network, das für die ALB-Konfiguration erforderlich ist.

IP-Adresse

Der STACKIT Application Load Balancer kann entweder mit einer externen oder einer dynamischen IP-Adresse bereitgestellt werden. Die folgende Tabelle fasst die Unterschiede zusammen:

IP-Adresstyp	Beschreibung	Verwaltung	Lebensdauer
Externe IP-Adresse	Vom Benutzer verwaltete, statische öffentliche IP-Adresse. Muss vor der ALB-Erstellung reserviert und bei der Einrichtung zugewiesen werden.	Benutzerverwaltet	Bleibt über die gesamte Lebensdauer des ALB bestehen
Dynamische IP-Adresse	Dynamische öffentliche IP-Adresse. Wird bei der ALB-Erstellung automatisch zugewiesen und bei Löschung freigegeben.	Systemverwaltet	An die Lebensdauer des ALB gebunden

Externe IP-Adresse

Die externe IP-Adresse ist eine statische, öffentliche Adresse, die Sie verwalten. Reservieren Sie diese Adresse vor dem Erstellen des Application Load Balancer und weisen Sie diese während der Einrichtung zu. Nach der Zuweisung können Sie die externe IP-Adresse nicht mehr ändern.

Dynamische IP-Adresse

Eine dynamische, öffentliche Adresse, die beim Erstellen des Application Load Balancer automatisch zugewiesen wird. Diese Adresse wird nicht vom Benutzer verwaltet und wird freigegeben, wenn der Application Load Balancer gelöscht wird.

Listener

Ein Listener ist der Einstiegspunkt für eingehende Verbindungen zum ALB. Er empfängt Traffic auf einem festgelegten Port und leitet ihn anhand definierter Regeln und Protokolloptionen an ein oder mehrere Targets weiter.

Ein Listener umfasst diese Einstellungen:

• Service-Port
• Protokoll
• HTTP-Optionen:
  • Host
  • Regeln (Pfadpräfix, Header, Query-Parameter, Cookies, WebSocket)
• HTTPS-Optionen:
  • TLS Offloading
    • Certificate ID

Service-Port

Der Service-Port legt den Port fest, auf dem der Listener eingehenden Traffic empfängt.

Protokoll

Das Protokoll definiert das Kommunikationsprotokoll, das der Listener verwendet. Der STACKIT Application Load Balancer unterstützt die Protokolle HTTP und HTTPS.

Protokolloptionen

Protokolloptionen sind Konfigurationsblöcke unter jedem Listener. Sie definieren, wie eingehender Traffic basierend auf dem ausgewählten Protokoll verarbeitet wird.

Sie können protokollspezifische Optionen für HTTP- und HTTPS-Listener konfigurieren. Diese Optionen steuern, wie Requests zugeordnet und weitergeleitet werden.

Host

Der Host ist ein Domainname, der festlegt, welcher virtuelle Host den Request verarbeiten soll.

Reihenfolge beim Host-Matching

Wenn ein Request einen Host-Header enthält, gleicht der ALB ihn mit den definierten Host-Einträgen in Ihren Regeln ab. Die Reihenfolge ist:

1. Exact Match: Regeln mit einem exakten Treffer für den Host-Header werden priorisiert. Beispiel: Eine Regel mit dem Host stackit.cloud hat Vorrang vor einer Wildcard- oder Catch-all-Regel für Requests mit dem Host-Header stackit.cloud.
2. Wildcard Match: Wenn kein exakter Treffer gefunden wird, prüft der Load Balancer auf Wildcard-Matches. Beispiel: Eine Regel mit dem Host *.stackit.cloud deckt Requests mit Host-Headern wie api.stackit.cloud oder docs.stackit.cloud ab. Bevorzugt wird der spezifischste Wildcard-Match. Beispiel: api.europe.stackit.cloud trifft zuerst *.europe.stackit.cloud und danach erst *.stackit.cloud.
3. Catch-all: Wenn kein exakter oder Wildcard-Match gefunden wird, verwendet der Load Balancer die Regel mit dem Catch-all-Host (*), sofern definiert. Diese Regel deckt jeden Host-Header ab.

Regel

Eine Regel definiert, wie eingehender Traffic verarbeitet wird. Sie legt die Bedingungen für das Matching von Requests und die Aktionen fest, die der ALB ausführt, wenn diese Bedingungen erfüllt sind.

Regeln können diese Matcher enthalten:

• Pfad: Fängt den Teil der URL nach der Domain (zum Beispiel /api/v1/users). Wird verwendet, um Requests an das richtige Target zu leiten.
• Header-Matcher: Ordnen Requests basierend auf HTTP-Header-Werten zu (zum Beispiel x-api-key: my-key).
• Query-Parameter-Matcher: Ordnen Requests basierend auf bestimmten Schlüssel-Wert-Paaren im Query-String zu (zum Beispiel ?version=1.0).
• Cookie-Persistenz: Stellt Session-Persistenz sicher, indem Requests desselben Nutzers über Cookies an dasselbe Target geleitet werden.
• WebSocket: Unterstützt WebSocket-Verbindungen für Echtzeitkommunikation zwischen Client und Server.

Pfad-Matching-Algorithmus

Sie können zwei Arten von Pfad-Matches verwenden:

• Prefix: Trifft Requests mit Pfaden, die mit dem angegebenen Präfix beginnen. Beispiel: /api trifft /api, /api/v1/users und /api123, aber nicht /foobar.
• Exact: Trifft Requests mit dem exakt angegebenen Pfad (zum Beispiel trifft /api/v1/users nur diesen Pfad).

Pfad-Auswahlstrategie

Der Application Load Balancer wertet Routen in der Reihenfolge aus, in der sie definiert sind. Die erste Route, die auf einen Request passt, wird ausgewählt, und das Matching stoppt sofort.

Beispiel: Gegeben sei diese Routenliste in dieser Reihenfolge:

1. /api
2. /api/v1

Ein Request an /api/v1/users wird Route 1 (/api) zugeordnet, obwohl Route 2 spezifischer ist, weil sie später in der Liste steht.

Damit der spezifischste Match verwendet wird, listen Sie spezifischere Präfixe immer zuerst auf.

TLS Offloading

TLS Offloading ist der Prozess, bei dem der STACKIT Application Load Balancer die Ver- und Entschlüsselung von sicherem Traffic übernimmt. Dadurch wird die kryptografische Verarbeitung von Ihren Backend-Servern entlastet, sodass diese sich auf Ihre Anwendungen konzentrieren können.

Wenn Nutzer über HTTPS auf Ihre Anwendung zugreifen, übernimmt der ALB die Ver- und Entschlüsselung. Nach dem Entschlüsseln leitet er die Daten als unverschlüsseltes HTTP an Ihre Target-Server weiter. Dieser Ansatz hält den Client-Traffic sicher und optimiert die Performance der Backend-Server.

Um einen HTTPS-Listener einzurichten, speichern Sie ein gültiges X.509-SSL/TLS-Zertifikat über die STACKIT Certificate API. Ein TLS-Zertifikat, das von einer Certificate Authority (CA) ausgestellt wird, enthält:

• Identifikationsdaten
• Gültigkeitszeitraum
• Öffentlicher Schlüssel
• Seriennummer
• Digitale Signatur des Ausstellers

TLS-Zertifikate stellen sicher, dass der Traffic zwischen Clients und dem Application Load Balancer verschlüsselt und authentifiziert ist. Dadurch werden sensible Informationen geschützt und die organisatorische Identität hinter Ihrer Website verifiziert.

Certificate ID

Die Certificate ID ist eine eindeutige Kennung für ein TLS/SSL-Zertifikat, das über die STACKIT Certificate API gespeichert wurde. Diese ID ist bei der Konfiguration von HTTPS-Listenern erforderlich.

Target Pool

Ein Target Pool ist eine Gruppe aus einer oder mehreren Backend-Ressourcen, sogenannten Targets, die vom ALB verteilten Traffic empfangen und verarbeiten. Jeder Target Pool wird mit einem Kommunikationsport und einer Menge von Targets konfiguriert, die über ihre IP-Adressen identifiziert werden.

Wenn Sie einen Target Pool konfigurieren, geben Sie Folgendes an:

• Mindestens eine Target-IP-Adresse
• Einen Target-Pool-Port für die Backend-Kommunikation

Der STACKIT Application Load Balancer verteilt Traffic über die Targets im Pool mit dem Maglev-Load-Balancing-Algorithmus. Dieser Ansatz stellt eine hohe Performance und eine konsistente Traffic-Verteilung sicher.

Target

Ein Target ist eine einzelne Backend-Ressource, entweder eine virtuelle Maschine (VM) oder ein Container, das vom Application Load Balancer weitergeleiteten Traffic verarbeitet. Targets müssen über das STACKIT Network erreichbar sein und auf dem angegebenen Target-Pool-Port antworten.

Gesunde und reaktionsfähige Targets sind entscheidend, um zuverlässige und skalierbare Services bereitzustellen.

HTTP-Header

Der Application Load Balancer ergänzt bei allen an Targets weitergeleiteten Requests automatisch die Header X-Forwarded-For und X-Forwarded-Proto. Diese Header kennzeichnen die ursprüngliche Client-IP-Adresse sowie das für die Verbindung zum ALB verwendete Protokoll. Aus Sicherheitsgründen ignoriert der ALB vorhandene Werte dieser Header in eingehenden Client-Requests, um Spoofing zu verhindern.

TLS Bridging

Ein Target Pool kann definieren, wie verschlüsselter Traffic zwischen dem STACKIT Application Load Balancer und Ihren Backend-Services verarbeitet wird. TLS Bridging funktioniert nur, wenn HTTPS aktiviert ist, und stellt dann sicher, dass der Traffic in jeder Phase des Verbindungspfads verschlüsselt ist.

Aktivieren Sie TLS Bridging, indem Sie TLS auf dem Target Pool für einen HTTPS-Listener konfigurieren. Sie können über das Feld customCAId eine benutzerdefinierte Certificate Authority (CA) angeben. Wenn Sie keine benutzerdefinierte CA angeben, werden standardmäßig die vertrauenswürdigen CAs des Systems verwendet.

TLS Bridging stellt sicher, dass sensible Daten sowohl über das öffentliche Internet als auch innerhalb Ihres privaten Netzwerks verschlüsselt bleiben.

Aktiver Health Check

Aktive Health Checks überwachen den Zustand von Backend-Targets, um sicherzustellen, dass Traffic nur an gesunde Instanzen geleitet wird. Der Application Load Balancer sendet anhand konfigurierbarer Einstellungen regelmäßig Requests an Targets. Wenn ein Target Health Checks nicht besteht, wird es vorübergehend aus dem Target Pool entfernt, bis es die Prüfungen wieder besteht.

Standard-Health-Checks

Die folgende Tabelle fasst die Standardwerte für Health Checks zusammen:

Einstellung	Beschreibung	Standardwert	Bereich
Down after (Checks)	Anzahl aufeinanderfolgender fehlgeschlagener Checks, bis ein Target als ungesund markiert wird	3	1-20
Check interval (Sekunden)	Zeit zwischen den Health Checks	5	Jeder positive Wert
Up after (Checks)	Anzahl aufeinanderfolgender erfolgreicher Checks, bis ein Target als gesund markiert wird	3	1-20

HTTP-Health-Checks (optional)

HTTP-Health-Checks prüfen die Reaktionsfähigkeit des Backends mit HTTP-Requests statt mit TCP-Verbindungen. Sie können Folgendes konfigurieren:

• Einen HTTP-Pfad (zum Beispiel /health)
• Akzeptierte HTTP-Statuscodes (zum Beispiel 200-299), um erfolgreiche Responses zu definieren

Observability

Observability ist ein Managed Service, der ein umfassendes Toolset zur Überwachung von Telemetriedaten bereitstellt, also Metriken, Logs und Traces. Detaillierte Informationen zu Observability und den Funktionen finden Sie in der Dokumentation zu Observability.

Sie können Ihren STACKIT Application Load Balancer in eine Observability-Instanz integrieren, um in Echtzeit Einblicke in Traffic-Fluss, Performance und Anwendungszustand zu erhalten. Diese Integration ermöglicht es Ihnen, das Verhalten der Anwendung zu überwachen, Engpässe schnell zu erkennen und eine nahtlose User Experience sicherzustellen.

Logs erfassen jeden Request, der vom Application Load Balancer verarbeitet wird, einschließlich Metadaten wie Client-IP-Adressen, Request-Pfaden und Response-Statuscodes.

Metriken liefern aggregierte Daten zur Überwachung des allgemeinen Zustands und der Performance des Application Load Balancer, einschließlich Request-Anzahl, Latenz, Fehlerraten und Ressourcenauslastung.

Um Logs und Metriken für den Application Load Balancer zu aktivieren, konfigurieren Sie die folgenden Einstellungen:

• Credentials Reference: Wird über den Observability Create Endpoint erstellt. Enthält Benutzername und Passwort für Basic Authentication für die durch die PushURL angegebene Logging- oder Metrik-Lösung. Dieses Setup ermöglicht Monitoring über die Remote-Write-Funktionalität.
• PushURL: Die Endpoint-URL, an die Logs und Metriken gesendet werden.