sre-k8s-pod-health

Diagnose Kubernetes pod failures across six failure modes using read-only kubectl commands.

Updated Apr 5, 2026
One-click install
npx skills add https://github.com/schoolofdevops/401 --skill sre-k8s-pod-health-schoolofdevops
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sre-k8s-pod-health
Source: https://github.com/schoolofdevops/401/tree/main/agents/track-c-kubernetes/skills/sre-k8s-pod-health
Command: npx skills add https://github.com/schoolofdevops/401 --skill sre-k8s-pod-health-schoolofdevops

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a Kubernetes pod enters CrashLoopBackOff, ImagePullBackOff, OOMKilled, or a Service loses its endpoints, on-call engineers need a structured, read-only diagnostic procedure that gathers the right evidence and routes the failure to the correct decision branch without making risky cluster changes. ## Core Features & Use Cases - Six-phase data collection: Runs a fixed sequence of kubectl commands (pod inventory, describe, current and previous logs, resource usage, endpoints, events) to capture complete diagnostic evidence. - Seven decision branches: Maps observed field values to specific failure modes including image pull failures, crash loops, OOM kills, liveness probe misconfigurations, missing Secrets, and Service port mismatches. - Escalation with guardrails: Enforces read-only operation, blocks destructive commands like kubectl delete or edit, and produces structured escalation handoffs for human approval. - Use Case: A pod in namespace k8s-trouble-image-pull shows ImagePullBackOff. The skill collects pod JSON and events, identifies a missing imagePullSecret for a private registry, and escalates with the exact image string and namespace. ## Quick Start Set the NAMESPACE environment variable and ask the agent to diagnose why the pods in that namespace are unhealthy using this skill.

Frequently Asked Questions about sre-k8s-pod-health

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I diagnose a Kubernetes pod stuck in CrashLoopBackOff?

Collect the pod JSON, describe output, and current plus previous container logs with kubectl. Then check the lastState terminated exit code: 137 indicates OOM kill, 1 or 2 indicates an application error visible in previous logs, and 0 with restarts suggests a batch process running under a Deployment.

How to troubleshoot ImagePullBackOff errors in Kubernetes?

Check the containerStatuses waiting reason for ImagePullBackOff or ErrImagePull, then review pod events for the exact pull failure message. If the image references a private registry without an imagePullSecret, missing credentials are the cause; otherwise suspect a typo or unreachable registry.

Why does my Kubernetes Service have no endpoints?

Empty endpoints mean no pods back the Service. Verify pods exist matching the Service selector, then compare the Service targetPort against the pod containerPort. A mismatch between these values is the most common cause of the endpoints list showing none.

Can this skill fix Kubernetes pod issues automatically?

No, the skill is strictly read-only and never modifies cluster resources. It diagnoses the failure mode, then escalates a recommended change such as increasing memory limits for human approval instead of running kubectl edit, patch, or delete.

What does OOMKilled exit code 137 mean in Kubernetes?

Exit code 137 with reason OOMKilled confirms the container exceeded its cgroup memory limit and was SIGKILLed. Compare the limits.memory value in the pod spec against actual usage from kubectl top, and recommend raising the limit to at least double the current value.

When should I not use kubectl-based pod diagnosis?

Avoid this approach for cluster autoscaler issues, PVC binding failures, RBAC or admission webhook problems, network policy debugging, and capacity planning. For steady-state monitoring without an active incident, Prometheus and Grafana dashboards are more appropriate.