Istio’s traffic management features, particularly its load balancing capabilities, are more about directing traffic between services than within a single service instance.
Let’s see Istio distribute traffic for a simple productpage service across its various productpage pods.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: productpage
spec:
hosts:
- productpage
http:
- route:
- destination:
host: productpage
subset: v1
weight: 70
- destination:
host: productpage
subset: v2
weight: 30
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: productpage
spec:
host: productpage
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
This VirtualService tells Istio to send 70% of traffic to pods labeled version: v1 and 30% to pods labeled version: v2. The DestinationRule is crucial here, defining these v1 and v2 subsets based on pod labels. When a request for productpage comes in, Istio’s Envoy proxies intercept it. They consult the VirtualService and, based on the defined weights, forward the request to an appropriate productpage pod matching the selected subset’s labels. This is Istio’s primary mechanism for controlling how traffic is distributed across different versions or instances of a service.
The problem Istio’s traffic management solves is the complexity of inter-service communication in a microservices environment. Without it, developers would need to build sophisticated client-side load balancing, service discovery, and routing logic into each service. Istio centralizes this, providing a consistent, configurable, and observable way to manage traffic flow. Internally, Istio leverages Envoy proxies deployed alongside each service instance (as a "sidecar"). These proxies intercept all inbound and outbound traffic for the pod. The Istio control plane (specifically istiod) configures these Envoy proxies. When you define a VirtualService, istiod translates that into Envoy configuration, telling the proxy how to route requests based on rules like host, path, headers, and weights.
The load balancing strategies available within Istio go beyond simple weighted distribution. You can configure ROUND_ROBIN, LEAST_REQUEST, RANDOM, and PASSTHROUGH (which relies on the upstream service’s load balancer). For LEAST_REQUEST, Envoy tracks active requests to each upstream host and sends new requests to the host with the fewest active requests. This is particularly useful when requests have varying processing times.
The surprising truth about Istio load balancing is that the "load balancing" isn’t happening in Istio itself in the way you might expect. Instead, Istio configures the Envoy sidecar proxies, and those proxies perform the load balancing based on the rules Istio provides. The control plane tells the data plane (Envoy) how to act.
When a request arrives at an Envoy sidecar for a service, say reviews, and the VirtualService dictates a split between v1 and v2 of reviews, Envoy checks its internal configuration derived from the DestinationRule. If ROUND_ROBIN is the strategy, it will cycle through available reviews:v1 pods sequentially. If LEAST_REQUEST is chosen, it will pick the reviews:v1 pod that currently has the fewest active connections or requests being processed. The PASSTHROUGH option is interesting because it delegates the load balancing decision entirely to the underlying Kubernetes Service, meaning Envoy just forwards the request to the Kubernetes Service IP, and Kubernetes Service’s kube-proxy (or equivalent) handles the distribution.
One aspect many overlook is how Istio handles canary deployments or A/B testing. You can define a VirtualService that routes 99% of traffic to version: v1 and 1% to version: v2. If the v2 version performs well, you can gradually increase its weight, all without redeploying your services. The Envoy proxies, constantly updated by istiod, seamlessly shift traffic according to these dynamic configurations. This allows for zero-downtime deployments and controlled rollouts.
The next step after mastering basic load balancing is understanding Istio’s fault injection capabilities to test service resilience.