Istio Service Mesh on Kubernetes

February 13, 2026 | Kubernetes Istio Service Mesh

Traffic management and mTLS.

Istio Service Mesh on Kubernetes

As your microservices architecture grows, managing service-to-service communication becomes increasingly complex. Istio provides a transparent infrastructure layer that handles traffic management, security (mTLS), and observability — without changing application code.

What Istio Provides

  • Traffic Management — Request routing, retries, timeouts, circuit breaking, and fault injection
  • Security — Automatic mutual TLS (mTLS) between all services, authorization policies
  • Observability — Distributed tracing, metrics, and access logging for every service call

Architecture

Istio uses a sidecar proxy pattern. Each pod gets an Envoy proxy container injected automatically:

  • istiod — Control plane that manages proxy configuration, certificates, and service discovery
  • Envoy sidecar — Data plane proxy that intercepts all pod traffic
  • Ingress Gateway — Entry point for external traffic

Installation

istioctl install --set profile=production \
  --set meshConfig.enableAutoMtls=true \
  --set meshConfig.accessLogFile=/dev/stdout

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

Traffic Routing

Route traffic between service versions using VirtualServices:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api-routing
spec:
  hosts:
  - api-service
  http:
  - match:
    - headers:
        x-canary:
          exact: "true"
    route:
    - destination:
        host: api-service
        subset: v2
  - route:
    - destination:
        host: api-service
        subset: v1
      weight: 90
    - destination:
        host: api-service
        subset: v2
      weight: 10

Mutual TLS (mTLS)

Istio automatically encrypts all service-to-service traffic:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: strict-mtls
  namespace: production
spec:
  mtls:
    mode: STRICT

With STRICT mode, only mTLS connections are accepted — plain-text traffic is rejected. This ensures encryption in transit for all inter-service communication.

Authorization Policies

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: api-auth
  namespace: production
spec:
  selector:
    matchLabels:
      app: api-service
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/production/sa/frontend-sa"]
    to:
    - operation:
        methods: ["GET", "POST"]
        paths: ["/api/*"]

Observability with Kiali

Kiali provides a real-time service graph showing traffic flow, error rates, and latency between services. Install it alongside Istio:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/kiali.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/prometheus.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/jaeger.yaml

When to Adopt Istio

  • Good fit: 10+ microservices, compliance requirements (mTLS), complex traffic routing needs
  • Overkill for: Less than 5 services, simple architectures, teams without Kubernetes expertise
  • Resource overhead: ~100MB memory per sidecar proxy, ~10ms P99 latency added per hop

Eazy SaaS Tip: We recommend starting with Istio's traffic management features (retries, timeouts, circuit breaking) and mTLS before adopting advanced features. This delivers 80% of the value with 20% of the complexity.