smithery.ai

k8s-debug

Kubernetes debugging patterns. Use for pod crashes, CrashLoopBackOff, OOMKilled, ImagePullBackOff, scheduling failures, deployment issues.

First seen Mar 21, 2026

Installation

$ npx skills add https://smithery.ai

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery.ai · top by installs.

npx skills add https://smithery.ai

Browse all from smithery.ai

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,618 B
  • docs SUMMARY.md 155 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 3 installs

SKILL.md

Kubernetes Debugging Expertise

Golden Rule: Events Before Logs

When debugging Kubernetes issues, ALWAYS check events first:

  1. getpodevents - Shows scheduling, pulling, starting, probes, OOM
  2. THEN getpodlogs - Application-level errors

Events explain most crash/scheduling issues faster than logs.

Typical Investigation Flow

1. list_pods        → Get overview of pod health in namespace
2. get_pod_events   → Understand WHY pods are in their state
3. get_pod_logs     → Only if events don't explain the issue
4. get_pod_resources → For performance/resource issues
5. describe_deployment → Check deployment status and conditions

Common Issue Patterns

CrashLoopBackOff

First check: getpodevents

Event Reason Likely Cause Next Step
OOMKilled Memory limit too low or memory leak Check getpodresources, increase limits
Error Application crash Check getpodlogs for stack trace
BackOff Repeated failures Check logs for startup errors

Checklist:

  • Memory limits vs actual usage
  • Recent deployment changes (getdeploymenthistory)
  • Missing config/secrets
  • Dependency failures (database, external services)

OOMKilled

First check: getpodevents (confirms OOMKilled) Then: getpodresources (compare usage to limits)

Common causes:

  • Memory limit set too low for workload
  • Memory leak (usage increases over time)
  • Sudden traffic spike causing memory pressure
  • Large request payloads cached in memory

ImagePullBackOff

First check: getpodevents

Common causes:

  • Wrong image name or tag
  • Private registry without imagePullSecrets
  • Rate limiting from registry
  • Network issues reaching registry

Pending Pods

First check: getpodevents

Look for:

  • FailedScheduling - Insufficient resources
  • Unschedulable - Node affinity/taints
  • No matching nodes for nodeSelector

Readiness/Liveness Probe Failures

First check: describepod (shows probe config) Then: getpodevents (probe failure events) Then: getpod_logs (why endpoint isn't responding)

Evicted Pods

First check: getpodevents

Causes:

  • Node resource pressure (disk, memory)
  • Priority preemption
  • Taint-based eviction

Deployment Issues

Stuck Rollout

describe_deployment  → Check replicas (desired vs ready vs available)
get_deployment_history → Compare current vs previous revision
get_pod_events → For pods in new ReplicaSet

Common causes:

  • New pods failing (CrashLoopBackOff)
  • Readiness probes failing
  • Resource constraints preventing scheduling

Rollback Decision

Use getdeploymenthistory to see previous working versions.

Error Classification

Non-Retryable (Stop Immediately)

  • 401 Unauthorized - Invalid credentials
  • 403 Forbidden - No permission
  • 404 Not Found - Resource doesn't exist
  • "config_required": true - Integration not configured

Retryable (May retry once)

  • 429 Too Many Requests
  • 500/502/503/504 Server errors
  • Timeout
  • Connection refused

Resource Investigation Pattern

For memory/CPU issues:

1. get_pod_resources → See allocation vs usage
2. describe_pod → See full container spec
3. get_cloudwatch_metrics/query_datadog_metrics → Historical usage
4. detect_anomalies on historical data → Find when issue started