TL;DR

Istio fügt deinem Kubernetes-Cluster eine Infrastrukturschicht für Service-Kommunikation hinzu. Du bekommst mTLS zwischen allen Services, Traffic-Splitting für Canary Deployments und Observability ohne Code-Änderungen. Installiere Istio mit istioctl, aktiviere Sidecar-Injection per Namespace-Label und steuere Traffic über VirtualService und DestinationRule.

Istio Service Mesh auf Kubernetes

Wenn deine Microservices-Architektur wächst, wächst auch die Komplexität der Kommunikation. Retries, Timeouts, mTLS, Canary Releases — all das in jeden Service einzubauen ist Wahnsinn. Ein Service Mesh löst das auf Infrastrukturebene.

Prüfe deine Kubernetes-Version (Istio 1.24+ braucht mindestens K8s 1.28):

kubectl version --short
kubectl get nodes -o wide

Istio installieren

Es gibt mehrere Installationsmethoden. istioctl ist die empfohlene für die meiste Kontrolle.

# istioctl herunterladen
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.24.2 sh -
cd istio-1.24.2
export PATH=$PWD/bin:$PATH

# Cluster-Kompatibilität prüfen
istioctl x precheck

# Installation mit demo-Profil (gut zum Lernen)
istioctl install --set profile=demo -y

Das Demo-Profil installiert Istiod (Control Plane), Ingress Gateway und Egress Gateway. Für Production nutze das default-Profil — es ist restriktiver.

Verifiziere die Installation:

kubectl get pods -n istio-system
kubectl get svc -n istio-system

Alle Pods in istio-system müssen Running sein.

Sidecar-Injection aktivieren

Istios Envoy-Proxys werden als Sidecar-Container in jeden Pod injiziert. Das passiert automatisch per Namespace-Label:

# Namespace erstellen und labeln
kubectl create namespace bookinfo
kubectl label namespace bookinfo istio-injection=enabled

# Label prüfen
kubectl get namespace bookinfo --show-labels

Ab jetzt bekommt jeder Pod in diesem Namespace automatisch einen Envoy-Sidecar. Bestehende Pods müssen neu gestartet werden:

kubectl rollout restart deployment -n bookinfo

Traffic-Routing mit VirtualService

VirtualServices sind das Herzstück von Istios Traffic Management. Sie definieren, wie Requests an Services weitergeleitet werden.

Zuerst brauchst du eine DestinationRule, die Subsets definiert:

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: api-service
  namespace: bookinfo
spec:
  host: api-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        h2UpgradePolicy: DEFAULT
        http1MaxPendingRequests: 100
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

Dann der VirtualService für das Routing:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: api-service
  namespace: bookinfo
spec:
  hosts:
    - api-service
  http:
    - route:
        - destination:
            host: api-service
            subset: v1
          weight: 100
      timeout: 10s
      retries:
        attempts: 3
        perTryTimeout: 3s
        retryOn: 5xx,reset,connect-failure

Hier geht 100% des Traffics an v1. Retries und Timeouts sind direkt konfiguriert — ohne eine Zeile Code in deinem Service.

Canary Deployment mit Traffic-Splitting

Der eigentliche Mehrwert zeigt sich bei Canary Deployments. Leite schrittweise Traffic auf die neue Version:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: api-service
  namespace: bookinfo
spec:
  hosts:
    - api-service
  http:
    - route:
        - destination:
            host: api-service
            subset: v1
          weight: 90
        - destination:
            host: api-service
            subset: v2
          weight: 10

10% des Traffics gehen an v2. Beobachte Error-Rate und Latenz in Kiali oder Grafana. Wenn alles stabil ist, erhöhe auf 50/50, dann 100% v2.

Den Fortschritt steuerst du durch Anpassen der Weights:

# Aktuelles Routing prüfen
kubectl get virtualservice api-service -n bookinfo -o yaml

# Schnell auf 50/50 umschalten
kubectl patch virtualservice api-service -n bookinfo --type merge -p '
spec:
  http:
  - route:
    - destination:
        host: api-service
        subset: v1
      weight: 50
    - destination:
        host: api-service
        subset: v2
      weight: 50'

mTLS zwischen Services

Istio verschlüsselt Service-zu-Service-Kommunikation automatisch mit mutual TLS. Im STRICT-Mode werden unverschlüsselte Verbindungen abgelehnt:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: bookinfo
spec:
  mtls:
    mode: STRICT

Prüfe den mTLS-Status:

istioctl x describe pod <pod-name> -n bookinfo

Die Zertifikate rotiert Istiod automatisch — du musst dich um nichts kümmern.

Wann ein Service Mesh Overkill ist

Istio bringt Overhead mit: Envoy-Sidecars verbrauchen ca. 50-100 MB RAM pro Pod, Istiod braucht 1-2 GB. Bei 5 Microservices lohnt sich das selten.

Service Mesh lohnt sich bei:

• 15+ Microservices mit komplexer Kommunikation
• Compliance-Anforderungen (mTLS, Audit-Logs)
• Canary/Blue-Green Deployments als Standard-Workflow
• Multi-Cluster oder Multi-Cloud Szenarien

Alternativen für kleinere Setups:

• Linkerd (deutlich leichtgewichtiger als Istio)
• Cilium Service Mesh (eBPF-basiert, kein Sidecar)
• Einfache Kubernetes NetworkPolicies + Cert-Manager für mTLS

FAQ

Wie viel Latenz fügt Istio hinzu?

Pro Hop (Sidecar → Service → Sidecar) typischerweise 1-3ms. Bei einer Kette von 5 Services summiert sich das auf 5-15ms. Für die meisten Anwendungen vernachlässigbar, für Hochfrequenz-Trading nicht.

Kann ich Istio für einzelne Pods deaktivieren?

Ja, mit der Annotation sidecar.istio.io/inject: "false" am Pod. Das ist nützlich für Jobs oder Pods, die Probleme mit dem Sidecar haben.

Wie debugge ich Routing-Probleme?

Nutze istioctl analyze -n <namespace> für Konfigurationsfehler. Für Live-Traffic: istioctl proxy-config routes <pod-name> zeigt die aktiven Envoy-Routen. Kiali bietet eine grafische Übersicht der Service-Kommunikation.

Ist Istio für Production bereit?

Ja — Google, Airbnb, eBay und viele andere nutzen Istio in Production. Seit Version 1.20+ ist die Ambient-Mesh-Architektur verfügbar, die den Sidecar-Overhead eliminiert. Für neue Installationen ist das einen Blick wert.

Nächster Schritt: Du planst ein Service Mesh einzuführen oder willst deine Microservices-Architektur auf Kubernetes optimieren?