Service Mesh Istio Grundlagen
Service Mesh mit Istio
Ein Service Mesh übernimmt Netzwerk-Funktionen wie Routing, Security und Observability. Lernen Sie die Grundlagen von Istio für Kubernetes.
Was ist ein Service Mesh?
┌─────────────────────────────────────────────────────────────┐ │ SERVICE MESH │ ├─────────────────────────────────────────────────────────────┤ │ │ │ OHNE SERVICE MESH: │ │ ┌─────────┐ ┌─────────┐ │ │ │ Service │────────►│ Service │ Direkte Kommunikation │ │ │ A │ │ B │ Kein Traffic Control │ │ └─────────┘ └─────────┘ │ │ │ │ MIT SERVICE MESH: │ │ ┌─────────┐ ┌─────────┐ │ │ │ Service │ │ Service │ │ │ │ A │ │ B │ │ │ │ ┌─────┐ │ │ ┌─────┐ │ │ │ │ │Proxy│─┼────────►┼─│Proxy│ │ Sidecar Proxies │ │ │ └─────┘ │ │ └─────┘ │ kontrollieren Traffic │ │ └─────────┘ └─────────┘ │ │ │ │ │ │ └───────────────────┘ │ │ │ │ │ ▼ │ │ ┌───────────┐ │ │ │ Control │ Konfiguration, │ │ │ Plane │ Policies, Telemetry │ │ └───────────┘ │ │ │ └─────────────────────────────────────────────────────────────┘
Service Mesh Features
| Feature | Beschreibung |
|---|---|
| Traffic Management | Routing, Load Balancing, Canary, Circuit Breaker |
| Security | mTLS, Authentifizierung, Autorisierung |
| Observability | Metriken, Tracing, Logs automatisch |
| Resilience | Retries, Timeouts, Circuit Breaker |
Istio Architektur
┌─────────────────────────────────────────────────────────────┐ │ ISTIO ARCHITEKTUR │ ├─────────────────────────────────────────────────────────────┤ │ │ │ CONTROL PLANE │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ istiod │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ │ │ Pilot │ │ Citadel │ │ Galley │ │ │ │ │ │(Config) │ │(Certs) │ │(Validate)│ │ │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ │ │ Push Config │ │ ▼ │ │ DATA PLANE │ │ ┌───────────────┐ ┌───────────────┐ │ │ │ Pod A │ │ Pod B │ │ │ │ ┌───────────┐ │ │ ┌───────────┐ │ │ │ │ │ App │ │ │ │ App │ │ │ │ │ └───────────┘ │ │ └───────────┘ │ │ │ │ ┌───────────┐ │ │ ┌───────────┐ │ │ │ │ │ Envoy │◄┼───►┼─│ Envoy │ │ │ │ │ │ Proxy │ │ │ │ Proxy │ │ │ │ │ └───────────┘ │ │ └───────────┘ │ │ │ └───────────────┘ └───────────────┘ │ │ │ └─────────────────────────────────────────────────────────────┘
Istio Installation
# istioctl installieren curl -L https://istio.io/downloadIstio | sh - cd istio-* export PATH=$PWD/bin:$PATH # Istio installieren (Demo Profile) istioctl install --set profile=demo -y # Oder minimales Profil für Production istioctl install --set profile=minimal -y # Namespace für Auto-Injection labeln kubectl label namespace default istio-injection=enabled # Installation prüfen istioctl verify-install kubectl get pods -n istio-system
Sidecar Injection
# Automatisch (empfohlen) # Namespace labeln: kubectl label namespace myapp istio-injection=enabled # Alle neuen Pods bekommen automatisch Envoy Sidecar # Manuell (für einzelne Pods) istioctl kube-inject -f deployment.yaml | kubectl apply -f - # Sidecar prüfen kubectl get pods # NAME READY STATUS # myapp-xyz 2/2 Running ← 2 Container (App + Envoy) # Sidecar-Logs kubectl logs myapp-xyz -c istio-proxy
VirtualService (Traffic Routing)
# Grundlegendes Routing
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: myapp
spec:
hosts:
- myapp
http:
- match:
- uri:
prefix: /api/v2
route:
- destination:
host: myapp
subset: v2
- route:
- destination:
host: myapp
subset: v1
# Canary Deployment (Traffic Split)
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: myapp
spec:
hosts:
- myapp
http:
- route:
- destination:
host: myapp
subset: stable
weight: 90
- destination:
host: myapp
subset: canary
weight: 10
# Header-basiertes Routing (für Testing)
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: myapp
spec:
hosts:
- myapp
http:
- match:
- headers:
x-canary:
exact: "true"
route:
- destination:
host: myapp
subset: canary
- route:
- destination:
host: myapp
subset: stable
DestinationRule
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: myapp
spec:
host: myapp
# Subsets definieren (für VirtualService)
subsets:
- name: stable
labels:
version: v1
- name: canary
labels:
version: v2
# Traffic Policy
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
http:
h2UpgradePolicy: UPGRADE
http1MaxPendingRequests: 100
http2MaxRequests: 1000
# Load Balancing
loadBalancer:
simple: ROUND_ROBIN
# Alternativen: LEAST_CONN, RANDOM, PASSTHROUGH
# Circuit Breaker
outlierDetection:
consecutive5xxErrors: 5
interval: 30s
baseEjectionTime: 30s
maxEjectionPercent: 50
Resilience Patterns
# Retries und Timeouts
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: myapp
spec:
hosts:
- myapp
http:
- route:
- destination:
host: myapp
# Timeout
timeout: 10s
# Retries
retries:
attempts: 3
perTryTimeout: 3s
retryOn: connect-failure,refused-stream,unavailable,cancelled,retriable-4xx
# Fault Injection (für Testing)
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: myapp
spec:
hosts:
- myapp
http:
- fault:
# Verzögerung simulieren
delay:
percentage:
value: 10
fixedDelay: 5s
# Fehler simulieren
abort:
percentage:
value: 5
httpStatus: 503
route:
- destination:
host: myapp
mTLS (Security)
# Strict mTLS für Namespace
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: myapp
spec:
mtls:
mode: STRICT # STRICT, PERMISSIVE, DISABLE
# Zertifikate werden automatisch von Istio verwaltet
# Authorization Policy
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-frontend
namespace: backend
spec:
selector:
matchLabels:
app: backend
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/frontend/sa/frontend-sa"]
to:
- operation:
methods: ["GET", "POST"]
paths: ["/api/*"]
Observability
# Kiali (Service Mesh Dashboard) kubectl apply -f samples/addons/kiali.yaml istioctl dashboard kiali # Prometheus (Metriken) kubectl apply -f samples/addons/prometheus.yaml # Grafana (Dashboards) kubectl apply -f samples/addons/grafana.yaml istioctl dashboard grafana # Jaeger (Distributed Tracing) kubectl apply -f samples/addons/jaeger.yaml istioctl dashboard jaeger
# Istio Metriken (automatisch gesammelt)
# Request Rate
istio_requests_total{destination_service="myapp"}
# Request Duration
istio_request_duration_milliseconds_bucket{destination_service="myapp"}
# Request Size
istio_request_bytes_bucket{destination_service="myapp"}
# Response Size
istio_response_bytes_bucket{destination_service="myapp"}
# TCP Connections
istio_tcp_connections_opened_total
istio_tcp_connections_closed_total
Gateway (Ingress)
# Istio Gateway
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: myapp-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "app.example.com"
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
credentialName: app-tls-secret
hosts:
- "app.example.com"
---
# VirtualService an Gateway binden
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: myapp
spec:
hosts:
- "app.example.com"
gateways:
- myapp-gateway
http:
- route:
- destination:
host: myapp
port:
number: 8080
Debugging
# Istio Config prüfen istioctl analyze # Proxy Config anzeigen istioctl proxy-config routes deploy/myapp istioctl proxy-config clusters deploy/myapp istioctl proxy-config listeners deploy/myapp # Envoy Admin Interface kubectl port-forward deploy/myapp 15000:15000 # Dann: http://localhost:15000 # Proxy-Status istioctl proxy-status # Debug Logs aktivieren istioctl proxy-config log deploy/myapp --level debug
⚠️ Beachten:
Service Mesh erhöht Komplexität und Ressourcenverbrauch. Evaluieren Sie, ob Sie die Features wirklich benötigen, bevor Sie Istio einführen. Für einfachere Anwendungsfälle reichen oft Kubernetes-native Lösungen.
💡 Best Practices:
1. Mit PERMISSIVE mTLS starten, dann zu STRICT wechseln
2. Observability-Tools (Kiali, Jaeger) immer mit installieren
3. Ressourcen-Limits für Sidecars setzen
4. VirtualServices und DestinationRules zusammen verwenden
5. istioctl analyze regelmäßig ausführen
2. Observability-Tools (Kiali, Jaeger) immer mit installieren
3. Ressourcen-Limits für Sidecars setzen
4. VirtualServices und DestinationRules zusammen verwenden
5. istioctl analyze regelmäßig ausführen