Kubernetes Troubleshooter
A scenario-based diagnostic Lab that practises moving from Kubernetes symptoms to evidence, containment and a safe first remediation. It rewards disciplined investigation instead of broad restarts or destructive guesses.
Who this Lab is for
Designed for
- Platform and DevOps engineers
- On-call engineers supporting Kubernetes
- Graduates building production diagnostic habits
Use it when
- Practising incident response before joining an on-call rota
- Teaching evidence-led Kubernetes troubleshooting
- Refreshing diagnostic choices for common failure modes
A complete run, step by step
Choose a scenario
Select scheduler pressure, a failed rollout or intermittent service errors.
Identify the primary symptom
Separate the observed symptom from an assumed root cause.
Select discriminating evidence
Choose evidence that safely narrows the hypothesis before changing the cluster.
Contain and remediate
Prefer a reversible first action that preserves evidence and limits customer impact.
What you will need
Prepare the following information before starting. Use measured evidence where possible; defaults are examples and should not be treated as recommendations.
Available scenarios
Pending workloads after a node-pool change.
Crash loops and readiness failures after deployment.
Endpoint and dependency failures across replicas.
Primary symptom
Choose the strongest observed signal.
Choices: Pods remain Pending · CrashLoopBackOff after rollout · Intermittent 503 responses
First evidence to inspect
Prefer evidence that narrows the hypothesis safely.
Choices: Pod events and scheduling conditions · Restart every pod · Increase all resource limits · Node CPU dashboard only
Initial response
Select the most reversible first move.
Choices: Contain rollout and preserve evidence · Delete the affected namespace · Disable probes globally · Scale every workload to zero
What the result tells you
Your report includes
- A scored diagnostic sequence
- Feedback on evidence quality and remediation safety
- A repeatable practice record across scenarios
How it is determined
Choices are scored for diagnostic value, reversibility and blast-radius control. Evidence-first actions receive more credit than global restarts, probe removal or destructive namespace operations.
The simulator grades diagnostic discipline; it has no cluster telemetry and cannot identify a production root cause.
Model assumptions
- • The selected symptom is the strongest observed signal.
- • Preserving evidence is safer than broad mutation.
- • The scenario omits provider and workload-specific behaviour.
Authoritative references
Pods remain Pending
Situation
A workload stops scheduling after a node-pool change.
Result
Inspecting pod events and scheduling conditions before changing resources leads to a strong score and a focused capacity or constraint hypothesis.
Use the result with engineering judgement
- Scenarios simplify real clusters and do not execute commands.
- Always follow your organisation's incident and access procedures.
- Production remediation should be validated against current cluster state.
Questions before you begin
Do I need a Kubernetes cluster?
No. The Lab is a decision simulator and can be used without infrastructure access.
Are commands included?
The Lab focuses on diagnostic reasoning. Use your approved runbooks and current Kubernetes documentation for exact commands.
Can I try every scenario?
Yes. Each variant can be run and saved separately to build a broader practice history.
Kubernetes Clinic is under review
This legacy judgement-based Lab has been retired. Existing saved reports remain available, but new execution is disabled.
Open deterministic utilities