Your deployment rolled out. Thirty seconds later, kubectl get pods shows CrashLoopBackOff and a restart counter climbing. You reach for the usual reflex — kubectl exec -it pod/... -- sh — and get:

OCI runtime exec failed: exec failed: unable to start container process: exec: "sh": executable file not found in $PATH

Enter fullscreen mode

Exit fullscreen mode

Welcome to the modern container world: your image is distroless (or scratch , or a FROM scratch Go binary), there is no shell, no ps , no curl , no cat . And even if there were, the container is dead most of the time anyway — you can't exec into something that isn't running.

This article is a step-by-step method to diagnose that pod without ever rebuilding the image with "debug tools". We'll read exit codes properly, decode init container failures, attach ephemeral containers with kubectl debug , and clone a pod into a debuggable copy.

Context: why CrashLoopBackOff got harder

CrashLoopBackOff is not an error in itself.…