cheat sheets / platforms
Docker, Kubernetes & Bash Cheat Sheets
Three references for the layer that runs modern software, plus the mental models that make the commands stop feeling arbitrary: what a container actually is, why Kubernetes wants a description rather than instructions, and the one line that makes shell scripts safe.
Nobody memorizes every Docker flag or kubectl subcommand. Experienced people keep a reference open and spend their attention elsewhere. What separates someone fast from someone frustrated is usually not command recall at all, it is understanding the model underneath: what a container is, what Kubernetes is doing when you apply a file, and why shell scripts fail in silent and confusing ways. This page lists the three references worth keeping and explains those models.
01 · CONTAINERS
What a container actually is
The single most useful clarification: an image is a stack of read-only filesystem layers plus some metadata, and a container is a running process with a thin writable layer on top of that stack. Almost every confusing Docker behavior follows from this. Files you write inside a running container live in that writable layer and vanish when the container is removed, which is why data has to go in a volume. Two containers started from the same image share the underlying layers rather than duplicating them, which is why images cost less disk than they appear to.
Layer caching explains build times too. Each instruction in a Dockerfile creates a layer, and Docker reuses cached layers until it reaches one whose inputs changed. Everything after that point rebuilds. This is why copying your whole project before installing dependencies makes every build slow: a one-character source change invalidates the dependency install. Copying the manifest first, installing, then copying the rest keeps the expensive layer cached.
docker ps lists only running containers, which is why people think theirs vanished when it exited. Adding the all flag reveals stopped ones along with their exit codes, and the logs of an exited container are usually still readable. That pair of facts resolves most "it just died" debugging.02 · THE REFERENCES
Docker, kubectl & the shell
The daily-driver commands for shipping and operating software. The kubectl sheet being the official one matters more here than elsewhere, because Kubernetes moves quickly and third-party references go stale in ways that are hard to spot until something behaves unexpectedly.
- Docker Cheat Sheet ↗Every common docker and Dockerfile command on one clean, searchable page from Devhints.devhints.io
- kubectl Cheat Sheet (official) ↗Kubernetes' own reference for the kubectl commands you need to manage a cluster. Authoritative and always current.kubernetes.io
- Bash / Shell Cheat Sheet ↗Loops, conditionals, string manipulation, and parameter expansion — the shell-scripting reference you'll reach for constantly.devhints.io
03 · KUBERNETES
Declarative beats imperative
Kubernetes is a system for reconciling reality with a description. You give it a desired state and controllers work continuously to make the cluster match it. That is why the durable way to work is applying configuration files rather than running one-off commands that create things directly. Imperative commands are fine while experimenting, but they leave no record of what the cluster is supposed to look like, so nobody can reproduce it later.
Debugging follows a predictable order
When something is broken, the sequence that resolves most problems is: check the pod's status, describe the pod to read its recent events, then read the container logs. Describing is the step people skip, and it is usually where the answer is, because scheduling failures, image pull errors, and failing health checks all surface as events rather than log lines. A pod that never started has no logs at all, which is exactly when events matter most.
Namespaces cause more confusion than anything else
Commands operate inside one namespace at a time, so a resource that appears missing is very often sitting somewhere else. Listing across all namespaces before concluding that something failed to create saves a surprising amount of time.
04 · THE SHELL
Shell scripts fail quietly by default
Bash's defaults come from an era of interactive use and they are genuinely dangerous in scripts. Out of the box, a script keeps running after a command fails, treats an unset variable as an empty string, and reports success for a pipeline as long as its final command succeeded. Together these turn a failed step into silently wrong behavior instead of a visible error.
The conventional fix is to enable three options at the top of the script: exit on error, error on unset variables, and propagate failures through pipelines. It is one line, and it converts a whole class of invisible bugs into loud ones. Anyone writing more than a few lines of shell should make it automatic.
05 · FAQ
Frequently asked questions
Are these Docker and Kubernetes cheat sheets free?
Yes. All three are free to read with no account required. The kubectl reference is published by the Kubernetes project itself, and the Docker and Bash sheets are free pages on Devhints.
What is the difference between a Docker image and a container?
An image is a read-only stack of filesystem layers plus metadata, and a container is a running process created from that image with a thin writable layer on top. Files written inside a container live in that writable layer and are lost when the container is removed, which is why persistent data belongs in a volume.
Do I need to learn Docker before Kubernetes?
Yes, in practice. Kubernetes schedules and manages containers, so approaching it without understanding what a container is means learning two unfamiliar models at once. A working grasp of images, containers, and volumes makes Kubernetes considerably easier.
Why did my container exit immediately?
Usually because its main process finished. A container runs for exactly as long as its primary process does, so a command that completes and returns causes the container to stop. Listing all containers rather than only running ones will show it with its exit code, and its logs are generally still readable.
Why does my shell script keep running after an error?
Because that is Bash's default. Scripts continue after a failed command unless told otherwise, and unset variables silently expand to nothing. Enabling exit-on-error, error-on-unset, and pipeline failure propagation at the top of a script turns those silent failures into visible ones.