Debugging with kubectl debug in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Output of kubectl debug creating ephemeral container

What is the output when running this command to add an ephemeral debug container to a running pod named webapp in namespace prod?

Kubernetes

kubectl debug -n prod -it webapp --image=busybox --target=webapp -- sh

A ephemeralcontainers "webapp-debugger" created in pod webapp

B Pod/webapp created in namespace prod

C Error from server (NotFound): pods "webapp" not found

D Warning: image busybox not found locally, pulling...

💡 Hint

Think about what kubectl debug does when adding ephemeral containers.

The command adds an ephemeral container named webapp-debugger to the existing pod webapp. The output confirms creation of the ephemeral container.

❓ Troubleshoot

intermediate

Troubleshooting kubectl debug failure due to missing target

You run kubectl debug -it mypod --image=busybox --target=app but get an error. What is the most likely cause?

A The image busybox is not available in the cluster

B The pod mypod does not exist in the current namespace

C The container named app does not exist in pod mypod

D kubectl debug requires --container flag instead of --target

💡 Hint

Check if the container name matches exactly inside the pod.

The --target flag specifies the container inside the pod to debug. If the container name is wrong or missing, kubectl debug fails with an error.

❓ Configuration

advanced

Configuring a pod to allow ephemeral containers

Which pod spec snippet correctly enables ephemeral containers for debugging?

A

spec:
  enableEphemeralContainers: true

B

metadata:
  annotations:
    ephemeral-containers.kubernetes.io/enabled: "true"

C

spec:
  ephemeralContainers:
  - name: debug
    image: busybox

D No special configuration is needed; ephemeral containers are enabled by default

💡 Hint

Consider the default Kubernetes behavior for ephemeral containers.

Ephemeral containers are enabled by default in Kubernetes 1.23+ and do not require special pod spec configuration.

✅ Best Practice

advanced

Best practice for debugging a pod with kubectl debug

What is the recommended approach to debug a running pod without disrupting its main containers?

A Delete the pod and recreate it with a debug container

B Add an ephemeral container using kubectl debug

C Modify the pod spec to add a permanent debug container

D Use kubectl exec to run commands inside the main container

💡 Hint

Think about non-disruptive debugging methods.

Adding an ephemeral container allows debugging without stopping or changing the main containers, minimizing disruption.

🧠 Conceptual

expert

Understanding ephemeral container lifecycle

Which statement about ephemeral containers added via kubectl debug is TRUE?

A Ephemeral containers are intended for temporary debugging and do not restart automatically

B Ephemeral containers restart automatically if they exit

C Ephemeral containers share the same lifecycle as the pod's main containers

D Ephemeral containers require pod restart to be removed

💡 Hint

Consider how ephemeral containers behave compared to normal containers.

Ephemeral containers are temporary and do not restart automatically if they exit; they are meant for short-term debugging.

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