Wie Istio den Traffic durch euren Cluster lenkt

1 Grundlagen: Data Plane & Control Plane

Istio besteht aus zwei getrennten Ebenen: der Data Plane, die den eigentlichen Netzwerkverkehr transportiert, und der Control Plane (istiod), die Konfiguration verteilt und Zertifikate ausstellt. Kein Anwendungscode wird verändert. Der gesamte Netzwerkverkehr eines Pods wird transparent über einen injizierten Envoy-Sidecar umgeleitet.

Sidecar Injection: Traffic-Interception im Pod

iptables-Regeln leiten allen In-/Outbound-Traffic des Pods zunächst durch den lokalen Envoy-Sidecar. istiod pusht Konfiguration & Zertifikate per gRPC (xDS-API) an jeden Sidecar.

2 Ingress Gateway: der Eintrittspunkt

Externer Request trifft auf das Mesh

Gateway-Resource (Beispiel)

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: shop-ingress-gw
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 443
        name: https
        protocol: HTTPS
      tls:
        mode: SIMPLE
        credentialName: shop-tls-cert
      hosts:
        - "shop.example.com"

3 VirtualService: Layer-7-Routing

Routing-Beispiel: Canary-Release per Gewichtung

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
    - reviews.prod.svc.cluster.local
  http:
    - match:
        - headers:
            x-canary:
              exact: "true"
      route:
        - destination:
            host: reviews.prod.svc.cluster.local
            subset: v2
    - route:
        - destination:
            host: reviews.prod.svc.cluster.local
            subset: v1
          weight: 90
        - destination:
            host: reviews.prod.svc.cluster.local
            subset: v2
          weight: 10

4 DestinationRule: Subsets & Policies

Subset-Auflösung & Load Balancing

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews-dr
spec:
  host: reviews.prod.svc.cluster.local
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
    loadBalancer:
      simple: LEAST_REQUEST
    outlierDetection:
      consecutive5xxErrors: 3
      interval: 10s
      baseEjectionTime: 30s
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

5 Service, Sidecar & Zugriffskontrolle: Ost-West-Traffic im Detail

Was zwischen Client-Aufruf und Antwort passiert

1. App-Container ruft http://payment.prod.svc.cluster.local auf, ganz normaler HTTP-Client-Code.
2. iptables im selben Pod-Netzwerk-Namespace fängt den Outbound-Call ab und leitet ihn transparent an den lokalen Envoy-Sidecar (Port 15001) um.
3. Der Outbound-Sidecar löst den Service-Namen über die von istiod gelieferte Endpoint-Liste auf, wendet VirtualService/DestinationRule an und wählt eine konkrete Ziel-Pod-IP per Load Balancing.
4. Verbindung wird per mTLS aufgebaut und direkt zum Inbound-Sidecar des Ziel-Pods gesendet (Service/ClusterIP wird dabei nur für die initiale Namensauflösung benötigt).
5. Inbound-Sidecar terminiert mTLS, prüft AuthorizationPolicies und reicht den Klartext-Request an den lokalen App-Container weiter (localhost).

Ruft ein Microservice einen anderen auf, sind also immer zwei Sidecars beteiligt: der ausgehende Sidecar des Aufrufers und der eingehende Sidecar des Ziels. Dazwischen läuft die Verbindung automatisch mTLS-verschlüsselt und gegenseitig authentifiziert, ganz ohne Code-Änderung an den Microservices.

Microservice A → Sidecar A (outbound) → mTLS → Sidecar B (inbound) → Microservice B. Antwort läuft denselben Weg zurück.

AuthorizationPolicy: wer darf wen aufrufen?

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: payment-allow-frontend
  namespace: prod
spec:
  selector:
    matchLabels:
      app: payment
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/prod/sa/frontend"]
      to:
        - operation:
            methods: ["POST"]
            paths: ["/api/orders/*"]

6 External Service & Egress Gateway

Verlässt ein Aufruf das Mesh, z.B. ein Microservice, der Nachrichten an ein externes RabbitMQ außerhalb des Clusters sendet, kennt Istio das Ziel standardmäßig nicht. Es gibt zwei Muster, um das zu lösen:

Traffic-Fluss zu einem externen RabbitMQ über das Egress Gateway

# 1. Externen Host im Mesh bekannt machen
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: external-rabbitmq
spec:
  hosts:
    - rabbitmq.partner.example.com
  ports:
    - number: 5671
      name: amqps
      protocol: TLS
  resolution: DNS
  location: MESH_EXTERNAL
---
# 2. Egress-Gateway-Deployment als Ziel für externen Traffic
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: rabbitmq-egress-gw
spec:
  selector:
    istio: egressgateway
  servers:
    - port:
        number: 5671
        name: tls
        protocol: TLS
      tls:
        mode: PASSTHROUGH
      hosts:
        - rabbitmq.partner.example.com
---
# 3. Mesh-internen Traffic explizit über das Egress Gateway leiten
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: rabbitmq-via-egress
spec:
  hosts:
    - rabbitmq.partner.example.com
  gateways:
    - mesh
    - rabbitmq-egress-gw
  tls:
    - match:
        - gateways: [mesh]
          port: 5671
          sniHosts: [rabbitmq.partner.example.com]
      route:
        - destination:
            host: rabbitmq-egress-gw.istio-system.svc.cluster.local
            port:
              number: 5671
    - match:
        - gateways: [rabbitmq-egress-gw]
          port: 5671
          sniHosts: [rabbitmq.partner.example.com]
      route:
        - destination:
            host: rabbitmq.partner.example.com
            port:
              number: 5671

7 Gesamtüberblick: kompletter Traffic-Pfad

Alle Bausteine zusammen: ein externer User ruft über das Ingress Gateway einen Microservice auf, der intern einen zweiten Microservice per mTLS anspricht, welcher wiederum über das Egress Gateway Nachrichten an ein externes RabbitMQ sendet.

Wer macht was? Kompakt-Übersicht