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.

Practice

1. What is the main purpose of a sidecar proxy like Envoy in a Kubernetes pod?

easy

A. To manage network traffic for the application without changing its code

B. To replace the main application container

C. To store application data persistently

D. To run database services inside the pod

Solution

1. Step 1: Understand the role of sidecar proxies

   Sidecar proxies like Envoy run alongside the main app to handle network tasks such as routing, security, and monitoring.

2. Step 2: Identify what sidecars do not do

   They do not replace the app, store data, or run databases; they only assist with traffic management.

3. Final Answer:

   To manage network traffic for the application without changing its code -> Option A

4. Quick Check:

   Sidecar proxy = traffic manager [OK]

Hint: Sidecar proxies help apps with traffic, not replace them [OK]

Common Mistakes:

• Thinking sidecar replaces the app container
• Confusing sidecar with storage or database
• Assuming sidecar changes app code

2. Which of the following is the correct way to define a sidecar container for Envoy in a Kubernetes pod spec?

easy

A. containers: - name: app - image: envoyproxy/envoy

B. containers: - name: envoy - image: envoyproxy/envoy

C. containers: - name: envoy - image: nginx

D. containers: - name: envoyproxy - image: envoyproxy/envoy

Solution

1. Step 1: Identify the correct container name and image

   The sidecar container should be named clearly (e.g., 'envoy') and use the official Envoy image 'envoyproxy/envoy'.

2. Step 2: Check the options for correctness

   containers: - name: envoy - image: envoyproxy/envoy correctly names the container 'envoy' and uses the right image. containers: - name: app - image: envoyproxy/envoy misnames the container as 'app'. containers: - name: envoy - image: nginx uses the wrong image 'nginx'. containers: - name: envoyproxy - image: envoyproxy/envoy uses a different container name but correct image.

3. Final Answer:

   containers: - name: envoy - image: envoyproxy/envoy -> Option B

4. Quick Check:

   Envoy container name and image must match [OK]

Hint: Sidecar container name 'envoy' with image 'envoyproxy/envoy' [OK]

Common Mistakes:

• Using wrong container name for Envoy
• Using incorrect image like nginx
• Mixing app container with sidecar container

3. Given a pod with two containers: an app and an Envoy sidecar proxy, what happens when the app sends a request to an external service?

medium

A. The request goes directly from the app container to the external service without passing Envoy.

B. The request is duplicated and sent twice, once by the app and once by Envoy.

C. The request is blocked by Kubernetes and never leaves the pod.

D. The request is intercepted and routed through the Envoy sidecar proxy before reaching the external service.

Solution

1. Step 1: Understand Envoy's role as a sidecar proxy

   Envoy intercepts outbound requests from the app container to manage traffic, security, and monitoring.

2. Step 2: Trace the request flow

   The app's request is routed through Envoy before reaching the external service, enabling control and visibility.

3. Final Answer:

   The request is intercepted and routed through the Envoy sidecar proxy before reaching the external service. -> Option D

4. Quick Check:

   Envoy intercepts outbound traffic [OK]

Hint: Envoy sidecar intercepts app traffic to external services [OK]

Common Mistakes:

• Assuming app bypasses Envoy for external calls
• Thinking Kubernetes blocks outbound requests
• Believing requests are duplicated

4. You notice that your Envoy sidecar proxy is not forwarding traffic correctly. Which of the following is the most likely cause?

medium

A. The Kubernetes node is running out of CPU resources.

B. The app container image is outdated.

C. The Envoy container is missing required network permissions or capabilities.

D. The pod has only one container defined.

Solution

1. Step 1: Analyze Envoy sidecar traffic issues

   Envoy needs proper network permissions (like NET_ADMIN) to intercept and forward traffic.

2. Step 2: Evaluate other options

   App image version or node CPU issues may affect performance but not specifically Envoy forwarding. A pod with one container means no sidecar exists.

3. Final Answer:

   The Envoy container is missing required network permissions or capabilities. -> Option C

4. Quick Check:

   Envoy needs network permissions to forward traffic [OK]

Hint: Check Envoy network permissions if traffic not forwarded [OK]

Common Mistakes:

• Blaming app container image for Envoy issues
• Ignoring network capabilities needed by Envoy
• Assuming pod must have one container only

5. You want to add an Envoy sidecar proxy to an existing Kubernetes deployment without changing the app code. Which approach is best to achieve this?

hard

A. Modify the deployment YAML to add an Envoy container in the pod spec as a sidecar

B. Replace the app container image with one that includes Envoy inside

C. Create a separate pod running Envoy and route traffic through it externally

D. Add an init container that installs Envoy inside the app container at startup

Solution

1. Step 1: Understand sidecar pattern in Kubernetes

   Sidecars run as additional containers in the same pod, so modifying the pod spec to add Envoy is the standard way.

2. Step 2: Evaluate alternatives

   Replacing app image changes code, separate pods lose pod-local benefits, and init containers run before app start and can't run sidecars.

3. Final Answer:

   Modify the deployment YAML to add an Envoy container in the pod spec as a sidecar -> Option A

4. Quick Check:

   Add Envoy as sidecar container in pod spec [OK]

Hint: Add Envoy container to pod spec, no app code change needed [OK]

Common Mistakes:

• Replacing app image instead of adding sidecar
• Using separate pods losing sidecar benefits
• Misusing init containers for sidecar functionality