Why service mesh matters in Kubernetes - See It in Action

Why Service Mesh Matters

📖 Scenario: You are working in a company that runs many small applications inside a Kubernetes cluster. These applications need to talk to each other securely and reliably. You want to understand how a service mesh can help manage this communication.

🎯 Goal: Learn the basics of why a service mesh is important by creating a simple Kubernetes setup with two services and adding a service mesh configuration to manage their communication.

📋 What You'll Learn

Create two Kubernetes services with pods

Add a label to identify services for the mesh

Configure a simple service mesh policy for communication

Display the status of the service mesh setup

💡 Why This Matters

🌍 Real World

Service meshes help manage communication between many small services in Kubernetes, improving security, reliability, and observability.

💼 Career

Understanding service mesh basics is important for Kubernetes administrators and DevOps engineers to build scalable and secure cloud-native applications.

1

Create two Kubernetes services

Create two Kubernetes services called service-a and service-b each with a pod running the nginx image. Use labels app: service-a and app: service-b respectively.

Kubernetes

# Create two Kubernetes services with pods
# Your code here

Hint

Use Kubernetes Pod and Service YAML definitions with correct labels and selectors.

2

Add labels for service mesh

Add the label mesh: enabled to both pods pod-a and pod-b to mark them for service mesh management.

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: pod-a
  labels:
    app: service-a
    # Add mesh label here
spec:
  containers:
  - name: nginx
    image: nginx
# Your code here

Hint

Add the label under metadata.labels for each pod.

3

Configure simple service mesh policy

Create a Kubernetes ConfigMap named mesh-policy with data key allow-communication set to service-a to service-b to simulate a mesh policy allowing communication from service-a to service-b.

Kubernetes

apiVersion: v1
kind: ConfigMap
metadata:
  name: mesh-policy
  # Add data key and value below
# Your code here

Hint

Use data field in ConfigMap to add the key and value.

4

Display service mesh status

Write a command to display the ConfigMap mesh-policy data to show the service mesh policy status.

Kubernetes

# Write the kubectl command to show the mesh-policy ConfigMap data
# Your code here

Hint

Use kubectl get configmap mesh-policy -o yaml to see the data.

Practice

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

easy

A. To build user interfaces for applications

B. To store application data persistently

C. To manage communication between microservices without changing their code

D. To replace Kubernetes cluster networking

Solution

1. Step 1: Understand service mesh role

   A service mesh helps microservices talk to each other without modifying their code.

2. Step 2: Compare options

   The other options describe unrelated tasks like building user interfaces, storing data persistently, or replacing Kubernetes networking.

3. Final Answer:

   To manage communication between microservices without changing their code -> Option C

4. Quick Check:

   Service mesh = communication management [OK]

Hint: Service mesh = communication layer, not storage or UI [OK]

Common Mistakes:

• Confusing service mesh with data storage
• Thinking service mesh builds user interfaces
• Assuming service mesh replaces Kubernetes networking

2. Which of the following is a correct feature provided by a service mesh?

easy

A. Automatic load balancing between services

B. Compiling application source code

C. Creating Kubernetes pods manually

D. Managing database schemas

Solution

1. Step 1: Identify service mesh features

   Service mesh provides features like load balancing, security, and observability between services.

2. Step 2: Eliminate unrelated options

   Compiling code, creating pods manually, and managing database schemas are not service mesh tasks.

3. Final Answer:

   Automatic load balancing between services -> Option A

4. Quick Check:

   Load balancing = service mesh feature [OK]

Hint: Service mesh handles traffic, not code or DB tasks [OK]

Common Mistakes:

• Confusing service mesh with build tools
• Thinking service mesh creates pods manually
• Assuming service mesh manages databases

3. Given a microservices app without a service mesh, what is a likely outcome when one service fails?

medium

A. Communication between services may fail without retries or observability

B. Other services automatically retry and route around the failure

C. The entire app crashes immediately

D. The failed service restarts itself without intervention

Solution

1. Step 1: Understand failure handling without service mesh

   Without a service mesh, services lack automatic retries, routing, and observability.

2. Step 2: Analyze options

   Other services automatically retry and route around the failure describes service mesh behavior. The entire app crashes immediately is too extreme. The failed service restarts itself without intervention is about service restart, not communication.

3. Final Answer:

   Communication between services may fail without retries or observability -> Option A

4. Quick Check:

   No service mesh = no automatic retries [OK]

Hint: No service mesh means no automatic communication fixes [OK]

Common Mistakes:

• Assuming app crashes immediately on one failure
• Thinking services auto-retry without mesh
• Confusing service restart with communication handling

4. You deployed a service mesh but notice no traffic routing improvements. What is a common mistake causing this?

medium

A. Setting CPU limits too low on pods

B. Using the wrong container image for your app

C. Deleting Kubernetes namespaces accidentally

D. Not injecting the service mesh sidecar proxy into pods

Solution

1. Step 1: Identify service mesh setup requirements

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

2. Step 2: Evaluate common errors

   Wrong container images, namespace deletion, or CPU limits do not directly stop service mesh routing.

3. Final Answer:

   Not injecting the service mesh sidecar proxy into pods -> Option D

4. Quick Check:

   Missing sidecar = no mesh routing [OK]

Hint: Check sidecar injection to enable service mesh features [OK]

Common Mistakes:

• Ignoring sidecar injection step
• Blaming unrelated pod resource limits
• Confusing namespace issues with mesh setup

5. In a Kubernetes app with many microservices, how does a service mesh improve security and observability?

hard

A. By automatically scaling pods based on CPU usage

B. By encrypting service-to-service traffic and providing detailed telemetry data

C. By storing logs in a centralized database

D. By replacing Kubernetes network plugins

Solution

1. Step 1: Understand security and observability roles

   Service mesh encrypts traffic between services and collects telemetry for monitoring.

2. Step 2: Compare other options

   Scaling pods, storing logs, or replacing network plugins are not primary service mesh functions.

3. Final Answer:

   By encrypting service-to-service traffic and providing detailed telemetry data -> Option B

4. Quick Check:

   Service mesh = encryption + telemetry [OK]

Hint: Service mesh secures and monitors service communication [OK]

Common Mistakes:

• Confusing scaling with security features
• Thinking service mesh stores logs directly
• Assuming it replaces Kubernetes networking