Service mesh vs library-based approach in Kubernetes - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Key difference between service mesh and library-based approach

Which statement best describes the main difference between a service mesh and a library-based approach for managing microservice communication?

A A service mesh operates as a separate infrastructure layer managing communication, while a library-based approach requires code changes inside each service.

B Both service mesh and library-based approaches require no changes to application code and operate transparently.

C A service mesh requires modifying application code, but a library-based approach works externally without code changes.

D A library-based approach manages communication at the network level, while a service mesh is embedded inside each service.

💡 Hint

Think about where the communication logic lives: inside the app or outside it.

A service mesh runs as a separate layer (usually sidecar proxies) managing communication without changing app code. A library-based approach requires adding code to each service to handle communication.

✅ Best Practice

intermediate

Choosing between service mesh and library-based approach

You want to add observability and traffic control to your microservices without changing their code. Which approach is best?

A Rewrite all services to include communication libraries for better control.

B Use a library-based approach because it requires no infrastructure changes.

C Use a service mesh because it works without modifying service code.

D Use manual network policies to control traffic instead of either approach.

💡 Hint

Consider which approach allows adding features without touching service code.

Service meshes add features like observability and traffic control externally, so services do not need code changes. Library-based approaches require modifying each service.

💻 Command Output

advanced

Output of checking sidecar proxy in a service mesh

What is the expected output of the following command in a Kubernetes cluster using Istio service mesh?

kubectl get pods -n default -l app=myservice -o jsonpath='{.items[0].spec.containers[*].name}'

Assuming Istio sidecar injection is enabled.

A Error: no such label

B myservice

C istio-proxy

D myservice istio-proxy

💡 Hint

Think about what containers run in a pod with Istio sidecar injection.

When Istio sidecar injection is enabled, each pod has the original service container plus an 'istio-proxy' sidecar container. The command lists both container names.

❓ Troubleshoot

advanced

Troubleshooting failed communication in library-based approach

You deployed a library-based communication approach in your microservices. Suddenly, services cannot communicate. Which is the most likely cause?

A Network policies block traffic between pods.

B The communication library version is incompatible with the service runtime.

C The service mesh sidecar proxy crashed.

D The Kubernetes API server is down.

💡 Hint

Focus on what is unique to library-based approaches compared to service mesh.

Library-based approaches depend on the communication library inside the service. If the library version is incompatible, communication fails. Sidecar crashes or network policies are more common in service mesh or network issues.

🔀 Workflow

expert

Correct order to enable service mesh on existing Kubernetes services

Arrange the steps in the correct order to enable a service mesh (e.g., Istio) on existing Kubernetes services.

A 1,2,3,4

B 2,1,3,4

C 1,3,2,4

D 3,1,2,4

💡 Hint

Think about installing first, then enabling injection, then redeploying.

First, install the control plane. Then enable sidecar injection in the namespace. Next, redeploy services to get sidecars injected. Finally, verify pods have both containers.