Service mesh concept overview in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the primary role of a service mesh in Kubernetes?

Choose the best description of what a service mesh does in a Kubernetes environment.

A It stores container images and manages image versions for deployments.

B It schedules pods onto nodes based on resource availability and affinity rules.

C It manages network traffic between microservices, providing features like load balancing, security, and observability.

D It monitors CPU and memory usage of nodes and automatically scales the cluster size.

💡 Hint

Think about what helps microservices communicate securely and reliably inside Kubernetes.

A service mesh handles communication between microservices, adding features like load balancing, security (mTLS), and observability without changing application code.

💻 Command Output

intermediate

Output of Istio sidecar injection command

What is the output when you run the following command to label a namespace for automatic Istio sidecar injection?

kubectl label namespace default istio-injection=enabled

A namespace/default labeled

B Error from server (NotFound): namespaces "default" not found

C Warning: label istio-injection already exists

D namespace/default created

💡 Hint

Labeling a namespace adds a label; it does not create or delete namespaces.

The command adds the label 'istio-injection=enabled' to the existing 'default' namespace and confirms with 'namespace/default labeled'.

❓ Configuration

advanced

Correct YAML snippet for enabling mutual TLS in Istio

Which YAML snippet correctly enables mutual TLS (mTLS) for all services in the default namespace using Istio PeerAuthentication?

A

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT

B

apiVersion: security.istio.io/v1alpha1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    enabled: true

C

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: default
  namespace: default
spec:
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

D

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: default
  namespace: default
spec:
  rules:
  - from:
    - source:
        principals: ["*"]

💡 Hint

Look for the correct apiVersion and kind that configures mTLS mode strictly.

PeerAuthentication with apiVersion security.istio.io/v1beta1 and mtls mode STRICT enables mutual TLS for all workloads in the namespace.

❓ Troubleshoot

advanced

Troubleshooting failed service-to-service communication in a service mesh

You deployed two microservices in Kubernetes with Istio service mesh enabled. Service A cannot reach Service B. Which of the following is the most likely cause?

A The cluster's DNS server is down, so pod names cannot be resolved.

B Service B's pod does not have the Istio sidecar proxy injected.

C Service A's container image is outdated and missing dependencies.

D The Kubernetes node running Service A is out of disk space.

💡 Hint

In a service mesh, communication depends on sidecar proxies intercepting traffic.

If Service B's pod lacks the Istio sidecar proxy, the mesh cannot route traffic to it, causing communication failure.

✅ Best Practice

expert

Best practice for securing service-to-service communication in a service mesh

Which practice is considered best for securing communication between microservices in a service mesh?

A Use plain HTTP for internal services and HTTPS only for external traffic.

B Disable encryption to reduce latency and rely on network firewalls only.

C Manually configure IP whitelists for each service instead of using mesh policies.

D Enable mutual TLS (mTLS) with strict mode and rotate certificates regularly.

💡 Hint

Think about encryption and automated security features in service meshes.

Enabling mTLS with strict mode ensures encrypted, authenticated communication. Regular certificate rotation maintains security.

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