Envoy main process and concepts

Envoy main process and concepts#

upstream/upstream#

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

Istio Data Panel Arch

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.

Upstream and downstream abstract flows from Envoy concepts. upstream vs. downstream abstract flow

Figure: upstream and downstream abstraction flows from Envoy concepts#

Open with Draw.io