Envoy Proxy

Envoy is a high-performance, open-source edge and service proxy designed for cloud-native applications. Originally built at Lyft, Envoy is now a graduated project of the Cloud Native Computing Foundation (CNCF). It functions as a "universal data plane," providing a common set of features for networking, observability, and security that can be used with any application, in any language, running on any infrastructure.

Envoy is typically deployed as a sidecar proxy alongside application services, forming the data plane of a service mesh architecture.

Key Features

• Out-of-Process Architecture: Envoy runs as a standalone process alongside your application, abstracting away network complexity. This means it works with any application language (Java, Go, Python, etc.) without requiring any changes to the application code.
• L3/L4 and L7 Architecture: Envoy operates at both L3/L4 (TCP/UDP) and L7 (HTTP/gRPC) layers. Its pluggable filter architecture allows for a wide range of tasks, such as TCP proxying, TLS termination, and advanced L7 routing.
• Advanced Load Balancing: Implements sophisticated load balancing features, including automatic retries, circuit breaking, rate limiting, request shadowing, and outlier detection.
• Dynamic Configuration: Envoy uses a set of dynamic configuration APIs (known as xDS) to discover backend services, routing rules, and security policies from a central management plane (like Istio or a custom control plane).
• Deep Observability: Provides detailed statistics, distributed tracing, and access logs for all traffic. This makes it easier to monitor and troubleshoot complex microservices architectures.
• HTTP/2 and HTTP/3 Support: Envoy has first-class support for modern protocols like HTTP/2 and gRPC, and it can proxy and translate between different HTTP versions.

Installation and Usage

Envoy is most commonly run as a Docker container. Here’s how you can run a basic Envoy proxy.

Basic Configuration

Create a simple configuration file named envoy.yaml:

static_resources:
  listeners:
    - name: listener_0
      address:
        socket_address:
          address: 0.0.0.0
          port_value: 10000
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                stat_prefix: ingress_http
                route_config:
                  name: local_route
                  virtual_hosts:
                    - name: local_service
                      domains: ["*"]
                      routes:
                        - match:
                            prefix: "/"
                          route:
                            host_rewrite_literal: www.google.com
                            cluster: service_google
                http_filters:
                  - name: envoy.filters.http.router
  clusters:
    - name: service_google
      type: LOGICAL_DNS
      # connect_timeout needs to be 0.250s to avoid DNS resolution race
      # with http route and connect timeouts.
      connect_timeout: 0.25s
      lb_policy: ROUND_ROBIN
      load_assignment:
        cluster_name: service_google
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: google.com
                      port_value: 443
      transport_socket:
        name: envoy.transport_sockets.tls
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
          sni: www.google.com

Run Envoy with Docker

docker run --rm -d -p 10000:10000 -v $(pwd)/envoy.yaml:/etc/envoy/envoy.yaml envoyproxy/envoy:v1.23-latest

You can now send a request to localhost:10000, and Envoy will proxy it to google.com.

Cilium vs. Envoy: A Comparison

While both Cilium and Envoy are critical components in cloud-native networking, they serve different primary purposes and operate at different levels of the stack.

Feature	Cilium	Envoy Proxy
Primary Role	CNI, eBPF-based Networking & Security	Service Mesh Data Plane, L7 Proxy
Core Technology	eBPF (in-kernel)	High-performance C++ proxy (userspace)
Operating Layer	L3/L4 networking, with L7 awareness	Primarily L7 (HTTP, gRPC), with L3/L4 capabilities
Deployment Model	Deployed as a DaemonSet on each node.	Typically deployed as a sidecar proxy for each application pod.
Key Strength	Highly efficient kernel-level packet filtering, security, and networking. Provides the underlying network fabric.	Advanced L7 traffic management, protocol-level resilience, and deep application-aware observability.
Use Case	Securing pod-to-pod connectivity, replacing kube-proxy, and providing efficient network policies.	Implementing a service mesh, API gateway, or edge proxy with features like retries, circuit breaking, and detailed metrics.

How They Work Together

Cilium and Envoy are not mutually exclusive; in fact, they are highly complementary and are often used together in advanced service mesh architectures like Istio.

• Cilium can provide the fast and secure network foundation, handling pod-to-pod connectivity and enforcing baseline network policies at the kernel level using eBPF.
• Envoy can then be layered on top as the service mesh data plane to manage L7 traffic, providing features like TLS termination, fine-grained traffic shifting, and application-specific metrics.

Some service mesh implementations are even optimizing this integration by using Cilium's eBPF capabilities to accelerate Envoy's performance, reducing the overhead of proxying traffic.