Linkerd as lightweight alternative in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why choose Linkerd over other service meshes?

Linkerd is known as a lightweight service mesh. Which of the following reasons best explains why someone might choose Linkerd instead of a heavier service mesh like Istio?

A Linkerd has a smaller resource footprint and simpler setup, making it easier to run on limited hardware.

B Linkerd supports more complex policy configurations and custom resource definitions than Istio.

C Linkerd requires manual sidecar injection, which gives more control over deployments.

D Linkerd uses a custom network protocol that replaces HTTP/2 for faster communication.

💡 Hint

Think about what 'lightweight' means in terms of resource use and complexity.

Linkerd is designed to be simple and use fewer resources, making it ideal for smaller clusters or those with limited hardware. It focuses on ease of use and performance rather than extensive features.

💻 Command Output

intermediate

Output of Linkerd check command

What is the expected output when running linkerd check on a healthy Kubernetes cluster with Linkerd installed?

Kubernetes

linkerd check

A Status check results are all green with messages like 'linkerd control plane is up and running' and 'data plane proxies are injected and ready'.

B Error messages indicating missing CRDs and control plane pods not found.

C A syntax error because 'linkerd check' requires additional flags.

D Output showing only the version of Linkerd installed without any status checks.

💡 Hint

Think about what a health check command should report if everything is working.

The linkerd check command verifies the health of the Linkerd control plane and data plane. When all components are healthy, it reports green status messages confirming readiness.

❓ Configuration

advanced

Configuring automatic proxy injection in Linkerd

You want to enable automatic sidecar proxy injection for a Kubernetes namespace named production. Which command correctly enables this feature?

A kubectl annotate namespace production linkerd.io/auto-inject=true

B kubectl annotate namespace production linkerd.io/inject=enabled

C kubectl label namespace production linkerd.io/auto-inject=true

D kubectl label namespace production linkerd.io/inject=enabled

💡 Hint

Think about whether Linkerd uses labels or annotations for enabling injection.

Linkerd uses an annotation linkerd.io/inject=enabled on the namespace to enable automatic proxy injection for pods created in that namespace.

❓ Troubleshoot

advanced

Diagnosing Linkerd proxy injection failure

You deployed an application in a namespace annotated for Linkerd injection, but the pods do not have the Linkerd proxy sidecar. Which of the following is the most likely cause?

A The application container image is missing the Linkerd proxy binary.

B The Linkerd control plane pods are running but the Kubernetes API server is down.

C The namespace annotation <code>linkerd.io/inject=enabled</code> was applied after the pods were created.

D The pod spec has <code>linkerd.io/inject: disabled</code> annotation overriding the namespace annotation.

💡 Hint

Consider when annotations take effect and how pods get injected.

Linkerd injects proxies only when pods are created in a namespace annotated for injection. If the annotation is added after pods exist, those pods won't have the proxy until restarted or recreated.

🔀 Workflow

expert

Steps to migrate from Istio to Linkerd with minimal downtime

You want to replace Istio with Linkerd in your Kubernetes cluster without causing downtime. Which sequence of steps is the correct order to achieve this?

A 1,3,2,4

B 2,1,3,4

C 2,3,1,4

D 1,2,3,4

💡 Hint

Think about installing Linkerd first, then enabling injection, then restarting pods, and finally removing Istio.

The correct migration order is to first install Linkerd, then annotate namespaces to enable injection, restart pods to get Linkerd proxies, and finally remove Istio to avoid downtime.

Practice

1. What is the main advantage of using Linkerd as a service mesh in Kubernetes?

easy

A. It replaces Kubernetes networking completely

B. It requires complex setup and high resource usage

C. It only works with virtual machines, not containers

D. It is lightweight and uses fewer resources

Solution

1. Step 1: Understand Linkerd's design goal

   Linkerd is designed to be a lightweight service mesh that adds security and observability without heavy resource use.

2. Step 2: Compare options with Linkerd's features

   Options B, C, and D describe incorrect or unrelated features. Linkerd is easy to install and uses fewer resources.

3. Final Answer:

   It is lightweight and uses fewer resources -> Option D

4. Quick Check:

   Lightweight = It is lightweight and uses fewer resources [OK]

Hint: Linkerd is known for being simple and light [OK]

Common Mistakes:

• Thinking Linkerd is complex to install
• Confusing Linkerd with full Kubernetes replacement
• Assuming it only works outside containers

2. Which command is used to add Linkerd's proxy to your Kubernetes application pods?

easy

A. linkerd inject

B. linkerd install

C. kubectl apply

D. kubectl expose

Solution

1. Step 1: Identify the command for proxy injection

   The linkerd inject command adds the Linkerd proxy sidecar to your app pods.

2. Step 2: Differentiate from other commands

   linkerd install sets up Linkerd control plane, kubectl apply applies configs, and kubectl expose creates services.

3. Final Answer:

   linkerd inject -> Option A

4. Quick Check:

   Proxy injection = linkerd inject [OK]

Hint: Inject adds proxy; install sets up control plane [OK]

Common Mistakes:

• Using linkerd install to inject proxies
• Confusing kubectl expose with proxy injection
• Skipping inject step after install

3. What is the output of this command sequence?

linkerd install | kubectl apply -f -
kubectl get pods -n linkerd

A) Shows error: command not found B) Injects proxy into app pods C) Deletes Linkerd namespace D) Installs Linkerd control plane and lists its pods

medium

A. Shows error: command not found

B. Injects proxy into app pods

C. Installs Linkerd control plane and lists its pods

D. Deletes Linkerd namespace

Solution

1. Step 1: Understand the command sequence

   linkerd install outputs YAML to install Linkerd control plane; piping it to kubectl apply -f - applies it to the cluster.

2. Step 2: Check the second command

   kubectl get pods -n linkerd lists pods in the Linkerd namespace, showing control plane pods running.

3. Final Answer:

   Installs Linkerd control plane and lists its pods -> Option C

4. Quick Check:

   Install + list pods = Installs Linkerd control plane and lists its pods [OK]

Hint: Install outputs YAML; apply deploys it; get pods shows status [OK]

Common Mistakes:

• Thinking inject happens with install
• Assuming namespace is deleted
• Expecting error without Linkerd installed

4. You ran linkerd inject deployment.yaml | kubectl apply -f - but your pods do not show the Linkerd proxy. What is the likely issue?

medium

A. kubectl apply command is incorrect

B. The Linkerd control plane is not installed

C. The deployment.yaml file is empty

D. Linkerd does not support proxy injection

Solution

1. Step 1: Check prerequisites for proxy injection

   Proxy injection requires the Linkerd control plane to be installed and running in the cluster.

2. Step 2: Analyze other options

   An empty deployment file would cause errors, incorrect kubectl apply syntax would fail, and Linkerd does support proxy injection.

3. Final Answer:

   The Linkerd control plane is not installed -> Option B

4. Quick Check:

   Proxy injection needs control plane installed [OK]

Hint: Proxy injection fails if control plane missing [OK]

Common Mistakes:

• Ignoring control plane installation
• Assuming deployment file is always correct
• Thinking kubectl apply syntax is wrong

5. You want to deploy a small Kubernetes app with minimal overhead but still want observability and security features. Which approach best uses Linkerd as a lightweight alternative?

hard

A. Install Linkerd control plane, then inject proxies into app pods using linkerd inject

B. Replace Kubernetes networking with Linkerd and disable proxies

C. Use Linkerd only on some nodes and skip installation on others

D. Manually add proxies to pods without using Linkerd commands

Solution

1. Step 1: Identify the correct lightweight setup

   Linkerd's lightweight approach is to install its control plane and inject proxies into app pods to add features with minimal resource use.

2. Step 2: Evaluate other options

   Replacing Kubernetes networking is not supported, partial node installation is not standard, and manual proxy addition is error-prone and not recommended.

3. Final Answer:

   Install Linkerd control plane, then inject proxies into app pods using linkerd inject -> Option A

4. Quick Check:

   Install + inject = lightweight Linkerd use [OK]

Hint: Install control plane, then inject proxies for lightweight setup [OK]

Common Mistakes:

• Trying to replace Kubernetes networking
• Skipping control plane installation
• Manually modifying pods without Linkerd tools