Debugging with kubectl debug in Kubernetes - Mini Project: Build & Apply

Debugging with kubectl debug

📖 Scenario: You are a DevOps engineer responsible for maintaining a Kubernetes cluster. One of the pods running a web application is not responding correctly. You need to debug the pod to find out what is wrong without stopping the application.

🎯 Goal: Learn how to use kubectl debug to create a debugging container inside a running pod and inspect its environment.

📋 What You'll Learn

Use kubectl debug to create a debug container

Attach to the debug container's shell

Run commands inside the debug container to inspect the pod

Exit the debug session cleanly

💡 Why This Matters

🌍 Real World

Debugging live applications running in Kubernetes without stopping them helps keep services available and reduces downtime.

💼 Career

Knowing how to use <code>kubectl debug</code> is essential for DevOps engineers and site reliability engineers to troubleshoot issues quickly in production environments.

1

Identify the pod to debug

Use kubectl get pods to list all pods in the default namespace and find the pod named webapp-12345.

Kubernetes

# Run the command to list pods and find 'webapp-12345'
# Your code here

Hint

Use kubectl get pods to see all pods and their status.

2

Start a debug container inside the pod

Use kubectl debug with the --image=busybox option to start a debug container named debugger inside the pod webapp-12345.

Kubernetes

kubectl get pods
# Start a debug container named 'debugger' inside 'webapp-12345' using the 'busybox' image
# Your code here

Hint

Use kubectl debug webapp-12345 -it --image=busybox --share-processes --container=debugger to start an interactive debug container named 'debugger'.

3

Run commands inside the debug container

Inside the debug container shell, run ps to list running processes and cat /etc/hosts to check the hosts file.

Kubernetes

kubectl get pods
kubectl debug webapp-12345 -it --image=busybox --share-processes --container=debugger
# Inside the debug container, run 'ps' and 'cat /etc/hosts'
# Your code here

Hint

Use ps to see processes and cat /etc/hosts to view the hosts file inside the debug container.

4

Exit the debug container

Type exit to leave the debug container shell and return to your local terminal.

Kubernetes

kubectl get pods
kubectl debug webapp-12345 -it --image=busybox --share-processes --container=debugger
ps
cat /etc/hosts
# Type 'exit' to leave the debug container
# Your code here

Hint

Simply type exit to end the debug session.

Practice

1. What is the main purpose of the kubectl debug command in Kubernetes?

easy

A. To delete a pod and recreate it with debug options

B. To permanently change the pod's container image

C. To scale the number of pod replicas for debugging

D. To add a temporary container with debugging tools to a running pod

Solution

1. Step 1: Understand the purpose of kubectl debug

   This command adds a temporary container to a running pod for debugging without changing the original pod.

2. Step 2: Compare other options

   Options A, B, and D describe permanent or unrelated actions, not the temporary debugging feature.

3. Final Answer:

   To add a temporary container with debugging tools to a running pod -> Option D

4. Quick Check:

   Temporary debug container = C [OK]

Hint: Remember: debug adds temporary tools, no permanent pod change [OK]

Common Mistakes:

• Thinking debug changes pod image permanently
• Confusing debug with pod scaling
• Assuming debug deletes pods

2. Which of the following is the correct syntax to start a debug session on a pod named webapp-123?

easy

A. kubectl debug --pod webapp-123 --image=busybox

B. kubectl debug webapp-123 -image=busybox

C. kubectl debug pod/webapp-123 --image=busybox

D. kubectl debug pod webapp-123 --image=busybox

Solution

1. Step 1: Recall correct kubectl debug syntax

   The correct syntax uses kubectl debug pod/NAME --image=IMAGE to specify the pod and debug container image.

2. Step 2: Analyze options

   kubectl debug pod/webapp-123 --image=busybox matches the correct syntax exactly. Options A, B, and C have syntax errors or missing slashes.

3. Final Answer:

   kubectl debug pod/webapp-123 --image=busybox -> Option C

4. Quick Check:

   Correct syntax includes 'pod/' prefix = D [OK]

Hint: Use 'pod/NAME' format with --image option for debug [OK]

Common Mistakes:

• Omitting 'pod/' prefix before pod name
• Using spaces instead of slash between 'pod' and name
• Misplacing --image option

3. What will be the output of this command if the pod api-server-1 does not exist?

kubectl debug pod/api-server-1 --image=busybox

medium

A. Error: pods "api-server-1" not found

B. A new debug container starts successfully

C. Pod is deleted and recreated with debug image

D. Command runs but no debug container is added

Solution

1. Step 1: Understand pod existence requirement

   The kubectl debug command requires the target pod to exist to add a debug container.

2. Step 2: Predict command behavior if pod missing

   If the pod does not exist, kubectl returns an error indicating the pod was not found.

3. Final Answer:

   Error: pods "api-server-1" not found -> Option A

4. Quick Check:

   Missing pod causes 'not found' error = A [OK]

Hint: Check pod exists before debug; else 'not found' error [OK]

Common Mistakes:

• Assuming debug creates pod if missing
• Expecting debug to run silently without pod
• Confusing debug with pod creation commands

4. You run kubectl debug pod/myapp --image=busybox but get an error: error: container busybox not found. What is the likely cause?

medium

A. The debug container image is missing or misspelled

B. The pod does not exist

C. The pod already has a container named busybox

D. kubectl debug requires root privileges

Solution

1. Step 1: Analyze the error message

   The error says 'container busybox not found', which usually means the image name is incorrect or missing.

2. Step 2: Check common causes

   The debug container image is missing or misspelled fits because a misspelled or missing image causes this error. The pod existence or privileges are unrelated.

3. Final Answer:

   The debug container image is missing or misspelled -> Option A

4. Quick Check:

   Image name errors cause 'container not found' message [OK]

Hint: Verify debug image name spelling and availability [OK]

Common Mistakes:

• Assuming pod absence causes this error
• Thinking debug needs root privileges
• Confusing container name with image name

5. You want to debug a running pod backend-0 but need to run a shell with root privileges inside the debug container. Which command correctly achieves this?

hard

A. kubectl debug pod/backend-0 --image=busybox --target=backend-0 -- sh

B. kubectl debug pod/backend-0 --image=busybox --privileged -- sh

C. kubectl debug pod/backend-0 --image=busybox --container=debugger -- sh

D. kubectl debug pod/backend-0 --image=busybox --as-root -- sh

Solution

1. Step 1: Identify how to run debug container with root

   The --privileged flag allows the debug container to run with root privileges.

2. Step 2: Check command correctness

   kubectl debug pod/backend-0 --image=busybox --privileged -- sh uses --privileged and runs shell sh, which is correct. Other options misuse flags or do not enable root.

3. Final Answer:

   kubectl debug pod/backend-0 --image=busybox --privileged -- sh -> Option B

4. Quick Check:

   Use --privileged to get root shell in debug container [OK]

Hint: Add --privileged flag to run debug container as root [OK]

Common Mistakes:

• Using nonexistent flags like --as-root
• Confusing --target with privilege escalation
• Omitting --privileged when root shell needed