Kubernetes Integration Patterns: API Gateway, Service Mesh und Event-Driven Architecture

TL;DR

• Drei Patterns decken 95% aller Integrationsszenarien ab: API Gateway (extern), Service Mesh (intern synchron), Event-Driven Architecture (intern asynchron)
• Startet mit Ingress Controller + API Gateway -- ein Service Mesh lohnt sich erst ab ca. 10 Microservices mit komplexen Abhaengigkeiten
• Event-Driven mit Kafka/NATS ist die beste Wahl fuer Legacy-Integration, hohe Entkopplung und Lastspitzen-Abfederung
• Istio vs. Linkerd: Istio bietet mehr Features, Linkerd hat weniger Overhead und ist einfacher zu betreiben
• Jedes Pattern bringt Komplexitaet mit -- fuehrt nur ein, was ihr tatsaechlich braucht

Die drei Saeulern der Service-Integration

Wenn ihr Microservices auf Kubernetes betreibt, muesst ihr drei Kommunikationsprobleme loesen:

1. Wie kommen externe Clients an meine Services? (Nord-Sued-Traffic)
2. Wie kommunizieren meine Services untereinander? (Ost-West-Traffic)
3. Wie entkopple ich Services die nicht sofort eine Antwort brauchen? (Asynchrone Kommunikation)

Fuer jedes Problem gibt es ein etabliertes Pattern. Die Herausforderung ist nicht, alle drei gleichzeitig einzufuehren, sondern zum richtigen Zeitpunkt das richtige Pattern zu waehlen.

Pattern 1: API Gateway (Nord-Sued)

Ein API Gateway sitzt zwischen externen Clients und euren internen Services. Es kuemmert sich um Routing, Authentifizierung, Rate Limiting und TLS-Terminierung -- alles an einer zentralen Stelle.

Wann braucht ihr ein API Gateway?

Sobald ihr mehr als einen Service habt, der von aussen erreichbar sein muss. Ein reiner Ingress Controller reicht fuer einfaches Path-basiertes Routing, aber fuer API-Key-Validierung, OAuth2, Request-Transformation oder detailliertes API-Analytics braucht ihr ein Gateway.

Kong vs. Ambassador vs. APISIX

Fuer die meisten Faelle ist Kong eine solide Wahl: Grosses Plugin-Ecosystem, aktive Community, und die Open-Source-Version deckt 90% der Anforderungen ab.

Beispiel: Kong Gateway mit JWT-Authentifizierung

# Kong als Ingress Controller installiert, dann:
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: jwt-auth
plugin: jwt
config:
  key_claim_name: kid
  claims_to_verify:
    - exp
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: order-api
  annotations:
    konghq.com/plugins: jwt-auth,rate-limiting
    konghq.com/strip-path: "true"
spec:
  ingressClassName: kong
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1/orders
        pathType: Prefix
        backend:
          service:
            name: order-service
            port:
              number: 8080
---
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rate-limiting
plugin: rate-limiting
config:
  minute: 100
  policy: redis
  redis_host: redis.infrastructure.svc.cluster.local
  redis_port: 6379

Jede Anfrage an /v1/orders wird zuerst auf ein gueltiges JWT geprueft, dann gegen das Rate-Limit gecheckt, und erst dann an den order-service weitergeleitet. Ohne Gateway muesste jeder Service diese Logik selbst implementieren.

Pattern 2: Service Mesh (Ost-West)

Ein Service Mesh injiziert einen Sidecar-Proxy in jeden Pod. Dieser Proxy uebernimmt die gesamte Netzwerk-Kommunikation zwischen Services -- transparent, ohne Aenderungen am Anwendungscode.

Was ein Service Mesh euch gibt

• mTLS everywhere: Verschluesselte Kommunikation zwischen allen Services, automatisch
• Traffic Management: Canary Deployments, Traffic Splitting, Retries, Timeouts
• Observability: Request-Level Metriken, Distributed Tracing, Service-Dependency-Maps
• Circuit Breaking: Automatisches Abschalten von Verbindungen zu kranken Services

Istio vs. Linkerd

Meine Empfehlung: Linkerd wenn ihr primaer mTLS, Observability und einfaches Traffic-Management braucht. Istio wenn ihr komplexes Traffic-Routing, Wasm-Erweiterungen oder fine-grained Authorization Policies braucht.

Linkerd installieren und ausprobieren

# Linkerd CLI installieren
curl -sL run.linkerd.io/install | sh
export PATH=$HOME/.linkerd2/bin:$PATH

# Preflight Check
linkerd check --pre

# Control Plane installieren
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
linkerd check

# Mesh fuer ein Namespace aktivieren
kubectl annotate namespace my-app linkerd.io/inject=enabled

# Bestehende Deployments restarten um Sidecar zu injizieren
kubectl rollout restart deployment -n my-app

# Dashboard starten
linkerd viz install | kubectl apply -f -
linkerd viz dashboard &

Nach dem Restart haben alle Pods im Namespace my-app einen Linkerd-Sidecar. Die gesamte Service-zu-Service-Kommunikation ist automatisch mit mTLS verschluesselt. Im Dashboard seht ihr Live-Metriken: Success Rate, Request Rate, Latency (p50/p95/p99) pro Service-zu-Service-Verbindung.

Wann ein Service Mesh Overkill ist

Ein Service Mesh bringt Overhead: Mehr Memory pro Pod, zusaetzliche Latenz, und eine weitere Infrastruktur-Komponente die betrieben werden muss. Fuer Cluster mit weniger als 10 Services oder fuer einfache Request-Response-Patterns ist der Nutzen oft kleiner als der Aufwand.

Alternativen ohne Service Mesh:

• mTLS: cert-manager mit selbst-signierten Zertifikaten
• Retries/Timeouts: Im Application Code oder per Envoy als Standalone (nicht als Sidecar)
• Metriken: Prometheus ServiceMonitor pro Service

Fuer komplexere Deployment-Strategien mit oder ohne Service Mesh siehe unseren Canary Deployment Guide.

Pattern 3: Event-Driven Architecture (Asynchron)

Nicht jede Kommunikation braucht eine sofortige Antwort. Wenn ein Bestellservice eine Bestellung annimmt, muss der Notification-Service nicht synchron aufgerufen werden. Stattdessen publiziert der Bestellservice ein Event, und der Notification-Service reagiert darauf -- entkoppelt.

Wann asynchron statt synchron?

Kafka vs. NATS vs. RabbitMQ auf Kubernetes

Fuer Einsteiger: NATS mit JetStream. Leichtgewichtig, einfach zu betreiben, und fuer die meisten KMU-Szenarien ausreichend.

Fuer Data-Intensive Workloads: Kafka mit Strimzi Operator. Der Goldstandard fuer Event Streaming, aber mit hoeherer Operational Complexity.

NATS JetStream auf Kubernetes

# NATS per Helm installieren
# helm install nats nats/nats --values nats-values.yaml
# nats-values.yaml:
nats:
  jetstream:
    enabled: true
    memStorage:
      enabled: true
      size: 1Gi
    fileStorage:
      enabled: true
      size: 10Gi
      storageClassName: "ssd-retain"

cluster:
  enabled: true
  replicas: 3

resources:
  requests:
    cpu: 250m
    memory: 512Mi
  limits:
    cpu: 500m
    memory: 1Gi

Einen Stream fuer Order-Events erstellen:

# NATS CLI im Cluster verwenden
kubectl exec -it nats-0 -- nats stream add ORDERS \
  --subjects "orders.>" \
  --retention limits \
  --max-msgs 1000000 \
  --max-age 72h \
  --storage file \
  --replicas 3 \
  --discard old

# Consumer fuer den Notification Service
kubectl exec -it nats-0 -- nats consumer add ORDERS notification-service \
  --filter "orders.created" \
  --ack explicit \
  --deliver all \
  --max-deliver 5 \
  --ack-wait 30s

Der Notification-Service bekommt jedes orders.created Event, hat 30 Sekunden zum Verarbeiten, und bei Fehler wird die Nachricht bis zu 5 Mal erneut zugestellt.

Die drei Patterns kombinieren

In der Praxis verwendet ihr alle drei Patterns zusammen. Eine typische Architektur:

Wichtig: Fuehrt nicht alles auf einmal ein. Eine sinnvolle Reihenfolge:

1. Monat 1-2: Ingress Controller + API Gateway fuer externe APIs
2. Monat 3-4: Event Broker fuer den ersten asynchronen Use Case (z.B. Notifications)
3. Monat 5-6: Service Mesh evaluieren, nur einfuehren wenn der Bedarf konkret ist

Monitoring und Observability

Jedes Pattern bringt seine eigenen Metriken mit:

• API Gateway: Request Rate, Error Rate (4xx/5xx), Latency, Top Consumers
• Service Mesh: Service-to-Service Success Rate, Latency Percentiles, TCP Connections
• Event Broker: Consumer Lag, Message Rate, Redelivery Count

Alle drei koennen Metriken an Prometheus liefern. Ein einheitliches Grafana Dashboard, das alle Layers abbildet, ist Gold wert fuer Debugging.

Unser Kubernetes Observability Stack Guide zeigt wie ihr Prometheus, Grafana und Tracing fuer den gesamten Cluster aufsetzt.

Sicherheitsaspekte

Jedes Integration Pattern hat Sicherheitsimplikationen:

API Gateway: Eure erste Verteidigungslinie. JWT-Validierung, Rate Limiting und IP-Whitelisting passieren hier. Stellt sicher, dass das Gateway selbst gehaertet ist -- es ist der attraktivste Angriffspunkt.

Service Mesh: mTLS zwischen Services ist der groesste Sicherheitsgewinn. Ohne Mesh laeuft intra-Cluster-Traffic typischerweise unverschluesselt. Linkerd aktiviert mTLS per Default.

Event Broker: Messages in Kafka/NATS sind standardmaessig nicht verschluesselt. Fuer sensible Daten: TLS fuer Transport und Payload-Encryption auf Anwendungsebene.

Details zu Network-Level Security in unserem Network Policies Guide.

Anti-Patterns: Was ihr vermeiden solltet

API Gateway als Business-Logic-Layer: Das Gateway soll routen, authentifizieren und limitieren -- nicht Geschaeftslogik ausfuehren. Transformation ja, Berechnungen nein.

Service Mesh fuer 3 Services: Der Overhead lohnt sich nicht. Nutzt stattdessen einfache Kubernetes Services und implementiert Retries im Application Code.

Synchrone Calls wo Events reichen: Wenn Service A Service B aufruft und die Antwort nicht sofort braucht, ist ein synchroner HTTP Call die falsche Wahl. Das koppelt die Verfuegbarkeit beider Services aneinander.

Kafka fuer alles: Kafka ist maechtig, aber auch komplex. Fuer einfache Work Queues ist RabbitMQ oder NATS die bessere Wahl. Kafka lohnt sich bei Event Sourcing, Stream Processing oder wenn ihr Messages Tage/Wochen aufbewahren muesst.

Kein API Versioning: Wenn ihr APIs ohne Versionierung (/v1/, /v2/) bereitstellt, bricht jede Aenderung alle Clients. Das API Gateway macht Versioning einfach -- nutzt es von Anfang an.

Fazit

Integration Patterns auf Kubernetes sind kein Selbstzweck. Sie loesen konkrete Probleme: Wie kommt Traffic rein, wie sprechen Services miteinander, wie entkopple ich asynchrone Prozesse. Wichtig ist, das richtige Pattern zum richtigen Zeitpunkt einzufuehren statt den gesamten CNCF-Katalog auf einmal zu deployen.

Die Reihenfolge API Gateway, dann Event Broker, dann (vielleicht) Service Mesh hat sich in der Praxis bewaehrt. Jeder Schritt liefert konkreten Mehrwert und baut auf dem vorherigen auf.

Wenn ihr Unterstuetzung bei der Auswahl oder Implementierung der richtigen Integration Patterns braucht, koennt ihr uns jederzeit kontaktieren.