Docker and Kubernetes explained simply

Containers, images, Dockerfiles, orchestration, pods and deployments in plain English, why each exists, and an honest answer to whether you actually need Kubernetes.

Docker packages an application with everything it needs, code, libraries and settings, into a container that runs the same way on any machine. Kubernetes runs and manages many containers across many machines: starting them, restarting failed ones, scaling up under load and rolling out updates. Docker solves “it works on my machine”; Kubernetes solves running containers at scale.

These two names appear in almost every backend, cloud and MLOps job description, and they are often explained with more jargon than necessary. This guide builds the ideas up from the problem each one solves.

What problem does Docker solve?

Every developer has heard it: “but it works on my machine”. Your app runs on your laptop, then fails on a colleague’s computer or the server, because of a different Python version, a missing library or a different operating system setting.

Docker’s answer is to package the app together with its environment. Think of a tiffin box: the whole meal is packed together, sealed, and arrives the same wherever it goes. A container is a tiffin box for software.

How is a container different from a virtual machine?

Because containers share the host’s operating system kernel rather than bringing their own, they are lighter and faster, so you can run many of them on one machine.

What are images, containers and Dockerfiles?

Three terms cover most of Docker. An image is the packed, read-only template: your code plus its environment. A container is a running instance of an image. A Dockerfile is the recipe for building an image. Docker’s official overview explains the architecture in more depth.

Here is a simple Dockerfile for a Python web API:

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Build it once, and run it anywhere Docker is installed:

docker build -t orders-api .
docker run -p 8000:8000 orders-api

Your laptop, your teammate’s laptop and the cloud server now run exactly the same thing.

What is Docker Compose?

For example, a college project with a web API and a PostgreSQL database can be described like this:

services:
  api:
    build: .
    ports:
      - "8000:8000"
    environment:
      DATABASE_URL: postgres://app:app@db:5432/app
    depends_on:
      - db
  db:
    image: postgres:16
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: app
      POSTGRES_DB: app

Running docker compose up starts both, connected to each other. Anyone who clones your repository can run the whole project with one command, which also makes it a much better portfolio piece. In a real deployment, the passwords would come from secrets, not the file.

Real apps have several parts: an API, a database, a cache, maybe a background worker. Docker Compose lets you describe them all in one file and start them together with a single command. It is ideal for development and for small deployments on a single server, and it is often all a small project needs.

What mistakes do beginners make with Docker?

Why does Kubernetes exist?

Running one container is easy. Running hundreds across many servers raises new questions. What happens when a server dies? How do you add more copies when traffic spikes during a sale? How do you update the app without downtime? How do containers find each other?

Kubernetes answers these questions. Its documentation describes it as a portable, extensible, open-source platform for managing containerised workloads and services, and notes that Google open-sourced the project in 2014. You tell Kubernetes the state you want, for example “three copies of the orders API, always”, and it continuously works to keep reality matching that description.

What are the core Kubernetes ideas?

The key shift is declarative thinking: instead of giving step-by-step instructions, you declare the desired state in configuration files, and Kubernetes handles the steps.

Do you actually need Kubernetes?

Often, no, at least not yet. Kubernetes is powerful but complex to run well. A small app, a startup’s first product or a college project is usually better served by Docker Compose on one server, or by a managed platform that runs containers for you. Many teams adopt Kubernetes only once they have many services, significant traffic or a platform team to look after it.

When teams do adopt Kubernetes, many use a managed service from their cloud provider rather than running the cluster themselves, which removes much of the operational work. Either way, the concepts are the same, so what you learn on a small local cluster carries over directly.

How are containers used in AI and MLOps?

Machine learning models have especially fussy environments: specific library versions, GPU drivers and large model files. Containers make models reproducible and deployable, and Kubernetes is widely used to serve models and run training jobs at scale. Program Zero’s explainer on what MLOps is and how the pipeline works shows where containers fit, from experiment tracking to serving and monitoring.

How should you learn Docker and Kubernetes?

For career context, our guide to a cloud and DevOps career in India explains the roles that use these skills. In Program Zero, Phase 10 covers cloud fundamentals, Docker, Kubernetes basics, CI/CD and model serving, applied to the projects built earlier in the programme.

Frequently asked questions

Related reading