DevOps6 min read

Service Mesh & Istio

Implement a service mesh with Istio - mTLS between services, traffic management, canary deployments, observability, and zero-trust networking.

Service MeshIstioEnvoymTLSTraffic Management

skill: Service Mesh & Istio category: DevOps tags: [Service Mesh, Istio, Envoy, mTLS, Traffic Management] readingTime: 6

A service mesh adds observability, security (mTLS), and traffic management to service-to-service communication without code changes - the Envoy sidecar proxy handles all of it at the network layer. Istio is the most feature-complete option but operationally complex. Consider Linkerd for simpler use cases or Cilium for eBPF-based mesh.

Workflow

Install Istio and enable sidecar injectionIstio injects an Envoy sidecar proxy into every pod - the proxy intercepts all traffic, enabling mTLS, observability, and traffic management transparently.
Manage traffic with VirtualServiceVirtualService enables sophisticated routing rules - canary deployments by weight, A/B testing by header, fault injection for chaos testing.
Inject faults for resilience testingIstio's fault injection adds latency or errors to specific services without code changes - testing how upstream services handle downstream failures.
Enforce authorization with AuthorizationPolicyIstio AuthorizationPolicy implements zero-trust - by default, deny all; explicitly allow only necessary service-to-service communication.
Observe with Kiali and telemetryIstio generates distributed traces, metrics, and service topology automatically. Kiali visualizes the service graph with real-time traffic and error rates.

Output Format

Istio: sidecar injection + STRICT mTLS, VirtualService canary routing, fault injection for resilience, AuthorizationPolicy zero-trust, and Kiali/Grafana/Jaeger observability.

PeerAuthentication: mtls: mode: STRICT
VirtualService: weights [v1: 90, v2: 10]
DestinationRule: subsets + outlierDetection
AuthorizationPolicy: deny-all + allow specific source/operation
Kiali: istioctl dashboard kiali

Examples

Input

Output

Edge Cases & Gotchas

Sidecar resource overhead - Each Envoy sidecar uses ~50MB memory and ~0.1 CPU cores. For 100 pods, that's 5GB memory and 10 CPU cores overhead. Account for this in cluster capacity planning.
Istio control plane upgrade - Istio upgrades require careful sequencing (control plane then data plane). Use canary upgrades: run two control plane versions simultaneously during rollout.
Non-HTTP protocols - Istio handles HTTP/HTTPS/gRPC natively. For raw TCP services (MySQL, Redis), Istio provides TCP routing but not HTTP-level features like header-based routing or fault injection.
Egress control - By default, Istio allows egress to any external service. Configure ServiceEntry resources to explicitly allowlist external hosts and apply egress authorization policies.

When to Break These Rules

Use Linkerd instead of Istio for simpler operational overhead - Linkerd's control plane is smaller, easier to operate, and covers the most common service mesh use cases.
Skip the service mesh entirely and use application-level mTLS (certificates managed by your app) when you have fewer than 5-10 services - the operational overhead of Istio isn't worth it for small microservice counts.

Reference Files

https://istio.io/latest/docs/
https://kiali.io/documentation/