Service mesh concept overview in Kubernetes - Step-by-Step Execution

Process Flow - Service mesh concept overview

Client Pod

↓

Sidecar Proxy

↓

Service Mesh Control Plane

↓

Sidecar Proxy

↓

Server Pod

The service mesh adds sidecar proxies to pods to manage communication, controlled by a central control plane.

Execution Sample

Kubernetes

kubectl apply -f service-mesh.yaml
# Deploys service mesh components
kubectl get pods -n istio-system
# Lists mesh control plane pods
kubectl get svc -n istio-system
# Shows services managed by mesh

Deploy service mesh, check control plane pods, and view services managed by the mesh.

Process Table

Step	Action	Component	Result	Notes
1	Deploy service mesh YAML	kubectl	Control plane pods start	Control plane manages mesh config
2	Client Pod sends request	Client Pod	Request intercepted by sidecar proxy	Sidecar handles routing and security
3	Sidecar proxy consults control plane	Sidecar Proxy	Receives routing rules	Control plane enforces policies
4	Sidecar proxy forwards request	Sidecar Proxy	Request sent to server pod's sidecar	Transparent to application
5	Server pod receives request	Server Pod	Processes request normally	No code change needed
6	Response sent back same path	Sidecar Proxy	Response intercepted and logged	Observability enabled
7	Exit	N/A	Communication complete	Request lifecycle finished

💡 Request completed through sidecar proxies with control plane managing policies

Status Tracker

Variable	Start	After Step 2	After Step 4	Final
Request State	Not sent	Intercepted by client sidecar	Forwarded to server sidecar	Processed by server pod
Routing Rules	Empty	Fetched from control plane	Applied to request	N/A
Policy Enforcement	None	Checked by sidecar	Enforced on request	N/A

Key Moments - 3 Insights

Why does the client pod's request go through a sidecar proxy?

Because the sidecar proxy intercepts all pod traffic to apply routing and security rules as shown in execution_table step 2.

Does the application code in pods need to change to use a service mesh?

No, the application code stays the same; the sidecar proxies handle communication transparently as seen in step 5.

What role does the control plane play in the service mesh?

The control plane provides routing and policy rules to sidecars, managing communication centrally as in step 3.

Visual Quiz - 3 Questions

Look at the execution table, at which step does the sidecar proxy get routing rules from the control plane?

A Step 2

B Step 4

C Step 3

D Step 5

💡 Hint

Check the 'Action' and 'Result' columns in execution_table row for step 3.

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

A Forwarded to server sidecar

B Intercepted by client sidecar

C Not sent

D Processed by server pod

💡 Hint

Look at 'Request State' variable in variable_tracker after step 4.

If the control plane fails, which step in the execution_table would be directly affected?

A Step 2 - Request interception

B Step 3 - Sidecar gets routing rules

C Step 5 - Server pod processes request

D Step 6 - Response sent back

💡 Hint

Control plane provides routing rules as shown in step 3.

Concept Snapshot

Service mesh adds sidecar proxies to pods.
Sidecars intercept and manage all pod communication.
Control plane centrally manages routing and policies.
No app code changes needed.
Improves security, observability, and traffic control.

Full Transcript

A service mesh works by adding a sidecar proxy to each pod. When a client pod sends a request, the sidecar proxy intercepts it. The sidecar then asks the control plane for routing and policy rules. Using these rules, the sidecar forwards the request to the server pod's sidecar proxy. The server pod processes the request normally without code changes. The response travels back through the sidecars, enabling logging and observability. This setup centralizes communication management and improves security and control without changing application code.

Practice

1. What is the main purpose of a service mesh in Kubernetes?

easy

A. To manage communication between services securely and reliably

B. To store data persistently for applications

C. To schedule pods on nodes

D. To build container images automatically

Solution

1. Step 1: Understand service mesh role

   A service mesh manages how services communicate with each other, focusing on security and reliability.

2. Step 2: Compare options

   Options B, C, and D relate to storage, scheduling, and building images, which are not service mesh functions.

3. Final Answer:

   To manage communication between services securely and reliably -> Option A

4. Quick Check:

   Service mesh = secure, reliable service communication [OK]

Hint: Service mesh controls service communication, not storage or scheduling [OK]

Common Mistakes:

• Confusing service mesh with storage or scheduling tools
• Thinking service mesh builds container images
• Assuming service mesh replaces Kubernetes itself

2. Which component is typically deployed alongside an application pod to enable a service mesh?

easy

A. A sidecar proxy

B. A persistent volume

C. A Kubernetes scheduler

D. A container registry

Solution

1. Step 1: Identify service mesh architecture

   Service meshes use sidecar proxies deployed with app pods to intercept and manage traffic.

2. Step 2: Eliminate unrelated components

   Persistent volumes store data, schedulers assign pods to nodes, and container registries store images, none manage traffic.

3. Final Answer:

   A sidecar proxy -> Option A

4. Quick Check:

   Sidecar proxy = service mesh traffic manager [OK]

Hint: Sidecar proxies run with pods to manage traffic [OK]

Common Mistakes:

• Confusing sidecar proxy with storage or scheduling components
• Thinking service mesh requires changes inside app code
• Assuming container registry is part of service mesh

3. Given a Kubernetes cluster with a service mesh installed, what happens when one service calls another?

medium

A. The call is converted into a database query

B. The call bypasses the sidecar and goes directly to the service

C. The service mesh blocks all calls by default

D. The call is routed through the sidecar proxy which handles retries and security

Solution

1. Step 1: Understand service mesh traffic flow

   Service mesh sidecars intercept calls between services to add features like retries and security.

2. Step 2: Evaluate options

   The call bypasses the sidecar and goes directly to the service is incorrect because calls do not bypass sidecars. The service mesh blocks all calls by default is wrong; calls are allowed with policies. The call is converted into a database query is unrelated.

3. Final Answer:

   The call is routed through the sidecar proxy which handles retries and security -> Option D

4. Quick Check:

   Service calls go through sidecar proxy [OK]

Hint: Service mesh sidecar proxies manage calls with retries and security [OK]

Common Mistakes:

• Assuming calls bypass the service mesh
• Thinking service mesh blocks all traffic
• Confusing service calls with database queries

4. You deployed a service mesh but notice that traffic between services is not being intercepted. What is a likely cause?

medium

A. The pods have no CPU resources assigned

B. The sidecar proxy was not injected into the pods

C. The container images are missing

D. The Kubernetes API server is down

Solution

1. Step 1: Identify why traffic is not intercepted

   Service mesh requires sidecar proxies injected into pods to intercept traffic.

2. Step 2: Rule out unrelated issues

   Kubernetes API server down or missing images cause broader failures, not just traffic interception. CPU limits affect performance but not injection.

3. Final Answer:

   The sidecar proxy was not injected into the pods -> Option B

4. Quick Check:

   Missing sidecar = no traffic interception [OK]

Hint: Check if sidecar proxy is injected in pods [OK]

Common Mistakes:

• Blaming Kubernetes API server for traffic interception issues
• Ignoring sidecar injection step
• Assuming CPU limits block traffic interception

5. You want to add fine-grained traffic control between services in your Kubernetes cluster. How does a service mesh help achieve this?

hard

A. By replacing Kubernetes networking with a custom network plugin

B. By modifying the application source code to handle traffic rules

C. By using sidecar proxies to route, split, and secure traffic without changing app code

D. By storing traffic rules in a database external to the cluster

Solution

1. Step 1: Understand service mesh traffic control features

   Service meshes use sidecar proxies to manage traffic routing, splitting, and security transparently.

2. Step 2: Evaluate other options

   By modifying the application source code to handle traffic rules requires app code changes, which service mesh avoids. By replacing Kubernetes networking with a custom network plugin is about networking plugins, not service mesh. By storing traffic rules in a database external to the cluster is unrelated to traffic control mechanisms.

3. Final Answer:

   By using sidecar proxies to route, split, and secure traffic without changing app code -> Option C

4. Quick Check:

   Sidecar proxies enable traffic control without app changes [OK]

Hint: Service mesh controls traffic via sidecars, no app code changes needed [OK]

Common Mistakes:

• Thinking app code must be changed for traffic control
• Confusing service mesh with network plugins
• Assuming traffic rules are stored externally