k8s-debug-pods
Skill558 starsChanged 3 years agoApache-2.0View on GitHub
Debug Kurtosis pods on Kubernetes. Diagnose why pods are Pending, CrashLoopBackOff, ImagePullBackOff, or Evicted. Check node taints, tolerations, resource pressure, and pod events. Use when kurtosis engine start fails or pods aren't coming online.
In this repository21 other files it gives its agents.
- cleanSkill
- cli-local-buildSkill
- cluster-manageSkill
- context-manageSkill
- docker-debugSkill
- docker-local-buildSkill
- dumpSkill
- enclave-inspectSkill
- engine-manageSkill
- files-inspectSkill
- gatewaySkill
- graflokiSkill
- import-composeSkill
- k8s-clean-clusterSkill
- k8s-dev-deploySkill
- lintSkill
- portalSkill
- port-forwardSkill
- run-packageSkill
- service-manageSkill
- starlark-devSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 0 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 41
Fix: Add tolerations to the kurtosis config at ~/Library/Application Support/kurtosis/kurtosis-config.yml or fix the node condition.
- Very specific: line 94
Check if old kurtosis namespaces exist: kubectl get ns | grep kurtosis
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
K8s Debug Pods
Diagnose and fix issues with Kurtosis pods on Kubernetes.
Quick triage
# See all kurtosis-related pods across namespaces
kubectl get pods -A | grep kurtosis
# Check for problem pods (not Running)
kubectl get pods -A | grep kurtosis | grep -v Running
# Get events for a specific pod
kubectl describe pod <POD_NAME> -n <NAMESPACE> | tail -30Common pod states and fixes
Pending — Unschedulable
The pod can't be scheduled because of node taints, resource pressure, or affinity rules.
# Check node taints
kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints
# Check node conditions (DiskPressure, MemoryPressure, etc.)
kubectl get nodes -o custom-columns=NAME:.metadata.name,CONDITIONS:.status.conditions[*].typeFix: Add tolerations to the kurtosis config at ~/Library/Application Support/kurtosis/kurtosis-config.yml or fix the node condition.
ImagePullBackOff
The image tag doesn't exist on the registry.
# Check which image is failing
kubectl describe pod <POD_NAME> -n <NAMESPACE> | grep -A5 "Image:"
# Verify image exists on Docker Hub
docker manifest inspect <IMAGE>:<TAG>Fix: Push the correct image tag, or fix the image reference in the code.
CrashLoopBackOff
The container starts but crashes immediately.
# Check container logs
kubectl logs <POD_NAME> -n <NAMESPACE>
kubectl logs <POD_NAME> -n <NAMESPACE> --previousEvicted
The node evicted the pod due to resource pressure.
# Check which nodes have pressure
kubectl get nodes -o custom-columns=NAME:.metadata.name,STATUS:.status.conditions[-1].type
# Clean up evicted pods
kubectl get pods -A | grep Evicted | awk '{print $2 " -n " $1}' | xargs -L1 kubectl delete podKurtosis-specific pod types
| Pod pattern | Component | Image source |
kurtosis-engine-* | Engine server | engine/server/Dockerfile |
kurtosis-api (in kt-* namespaces) | API Container (APIC) | core/server/Dockerfile |
kurtosis-logs-collector-* | Fluentbit DaemonSet | Pulled from registry |
kurtosis-logs-aggregator-* | Vector deployment | Pulled from registry |
remove-dir-pod-* | Fluentbit cleanup pods | busybox |
files-artifact-expander (init container) | Files artifacts | core/files_artifacts_expander/Dockerfile |
Engine start failures
If kurtosis engine start fails:
- Check if old kurtosis namespaces exist:
kubectl get ns | grep kurtosis - Delete them:
kubectl get ns | grep kurtosis | awk '{print $1}' | xargs -r kubectl delete ns - Retry engine start
Logs collector issues
The logs collector is a DaemonSet that runs on every node. If some nodes are unhealthy:
# Check DaemonSet status
kubectl get ds -A | grep kurtosis
# See which pods are not running
kubectl get pods -A | grep logs-collector | grep -v RunningNodes with DiskPressure or other taints may not schedule collector pods — this is expected and the engine should start with a warning about partially degraded collection.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

