Why service mesh matters in Kubernetes - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to deploy a simple service in Kubernetes.

Kubernetes

kubectl create deployment myapp --image=[1]

Drag options to blanks, or click blank then click option'

Amysql

Bnginx

Credis

Dpostgres

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing a database image instead of a web server.

The nginx image is a common lightweight web server used for simple service deployment.

2fill in blank

medium

Complete the command to expose the deployment as a service.

Kubernetes

kubectl expose deployment myapp --type=[1] --port=80

Drag options to blanks, or click blank then click option'

ALoadBalancer

BClusterIP

CNodePort

DExternalName

Attempts:

3 left

💡 Hint

Common Mistakes

Using ClusterIP which only exposes service inside the cluster.

LoadBalancer exposes the service externally using a cloud provider's load balancer.

3fill in blank

hard

Fix the error in the service mesh sidecar injection command.

Kubernetes

kubectl label namespace default istio-injection=[1]

Drag options to blanks, or click blank then click option'

Aenabled

Bdisable

Coff

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'off' or 'disable' which turns injection off.

To enable automatic sidecar injection, the label value must be enabled.

4fill in blank

hard

Fill both blanks to create a service mesh policy that allows traffic only from a specific service.

Kubernetes

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-specific
  namespace: default
spec:
  selector:
    matchLabels:
      app: [1]
  rules:
  - from:
    - source:
        principals: ["[2]"]

Drag options to blanks, or click blank then click option'

Areviews

Bratings

Ccluster.local/ns/default/sa/reviews

Dcluster.local/ns/default/sa/ratings

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing labels and principals incorrectly.

The policy selects pods with label app: reviews and allows traffic only from the service account reviews in the default namespace.

5fill in blank

hard

Fill all three blanks to define a traffic routing rule in Istio VirtualService.

Kubernetes

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp.example.com
  http:
  - route:
    - destination:
        host: [1]
        subset: [2]
      weight: [3]

Drag options to blanks, or click blank then click option'

Amyapp

Bv1

C80

Dv2

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong subset or weight values.

The rule routes 80% of traffic to subset v1 of the host myapp.

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