Sidecar proxy concept (Envoy) in Kubernetes - Step-by-Step Execution

Process Flow - Sidecar proxy concept (Envoy)

Application Pod Starts

↓

Sidecar Proxy (Envoy) Injected

↓

All Outgoing Traffic Routed Through Envoy

↓

Envoy Applies Policies, Observability, Security

↓

Traffic Sent to Destination Service

↓

Incoming Traffic Routed Through Envoy

↓

Envoy Applies Inbound Rules

↓

Traffic Delivered to Application Container

The application pod runs with an Envoy sidecar proxy that intercepts all traffic in and out, applying rules and sending traffic securely.

Execution Sample

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  containers:
  - name: app
    image: myapp:latest
  - name: envoy
    image: envoyproxy/envoy:v1.22.0

A Kubernetes pod spec showing an application container and an Envoy sidecar container running together.

Process Table

Step	Action	Traffic Direction	Envoy Role	Result
1	Pod starts with app and Envoy containers	N/A	Envoy initialized	Envoy ready to intercept traffic
2	App sends request to external service	Outbound	Envoy intercepts outbound traffic	Traffic routed through Envoy proxy
3	Envoy applies outbound policies (e.g., retries, TLS)	Outbound	Envoy modifies or secures traffic	Request sent securely to destination
4	External service responds	Inbound	Response routed back through Envoy	Envoy applies inbound policies
5	Envoy delivers response to app container	Inbound	Envoy completes traffic flow	App receives response
6	Pod terminates	N/A	Envoy shuts down	Traffic interception stops

💡 Pod stops, Envoy sidecar terminates, traffic interception ends

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 5	Final
Envoy Status	Not running	Running	Running	Running	Running	Stopped
Traffic State	No traffic	Outbound intercepted	Outbound secured	Inbound intercepted	Delivered to app	No traffic

Key Moments - 3 Insights

Why does Envoy need to be in the same pod as the application?

Envoy runs as a sidecar container in the same pod to intercept all network traffic locally before it leaves or reaches the app, as shown in execution_table steps 2 and 4.

Does the application need to change its code to use Envoy?

No, the application sends traffic normally. Envoy transparently intercepts and manages traffic without app code changes, as seen in step 2 where traffic is routed through Envoy.

What happens if Envoy stops running while the pod is active?

Traffic interception stops, so policies and security Envoy provides are lost. This is shown in the final variable_tracker state where Envoy status changes to stopped.

Visual Quiz - 3 Questions

Look at the execution table, at which step does Envoy apply outbound policies like retries or TLS?

A Step 4

B Step 2

C Step 3

D Step 5

💡 Hint

Check the 'Envoy Role' column in execution_table row for step 3.

According to variable_tracker, what is the traffic state after step 4?

A Outbound intercepted

B Inbound intercepted

C Delivered to app

D No traffic

💡 Hint

Look at the 'Traffic State' row under 'After Step 4' in variable_tracker.

If the Envoy container was removed from the pod, what would change in the execution flow?

A Traffic would bypass Envoy and go directly to destination

B Traffic would still be intercepted by Envoy

C Pod would fail to start

D Application would crash

💡 Hint

Refer to concept_flow showing Envoy intercepting traffic inside the pod.

Concept Snapshot

Sidecar proxy (Envoy) runs alongside app in same pod
Intercepts all inbound and outbound traffic
Applies security, routing, observability policies
Transparent to app code
Improves traffic control and resilience
Pod stops = Envoy stops intercepting

Full Transcript

In Kubernetes, a sidecar proxy like Envoy runs as a separate container inside the same pod as the application. When the pod starts, both the app and Envoy containers launch. Envoy intercepts all outgoing and incoming network traffic for the app. Outbound requests from the app go through Envoy, which can apply policies like retries or encryption before sending them out. Responses from external services come back through Envoy, which applies inbound rules before delivering them to the app. This setup allows traffic control and security without changing the app code. When the pod stops, Envoy also stops, ending traffic interception.