envoy - listener, route, cluster and endpoint

    

    It become important to understand envoy mechanics and this is an awesome illustration of it and how these listeners and cluster and endpoints are linked together.

1. Listener (Where traffic enters)

A Listener is a named network location (an IP address and a port) that Envoy opens up to accept incoming connections from clients.

• What it does: It's the "front door." It listens for incoming traffic, handles TLS decryption (if configured), and passes the request down the chain.

• In Istio: When you create an Istio Gateway resource and specify port 80 or 443, Istio tells Envoy to open a Listener on that port.

• Real-world analogy: The receptionist desk at a building entrance.

---

2. Route (How traffic is matched)

Once a request enters through a Listener, Envoy needs to decide what to do with it. This is where the Route comes in.

• What it does: It inspects the request details—like the URI path (/html vs /status/200), HTTP methods (GET, POST), or headers—and matches it to a specific destination.

• In Istio: This maps directly to your Istio VirtualService. If the request path matches /html, the route tells Envoy to send the traffic to the httpbin service.

• Real-world analogy: The directory in the lobby that says, "If you are looking for the Accounting department, go to the 3rd floor."

---

3. Cluster (Where traffic is headed)

A Cluster is a logical grouping of upstream hosts that deliver the same service.

• What it does: Instead of pointing directly to a specific server, the Route points to a Cluster (e.g., the "payment-service" cluster). The cluster is responsible for health checking and load-balancing traffic across its members.

• In Istio: This maps to a Kubernetes Service. When you saw outbound|8000||httpbin.default.svc.cluster.local in your logs, that was Envoy's name for the httpbin Cluster.

• Real-world analogy: The "Accounting Department" as a whole. You don't care which specific accountant helps you, just that you reach the team.

---

4. Endpoint (The exact destination)

An Endpoint is an individual, concrete IP address and port that belongs to a Cluster.

• What it does: It is the actual backend server that handles the request. A Cluster can have one or many Endpoints. Envoy load-balances traffic (e.g., Round Robin) among all the healthy endpoints inside that cluster.

• In Istio: These map directly to your Kubernetes Pods. In your previous logs, the IP 10.1.4.184:8080 was the specific Endpoint pod that processed your /html request.

• Real-world analogy: A specific desk/person sitting in the Accounting department.

---

Putting It All Together: The Traffic Flow

To tie it back to the logs you shared earlier, here is the chain of events Envoy goes through for every request:

1. Listener: Traffic from the client hits the Ingress Gateway on port 8080 (10.1.4.177:8080).

2. Route: Envoy matches the request path /html and host localhost to the correct routing rule.

3. Cluster: The route says to send this to the httpbin cluster (outbound|8000||httpbin...).

4. Endpoint: The cluster selects a healthy pod IP (10.1.4.184:8080) and forwards the request.

How does this related to Istio? 

When we run command like below, this will provide us more insights into how our request are being handle by istio.

Listener Tracking

istioctl proxy-config listener $POD

Notice here that we have route to 0.0.0.0 for port 8000

From here, run the following command to trace for this route 

istioctl proxy-config listener $POD -o json --address 0.0.0.0 --port 8000 | more

And you will get the followings - A route name 8000. Envoy uses the port as the route name too. 

Let's track the route name by running the following command. You can see the virtualHost is httpbin and the route is just one route which is "outbound|8000||httpbin.default.svc.cluster.local".

Then we trace by getting our cluster info. Run this command 

istioctl proxy-config cluster $POD -o json --fqdn httpbin.default.svc.cluster.local  

or 

istioctl proxy-config cluster $POD -o json --fqdn httpbin

or

istioctl proxy-config cluster $POD -o json --fqdn httpbin.default.svc

The output is the same as the service name below :-

Look for serviceName. From here we know that it will be going to :-

  "serviceName": "outbound|8000||httpbin.default.svc.cluster.local"

And finally running this command would allow to confirm if the endpoint is successful 

istioctl proxy-config endpoint $POD --cluster "outbound|8000||httpbin.default.svc.cluster.local"

We will get all these relevant information 

More documentation can be found here

https://www.envoyproxy.io/docs/envoy/latest/intro/life_of_a_request