Bearbeiten von „Hochverfügbarkeit“

== Hochverfügbarkeit (HA) in der Cloud-nativen Orchestrierung ==

'''Hochverfügbarkeit''' (High Availability, HA) beschreibt das Ziel, ein System so zu gestalten, dass es trotz des Ausfalls einzelner Komponenten (Server, Netzwerke, Rechenzentren) für den Nutzer unterbrechungsfrei erreichbar bleibt. In einer Container-Umgebung wird dies nicht nur durch Hardware-Redundanz, sondern primär durch intelligente Software-Steuerung erreicht.

=== 1. Die drei Säulen der HA in Container-Clustern ===

* '''Redundanz (Replikation):''' Ein Dienst läuft nie nur einmal. Die Orchestrierung (z. B. Kubernetes) sorgt dafür, dass mehrere Instanzen (Pods) desselben Dienstes über verschiedene physische Server verteilt sind.
* '''Health Checking:''' Der Orchestrator prüft kontinuierlich den Zustand ("Liveness") der Container. Reagiert ein Container nicht mehr, wird er automatisch terminiert und durch einen neuen ersetzt.
* '''Failover:''' Fällt ein ganzer Worker-Node (Server) aus, werden alle darauf befindlichen Workloads sofort auf andere, gesunde Knoten im Cluster verschoben.

=== 2. Multi-Zone & Multi-Region Deployments ===

Echte Hochverfügbarkeit in der Cloud nutzt die geografische Verteilung der Anbieter:
* '''Availability Zones (AZs):''' Ein Cluster erstreckt sich über mehrere separate Rechenzentren innerhalb einer Region. Fällt ein Rechenzentrum (z. B. durch Stromausfall) aus, übernehmen die anderen Zonen.
* '''Multi-Region:''' Für extrem kritische Anwendungen wird die Applikation in verschiedenen geografischen Regionen (z. B. Frankfurt und Dublin) gespiegelt, um selbst großflächige Katastrophen abzufangen.



=== 3. Die Rolle der Orchestrierung beim Lastmanagement ===

Die Hochverfügbarkeit wird durch zwei Skalierungsmechanismen unterstützt:
# '''Horizontal Pod Autoscaler (HPA):''' Erhöht die Anzahl der Container-Kopien bei steigender Last, um Überlastung zu vermeiden.
# '''Cluster Autoscaler:''' Fügt der Infrastruktur automatisch neue virtuelle Maschinen hinzu, wenn der Platz im Cluster für weitere Container nicht mehr ausreicht.

=== 4. Daten-Konsistenz als Herausforderung ===

Während zustandslose (stateless) Web-Server leicht zu replizieren sind, erfordern Datenbanken in HA-Szenarien besondere Konzepte:
* '''Read Replicas:''' Kopien der Datenbank für Lesezugriffe.
* '''Leader-Election:''' Ein automatisierter Prozess, der bei Ausfall des Haupt-Datenbankknotens sofort einen Nachfolger bestimmt.

'''Zusammenfassend:''' Hochverfügbarkeit in der Cloud ist kein statischer Zustand, sondern ein dynamischer Prozess. Die Container-Orchestrierung fungiert als automatischer Operator, der 24/7 sicherstellt, dass die Differenz zwischen dem "Soll-Zustand" (z. B. 5 laufende Instanzen) und dem "Ist-Zustand" immer Null beträgt.

= Service Mesh =

Ein '''Service Mesh''' ist die logische Fortführung der Container-Orchestrierung. Während Kubernetes verwaltet, wo Container laufen, verwaltet ein Service Mesh (wie '''Istio''' oder '''Linkerd'''), wie diese Container sicher und zuverlässig miteinander kommunizieren.


Man spricht hier oft von der Trennung zwischen der '''Data Plane''' (dem tatsächlichen Datenfluss) und der '''Control Plane''' (der Konfiguration).

== Erweiterung: Service Mesh Architektur ==

In einer komplexen Microservices-Landschaft reicht einfaches Load Balancing oft nicht mehr aus. Ein '''Service Mesh''' wird als dedizierte Infrastrukturschicht eingebaut, um die Kommunikation zwischen den Diensten (East-West-Traffic) zu steuern.

=== 1. Das Sidecar-Prinzip ===
Die wichtigste Komponente eines Service Mesh ist der '''Sidecar-Proxy''' (z. B. Envoy). 
* Jedem Anwendungs-Container wird ein kleiner Proxy-Container zur Seite gestellt.
* Der Anwendungscode selbst weiß nichts vom Netzwerk; er sendet Anfragen einfach an "localhost".
* Der Sidecar übernimmt Aufgaben wie Verschlüsselung, Retries und Telemetrie.

=== 2. Zentrale Funktionen eines Service Mesh ===

* '''Mutual TLS (mTLS):''' Automatische Verschlüsselung der gesamten Kommunikation zwischen Services, ohne dass die Entwickler Zertifikate im Code verwalten müssen.
* '''Traffic Management:''' Feingranulare Steuerung, z. B. "Sende 5% des Traffics an die neue Version v2" (Canary Deployment).
* '''Resilience (Resilienz):''' 
** ''Circuit Breaking:'' Wenn ein Service überlastet ist, kappt das Mesh die Verbindung kurzzeitig, um eine Kettenreaktion zu verhindern.
** ''Retries & Timeouts:'' Automatische Wiederholungsversuche bei Netzwerkfehlern.
* '''Observability:''' Detaillierte Einblicke, welcher Service wie lange braucht, um auf einen anderen zu antworten (Distributed Tracing).

=== 3. Vergleich: API Gateway vs. Service Mesh ===

{| class="wikitable"
! Merkmal !! API Gateway !! Service Mesh
|-
| '''Fokus''' || North-South (Nutzer zu App) || East-West (Service zu Service)
|-
| '''Aufgabe''' || Authentifizierung, Rate Limiting || Sicherheit, Zuverlässigkeit, Tracing
|-
| '''Ort''' || Am Rand des Netzwerks (Edge) || Überall im Cluster verteilt
|}

=== 4. Bekannte Implementierungen ===
* '''Istio:''' Sehr mächtig, hoher Funktionsumfang, aber komplex in der Verwaltung.
* '''Linkerd:''' Fokus auf Leichtgewichtigkeit und einfache Bedienung.
* '''Consul Connect:''' Gut geeignet für hybride Umgebungen (Cloud + On-Premise).

'''Zusammenfassend:''' Ein Service Mesh entlastet Entwickler von Netzwerk-Logik. Es sorgt dafür, dass die Kommunikation in einer Cloud-Native-Architektur genauso sicher und beobachtbar ist wie ein Monolith, trotz hunderter verteilter Einzelteile.