Installing K3s Control Plane
Introduction
A small Kubernetes cluster is a strong fit for a homelab, especially when it is built from low-power hardware like Raspberry Pis in a rack. K3s keeps the control plane lightweight while still giving you the core Kubernetes features needed to manage workloads, services, secrets, storage, and deployments. In this guide, we will set up the K3s control plane in a way that is practical for a home rack environment, with an eye toward stability, simplicity, and easy expansion later.
Prerequisites
Before you begin, make sure you have:
- A Raspberry Pi cluster ready to use in your rack
- A fresh Raspberry Pi OS or other Linux installation on the control plane node
- Static or reserved IP addressing for the node
sudoaccess on the machine- Network access between all nodes in the cluster
Install K3s on the First Control Plane Node
On the first server node, install K3s with the built-in install script:
curl -sfL https://get.k3s.io | sh -
After the installation finishes, verify that the service is running:
sudo systemctl status k3s
Check that the node joined successfully:
sudo kubectl get nodes
If you prefer using kubectl without typing sudo every time, copy the kubeconfig into your home directory and update the permissions:
mkdir -p ~/.kube
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown $(id -u):$(id -g) ~/.kube/config
Then test access again:
kubectl get nodes
Verify the Cluster
Once the control plane is installed, check the cluster components and make sure the node is ready:
kubectl get pods -A
kubectl get nodes -o wide
You should see the control plane node listed and the system pods moving into a ready state.
Optional: Add More Nodes Later
If your rack grows and you want to add more Pi nodes, you can join them to the cluster as agents or additional servers. K3s makes it straightforward to expand without the overhead of a full upstream Kubernetes installation. That is one of the reasons it works so well in a homelab where simplicity matters.
Conclusion
K3s is one of the easiest ways to get a reliable Kubernetes control plane running on a Raspberry Pi cluster. For a rack-based homelab, it gives you a good balance of lightweight performance and real Kubernetes functionality, which makes it a solid foundation for apps, databases, CI/CD, and other services. With the control plane in place, you can move on to deploying workloads, setting up storage, and building out the rest of your home infrastructure.
More in infrastructure-engineering
Continue exploring articles in this category.
Sep 7, 2025
K3s on Raspberry Pis
Step-by-step guide to setting up a K3s Kubernetes cluster on Raspberry Pi nodes — networking, configuration, a…
Sep 13, 2025
Hardware List and Costs
Full hardware list and cost breakdown for my ARM64 homelab Kubernetes cluster — Raspberry Pis, switches, stora…
Sep 20, 2025
Flashing Raspberry Pi OS
How to flash Raspberry Pi OS Lite and configure base settings for a production-ready Kubernetes homelab node f…
Case Study
Bible Verse — Case Study
Production SaaS Platform · Full-Stack · Founder & Sole Engineer
A domain-driven SaaS platform with five independently scalable system boundaries: scripture content delivery, RAG-backed AI study, real-time community interaction, async media processing, and infrastructure services — built and operated end-to-end.
Our Results
How We Built It
- RAG pipeline grounding AI responses in actual scripture rather than model memory
- Hybrid Llama / OpenAI routing — local inference for cost, API fallback for quality at the edge
- Non-blocking media processing — FFmpeg jobs enqueued via BullMQ, API never waits on transcoding
- Cross-instance real-time consistency via Redis pub/sub behind WebSocket and WebRTC layers
Lessons Learned
- Domain boundaries enforced at the service layer prevent coupling long before scale demands microservices.
- RAG retrieval quality matters more than model size — better embeddings outperform a larger model on poor context.
- Async queue design should be first-class, not bolted on; BullMQ worker isolation saved the request path repeatedly.
Stack
Written by
5+ years building production systems · AI, Backend & Infrastructure · Founder of Bible Logic
Full-stack engineer with 5+ years of hands-on experience designing and shipping production systems — from Nuxt 3 frontends and Nitro APIs to self-hosted Kubernetes clusters, RAG pipelines, and real-time AI applications. Everything I write comes from systems I've designed, deployed, and operated in production.

