Do You Actually Need Kubernetes at Home? (Probably Not, But Let’s Do It Anyway)

5 min readByArnau Ruiz

Short answer: no. If you’re running one Raspberry Pi and a couple of self-hosted services, you do not need Kubernetes, you need Docker Compose and maybe a nap. Longer answer: you’re going to install it anyway, because that’s what homelabbers do, and honestly, it’s a genuinely good way to actually learn Kubernetes instead of just reading about it. Let’s do it properly.

What Kubernetes actually is, in one paragraph

Kubernetes takes a bunch of containers and a bunch of machines, and figures out where to run what, restarts things that crash, and moves workloads around if a machine dies. Docker Compose runs containers on one host you manage by hand. Kubernetes runs containers across a cluster and manages itself. That difference is the entire reason it exists, and also why it’s overkill for a single Pi.

k3s: Kubernetes without the misery

Full Kubernetes (k8s) wants several gigs of RAM before it even starts thinking about your workloads. k3s is a stripped-down, genuinely lightweight distribution built for exactly this: single-board computers, edge devices, and homelabbers who want the real thing without a server rack. Installing it is one line:

curl -sfL https://get.k3s.io | sh -

That’s it. A few seconds later you have a working single-node Kubernetes cluster. Check it worked:

sudo k3s kubectl get nodes

Deploying something (finally)

Save this as deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello-nginx
  template:
    metadata:
      labels:
        app: hello-nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Apply it:

sudo k3s kubectl apply -f deployment.yaml

You now have 2 replicas of nginx running, and if one dies, Kubernetes starts a new one without you doing anything. That self-healing bit is the whole point, and on one Pi it’s admittedly a bit like using a fire truck to water a houseplant.

Commands you’ll actually use

  • kubectl get pods: see what’s running
  • kubectl get svc: see what’s exposed and where
  • kubectl logs : read logs for a specific pod
  • kubectl describe pod : find out why something is stuck in Pending, it’s usually resources or an image pull error
  • kubectl delete -f deployment.yaml: tear it all down when you’re done experimenting

When it’s actually worth it

Multiple nodes you want to load-balance across, workloads that genuinely need to survive a machine dying, or you’re learning it for work. If none of that applies and you just want three self-hosted apps running reliably on one box, Docker Compose does the job with a fraction of the complexity.

If you’re running one Raspberry Pi, you don’t need Kubernetes. You need Docker Compose and a nap. Install k3s anyway, though, because it’s a genuinely good way to actually learn how this stuff works.

Requests and limits: telling k3s how much a pod can use

On a single Pi with limited RAM, an unbounded pod is the fastest way to bring the whole node down. Requests and limits fix that:

resources:
  requests:
    memory: "64Mi"
    cpu: "100m"
  limits:
    memory: "128Mi"
    cpu: "250m"

“requests” is what the scheduler reserves for the pod before placing it, “limits” is the hard ceiling it can’t exceed, the container gets throttled (CPU) or killed and restarted (memory) if it crosses that line. Add this block under each container in the deployment spec. Without it, one misbehaving container can starve everything else running on the same node, which on a single-Pi cluster means everything.

When a pod gets stuck in Pending or CrashLoopBackOff

  • Stuck in Pending: almost always insufficient resources on the node to satisfy the requests you set, or an image the node can’t pull. kubectl describe pod <name> shows the exact scheduling event that’s blocking it in the Events section at the bottom.
  • CrashLoopBackOff: the container starts, then exits, repeatedly. Check kubectl logs <pod-name> first, that’s almost always where the actual application error is. If logs are empty, the container is exiting before it can even log anything, which usually points to a bad command or entrypoint in the image.
  • ImagePullBackOff: either a typo in the image name/tag, or (on ARM devices like a Pi) the image simply doesn’t have an arm64 build. Not every Docker image supports Raspberry Pi’s architecture, worth checking before assuming k3s itself is broken.

Adding a second node, if you want to go further

The single command from earlier sets up a server node. To actually get the multi-machine self-healing that makes Kubernetes worth using, join a second Pi as a worker using the token from the first node’s /var/lib/rancher/k3s/server/node-token:

curl -sfL https://get.k3s.io | K3S_URL=https://first-node-ip:6443 K3S_TOKEN=your-token sh -

This is genuinely where the earlier “probably not worth it for one Pi” caveat stops applying, once a workload can actually survive a node going down, the whole exercise starts paying for itself.

Related reading

Similar Posts