Envoy main process and concepts

upstream/upstream

Let’s go back to the Envoy Configuration Example under Istio example:

Figure:Envoy Configuration in Istio - Deployment

Open with Draw.io

I will only analyze what is going on inside fortio-server(pod) here. In terms of POD traffic, it can be subdivided into two parts:

• inbound : inbound (called)

• outbound : outbound (invoked)

But from an Envoy implementation point of view alone, the concepts of inbound or outbound are rarely used. inbound/outbound are concepts mainly used in Istio. See: Concepts of Service Mesh. section. Envoy uses the concepts of upstream and downstream.

For fortio-server(pod) inbound.

• downstream: client pod

• upstream: app:8080

outbound: downstream: client pod upstream: app:8080 for fortio-server(pod).

• downstream: app

• upstream: fortio-server-l2(pod):8080

When I first started learning Istio, the hardest thing to understand was the above concept. The bend was too hard to turn. To wit:

Attention

In Istio, from the point of view of the Envoy Proxy within a POD, an app/service process within the same POD is just an ordinary upstream cluster. When the app calls a service running on another POD, the target POD is also an upstream cluster. It’s conceptually the same.

Figure: upstream and downstream abstraction flows from Envoy concepts

Open with Draw.io