Using Envoy for Egress Traffic

Palantir
6 min readadvanced
--
View Original

Overview

The article discusses the transition from using Squid as a forward proxy to implementing Envoy for managing egress traffic in the Rubix platform. It highlights the benefits of Envoy's dynamic resource discovery and observability features, which enhance traffic control and reduce manual configuration burdens on infrastructure engineers.

What You'll Learn

1

How to implement Envoy as a forward proxy for egress traffic management

2

Why dynamic resource discovery is essential for modern proxy configurations

3

How to monitor Envoy metrics effectively using Datadog

Prerequisites & Requirements

  • Understanding of Kubernetes and network traffic management
  • Familiarity with Envoy and its configuration(optional)

Key Questions Answered

What are the advantages of using Envoy over Squid for egress traffic?
Envoy offers dynamic resource discovery and extensive observability metrics, allowing for automatic configuration updates without requiring cluster restarts. This flexibility empowers users to manage egress traffic more effectively compared to the static configurations of Squid.
How does the Envoy proxy setup work within the Rubix platform?
The Envoy proxy setup in Rubix involves creating an xDS control plane using the go-control-plane library, which manages egress traffic filter rules and updates proxy configurations dynamically. This setup allows for efficient traffic management and reduces the need for manual interventions.
What metrics should be monitored during the Envoy migration?
Key metrics to monitor include listener.no_filter_chain_match, which indicates configuration issues, and listener.downstream_cx_destroy/listener.downstream_cx_total, which assesses connection health between Rubix pods and Envoy instances. Monitoring control_plane.connected_state ensures that Envoy instances remain connected to the control plane.
How does Cilium integrate with Envoy for egress traffic control?
Cilium policies allow services to declare egress destinations, which must be defined for traffic to pass through the Envoy proxy. This dual-layer approach ensures that even if a rogue policy is created, traffic will be blocked at the egress proxy if the destination is not included in its allowlist.

Technologies & Tools

Some links below are affiliate links. We may earn a commission if you make a purchase.

Proxy
Envoy
Used as a forward proxy for managing egress traffic in the Rubix platform.
Network Security
Cilium
Provides Kubernetes-based firewalls for controlling egress traffic.
Monitoring
Datadog
Used for displaying metrics and monitoring the health of Envoy instances.
Library
Go-control-plane
Used to implement the discovery service API server for Envoy.

Key Actionable Insights

1
Implementing Envoy can significantly streamline egress traffic management by allowing dynamic updates without downtime.
This is particularly beneficial in environments where traffic rules frequently change, as it reduces the manual workload on infrastructure teams.
2
Utilizing Envoy's observability features can enhance network transparency and troubleshooting capabilities.
By monitoring metrics and logs, teams can quickly identify and resolve issues, improving overall system reliability.
3
Integrating Cilium with Envoy provides a robust security model for egress traffic.
This combination allows for granular control at both the application and network levels, ensuring that only authorized traffic is allowed to leave the cluster.

Common Pitfalls

1
Failing to properly configure Envoy's allowlist can lead to unauthorized egress traffic.
This can happen if the configuration does not align with Cilium policies, resulting in blocked traffic or security vulnerabilities.
2
Neglecting to monitor Envoy metrics can lead to undetected issues in traffic management.
Without proper monitoring, teams may miss critical signals indicating network problems, which can affect application performance and reliability.

Related Concepts

Kubernetes Networking
Traffic Management Best Practices
Observability In Microservices