Bird
Raised Fist0
Kubernetesdevops~5 mins

Sidecar proxy concept (Envoy) in Kubernetes - Cheat Sheet & Quick Revision

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Recall & Review
beginner
What is a sidecar proxy in Kubernetes?
A sidecar proxy is a helper container that runs alongside the main application container in the same pod. It manages network traffic, security, and communication without changing the main app.
Click to reveal answer
beginner
What role does Envoy play as a sidecar proxy?
Envoy acts as a sidecar proxy to handle service-to-service communication, load balancing, and security features like encryption, making apps more reliable and secure.
Click to reveal answer
intermediate
Why use a sidecar proxy instead of modifying the application?
Using a sidecar proxy lets you add features like traffic control and security without changing the app code. It keeps the app simple and focuses on its main job.
Click to reveal answer
intermediate
How does Envoy improve security in a Kubernetes environment?
Envoy encrypts traffic between services and can enforce policies, helping protect data and control who talks to whom inside the cluster.
Click to reveal answer
beginner
What is the main benefit of running Envoy as a sidecar proxy in a pod?
It provides consistent network features like retries, timeouts, and monitoring for the app without changing the app itself.
Click to reveal answer
What does a sidecar proxy typically run alongside in Kubernetes?
AThe Kubernetes master node
BA separate pod in the cluster
CThe main application container in the same pod
DA different namespace
Which of the following is a key feature of Envoy as a sidecar proxy?
ARunning database queries
BStoring application data
CScheduling pods
DManaging service-to-service communication
Why is a sidecar proxy preferred over modifying the application for network features?
AIt avoids changing the app code
BIt makes the app slower
CIt requires more resources
DIt disables security
How does Envoy enhance security between services?
ABy encrypting traffic and enforcing policies
BBy storing passwords
CBy running antivirus scans
DBy blocking all traffic
What is NOT a responsibility of a sidecar proxy like Envoy?
ALoad balancing
BApplication business logic
CTraffic routing
DMonitoring network traffic
Explain the concept of a sidecar proxy and why Envoy is commonly used for this purpose in Kubernetes.
Think about how adding helpers can improve communication without changing the main worker.
You got /4 concepts.
    Describe how Envoy as a sidecar proxy improves security and reliability in a Kubernetes environment.
    Consider how Envoy acts like a traffic controller and security guard for app communication.
    You got /4 concepts.

      Practice

      (1/5)
      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