Istio für Einsteiger:
Konzepte, Einrichtung, Praxis

Istio startet im Modus PERMISSIVE: Proxies nehmen mTLS und Klartext an. Das erlaubt eine schrittweise Migration. Zwischen zwei Proxies wird trotzdem automatisch mTLS verwendet.

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

Mesh-weit: dieselbe Ressource im Namespace istio-system anlegen. Test – ein Pod ohne Sidecar erreicht die Services nicht mehr:

kubectl create namespace legacy   # ohne Injection-Label
kubectl apply -n legacy -f samples/curl/curl.yaml
kubectl exec -n legacy deploy/curl -- curl -s -o /dev/null -w "%{http_code}\n" \
  http://productpage.bookinfo:9080/productpage
# Ergebnis: 000 bzw. "connection reset" statt 200

Erst die Versionen als Subsets definieren (Wie), dann den Traffic lenken (Wohin):

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews
  namespace: bookinfo
spec:
  host: reviews
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2
    - name: v3
      labels:
        version: v3
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
  namespace: bookinfo
spec:
  hosts:
    - reviews
  http:
    - route:
        - destination:
            host: reviews
            subset: v1

Die Seite zeigt jetzt dauerhaft keine Sterne. Die Subsets greifen über Pod-Labels – version: v1 muss also als Label auf den Pods existieren.

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

Dasselbe mit der Gateway API – statt Subsets ein eigener Service pro Version, den bookinfo-versions.yaml bereits angelegt hat:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: reviews
  namespace: bookinfo
spec:
  parentRefs:
    - group: ""
      kind: Service
      name: reviews
      port: 9080
  rules:
    - backendRefs:
        - name: reviews-v1
          port: 9080
          weight: 90
        - name: reviews-v3
          port: 9080
          weight: 10

Hochdrehen: 90/10 → 50/50 → 0/100, jeweils Fehlerraten und Latenz beobachten. Nicht gleichzeitig VirtualService und HTTPRoute für denselben Service verwenden.

Nur ein bestimmter Nutzer sieht v2, alle anderen bleiben auf v1. Bookinfo setzt nach dem Login den Header end-user.

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
  namespace: bookinfo
spec:
  hosts:
    - reviews
  http:
    - match:
        - headers:
            end-user:
              exact: jason
      route:
        - destination:
            host: reviews
            subset: v2
    - route:
        - destination:
            host: reviews
            subset: v1

Damit das funktioniert, muss die Anwendung den Header an ihre eigenen ausgehenden Aufrufe weiterreichen. Istio kann nur routen, was im Request steht. Dasselbe gilt für Tracing-Header: Ohne Weitergabe in der App zerfallen Traces in Einzelteile.

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: ratings
  namespace: bookinfo
spec:
  hosts:
    - ratings
  http:
    - route:
        - destination:
            host: ratings
      timeout: 3s
      retries:
        attempts: 2
        perTryTimeout: 1s
        retryOn: 5xx,connect-failure,reset

• timeout ist die Gesamtzeit inklusive aller Retries.
• Retries nur für idempotente Operationen. Ein wiederholtes POST /bestellung kann zwei Bestellungen erzeugen.
• Istio führt standardmäßig bereits Retries durch. Bei Retries in der App und im Mesh multiplizieren sich die Versuche.

Wie verhält sich die Anwendung, wenn ein abhängiger Service langsam ist oder Fehler liefert? Testbar ohne Codeänderung:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: ratings
  namespace: bookinfo
spec:
  hosts:
    - ratings
  http:
    - fault:
        delay:
          percentage:
            value: 50
          fixedDelay: 5s
        abort:
          percentage:
            value: 10
          httpStatus: 503
      route:
        - destination:
            host: ratings

50 % der Requests werden um 5 Sekunden verzögert, 10 % bekommen ein 503. Fragen, die der Test beantwortet: Zeigt productpage eine saubere Fehlermeldung oder hängt die Seite? Passen die Timeouts der aufrufenden Services zueinander?

• connectionPool begrenzt, wie viele Verbindungen und wartende Requests ein Ziel bekommt. Ist es voll, wird sofort abgelehnt, statt einen überlasteten Service weiter zu fluten.
• outlierDetection wirft einzelne Pods temporär aus dem Loadbalancing, wenn sie wiederholt Fehler liefern.

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews
  namespace: bookinfo
spec:
  host: reviews
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
        maxRequestsPerConnection: 10
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 10s
      baseEjectionTime: 30s
      maxEjectionPercent: 50
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v3
      labels:
        version: v3

maxEjectionPercent verhindert, dass alle Pods gleichzeitig ausgeschlossen werden. Abgelehnte Requests erscheinen im Access-Log mit dem Flag UO. Zum Ausprobieren eignet sich fortio aus samples/httpbin/sample-client/fortio-deploy.yaml.

Die Auswertung läuft in fester Reihenfolge:

Sauberes Vorgehen: erst alles verbieten, dann gezielt erlauben.

# 1. Alles im Namespace verbieten
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-nothing
  namespace: bookinfo
spec: {}
---
# 2. Das Gateway darf productpage aufrufen
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: productpage-from-gateway
  namespace: bookinfo
spec:
  selector:
    matchLabels:
      app: productpage
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - cluster.local/ns/bookinfo/sa/bookinfo-gateway-istio
      to:
        - operation:
            methods: ["GET"]
---
# 3. productpage darf reviews lesen, sonst niemand
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: reviews-from-productpage
  namespace: bookinfo
spec:
  selector:
    matchLabels:
      app: reviews
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - cluster.local/ns/bookinfo/sa/bookinfo-productpage
      to:
        - operation:
            methods: ["GET"]

Dasselbe Muster für details (von productpage) und ratings (von reviews) ergänzen. Welche Identität ein Aufrufer hat, zeigt istioctl x describe pod <pod> -n bookinfo. Der Name des Gateway-ServiceAccounts hängt vom Gateway-Namen ab: kubectl get sa -n bookinfo. Abgelehnte Requests liefern HTTP 403 mit RBAC: access denied.

Standardmäßig dürfen Pods im Mesh jedes externe Ziel erreichen (ALLOW_ANY). Strenger ist REGISTRY_ONLY: Nur bekannte Ziele sind erreichbar.

istioctl install ... --set meshConfig.outboundTrafficPolicy.mode=REGISTRY_ONLY

Unter OSSM 3 kommt die Einstellung in spec.values.meshConfig.outboundTrafficPolicy.mode der Istio-Ressource. Danach jedes erlaubte Ziel per ServiceEntry freigeben:

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: github-api
  namespace: bookinfo
spec:
  hosts:
    - api.github.com
  ports:
    - number: 443
      name: tls
      protocol: TLS
  resolution: DNS
  location: MESH_EXTERNAL

kubectl apply -f samples/addons
kubectl rollout status deployment/kiali -n istio-system
istioctl dashboard kiali

Kiali zeigt den Service-Graphen live: wer mit wem spricht, Fehlerraten, Latenzen, ob mTLS aktiv ist (Schloss-Symbol) und Validierungsfehler in der Istio-Konfiguration. Für Einsteiger das wichtigste Werkzeug, um zu sehen, was die Regeln bewirken.

Access-Logs für das ganze Mesh einschalten:

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: mesh-default
  namespace: istio-system
spec:
  accessLogging:
    - providers:
        - name: envoy

kubectl logs -n bookinfo deploy/productpage-v1 -c istio-proxy --tail=20