Istio — service mesh for Kubernetes microservices

We have 30 microservices in our cluster. Each needs TLS, retry logic, circuit breaking, distributed tracing. Implement this in each service separately? Istio promises a solution at the infrastructure level.

What is service mesh¶

Service mesh is an infrastructure layer that manages communication between services. Istio uses Envoy from Lyft as a sidecar proxy. Envoy intercepts all network traffic from the pod and applies configuration from the Istio control plane.

Mutual TLS — encryption without effort¶

With Istio, you get mutual TLS between all services “for free”. Istio automatically generates certificates for each pod, rotates them, and ensures encrypted and authenticated communication.

Traffic management¶

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: api-server
spec:
  hosts:
  - api-server
  http:
  - route:
    - destination:
        host: api-server
        subset: v1
      weight: 95
    - destination:
        host: api-server
        subset: v2
      weight: 5

• Canary deployment — 5% traffic to new version
• Circuit breaking — automatically disconnect non-functional service
• Fault injection — simulate outages for chaos testing

Resource overhead¶

Each pod gets an Envoy sidecar, ~50 MB RAM and ~3 ms additional latency. For 100 pods, that’s 5 GB RAM. Mixer is a bottleneck — it processes telemetry synchronously.

Verdict¶

Istio is version 0.4 — pre-release. We deployed it on staging. For production, we’re waiting for stable 1.0 release planned for summer 2018.

Service mesh is the future of microservices¶

Istio solves real problems — mutual TLS, canary deployments, observability without code changes. We’re watching the development toward 1.0 with excitement.