A K3S Raspberry Pi cluster is a lightweight way to learn Kubernetes without hiding behind managed services or controlled labs. You build a real multi-node environment, configure Linux, join worker nodes, deploy an application, expose it with ServiceLB, and learn how Kubernetes behaves on physical hardware.
This guide is for aspiring DevOps engineers, cloud engineers, SRE candidates, and career changers who want practical proof of skill. The goal is not to build a flashy server rack. The goal is to create a working Kubernetes homelab you can troubleshoot, explain, and talk about in interviews.
Transform your Raspberry Pi into a lightweight Kubernetes cluster with K3S and gain hands-on experience with container orchestration that mirrors the kind of infrastructure thinking used in production environments.
Having a line on your resume that says “I run a Kubernetes cluster in my basement” immediately sets you apart from candidates who only watch videos or complete labs in controlled environments. It shows initiative. It shows you are building real infrastructure, solving real problems, and learning the operational habits hiring managers look for in DevOps, cloud engineering, and SRE roles.
| Stage | What you do | Why it matters | Proof or outcome |
|---|---|---|---|
| 1 | Prepare two Raspberry Pi devices | A multi-node setup teaches distributed systems behavior | One control plane node and one worker node |
| 2 | Configure Linux, SSH, hostnames, and hosts file entries | Kubernetes depends on Linux and reliable node identity | pi1 and pi2 are reachable and uniquely named |
| 3 | Install K3S on the primary node | This creates the Kubernetes control plane | The API server, scheduler, and controller manager run on pi1 |
| 4 | Enable cgroup memory if needed | Kubernetes needs resource-control features from Linux | K3S can start successfully on Raspberry Pi OS |
| 5 | Retrieve the node token | Worker nodes need secure authentication to join | You have the token from /var/lib/rancher/k3s/server/node-token |
| 6 | Join the second Raspberry Pi as a worker | This turns the lab into a real multi-node cluster | kubectl get nodes shows pi1 and pi2 as Ready |
| 7 | Copy kubeconfig to your local machine | This mirrors professional remote cluster administration | You can manage the cluster from your workstation |
| 8 | Deploy Linkding | A real application teaches Kubernetes workflows better than empty demos | Linkding runs in its own namespace |
| 9 | Expose Linkding with ServiceLB | This teaches a more production-like access pattern than port-forwarding | The app is reachable through the Raspberry Pi’s IP address |
| 10 | Continue with storage, monitoring, Ingress, and security projects | Each follow-up project builds deeper Kubernetes skill | Your homelab becomes a portfolio of real DevOps work |
A Kubernetes homelab is not about buying hardware. It is about building proof.
When you can explain how you installed K3S, configured Raspberry Pi nodes, fixed cgroup memory issues, joined worker nodes, copied kubeconfig, deployed Linkding, exposed it through ServiceLB, and kept improving the cluster, you have something stronger than a course-completion badge.
You have a technical story.
That story matters in interviews because DevOps work is practical. Hiring managers want to know whether you can build, troubleshoot, explain, and operate real systems. A homelab gives you a safe environment where things can break without damaging production.
That is the point: build real infrastructure, solve real problems, and document what you learn.
K3S and Raspberry Pi work well together because they keep you close to real infrastructure without overwhelming you with unnecessary complexity.
Unlike kubeadm, which can feel intimidating for people new to Kubernetes, K3S lowers the installation barrier. Unlike Talos, which removes traditional SSH access to Linux, K3S preserves the Linux foundation that underpins cloud-native operations.
That matters because Kubernetes runs on top of Linux. If you want to become strong at troubleshooting, optimization, and day-to-day cluster administration, you need to understand that relationship.
Raspberry Pi devices give you an affordable and energy-efficient way to practice production-style cluster behavior. You do not need a massive server rack or enterprise hardware to gain useful experience. With compact Raspberry Pi boards, refurbished laptops, old desktops, or mini PCs, you can deploy containerized applications, configure networking, manage storage, and work with security policies.
Choosing bare metal over virtualization also reduces abstraction. When you work directly with hardware, you get closer to how Kubernetes schedules workloads, allocates resources, and manages node health. That hands-on exposure builds the troubleshooting instincts that separate strong DevOps engineers from people who only use managed services and graphical interfaces.
Before installing K3S, prepare your hardware and make sure your Linux fundamentals are strong enough to follow the work.
If the command-line work in this guide feels too fast or unfamiliar, spend more time on Linux first. Kubernetes builds on Linux. Without solid Linux knowledge, cluster administration, debugging, and day-to-day operations become much harder.
The KubeCraft learning path follows this sequence intentionally:
For this setup, you need at least two devices so you can create a multi-node cluster that resembles production architecture.
The example configuration uses:
kubectl installed.You can also start with more modest hardware. Older Raspberry Pi models, refurbished mini PCs, or laptops that are no longer in active use can still be useful for learning.
The key is having multiple physical nodes. That is how you learn distributed systems, networking between nodes, and workload scheduling.
Prepare both devices by installing the operating system, setting a secure password, configuring SSH, and assigning unique hostnames. Add entries to your hosts file so friendly names like pi1 and pi2 map to each device’s IP address.
This makes administration easier and mirrors hostname management practices used in production environments.
Start by establishing unique hostnames for each Raspberry Pi.
Your primary device will become the control plane node. Give it a descriptive hostname such as pi1 or k3s-control.
This step matters because Kubernetes needs to identify, track, and manage each node correctly. Duplicate or unclear hostnames make administration harder and can create confusion later.
Once the hostname is set, SSH into the primary device and run the K3S installation script.
On Raspberry Pi devices, the installation may initially fail because the default Raspberry Pi OS configuration does not enable cgroup memory. Kubernetes requires cgroup memory to manage container resource limits.
That failure is useful. It shows you that Kubernetes depends on specific Linux kernel features, and it forces you to interact with system-level configuration instead of treating Kubernetes as magic.
To resolve the cgroup issue, edit the boot command line file:
/boot/cmdline.txtAdd these parameters to the existing line:
cgroup_memory=1 cgroup_enable=memoryDo not create a new line. These parameters must be appended to the single existing line in the file.
Save the change, verify the syntax, and reboot the device.
After the reboot, confirm that your hostname change persisted and that your hosts file entries are correct. Then run the K3S installation script again.
This time, the installation should complete successfully. Your pi1 device becomes the control plane node running the Kubernetes API server, scheduler, and controller manager.
K3S installs as a single binary and starts as a system service. That means the cluster can restart cleanly after power cycles or reboots.
Use this to confirm the control plane is ready:
kubectl get nodesYou should see your primary node listed and healthy.
A single-node cluster is useful for a first test, but it does not give you the distributed-systems experience you need for production-style Kubernetes work.
Adding a worker node teaches you:
To add a worker node, first retrieve the node token from the control plane.
SSH into pi1 and locate this file:
/var/lib/rancher/k3s/server/node-tokenThis token is the authentication credential that lets worker nodes securely join the cluster.
Copy the token value. You also need the control plane address and the Kubernetes API port, which defaults to 6443.
Then SSH into your second Raspberry Pi device, pi2.
Make sure it has the same cgroup configuration you applied to the control plane. Edit the boot command line file, add the cgroup parameters, fix the hostname and hosts file, and reboot.
Once pi2 is back online, run the K3S agent installation command using the token and control plane address.
The command should look like this:
curl -sfL https://get.k3s.io | K3S_URL=https://pi1:6443 K3S_TOKEN=<node-token> sh -This tells the K3S agent where to find the control plane and how to authenticate.
After the agent installation completes, return to the control plane and run:
kubectl get nodesYou should now see both pi1 and pi2 listed with a status of Ready.
If the worker node does not appear or shows a NotReady status, check three things from the original setup flow:
journalctl.That troubleshooting loop is part of the learning. Production DevOps work is full of situations where the first command does not work and you need to inspect the system carefully.
Running kubectl directly on your cluster nodes works for initial verification, but professional workflows usually involve managing clusters remotely from a dedicated workstation.
To mirror that workflow, copy the kubeconfig file from the control plane to your local development machine.
The file is located here on the control plane:
/etc/rancher/k3s/k3s.yamlAfter copying it, update the server address in the file so it points to your control plane’s IP address instead of localhost.
Then place the file in:
~/.kube/configOr reference it with the KUBECONFIG environment variable.
This setup lets you manage the cluster from your local machine, just as you would manage cloud-based clusters in a professional DevOps environment.
That separation matters. Your workstation is where you write manifests, apply configuration, inspect resources, and operate the cluster remotely. The Raspberry Pi nodes are the infrastructure you manage.
With remote kubectl access configured, deploy your first real application.
The source blog uses Linkding, an open source bookmark manager. That is a better learning target than an empty demo because it gives you a real web application to operate.
Start by creating a namespace for the application.
Namespaces provide logical separation between projects and reflect multi-tenancy patterns used in production environments.
Then deploy Linkding by creating a Deployment resource that defines:
Apply the manifest with:
kubectl applyThen watch the pods come online in the namespace you created:
kubectl get pods -n <namespace>This demonstrates the core Kubernetes workflow:
kubectl.That workflow is the foundation of Kubernetes operations.
After Linkding is running, use kubectl port-forward to access the application from your local machine.
Port-forwarding creates a temporary tunnel from your localhost to the pod running inside the cluster.
Open your browser, navigate to the forwarded port, and confirm that the Linkding login page appears.
This step is useful because it teaches a simple debugging and access pattern. You can confirm that the application is running before exposing it through a more stable service.
The source blog also includes two follow-up operations:
kubectl exec to run commands inside the running container.Those operations build familiarity with Kubernetes primitives. They also give you confidence managing containerized applications instead of only reading about them.
Port-forwarding is useful, but it is temporary.
To move toward a more production-like access pattern, create a LoadBalancer service.
K3S includes ServiceLB out of the box. This allows K3S to assign an external IP address to LoadBalancer services without requiring extra components or cloud provider integrations.
Apply a Service manifest with:
type: LoadBalancerK3S will expose the application on a port accessible through the Raspberry Pi’s IP address.
Then access Linkding through that stable endpoint instead of relying on port-forwarding.
This configuration mirrors the access pattern you will eventually build on with:
You are still in a homelab, but the mental model carries forward into professional Kubernetes work.
Your working two-node Kubernetes cluster is now the foundation for ongoing learning.
From here, the source blog recommends exploring:
Each project you complete gives you more than technical knowledge. It gives you interview material.
You can explain what you built, what broke, how you fixed it, and what you would improve next.
That is the difference between passive learning and career proof.
Members of the KubeCraft community have landed DevOps and SRE roles by demonstrating homelab projects and showing that they can work with real infrastructure, not just theory and simulations.
Kubernetes builds on Linux. If you do not understand the command line, logs, services, files, networking, and system behavior, Kubernetes administration will feel much harder than it needs to.
The KubeCraft learning sequence is intentional: Linux first, Kubernetes fundamentals second, Kubernetes homelab third.
A single-node setup can help you test K3S, but it does not teach you enough about distributed systems.
Adding a worker node introduces cluster communication, token-based authentication, node readiness, and workload scheduling.
On Raspberry Pi OS, the K3S installation may fail because cgroup memory is not enabled.
That is not a reason to quit. It is a useful lesson about how Kubernetes depends on Linux kernel features.
Port-forwarding is useful for testing, but it is temporary.
A LoadBalancer service with ServiceLB gives you a more stable access pattern and prepares you for working with Ingress controllers, TLS certificates, and DNS records later.
The homelab becomes more valuable when you document it.
Write down the architecture, the setup steps, the problems you hit, and the improvements you want to make next. That turns private learning into visible evidence.
Yes. Raspberry Pi devices can be used to build a lightweight Kubernetes cluster with K3S. The example setup uses two Raspberry Pi 5 boards, with one acting as the control plane and one acting as a worker node.
You need at least two devices if you want a multi-node cluster that resembles production architecture. One device acts as the control plane, and the second acts as a worker node.
K3S is easier to approach for beginners while still keeping you close to Linux and real infrastructure. The source blog contrasts this with kubeadm, which can feel intimidating for people new to Kubernetes.
Kubernetes needs cgroup memory to manage container resource limits. The source setup notes that Raspberry Pi OS may not enable this by default, so you may need to add cgroup_memory=1 cgroup_enable=memory to /boot/cmdline.txt.
The source blog uses Linkding, an open source bookmark manager. It gives you a real application to deploy, inspect, access with port-forwarding, and later expose with a LoadBalancer service.
Yes. A working homelab gives you something concrete to discuss: the cluster you built, the worker node you joined, the application you deployed, and the problems you solved along the way.
A K3S Raspberry Pi cluster is one of the most practical Kubernetes homelab projects you can build as an aspiring DevOps engineer.
It teaches Linux, Kubernetes, networking, cluster administration, application deployment, remote kubectl workflows, and service exposure on real hardware. More importantly, it gives you something you can explain in interviews.
Do not build the homelab just to say you built one. Build it, break it, fix it, document it, and keep improving it.
If you want a structured path through Linux, Kubernetes, cloud, automation, and DevOps career skills, KubeCraft is built around that kind of hands-on proof. Start with the cluster, then make your work visible. We land DevOps jobs every week at https://www.kubecraft.dev/