Istio

Istio’s control plane (istiod) programs the proxies across the mesh, pushing configuration for routing rules and service discovery, and acting as a certificate authority that issues certificates for mutual TLS between workloads. In sidecar mode the data plane is Envoy: every call between services passes through the proxy that sits beside each workload.

How it works

Istio is a service mesh that adds secure connectivity, traffic control and monitoring to distributed applications with few or no code changes. The control plane takes your desired configuration, together with its view of the services, and dynamically programs the proxies as rules or the environment change.

There are two data plane modes. In sidecar mode, an Envoy proxy runs alongside each workload and provides load balancing, TLS termination, circuit breaking, health checks, fault injection and metrics. In ambient mode, a per-node Layer 4 proxy handles connectivity and security, with an optional Layer 7 proxy for features that need to understand HTTP. Istio secures service-to-service traffic with mutual TLS plus identity-based authentication and authorisation. Traffic behaviour is declared with resources such as VirtualService for request routing, DestinationRule for load balancing and outlier detection, and Gateway for edge load balancers.

A practical example

A common use is a canary release: a VirtualService sends most requests to the stable version of a service and a small share to the new one, while a DestinationRule defines the two versions as subsets by label. If error rates rise, you change the weights back without redeploying the application. Mutual TLS can be required for a namespace with a PeerAuthentication resource, so plaintext traffic between workloads is rejected. For detailed syntax, follow the Istio documentation for your installed version.

Common mistakes

• Adopting a mesh for a handful of services, where simpler tools would do the job.
• Forgetting that the proxy needs its own CPU and memory in the pod. Measure the cost in your cluster rather than relying on general figures, and include it in resource requests.
• Enabling strict mutual TLS everywhere at once, which can break clients and health probes outside the mesh. Roll out gradually.
• Debugging only the application when the cause is a mesh routing or policy rule.
• Skipping upgrades of the control plane and proxies, so they drift apart.

When to use it and when not to

Use a mesh when you need consistent mutual TLS, fine-grained traffic shifting, retries and telemetry across many services, and you can staff the operational work. Weigh the extra moving parts and the learning curve against what the use case needs, and compare options such as service mesh alternatives and the ambient mode before committing. Mesh telemetry also feeds distributed tracing. See our Istio technology page and Kubernetes consulting service.

See also

• Service Mesh
• Kubernetes
• Distributed Tracing
• Network Policy