Do I need Kubernetes if I'm already using Docker?

Only once you have enough containers, or high enough availability requirements, that manually starting, restarting, and load-balancing them by hand becomes the bottleneck. A single service on one host runs fine under plain Docker or Docker Compose; orchestration earns its complexity at multi-service, multi-node scale.

Is Docker still relevant if Kubernetes doesn't use the Docker daemon directly?

Yes — Kubernetes runs OCI-compliant container images regardless of which runtime built them, and Docker (via `docker build`) remains one of the most common ways to build those images, even though most clusters now run them with containerd rather than the Docker daemon itself.

What's the actual unit Kubernetes schedules — a container?

A Pod — one or more containers that share networking and storage and are always scheduled together on the same node. Most Pods run a single container, but sidecar patterns (a logging or proxy container alongside the main one) are common.

Docker vs. Kubernetes: Container Basics

Docker packages an application and its dependencies into a portable container image and runs individual containers on a single machine. Kubernetes orchestrates many containers across many machines — scheduling them onto nodes, restarting failed ones, scaling replicas, and routing traffic between them. They're complementary, not competing: Kubernetes typically runs containers that Docker (or a compatible runtime) builds.

Introduction

Docker and Kubernetes are complementary technologies that solve different problems in the container ecosystem. Docker is a container runtime — it packages your application code, dependencies, and OS libraries into a portable image that runs identically anywhere. Kubernetes is a container orchestrator — it manages where, when, and how many copies of that container run across a cluster of machines.

Confusingly, developers often phrase the choice as “Docker vs. Kubernetes,” but a more accurate framing is “Docker alone vs. Docker managed by Kubernetes.” Nearly every Kubernetes cluster still uses the Docker image format (OCI spec) under the hood.

Step-by-Step: From Dockerfile to Running Cluster

flowchart TD
    A["1. Write a Multi-Stage Dockerfile"]
    B["2. Build and Push the Image"]
    C["3. Define a Kubernetes Deployment"]
    D["4. Expose with a Service"]
    E["5. Scale with HPA"]
    A --> B
    B --> C
    C --> D
    D --> E

Step 1: Write a Multi-Stage Dockerfile

Multi-stage builds separate the build environment from the runtime image, keeping final images small:

# Stage 1: Build
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o api-server ./cmd/api

# Stage 2: Minimal runtime (25 MB vs 800 MB)
FROM gcr.io/distroless/static-debian12
COPY --from=builder /app/api-server /api-server
EXPOSE 8080
USER nonroot:nonroot
ENTRYPOINT ["/api-server"]

Step 2: Build and Push the Image

docker build -t registry.example.com/api-server:v1.2.0 .
docker push registry.example.com/api-server:v1.2.0

Step 3: Define a Kubernetes Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
  namespace: production
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
      - name: api-container
        image: registry.example.com/api-server:v1.2.0
        ports:
        - containerPort: 8080
        resources:
          limits:
            cpu: "500m"
            memory: "512Mi"
          requests:
            cpu: "100m"
            memory: "256Mi"
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 20

Step 4: Expose with a Service

apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  selector:
    app: api-server
  ports:
  - port: 80
    targetPort: 8080
  type: LoadBalancer

Step 5: Scale with HPA

kubectl autoscale deployment api-deployment --cpu-percent=70 --min=3 --max=10

Key Takeaways

Docker packages apps into OCI-compliant images; multi-stage builds dramatically reduce final image size.
Kubernetes manages desired state — you declare what you want (3 replicas) and K8s ensures reality matches.
Rolling updates with maxUnavailable: 0 guarantee zero-downtime deployments.
Liveness and readiness probes let K8s automatically restart unhealthy containers.
Use resource requests and limits to prevent noisy-neighbor CPU starvation in shared clusters.