Sidecar proxy concept (Envoy) in Kubernetes - Mini Project: Build & Apply

Sidecar Proxy Concept with Envoy in Kubernetes

📖 Scenario: You are working in a Kubernetes environment where you want to add a sidecar proxy to your application pod. This proxy will help manage network traffic for your app securely and efficiently.Envoy is a popular sidecar proxy used in service meshes. In this project, you will create a simple Kubernetes pod manifest that includes an Envoy sidecar container alongside your main application container.

🎯 Goal: Build a Kubernetes pod manifest YAML file that defines a pod with two containers: one for your application and one for the Envoy sidecar proxy. This setup will help you understand how sidecar proxies work in Kubernetes.

📋 What You'll Learn

Create a Kubernetes pod manifest named pod.yaml.

Define a pod with metadata name app-with-envoy.

Add two containers: app-container running nginx image and envoy-proxy running envoyproxy/envoy:v1.22.0 image.

Configure the Envoy container with a volume mount for its configuration file.

Add a ConfigMap named envoy-config with a basic Envoy configuration.

Mount the ConfigMap as a volume in the Envoy container.

💡 Why This Matters

🌍 Real World

Sidecar proxies like Envoy are used in Kubernetes to manage network traffic, add security, and enable observability without changing the application code.

💼 Career

Understanding how to configure sidecar proxies is essential for roles in cloud engineering, DevOps, and site reliability engineering where managing microservices traffic is common.

1

Create the basic pod manifest with the app container

Create a Kubernetes pod manifest file named pod.yaml with a pod named app-with-envoy. Add a single container named app-container using the image nginx.

Kubernetes

# Your code here to create pod.yaml with app-container using nginx image

Hint

Start with apiVersion: v1 and kind: Pod. Under spec, add containers list with one container named app-container using nginx image.

2

Add the Envoy sidecar container with volume mount

In the same pod.yaml, add a second container named envoy-proxy using the image envoyproxy/envoy:v1.22.0. Mount a volume named envoy-config-volume at /etc/envoy inside the Envoy container.

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: app-with-envoy
spec:
  containers:
  - name: app-container
    image: nginx
  # Add envoy-proxy container with volume mount below

Hint

Under containers, add the Envoy container with volumeMounts. Then add volumes section referencing the ConfigMap envoy-config.

3

Create the Envoy ConfigMap with basic configuration

Create a ConfigMap named envoy-config with a key envoy.yaml containing a minimal Envoy configuration that listens on port 10000 and routes traffic to localhost:80.

Kubernetes

# Your code here to create ConfigMap named envoy-config with envoy.yaml key and minimal config

Hint

Use apiVersion: v1 and kind: ConfigMap. Add envoy.yaml key with a minimal Envoy config that listens on port 10000 and routes to localhost port 80.

4

Display the pod manifest and ConfigMap to verify

Print the contents of pod.yaml and the Envoy ConfigMap to verify your setup. Use kubectl apply -f pod.yaml --dry-run=client -o yaml and kubectl get configmap envoy-config -o yaml commands.

Kubernetes

# Run the following commands to display the pod manifest and ConfigMap
# kubectl apply -f pod.yaml --dry-run=client -o yaml
# kubectl get configmap envoy-config -o yaml

Hint

Use kubectl apply -f pod.yaml --dry-run=client -o yaml to see the pod manifest and kubectl get configmap envoy-config -o yaml to see the ConfigMap.

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