Container debugging involves identifying and resolving issues in containerized applications running in Docker and Kubernetes environments, from startup failures to runtime crashes. While containers abstract away infrastructure complexity, they introduce unique debugging challenges: ephemeral filesystems, network isolation, and multi-layered configurations that require specialized tools and techniques. This cheat sheet covers the most common debugging commands first, followed by advanced forensic methods—ensuring you can diagnose anything from a simple port conflict to a segfault buried in a production pod.
What This Cheat Sheet Covers
This topic spans 15 focused tables and 103 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Container Shell Access Methods
Getting a shell inside a container is usually the first move when something looks wrong from the outside. docker exec and kubectl exec cover the everyday case of poking around a running container, while the trickier rows here handle the awkward situations — a crashed entrypoint, a distroless image with no shell at all, or debugging straight at the runtime level with crictl or nerdctl.
| Command | Example | Description |
|---|---|---|
docker exec -it mycontainer /bin/bash | • Executes a new process inside a running container • most common method for interactive debugging with full shell access. | |
kubectl exec -it mypod -- /bin/sh | • Opens an interactive shell in a Kubernetes pod • essential for debugging live workloads without restarting. | |
docker attach mycontainer | • Attaches to the container's main process stdin/stdout/stderr • detaching with Ctrl+C may stop the container unless started with -it. | |
crictl exec -it abc123 /bin/sh | • CRI-compatible tool for debugging containers using containerd or CRI-O at the runtime level • bypasses Kubernetes API. |