Istio Service Mesh: Traffic Management and Observability (2026)

Istio is the most feature-complete service mesh available for Kubernetes, providing transparent mTLS encryption, fine-grained traffic control, distributed tracing, and zero-trust authorization — all without changing application code. This guide covers the architecture, key resources, and production patterns your team needs in 2026.

Service Mesh Concepts

A service mesh is an infrastructure layer that handles service-to-service communication in a microservices architecture. Instead of implementing retry logic, TLS, tracing, and access control in every service, you move that responsibility to sidecar proxies injected alongside each Pod.

The core problems a service mesh solves:

• Observability — distributed tracing, golden metrics (latency, traffic, errors, saturation) per service pair without instrumenting application code.
• Security — automatic mTLS between all services with certificate rotation, preventing lateral movement if one service is compromised.
• Traffic control — canary deployments, A/B testing, weighted routing, retries, timeouts, and circuit breakers at the network level.
• Policy — who is allowed to call which service, enforced by the mesh independent of application code.

Istio Architecture: istiod and Envoy

Istio has simplified its architecture significantly since version 1.5. The control plane is now a single binary called istiod, and the data plane consists of Envoy proxy sidecars injected into every Pod in meshed namespaces.

# Install Istio with the default profile (suitable for production evaluation)
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.23.0 sh -
export PATH="$PWD/istio-1.23.0/bin:$PATH"

# Install to cluster
istioctl install --set profile=default -y

# Enable automatic sidecar injection for a namespace
kubectl label namespace production istio-injection=enabled

# Verify installation
istioctl verify-install
kubectl get pods -n istio-system

# Check that Envoy sidecars are running in your app pods
kubectl get pod -n production -l app=payment-service -o jsonpath='{.items[0].spec.containers[*].name}'
# Expected: payment-service istio-proxy

VirtualService: Canary and Weighted Routing

A VirtualService defines traffic routing rules for a Kubernetes service. You can split traffic by weight, route based on headers or cookies, inject faults for chaos testing, and set timeouts and retries — all without touching application code.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: payment-service
  namespace: production
spec:
  hosts:
    - payment-service
  http:
    # Canary: internal beta users (based on header) go to v2
    - match:
        - headers:
            x-canary:
              exact: "true"
      route:
        - destination:
            host: payment-service
            subset: v2
      timeout: 10s
      retries:
        attempts: 3
        perTryTimeout: 3s
        retryOn: 5xx,reset,connect-failure

    # Default: 90% to stable v1, 10% to canary v2
    - route:
        - destination:
            host: payment-service
            subset: v1
          weight: 90
        - destination:
            host: payment-service
            subset: v2
          weight: 10
      timeout: 10s

DestinationRule: Load Balancing and Circuit Breaker

A DestinationRule configures how traffic is sent to a service after routing decisions are made. It defines subsets (for canary), load balancing algorithms, connection pool limits, and circuit breaker (outlier detection) behavior.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: payment-service
  namespace: production
spec:
  host: payment-service
  trafficPolicy:
    loadBalancer:
      simple: LEAST_CONN     # or ROUND_ROBIN, RANDOM, PASSTHROUGH
    connectionPool:
      tcp:
        maxConnections: 100
        connectTimeout: 30ms
      http:
        h2UpgradePolicy: UPGRADE
        http1MaxPendingRequests: 100
        maxRequestsPerConnection: 10
    outlierDetection:         # circuit breaker
      consecutiveGatewayErrors: 5
      interval: 10s
      baseEjectionTime: 30s
      maxEjectionPercent: 50  # at most 50% of hosts ejected at once
      minHealthPercent: 30
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2
      trafficPolicy:
        connectionPool:
          http:
            maxRequestsPerConnection: 1   # tighter limit for canary

Gateway: Ingress Traffic

Istio provides its own ingress Gateway, which offers more control than a standard Kubernetes Ingress controller — including TLS termination, SNI routing, and protocol-level configuration for TCP, HTTP/2, and gRPC.

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: techoral-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 443
        name: https
        protocol: HTTPS
      tls:
        mode: SIMPLE
        credentialName: techoral-tls    # Kubernetes Secret with TLS cert
      hosts:
        - "api.techoral.com"
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: techoral-api
  namespace: production
spec:
  hosts:
    - "api.techoral.com"
  gateways:
    - istio-system/techoral-gateway
  http:
    - route:
        - destination:
            host: payment-service
            port:
              number: 8080

PeerAuthentication: mTLS Everywhere

Istio automatically provisions X.509 certificates for every service identity using SPIFFE/SPIRE. The PeerAuthentication resource controls whether mTLS is enforced or optional for incoming connections to a workload or namespace.

# Enforce strict mTLS cluster-wide (best practice for production)
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system    # applies cluster-wide
spec:
  mtls:
    mode: STRICT             # reject all plaintext connections
---
# Allow permissive mode for a specific deployment during migration
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: legacy-service-permissive
  namespace: production
spec:
  selector:
    matchLabels:
      app: legacy-service
  mtls:
    mode: PERMISSIVE         # accepts both mTLS and plaintext

AuthorizationPolicy: Zero-Trust Access Control

With mTLS in place, every service has a cryptographic identity (SPIFFE URI). AuthorizationPolicy uses these identities to enforce fine-grained access control: which service can call which endpoint using which HTTP method.

# Deny all traffic by default in the production namespace
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: production
spec: {}    # empty spec = deny all
---
# Allow only the checkout service to call payment-service POST /charge
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payment-service-policy
  namespace: production
spec:
  selector:
    matchLabels:
      app: payment-service
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - "cluster.local/ns/production/sa/checkout-service"
      to:
        - operation:
            methods: ["POST"]
            paths: ["/charge", "/refund"]

Kiali and Jaeger Tracing

Istio's observability story is built on three pillars: metrics (Prometheus), tracing (Jaeger/Zipkin), and the service topology graph (Kiali). All three are populated automatically by Envoy without any application instrumentation.

# Deploy Kiali, Prometheus, Jaeger, Grafana from Istio samples
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.23/samples/addons/prometheus.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.23/samples/addons/grafana.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.23/samples/addons/jaeger.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.23/samples/addons/kiali.yaml

# Open Kiali dashboard (shows live service topology with error rates)
istioctl dashboard kiali

# Open Jaeger for distributed trace search
istioctl dashboard jaeger

# Generate some traffic to see traces
kubectl exec -n production deploy/frontend -- curl -s payment-service:8080/health

Kiali shows you a real-time graph of which services call which, with latency and error rate per edge. Jaeger lets you search traces by service, operation, duration, or tags — critical for debugging latency issues in distributed systems.

Istio vs Linkerd vs Cilium

FAQ

Does Istio require changes to my application code?

No. Istio's sidecar proxy intercepts all network traffic transparently. The only application-side requirement for distributed tracing is propagating the B3 or W3C trace headers (x-request-id, x-b3-traceid, etc.) from incoming to outgoing requests — which most HTTP client frameworks can do automatically.

How much CPU and memory does the Envoy sidecar consume?

In a typical production workload, each Envoy sidecar uses 50–100m CPU and 50–100Mi memory at steady state. Under high traffic, CPU usage scales with requests per second. For very high-density clusters, consider Istio's ambient mode which removes per-pod sidecars entirely.

Can I use Istio with AWS EKS?

Yes. Istio is cloud-agnostic and works on any Kubernetes distribution. For EKS, use the NLB (Network Load Balancer) for the istio-ingressgateway Service by setting the service annotation service.beta.kubernetes.io/aws-load-balancer-type: nlb.

What is the difference between a VirtualService and a Kubernetes Ingress?

A Kubernetes Ingress is a simple L7 routing resource handled by your ingress controller (nginx, ALB, etc.). An Istio VirtualService is far more capable: it handles traffic routing within the mesh (service-to-service), not just ingress, and supports weighted routing, fault injection, retries, timeouts, and header-based routing in a single resource.

Does Istio work with non-HTTP protocols?

Yes. Istio supports TCP, TLS, HTTP/1.1, HTTP/2, gRPC, WebSocket, and MongoDB protocols. For non-HTTP protocols, VirtualService routing is limited (only TCP weight-based routing), but mTLS, connection pool management, and outlier detection all apply.