# Kubernetes Pod Debugging

> Methodology for identifying and fixing CrashLoopBackOff and OOMKilled in K8s.

- Skill: `creanlab/kubernetes-pod-debugging` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add creanlab/kubernetes-pod-debugging`
- Raw SKILL.md: https://api.skillmd.com/api/skills/creanlab/kubernetes-pod-debugging/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: creanlab (https://skillmd.com/u/creanlab)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/creanlab/kubernetes-pod-debugging

---

# Kubernetes Pod Debugging

Methodology for identifying and fixing CrashLoopBackOff and OOMKilled in K8s.

## When to use
- When operating in the `devops` domain.
- When resolving incidents related to kubernetes pod debugging.

## When not to use
- If the issue requires manual human intervention.
- If the domain does not apply.

## Triggers
- Pattern: `kubernetes-pod-debugging`
- Keywords: devops, kubernetes

## Inputs
- Context from the current user session or incident report.

## Steps
### 1. Step 1
Check pod status with `kubectl get pods` and identify the failing pod.

### 2. Step 2
Inspect previous logs with `kubectl logs <pod-name> --previous` to find the panic or exception.

### 3. Step 3
Check pod events using `kubectl describe pod <pod-name>` to look for OOMKilled or readiness probe failures.

### 4. Step 4
If OOMKilled, review resource limits in the deployment manifest and suggest an increase based on current usage estimates.

## Success signals
- The task is resolved without regressions.
- Logs confirm the procedure was successfully applied.

## Failure modes
- Incorrect application of the steps leading to side effects.

## Safety notes
- Always verify changes in a staging environment before applying to production.
- Do not execute destructive commands without explicit authorization.