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 besteht aus einer kleinen Menge von übergeordneten Feldern und einem Options-Bereich je Protokoll. Die folgende Tabelle fasst die einzelnen Felder zusammen:

Feld	Typ	Beschreibung
name	String	Lesbarer Bezeichner für den Listener. Muss innerhalb des ALB eindeutig sein. Wird in API-Pfaden, Logs und Verweisen verwendet.
port	Integer	Service-Port, auf dem der Listener eingehenden Traffic akzeptiert.
protocol	enum	Kommunikationsprotokoll, das der Listener akzeptiert. Unterstützte Werte sind PROTOCOL_HTTP und PROTOCOL_HTTPS.
http	Object	HTTP-spezifischer Konfigurations-Block. Vorhanden, wenn protocol den Wert PROTOCOL_HTTP hat. Enthält Host- und Regel-Definitionen.
https	Object	HTTPS-spezifischer Konfigurations-Block. Vorhanden, wenn protocol den Wert PROTOCOL_HTTPS hat. Enthält Host- und Regel-Definitionen sowie TLS-Offloading-Einstellungen.
wafConfigName	String	Optional. Name der ALB WAF-Konfiguration, die den Traffic auf diesem Listener prüft. Weglassen oder leer lassen, um den Listener ohne ALB WAF-Inspektion zu betreiben.

Den vollständigen Request- und Response-Body des Listeners finden Sie in der v2 API: ALB Listeners-Referenz.

Name

Der Name ist ein lesbarer Bezeichner für den Listener. Er muss innerhalb desselben ALB eindeutig sein und wird in API-Pfaden, Log-Einträgen und Verweisen aus anderen Objekten verwendet.

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 spezifische Optionen für HTTP- und HTTPS-Listener konfigurieren. Diese Optionen steuern, wie Requests zugeordnet und weitergeleitet werden. Der http-Block gilt für PROTOCOL_HTTP-Listener und der https-Block für PROTOCOL_HTTPS-Listener; beide Blöcke teilen dasselbe Host- und Regel-Modell, aber nur https akzeptiert TLS-Offloading-Einstellungen.

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.

ALB WAF Konfiguration

Das Feld wafConfigName bindet eine ALB WAF-Konfiguration an den Listener. Wenn es auf den Namen einer bestehenden ALB WAF-Konfiguration im selben Projekt und derselben Region gesetzt ist, prüft der Listener den gesamten Layer-7-Traffic auf diesem Port mit der Coraza Engine, bevor Requests an die Target Pools weitergeleitet werden. Durch Entfernen des Felds wird die ALB WAF-Inspektion für diesen Listener deaktiviert, ohne die referenzierte ALB WAF-Konfiguration zu löschen, die weiterhin an andere Listener angehängt werden kann.

Da die Aktivierung pro Listener erfolgt, können Sie nur die Ports schützen, die eine Inspektion benötigen (zum Beispiel PROTOCOL_HTTPS auf 443), während andere Listener auf demselben ALB unverändert bleiben.

Informationen zum Objekt-Modell, zu Managed Rule Sets, Custom Rule Groups und zur ALB WAF-Protokollierung finden Sie unter ALB WAF Funktionen und Grundkonzepte der ALB WAF.

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 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.

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.

Aktive Health Checks

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:

Option	Beschreibung	Bereich	Standardwert
Check interval	Zeit zwischen den Health Checks in Sekunden.	>0	5
Down after	Anzahl aufeinanderfolgender fehlgeschlagener Checks, bis ein Ziel als “unhealthy” markiert wird.	1-20	3
Up after	Anzahl aufeinanderfolgender erfolgreicher Checks, bis ein Ziel als “healthy” markiert wird.	1-20	3

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 Observability-Dokumentation.

Sie können Ihren STACKIT Application Load Balancer mit einer Observability-Instanz integrieren, um in Echtzeit Einblicke in den Traffic-Fluss, die Performance und den Anwendungs-Zustand zu erhalten. Diese Integration ermöglicht es Ihnen, Ihr Traffic-Verhalten und Ihre Infrastruktur-Performance zu überwachen, Engpässe schneller zu identifizieren und eine reibungslose Nutzer-Erfahrung sicherzustellen.

Logs

Standard-Ausgaben bestehen hauptsächlich aus den zugrunde liegenden Envoy-Proxy-System-Logs. Diese zeigen an, ob Envoy gestartet hat, gestoppt wurde oder fehlerfrei läuft. Eine erweiterte Log-Bereitstellung befindet sich auf unserer aktuellen Roadmap.

Wenn an einem ALB-Listener eine ALB WAF-Konfiguration angehängt ist, sendet der ALB zusätzlich ALB WAF-Logs, die von der eingebetteten Coraza Engine erzeugt werden (unter dem Label component="waf" übermittelt). Informationen zum Aufbau der Records, zur Korrelation und ein ausführliches Beispiel finden Sie unter ALB WAF Logs in Grundkonzepte der ALB WAF.

Metriken

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

Logs und Metriken aktivieren

Um Logs und Metriken für den Application Load Balancer zu aktivieren, hängen Sie eine Observability-Instanz an und konfigurieren Sie die folgenden zwei Einstellungen am ALB pro Stream (Logs und Metriken):

• credentialsRef: Referenz auf ein technisches Credential (Benutzername und Passwort für Basic Authentication), das den ALB autorisiert, in die Observability-Instanz zu schreiben. Das Credential wird in der Observability-Instanz selbst erstellt; der ALB speichert nur die Referenz.
• pushUrl: Remote-Write-Endpunkt-URL der Observability-Instanz, die den Stream empfängt. Der Hostname ist regions- und instanzspezifisch und wird auf der Detailseite der Observability-Instanz angezeigt.

Die URLs folgen diesen Mustern:

Stream	pushUrl-Muster
Logs	https://logs.<region-cluster>.argus.<region>.stackit.cloud/instances/<instance-id>/loki/api/v1/push
Metrics	https://push.metrics.<region-cluster>.argus.<region>.stackit.cloud/instances/<instance-id>/api/v1/receive

<region-cluster> und <region> werden pro Observability-Instanz bereitgestellt (zum Beispiel eu01). Kopieren Sie die konkrete URL immer von der Observability-Instanz, anstatt sie manuell zusammenzustellen—das genaue Host-Präfix kann je nach Instanz und Region variieren.

Credentials können auf mehrere Arten erstellt werden. Die ALB API speichert nur den Credential-Namen, den Sie angeben; das Credential selbst existiert in der Observability-Instanz und kann über das STACKIT Portal, die STACKIT CLI, den STACKIT Terraform Provider oder die Observability API erstellt werden. Der Name, den Sie in credentialsRef am ALB angeben, muss exakt mit dem Credential-Namen übereinstimmen, der auf der Observability-Instanz existiert, unabhängig davon, mit welchem Tool Sie diesen erstellt haben.

Eine Schritt-für-Schritt-Anleitung zur Credential-Erstellung finden Sie unter Obtaining Technical Credentials. Die konkreten pushUrl-Werte Ihrer Instanz finden Sie unter Locating your identifiers and Endpoint URLs.

Den vollständigen ALB-Request-Body (einschließlich des observability-Blocks) finden Sie in der v2 API: Application Load Balancer-Referenz.