Docker vs Kubernetes A Clear Comparison for Beginners

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8000

CMD ["python", "app.py"]

Build the image:
docker build -t myapp:1.0 .

Run it locally:
docker run -p 8000:8000 myapp:1.0

List running containers:
docker ps

Push to a registry:
docker tag myapp:1.0 myuser/myapp:1.0
docker push myuser/myapp:1.0

Docker packages the app.
You choose where to run it.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: myuser/myapp:1.0
          ports:
            - containerPort: 8000

apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
  ports:
    - port: 80
      targetPort: 8000
  type: ClusterIP

Apply both files:
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

Kubernetes pulls the image and keeps
the desired number of replicas running.

Think of shipping containers:

Docker = the shipping container
- Packs the goods safely
- Standard size
- Can be moved anywhere

Kubernetes = the port
- Decides where containers go
- Loads and unloads them
- Handles many containers at once
- Recovers if one fails

You need both.
One packages, the other manages.

In a real project:

1. Developer writes a Dockerfile
   - Builds an image with the app
   - Pushes it to a registry

2. Kubernetes pulls that image
   - Creates a Deployment
   - Runs multiple Pods
   - Exposes them via a Service

3. CI/CD automates both
   - Build the image on every commit
   - Push to the registry
   - kubectl apply the new image

The image and the cluster grow together.

Choose Docker when you need to:

□ Package an app with its dependencies
□ Run the same environment locally and in CI
□ Share a reproducible build with your team
□ Run a simple single-server app
□ Compose multi-container apps locally
□ Build images that others will deploy

Example tasks:
- Build a Python or Node image
- Run it on your laptop
- Push to Docker Hub
- Use it in CI pipelines

Choose Kubernetes when you need to:

□ Run many services in production
□ Scale automatically based on load
□ Self-heal failed containers
□ Do rolling updates with no downtime
□ Manage multiple teams on one platform
□ Use cloud-native deployment patterns

Example tasks:
- Deploy a microservices app
- Add autoscaling
- Roll out a new version safely
- Run across multiple nodes

Learn both when:

□ You are building a full deployment pipeline
□ You want a DevOps or platform role
□ You need a strong portfolio project
□ You want to understand cloud-native systems

Suggested order for beginners:
1. Learn Docker — build and run one image
2. Learn Compose — run multiple containers
3. Learn Kubernetes basics — Deployment + Service
4. Deploy your image to a local cluster
5. Add autoscaling and rolling updates

This gives you:
- Packaging skills
- Orchestration skills
- A real deployment to show

1. Write a Dockerfile for your app
2. Build the image:
   docker build -t myuser/myapp:1.0 .
3. Push the image to a registry:
   docker push myuser/myapp:1.0
4. Write a Kubernetes Deployment
   that references that image
5. Apply it:
   kubectl apply -f deployment.yaml
6. Expose it with a Service
7. Update the image tag to release
   a new version

Docker builds the unit.
Kubernetes runs and manages the fleet.

Practice locally with kind or minikube:

1. Install kind or minikube
2. Create a cluster:
   kind create cluster
3. Load your image into the cluster:
   kind load docker-image myuser/myapp:1.0
4. Apply the Deployment and Service
5. Check Pods:
   kubectl get pods
6. Port-forward the Service:
   kubectl port-forward svc/myapp 8080:80
7. Open http://localhost:8080

This is the safest way to learn
both tools together without a cloud bill.

What each tool handles:

Docker:
- Image format
- Build process
- Local runtime
- Compose for local multi-container

Kubernetes:
- Scheduling
- Scaling
- Self-healing
- Networking
- Rolling updates

The boundary is clear:
Docker = the artifact
Kubernetes = the platform