How Istio Extends Kubernetes: Service Mesh, Envoy, and Traffic Management

If you have heard of Service Mesh and tried Istio, you may wonder why Istio runs on Kubernetes, what roles Kubernetes and Service Mesh play in cloud‑native architectures, how Istio extends Kubernetes, and the relationship between Kubernetes, Envoy, and Istio.

Why does Istio run on Kubernetes?

What roles do Kubernetes and Service Mesh play in cloud‑native application architecture?

In what ways does Istio extend Kubernetes and what problems does it solve?

What is the relationship between Kubernetes, Envoy, and Istio?

This article walks through the internal workings of Kubernetes and Istio, introduces Kubernetes load‑balancing methods, and explains why Istio is needed even with Kubernetes.

Kubernetes manages application lifecycles declaratively, while a Service Mesh provides inter‑service traffic, security, and observability. If you have a stable Kubernetes platform, you still need a way to control load balancing and traffic between services—this is where a Service Mesh shines.

Envoy introduces the xDS protocol, supported by many open‑source projects such as Istio and MOSN. Envoy is a modern proxy configurable via API and serves as sidecar, edge, or API‑gateway proxy.

The article covers:

Description of kube‑proxy.

Limitations of Kubernetes for micro‑service management.

Functions of the Istio Service Mesh.

Comparison of concepts in Kubernetes, Envoy, and Istio.

Kubernetes and Service Mesh

The diagram below shows service access relationships in Kubernetes and a Service Mesh (sidecar per pod).

Traffic Forwarding

Each node runs a kube‑proxy component that talks to the API server, retrieves service information, and sets iptables rules to forward requests directly to the appropriate pod endpoints.

Service Discovery

Istio can follow Kubernetes service registration and, via control‑plane adapters, integrate with other service‑discovery systems. It generates data‑plane configurations stored as CRDs in etcd. Sidecar proxies deployed in each pod intercept traffic transparently, while kube‑proxy continues to handle node‑level traffic.

Drawbacks of Service Mesh

Running sidecar proxies in every pod adds latency and resource consumption because traffic must hop through additional proxies. The finer‑grained abstractions increase learning overhead, though this eases as the technology matures.

Benefits of Service Mesh

kube‑proxy applies globally and cannot control traffic per service. Service Mesh extracts traffic control from the Kubernetes service layer via sidecars, enabling greater elasticity.

Kube‑Proxy Limitations

If a destination pod fails, kube‑proxy does not automatically retry another pod. Health checks trigger pod restarts, and kube‑proxy removes the corresponding rules. NodePort services cannot add TLS or complex routing.

kube‑proxy balances traffic among pod instances but cannot perform fine‑grained traffic splitting (e.g., percentage‑based routing, canary, blue‑green deployments). Kubernetes Deployments support canary releases by modifying pod labels:

This essentially changes pod labels to assign pods to different deployment services.

Kubernetes Ingress vs. Istio Gateway

kube‑proxy only routes traffic inside the cluster. Ingress resources manage north‑south traffic via an Ingress controller (e.g., nginx). Ingress handles HTTP only and matches limited fields, making it unsuitable for TCP services like MySQL or Redis. Direct north‑south routing requires LoadBalancer or NodePort services.

Istio Gateway functions similarly to Kubernetes Ingress, handling inbound and outbound traffic at the mesh edge.

It defines a load balancer with open ports, protocols, and SNI configuration. The Gateway is a CRD that reuses sidecar capabilities; detailed configuration is available on the Istio website.

Envoy

Envoy is the default sidecar proxy in Istio. Istio extends Envoy’s control plane via the xDS protocol. Before discussing xDS, familiarize yourself with basic Envoy terminology.

Basic Terminology

Downstream : The host that connects to Envoy, sends requests, and receives responses. i.e., the client sending the request.

Upstream : The host that receives connections from Envoy and returns responses. i.e., the server receiving the request.

Listener : A named network address (port, Unix socket, etc.) that downstream clients connect to.

Cluster : A group of logically identical upstream hosts; Envoy discovers members via service discovery and selects one based on load‑balancing policies.

Envoy can configure multiple listeners, each with a filter chain that can be extended to manipulate traffic (e.g., encryption, private RPC).

The xDS protocol, proposed by Envoy, is used by Istio’s sidecar but can be implemented by other proxies such as MOSN.

Istio offers a rich set of features:

Traffic Management (core function).

Policy Control (access control, telemetry, quota, billing).

Observability (implemented in sidecar proxies).

Security Authentication (Citadel handles keys and certificates).

Istio Traffic Management

Istio defines several CRDs for traffic management:

Gateway : Describes a load balancer at the network edge for inbound/outbound HTTP/TCP connections.

VirtualService : Connects a Kubernetes Service to an Istio Gateway and defines routing rules.

DestinationRule : Specifies policies for traffic after routing, such as load‑balancing settings, connection pools, and outlier detection.

EnvoyFilter : Allows advanced users to customize the proxy configuration generated by Istio Pilot.

ServiceEntry : Enables discovery of services outside the mesh by adding them to Istio’s service registry.

Kubernetes, xDS, and Istio Comparison

After reviewing kube‑proxy, xDS, and Istio’s traffic‑management abstractions, we compare the three:

Kubernetes focuses on application lifecycle management (deployment, scaling, self‑healing).

Kubernetes provides a scalable, resilient platform for micro‑services.

Service Mesh uses transparent sidecar proxies to intercept inter‑service traffic and manage it via a control plane.

Service Mesh decouples traffic management from Kubernetes, eliminating the need for kube‑proxy for mesh traffic and offering higher‑level abstractions for traffic, security, and observability.

xDS is a standard protocol for configuring service‑mesh data planes.

Service Mesh is a higher‑level abstraction over Kubernetes services.

Key Takeaways

Kubernetes fundamentally manages Pods, while Service Mesh manages services.

Using Kubernetes for micro‑service deployment and adding a Service Mesh provides advanced traffic control.

If you prefer a serverless approach, platforms like Knative can replace both Kubernetes and Service Mesh.