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

Practice - 5 Tasks

1fill in blank

easy

Complete the code to deploy a service mesh sidecar proxy in Kubernetes.

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: myapp
    image: myapp:latest
  - name: [1]
    image: envoyproxy/envoy:v1.18-latest

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

Alibrary-agent

Bservice-mesh

Cmesh-controller

Dsidecar-proxy

Attempts:

3 left

💡 Hint

Common Mistakes

Using the application container name instead of the sidecar proxy name.

Confusing the service mesh control plane with the sidecar proxy.

The sidecar proxy container is added alongside the application container to handle service mesh traffic.

2fill in blank

medium

Complete the statement to describe a library-based approach in microservices.

Kubernetes

In a library-based approach, the application code includes a [1] to handle networking and security.

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

Aservice mesh

Blibrary

Csidecar proxy

Dcontroller

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing 'sidecar proxy' which is part of service mesh, not library-based.

Confusing the control plane with the library.

The library is embedded in the application to provide features like networking and security without a separate proxy.

3fill in blank

hard

Fix the error in the description of service mesh benefits.

Kubernetes

Service mesh provides [1] management, observability, and security without changing application code.

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

Amanual

Boptional

Cautomatic

Dpartial

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing 'manual' which contradicts the purpose of service mesh.

Selecting 'optional' which is vague and incorrect here.

Service mesh automatically manages traffic and security, so developers don't need to change application code.

4fill in blank

hard

Fill both blanks to complete the comparison between service mesh and library-based approach.

Kubernetes

Service mesh uses a [1] proxy, while library-based approach embeds [2] in the application code.

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

Asidecar

Ba separate

Ca library

Da sidecar

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing up 'sidecar' and 'library' terms.

Using 'a separate' which is incomplete without proxy.

Service mesh uses a sidecar proxy container, while library-based approach uses a library embedded in the app code.

5fill in blank

hard

Fill all three blanks to complete the Kubernetes manifest snippet for injecting a service mesh sidecar.

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  template:
    metadata:
      annotations:
        [1]: "enabled"
    spec:
      containers:
      - name: myapp
        image: myapp:latest
      - name: [2]
        image: [3]

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

Asidecar.istio.io/inject

Bistio-proxy

Cenvoyproxy/envoy:v1.18-latest

Dmesh.istio.io/inject

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong annotation keys.

Incorrect container names or images.

The annotation 'sidecar.istio.io/inject' enables sidecar injection. The sidecar container is named 'istio-proxy' and uses the Envoy image.

Practice

1. What is the main difference between a service mesh and a library-based approach in Kubernetes?

easy

A. Service mesh requires changing app code, library-based works externally

B. Service mesh is for storage, library-based is for networking

C. Service mesh only works with databases, library-based only with APIs

D. Service mesh manages communication outside the app, library-based adds code inside the app

Solution

1. Step 1: Understand service mesh role

   A service mesh manages communication between services outside the app, usually with sidecar proxies.

2. Step 2: Understand library-based approach

   Library-based approach adds communication features inside the app code itself.

3. Final Answer:

   Service mesh manages communication outside the app, library-based adds code inside the app -> Option D

4. Quick Check:

   Service mesh = external, library-based = internal [OK]

Hint: Service mesh is external, library-based is inside app code [OK]

Common Mistakes:

• Confusing which approach requires code changes
• Thinking service mesh only works with databases
• Mixing up external vs internal communication handling

2. Which of the following is a correct statement about implementing a service mesh in Kubernetes?

easy

A. Service mesh uses sidecar proxies injected alongside application pods

B. You must modify each application's source code to use the service mesh

C. Service mesh replaces Kubernetes networking completely

D. Service mesh only works with monolithic applications

Solution

1. Step 1: Recall service mesh architecture

   Service mesh typically uses sidecar proxies injected into pods to handle communication externally.

2. Step 2: Evaluate other options

   Modifying app code is not required; it does not replace Kubernetes networking; it works with microservices too.

3. Final Answer:

   Service mesh uses sidecar proxies injected alongside application pods -> Option A

4. Quick Check:

   Sidecar proxies = service mesh [OK]

Hint: Sidecar proxies run alongside apps in service mesh [OK]

Common Mistakes:

• Thinking app code must be changed for service mesh
• Believing service mesh replaces Kubernetes networking
• Assuming service mesh only supports monoliths

3. Given a Kubernetes app using a library-based approach for service communication, what is the expected output if the app code does not include the library?

medium

A. The app will fail to communicate with other services

B. The app will automatically use a service mesh fallback

C. The app will communicate normally without any issues

D. The app will crash immediately on startup

Solution

1. Step 1: Understand library-based approach dependency

   Library-based approach requires the app code to include the communication library to work properly.

2. Step 2: Predict behavior without library

   If the library is missing, the app cannot handle communication as expected and will fail to connect to other services.

3. Final Answer:

   The app will fail to communicate with other services -> Option A

4. Quick Check:

   Missing library = communication failure [OK]

Hint: Library missing means communication fails [OK]

Common Mistakes:

• Assuming app works without library in library-based approach
• Thinking service mesh auto-fallback happens
• Confusing app crash with communication failure

4. You deployed a service mesh but notice your app is not routing traffic correctly. Which is the most likely cause?

medium

A. The app code lacks the required communication library

B. Sidecar proxy injection failed or is missing

C. The Kubernetes cluster is down

D. The app is using an unsupported programming language

Solution

1. Step 1: Identify service mesh traffic handling

   Service mesh relies on sidecar proxies injected into pods to route traffic correctly.

2. Step 2: Analyze common deployment issues

   If traffic is not routing, a common cause is sidecar proxy injection failure or absence.

3. Final Answer:

   Sidecar proxy injection failed or is missing -> Option B

4. Quick Check:

   Missing sidecar = routing issues [OK]

Hint: Check sidecar proxy injection for routing issues [OK]

Common Mistakes:

• Blaming app code library in service mesh setup
• Assuming cluster is down without checking
• Thinking language support affects routing directly

5. You want to add observability and security features to your Kubernetes microservices without changing app code. Which approach is best and why?

hard

A. Rewrite apps to include custom communication logic

B. Use a library-based approach to add features inside each app

C. Use a service mesh to manage features externally with sidecars

D. Disable all communication features for simplicity

Solution

1. Step 1: Identify requirement to avoid app code changes

   The question states no changes to app code are desired.

2. Step 2: Match approach to requirement

   Service mesh manages communication externally using sidecars, so it adds features without touching app code.

3. Step 3: Evaluate other options

   Library-based requires code changes; rewriting apps is costly; disabling features is not helpful.

4. Final Answer:

   Use a service mesh to manage features externally with sidecars -> Option C

5. Quick Check:

   No code change = service mesh best [OK]

Hint: No code change? Choose service mesh [OK]

Common Mistakes:

• Choosing library-based despite no code change allowed
• Thinking rewriting apps is easier
• Ignoring observability and security needs