Istio & Envoy: How They Work Together

By /

In the world of cloud-native architectures and microservices, two names frequently appear together: Istio and Envoy. While often mentioned in the same breath, they are distinct technologies with different origins and purposes that work together to create a powerful service mesh solution. This blog explores the relationship between Istio and Envoy, how they complement each other, and provides practical examples of their combined power.

Understanding the Foundation: What Are Istio and Envoy?

Envoy: The High-Performance Proxy

Envoy is an open-source edge and service proxy designed for cloud-native applications. Originally developed by Lyft in 2016, Envoy was created to solve a critical problem: the need for a high-performance, platform-agnostic proxy that could handle service-to-service communication reliably and transparently.

Key characteristics of Envoy include:

  • Language-agnostic: Works with services written in any programming language
  • High performance: Built for low latency and high throughput
  • Extensible: Supports dynamic configuration and plugins
  • Observability-focused: Provides detailed metrics, logging, and tracing capabilities
Istio: The Service Mesh Control Plane

Istio, on the other hand, is a complete service mesh solution that provides a way to control the traffic flow between services, enforce policies, and collect telemetry data. Launched in 2017 by Google, IBM, and Lyft, Istio builds upon Envoy’s capabilities by providing a control plane that configures and manages the Envoy proxies.

Istio’s primary functions include:

  • Traffic management: Routing, load balancing, and resilience features
  • Security: Authentication, authorization, and encryption
  • Observability: Metrics, logs, and traces collection
  • Policy enforcement: Rate limiting and access control

The Symbiotic Relationship: How Istio and Envoy Work Together

The relationship between Istio and Envoy is best understood as a control plane (Istio) and data plane (Envoy) architecture:

The Data Plane: Envoy Proxies

In an Istio service mesh, Envoy proxies are deployed as sidecars alongside each service instance. This means each service gets its own dedicated Envoy proxy. These proxies intercept all network communication to and from the service, enabling:

  1. Traffic interception: All inbound and outbound traffic passes through the proxy
  2. Protocol translation: Converting between different protocols as needed
  3. First-level policy enforcement: Load balancing, circuit breaking, retries
  4. Telemetry collection: Gathering data about request/response patterns

The deployment pattern looks like this:

The Control Plane: Istio Components

Istio’s control plane consists of several components, with istiod (Istio daemon) being the central component in modern versions. The control plane:

  1. Configures the Envoy proxies: Translates high-level traffic management, security policies into Envoy-specific configuration
  2. Manages certificates: Handles generation and distribution of certificates for mTLS
  3. Service discovery: Keeps track of service endpoints
  4. Aggregates telemetry: Collects and processes metrics, traces, and logs

How Configuration Flows Through the System

When you apply an Istio configuration (using Kubernetes Custom Resource Definitions or CRDs), here’s what happens:

  1. The configuration is stored in the Kubernetes API server
  2. Istio’s control plane (istiod) detects the configuration change
  3. Istiod translates the high-level configuration into Envoy-specific configuration
  4. The Envoy proxies receive the new configuration via xDS APIs
  5. Envoy proxies apply the configuration changes without service restarts

This dynamic configuration capability is one of the most powerful aspects of the Istio-Envoy relationship.

Practical Examples of Istio and Envoy in Action

Let’s explore some practical examples of how Istio and Envoy work together to solve common challenges in microservices environments.

Example 1: Traffic Splitting for Canary Deployments

One of the most common use cases for Istio is implementing canary deployments, where traffic is gradually shifted from an old version to a new version of a service.

Here’s how it works:

  1. You deploy v1 and v2 of your service
  2. You configure Istio’s VirtualService and DestinationRule to route 90% of traffic to v1 and 10% to v2
  3. Istio’s control plane translates this to Envoy configuration
  4. Envoy proxies implement the traffic splitting
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service
  http:
  - route:
    - destination:
        host: my-service
        subset: v1
      weight: 90
    - destination:
        host: my-service
        subset: v2
      weight: 10
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-service
spec:
  host: my-service
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

The traffic flow looks like this:

Example 2: Circuit Breaking with Envoy

Circuit breaking is a critical pattern for building resilient microservices. With Istio and Envoy, you can implement circuit breaking without modifying your service code:

  1. You define circuit breaking parameters in an Istio DestinationRule
  2. Istio converts this to Envoy configuration
  3. Envoy enforces the circuit breaking locally at each proxy
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-service
spec:
  host: my-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutiveErrors: 3
      interval: 30s
      baseEjectionTime: 30s

When the service becomes overwhelmed:

Example 3: Securing Service-to-Service Communication with mTLS

Istio and Envoy work together to provide automatic mutual TLS (mTLS) encryption between services:

  1. Istio’s control plane (istiod) acts as a Certificate Authority
  2. It generates and distributes certificates to all Envoy proxies
  3. Envoy proxies use these certificates to establish mTLS connections
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

This creates a zero-trust network environment:

Example 4: Observability with Envoy’s Telemetry

The Envoy proxies collect detailed telemetry about all service interactions:

  1. Envoy proxies capture timing, status codes, and other metadata for each request
  2. This data is sent to Istio’s telemetry systems
  3. Tools like Prometheus, Grafana, Jaeger, or Kiali visualize the data

Under the Hood: How Envoy Gets Configured by Istio

To understand the technical relationship better, let’s look at how Istio actually configures Envoy:

The xDS Protocol

Istio uses Envoy’s xDS (x Discovery Service) APIs to dynamically configure the proxies:

  • LDS (Listener Discovery Service): Configures which ports Envoy listens on
  • RDS (Route Discovery Service): Configures routing rules
  • CDS (Cluster Discovery Service): Defines upstream services
  • EDS (Endpoint Discovery Service): Provides actual IP addresses and ports

When you apply an Istio configuration, it translates your high-level intent into these low-level Envoy configurations.

Configuration Example

Consider this simplified view of how a VirtualService translates to Envoy configuration:

Istio VirtualService:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1

Translated to Envoy configuration (simplified):

{
  "name": "reviews.default.svc.cluster.local:9080",
  "domains": ["reviews.default.svc.cluster.local"],
  "routes": [
    {
      "match": {
        "headers": [
          {
            "name": "end-user",
            "exactMatch": "jason"
          }
        ]
      },
      "route": {
        "cluster": "outbound|9080|v2|reviews.default.svc.cluster.local"
      }
    },
    {
      "route": {
        "cluster": "outbound|9080|v1|reviews.default.svc.cluster.local"
      }
    }
  ]
}

Deployment Considerations

When deploying Istio and Envoy in production, several patterns have emerged:

1. Incremental Adoption

You can adopt Istio incrementally by:

  • Starting with a few services rather than your entire mesh
  • Beginning with observability features before security or traffic management
  • Using namespaces to control which services are part of the mesh
2. Resource Tuning

Since Envoy proxies consume resources:

  • Set appropriate CPU and memory limits based on traffic volume
  • Use horizontal pod autoscaling for the control plane
  • Consider the resource impact when planning cluster capacity
3. Multi-Cluster Deployment

Istio supports multi-cluster deployments:

  • Primary-remote: One control plane manages multiple clusters
  • Multi-primary: Each cluster has its own control plane

Future Directions: Ambient Mesh

One of the most exciting developments in the Istio-Envoy relationship is the ambient mesh concept. This approach aims to address the performance and complexity concerns of the sidecar pattern:

  • Instead of a sidecar per service, use shared proxies per node
  • Split security and routing into separate layers
  • Reduce per-service overhead while maintaining functionality

Challenges and Best Practices

While powerful, the Istio-Envoy combination has its challenges:

Challenges
  1. Complexity: The learning curve can be steep
  2. Resource overhead: Envoy proxies consume CPU and memory
  3. Debugging: Troubleshooting issues can be more complex
  4. Upgrade paths: Keeping components in sync requires planning
Best Practices
  1. Start small: Begin with a subset of services and features
  2. Monitor proxy performance: Keep an eye on Envoy resource usage
  3. Use Istio profiles: Utilize installation profiles to install only what you need
  4. Invest in training: Ensure your team understands the architecture

Conclusion

The partnership between Istio and Envoy represents one of the most powerful combinations in the cloud-native ecosystem. Envoy provides a robust, high-performance proxy that handles the actual traffic, while Istio provides the management layer that makes it easier to configure and control complex service interactions.

As service meshes continue to evolve, this relationship will likely deepen, with Istio leveraging more of Envoy’s capabilities and Envoy evolving to better support Istio’s requirements. Whether you’re implementing basic traffic routing or building a zero-trust security model, understanding how these technologies work together is key to successfully implementing a service mesh.

By starting with simple use cases and gradually expanding your use of the platform, you can harness the full power of Istio and Envoy to build more reliable, secure, and observable microservices architectures.

Related Posts

Scroll to Top