Kubernetes环境下Istio中Envoy Sidecar流量控制及网络机制问询

Great question—understanding how Envoy sidecars work under the hood is crucial to getting the most out of Istio. Let’s break down both of your questions clearly:

1. Why does the Envoy Sidecar have control over traffic? #

At its core, it’s all about how Istio hooks into the pod’s network stack and uses Envoy as a transparent proxy:

• Kernel-level traffic hijacking with iptables: When Istio injects the Envoy sidecar into a pod, it runs an init container that sets up custom iptables rules in the pod’s network namespace. These rules do two key things:
  • Redirect all inbound traffic to the pod (except loopback traffic and Envoy’s own internal traffic) to Envoy’s inbound port (typically 15001).
  • Redirect all outbound traffic from your application container to Envoy’s outbound port (typically 15003).
    This happens at the kernel layer, so your application never knows its traffic is being intercepted—it just sends/receives data as usual, and the kernel silently routes it through Envoy.
• Envoy acts as the single traffic gateway: Once traffic hits Envoy, it uses dynamic configuration pushed from Istio’s control plane (Pilot) to manage every aspect of the traffic flow. This includes routing to the right destination, enforcing mTLS encryption, applying rate limits, collecting metrics, and even blocking traffic if needed. Since every network request passes through Envoy, it has full control over how traffic moves to and from your app.
• Co-location in the same pod: The Envoy sidecar shares the same network namespace as your application container. This means it can intercept all traffic without any external network changes—everything is contained within the pod itself, making the setup seamless and portable.

2. Why can’t the original container access external networks without an EgressRule? #

This ties directly to Istio’s default security posture and how outbound traffic is handled:

• All outbound traffic is redirected to Envoy: Thanks to those iptables rules we talked about, every outgoing request from your application gets sent to Envoy first—even traffic to external services like api.example.com or public APIs.
• Envoy follows a "deny-by-default" policy for external traffic: For services inside your Kubernetes cluster, Istio automatically creates routing rules based on Kubernetes Service resources, so Envoy knows how to handle that traffic. But for external services, Istio doesn’t assume you want to allow all communication by default. Without an explicit EgressRule (or the newer combination of ServiceEntry + VirtualService) telling Envoy "it’s okay to forward traffic to this external service", Envoy has no instruction on where to send the request, so it rejects it.
• It’s a security feature, not a bug: This strict default is intentional. It forces you to explicitly define which external services your applications can talk to, reducing the risk of accidental data leaks or communication with untrusted endpoints. If you need to allow all outbound traffic (for testing or less secure environments), you can modify Istio’s global outbound traffic policy to ALLOW_ANY, which tells Envoy to forward any unconfigured outbound traffic directly to its destination.

内容的提问来源于stack exchange，提问作者Haoyuan Ge