DevOps15 min read

Kubernetes for Humans: A Real Talk Guide (With FastAPI)

BY MANISH KUMAR
June 2, 2026

I'm not a Kubernetes expert. I'm still figuring it out. But I spent a while learning it and wanted to write down what I understood so far in case it helps someone else.

So you've been hearing about Kubernetes everywhere. Your tech lead mentions it. Twitter won't shut up about it. And you're like... "should I care about this?"

I tried to learn it. Here's what I figured out so far.

What I Understand About Kubernetes

Okay so Kubernetes (K8s if you want to sound cool) is a manager for your apps.

You package your app in Docker. Kubernetes looks at how many people are using your app and says "you need 5 copies running right now." Traffic spikes? "Now you need 20 copies." One copy crashes? "I'll restart it."

Without it, you do all that manually. With it, it's automatic. That's the basic idea.

I don't think most startups need it though. I've seen teams add it way too early and waste months on infrastructure instead of building product.

Before vs After (from what I've seen)

Without Kubernetes:

  • Day 1: 100 users, 1 server. Works fine.
  • Day 30: 1K users. You manually start another server.
  • Day 60: 5K users. You're running infrastructure at 3 AM.
  • Day 90: 10K users. Your server crashes.

With Kubernetes:

  • Day 1: 1 server running your app.
  • Day 30: Automatically spins up more.
  • Day 60: Still just works.
  • Day 90: Handles 10K users without you doing anything.

When I'd Skip Kubernetes

Docker and Docker Compose work fine if:

  • You have 1-3 servers
  • Your app doesn't get huge traffic spikes
  • It's okay if your app goes down for 10 minutes
  • You're a small team
  • You're still figuring out your product

Docker Compose is dead simple:

version: '3'
services:
  web:
    build: .
    ports:
      - "8000:8000"
    environment:
      - DEBUG=true
  db:
    image: postgres

Run this and your whole app is running. No Kubernetes needed.

When Kubernetes Might Make Sense

From what I can tell, Kubernetes is worth looking at when:

  • Your app needs to stay online all the time
  • You're handling 50k+ requests per day
  • You deploy code multiple times per day
  • Your traffic varies wildly

The Concepts (as I Understand Them)

Pod - it's just a container. Don't overthink it.

Deployment - tells Kubernetes "keep 5 copies running." If one crashes, start another.

Service - gives your app a stable URL. Users hit one URL, it routes to whichever copy is available.

ConfigMap and Secrets - store settings. ConfigMap for normal stuff, Secrets for passwords.

That's honestly most of what you need. Everything else is details.

Building a Simple App (what I tried)

I made a basic FastAPI app to test this stuff out. Nothing special.

Create main.py:

from fastapi import FastAPI
import os

app = FastAPI()

@app.get("/")
def home():
    return {"message": "hello world"}

@app.get("/health")
def health():
    return {"status": "ok"}

@app.get("/user/{name}")
def greet(name: str):
    debug = os.getenv("DEBUG_MODE", "false")
    return {"hello": name, "debug_mode": debug}

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8000)

requirements.txt:

fastapi==0.104.1
uvicorn==0.24.0

Dockerfile:

FROM python:3.9-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY main.py .
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Build it:

docker build -t my-app:1.0 .

Test it:

docker run -p 8000:8000 my-app:1.0

Good. Your app is dockerized. You can stop here honestly. Docker is fine for most people.

The Kubernetes Part (what I managed to get working)

If you want to try Kubernetes:

  • Mac/Windows: Docker Desktop has Kubernetes built in
  • Linux: Minikube or kind
  • Production: Use managed stuff like GKE or AKS

I made a deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-app:1.0
        ports:
        - containerPort: 8000
        livenessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 10
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 5
          periodSeconds: 5
        env:
        - name: DEBUG_MODE
          value: "false"
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"

This keeps 3 copies running. Every 10 seconds it checks /health. If it fails, it restarts. The resources section stops one copy from hogging everything.

Then service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8000

Deploy:

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl get services

If it works you'll see an external IP. Your app is running on Kubernetes.

Should You Use This?

Honestly I'm still figuring that out myself.

You don't need Kubernetes if you have 1-3 servers. You probably don't need it if you're not sure whether you need it.

Use managed Kubernetes (GKE, AKS) if you try it. Don't set it up yourself. I tried and it was a nightmare.

Get comfortable with Docker first. Mess around for a week. Then try Docker Compose. When you run into problems Docker Compose can't solve, maybe look at Kubernetes.

I'm still learning. This is just what I've figured out so far.