pods

Inspect Kubernetes Pod status, logs, and runtime failures via kubectl.

Updated Apr 10, 2026
One-click install
npx skills add https://github.com/theslashdojo/dojo --skill pods-theslashdojo
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: pods
Source: https://github.com/theslashdojo/dojo/tree/main/nodes/kubernetes/pods
Command: npx skills add https://github.com/theslashdojo/dojo --skill pods-theslashdojo

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires kubectl, and includes scripts (resource) components.

What problem does it solve?

Managing and diagnosing individual Kubernetes Pods can be time consuming and error prone when dealing with failing containers, missing logs, scheduling issues, and probe or resource misconfigurations. This Skill centralizes the common Pod operations needed to inspect status, retrieve logs, open interactive shells, port-forward, and interpret events so agents and operators can rapidly identify root causes.

Core Features & Use Cases

  • Inspect Pod status and wide metadata to determine scheduling and runtime state.
  • Describe Pods to surface events, container statuses, exit codes, and error reasons for troubleshooting CrashLoopBackOff, ImagePullBackOff, Pending, and OOMKilled scenarios.
  • Retrieve recent and previous logs, open an exec shell into a container, port-forward for local access, and copy files to/from Pods for debugging and diagnostics.
  • Includes reusable bash scripts to list pod status and run a combined debug sequence, plus a schema for structured input when creating or querying Pods.
  • Use case: an SRE investigating a production pod repeatedly restarting can describe the pod, read previous crash logs, check resource limits and probes, and port-forward to reproduce the issue locally.

Quick Start

Ask the skill to describe pod my-app in the target namespace and show recent and previous logs for diagnosis.

Frequently Asked Questions about pods

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

FAQPage Schema
How do I debug a Kubernetes Pod stuck in CrashLoopBackOff?

To debug a Kubernetes Pod stuck in CrashLoopBackOff, you need to describe the pod to surface error reasons and exit codes, then retrieve previous container logs to identify the root cause of the runtime failure. This skill automates that diagnostic sequence.

How can I check Kubernetes Pod status and events for scheduling failures?

Checking Kubernetes Pod status and events for scheduling failures requires describing the target pod to inspect wide metadata, resource limits, and recent events. This provides the scheduling state and runtime conditions needed to resolve Pending or ImagePullBackOff states.

Can I port-forward and open an exec shell into a Kubernetes Pod for local diagnostics?

Yes, you can port-forward to access the pod locally and open an interactive exec shell into the container. This allows you to reproduce issues locally and run real-time diagnostics within the target namespace.

Do I need kubectl access to troubleshoot OOMKilled and readiness probe failures?

Yes, you need kubectl access to the cluster and namespace to troubleshoot OOMKilled and readiness probe failures. This access enables the required describe, logs, and exec operations to inspect resource limits and probe configurations.

What's the best way to retrieve previous logs from a restarting Kubernetes container?

The best way to retrieve previous logs from a restarting Kubernetes container is using the logs operation with the previous flag. This surfaces the crash output from the last terminated instance to help identify why the pod is failing.