Debugging with kubectl debug in Kubernetes - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the purpose of the kubectl debug command?

The kubectl debug command helps you create a temporary debugging container or pod to inspect and fix issues in your running Kubernetes pods without changing the original pod.

beginner

How does kubectl debug differ from kubectl exec?

kubectl exec runs commands inside an existing container, while kubectl debug can create a new debugging container or pod with extra tools to help investigate problems.

intermediate

How do you create an ephemeral container inside a running pod with kubectl debug?

Run kubectl debug <pod-name> --image=busybox --target=<container-name> without the --copy-to flag to add a temporary container inside a running pod for debugging.

intermediate

Why are ephemeral containers useful for debugging?

Ephemeral containers let you add debugging tools to a running pod without restarting or changing it, so you can inspect the pod's state safely and quickly.

beginner

What is a common use case for kubectl debug when a pod is stuck or not responding?

You can use kubectl debug to start a new pod with the same configuration or add an ephemeral container to inspect logs, network, or file system to find the cause of the problem.

What does kubectl debug pod-name --image=busybox do?

A Deletes the pod and creates a new one

B Adds a temporary container inside a running pod for debugging

C Executes a command inside the main container

D Scales the pod to zero replicas

It adds a temporary container inside the running pod to help with debugging.

Which command helps you create a new pod for debugging based on an existing pod's configuration?

A kubectl debug pod-name --copy-to=new-pod

B kubectl exec pod-name

C kubectl delete pod-name

D kubectl scale pod-name

The --copy-to option creates a new pod for debugging using the existing pod's setup.

Why might you prefer kubectl debug over restarting a pod to fix an issue?

A It automatically fixes the bug

B It deletes the pod faster

C It scales the pod to multiple replicas

D It allows inspection without stopping the pod

kubectl debug lets you inspect the pod live without restarting or interrupting it.

Which of these is NOT a feature of kubectl debug?

A Automatically fixing pod errors

B Creating a copy pod for debugging

C Running debugging tools inside pods

D Adding ephemeral containers

kubectl debug helps inspect and troubleshoot but does not automatically fix errors.

What is the first step to start debugging a pod with kubectl debug?

A Restart the Kubernetes cluster

B Delete the pod

C Identify the pod name you want to debug

D Scale the pod to zero

You need to know the pod name to target it for debugging.

Explain how kubectl debug helps troubleshoot a stuck pod.

Think about how you can add tools or create a copy pod to look inside without stopping the original pod.

Describe the difference between kubectl exec and kubectl debug.

Consider what each command does inside or outside the pod.

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