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.