Troubleshoot Kubernetes with Claude Code + MCP

Intermediate

Put the read-only MCP lab to work. Diagnose the crashing pod from Lesson 1 entirely through Claude Code — reading pods, events, and logs — separate the CrashLoopBackOff symptom from its real root cause, and prove the agent can fully explain the failure while being unable to change anything. Then fix it yourself and confirm the repair through the agent, read-only.

Learning Objectives

Reproduce and read a CrashLoopBackOff through the agent's read-only tools — pods, events, and logs

Separate the symptom (CrashLoopBackOff back-off) from the root cause (the container's non-zero exit)

Tell apart the three classic crash-loop signatures — application exit, OOMKilled, and image-pull — by the signal each one leaves

Confirm the agent can fully diagnose the failure but cannot remediate it: no mutating tool exists and the real credential is refused on writes

Remediate as the operator with your own credentials, then confirm the fix through the agent without granting any write access

Step 1

Confirm the lab and a live failure are still present

This lesson diagnoses the exact crasher pod from Lesson 1 through the agent — it does not create a new problem. Confirm the crash is still happening and the read-only MCP server is still connected before you start investigating.

Commands to Run

kubectl get pods -n demo

claude mcp list

What This Does

The crasher pod should be cycling through Error and CrashLoopBackOff with a climbing RESTARTS count, while the web pods stay Running. 'claude mcp list' confirms the k8s-readonly server from Lesson 1 is still registered and connected, so the agent has its read-only tools available.

Expected Outcome

'kubectl get pods -n demo' shows the web-... pods Running and crasher in CrashLoopBackOff (or Error) with RESTARTS greater than zero. 'claude mcp list' lists k8s-readonly as connected.

Pro Tips

1
No crasher pod? Re-run Lesson 1 step 2 to recreate it, then come back — this lesson needs a live failure to investigate.
2
The RESTARTS number climbing over time is Kubernetes retrying the container with an increasing back-off delay.

Common Mistakes to Avoid

⚠️Trying to diagnose from 'kubectl get pods' alone. STATUS tells you a pod is unhealthy, not why — the events and logs the agent reads next carry the actual cause.

Was this step helpful?