Containers, Docker and Kubernetes for Beginners

You build a Flask app on your laptop with Python 3.12. Your teammate has Python 3.9 and a different version of a library. The server runs another Linux distribution. Each environment behaves slightly differently, and the app breaks in places it never broke for you. Containers fix this by packaging the app together with everything it needs to run.

What is a container?

A container is a lightweight, isolated package containing your application, its runtime, libraries and settings. It runs the same on your laptop, a colleague's machine, a test server and the cloud.

Shipping containers transformed trade because one standard box fits every ship, train and truck. Software containers do the same for applications.

Docker vocabulary

• Dockerfile — the recipe: start from a base image, copy code, install dependencies, set the start command.
• Image — the built, read-only package produced from the Dockerfile.
• Container — a running instance of an image. One image can run as many containers.
• Registry — where images are stored and shared: Docker Hub, Amazon ECR, Azure Container Registry, Google Artifact Registry.

A real Dockerfile for a Python web app

# Dockerfile
FROM python:3.12-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt   # dependencies first: this layer is cached

COPY . .
EXPOSE 8000
CMD ["gunicorn", "--bind", "0.0.0.0:8000", "app:app"]

Copying requirements.txt before the rest of the code is a deliberate trick: Docker caches each step, so when you change only your code, the slow dependency install is skipped on the next build.

Build, run, push

docker build -t placement-app:1.0 .            # build an image from the Dockerfile
docker run -d -p 8000:8000 placement-app:1.0   # run it; open http://localhost:8000
docker ps                                       # list running containers
docker logs <container-id>                       # see the app's output
docker tag placement-app:1.0 <registry>/placement-app:1.0
docker push <registry>/placement-app:1.0       # share it so a server can pull and run it

Docker Compose: several containers together

Most apps need more than one piece — a web app and a database, say. docker compose starts them together from one file:

services:
  web:
    build: .
    ports: ["8000:8000"]
    environment:
      DATABASE_URL: postgresql://app:secret@db:5432/placements
    depends_on: [db]
  db:
    image: postgres:16
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret     # fine for local practice only
      POSTGRES_DB: placements
    volumes: ["pgdata:/var/lib/postgresql/data"]
volumes:
  pgdata:

docker compose up and your whole stack is running locally — a big reason Docker is now expected in fresher backend and DevOps roles.

Kubernetes: running containers at scale

Running three containers on a laptop is easy. Running hundreds across many servers — restarting crashed ones, spreading load, rolling out new versions without downtime — needs an orchestrator. Kubernetes (K8s) is the standard one.

• Cluster — a group of machines (nodes) managed by Kubernetes.
• Pod — the smallest unit: one (sometimes more) container running together.
• Deployment — "keep 3 copies of this pod running, and replace them gradually when I ship a new version". If a pod dies, Kubernetes starts a new one.
• Service — a stable address and load balancing in front of a changing set of pods.
• Ingress — routes outside HTTP traffic (yourapp.in/api) to the right service.

You describe the desired state ("3 replicas of version 1.4") and Kubernetes keeps working to make reality match it. Managed Kubernetes — Amazon EKS, Azure AKS, Google GKE — runs the control plane for you.