Containers in a nutshell
The thing Kubernetes actually runs.
In plain terms
A container is a lunchbox for a program: the app plus everything it needs, sealed so it runs the same on your laptop and in the cloud. Kubernetes is what arranges thousands of these lunchboxes.
Kubernetes runs containers, so one minute on those first. A container packages your app together with everything it needs — the code, the runtime, the libraries — into one sealed unit that runs the same on your laptop, a teammate’s machine, and a server in the cloud. No more “works on my machine.”
Image vs container
An image is the recipe: built once and stored in a registry. A container is a running instance of that image. You can start many containers from one image, the way you bake many cakes from one recipe. Kubernetes pulls the image and starts the containers for you.
terminal
# an image lives in a registry, tagged by versionregistry.internal/payments-api:1.4.2# by hand you might run one container like this:$ docker run registry.internal/payments-api:1.4.2# Kubernetes does this for you — many copies, across many machines
Kubernetes does not build images
You build images (with Docker or similar) and push them to a registry. Kubernetes only pulls and runs them — building is a separate step that happens before Kubernetes gets involved.