The Genesis: A Discarded Office PC
The project began not with a planned purchase, but with a discovery: a Dell OptiPlex 7040 tucked away in a recycling pile. This unassuming machine, packing an Intel i5-6500, 16GB of DDR4 RAM, and a 256GB SATA SSD, became the unexpected foundation. After a swift wipe of its Windows 10 installation, Proxmox was installed, and a bold declaration was made: "This is going to be my cloud." This initial spark, fueled by the desire for a personal cloud environment, set in motion a three-month journey that would transform discarded electronics into a functional, albeit hard-won, Kubernetes cluster.
Hardware Assembly: Beyond the PC
The OptiPlex, while a capable starting point, was not enough. The vision expanded to include three Raspberry Pi 4s, each equipped with 4GB of RAM and 1TB NVMe SSDs connected via USB adapters. The networking was handled by a second-hand managed switch, a crucial component for orchestrating traffic between the nodes. This collection of salvaged and repurposed hardware — the OptiPlex and the Pis — formed the core of the 4-node cluster. The total cost for this hardware acquisition, excluding the initial OptiPlex which was essentially free, amounted to approximately $200. This budget-conscious approach underscored the project's ethos: leveraging readily available, often overlooked, resources to achieve sophisticated technical goals.
The Software Stack: Talos Linux and Cilium
The choice of operating system and networking components was deliberate, prioritizing security and Kubernetes-native design. Talos Linux, an immutable, API-driven operating system purpose-built for Kubernetes, was selected for its minimal attack surface and robust security posture. Unlike traditional Linux distributions, Talos offers no SSH access by default and is managed entirely through its API. This approach ensures that the OS remains in a known, consistent state, simplifying management and reducing the risk of configuration drift or unauthorized changes. For the Container Network Interface (CNI), Cilium was chosen. Cilium leverages eBPF (extended Berkeley Packet Filter) technology to provide advanced networking, observability, and security features directly within the Linux kernel. It replaces traditional components like kube-proxy, offering a more performant and feature-rich networking layer. Cilium's capabilities extend to network policy enforcement, service mesh functionalities, and deep network visibility, making it a powerful choice for a production-grade homelab environment.
Orchestration and Storage: ArgoCD and Longhorn
With the infrastructure in place, the focus shifted to application deployment and persistent storage. Argo CD was integrated as the GitOps continuous delivery tool. Argo CD automates the deployment of desired application states from Git repositories to Kubernetes clusters. This declarative approach ensures that the cluster's state is always aligned with the configurations defined in version control, enabling reliable and repeatable deployments. For persistent storage, Longhorn was selected. Longhorn is an open-source, distributed block storage system for Kubernetes. It provides reliable, shared storage for stateful applications running in the cluster, replicating data across nodes to ensure high availability and fault tolerance. Longhorn's integration with Kubernetes makes it straightforward to provision and manage persistent volumes for applications. The combination of Argo CD and Longhorn provides a robust platform for managing and running stateful applications within the bare-metal Kubernetes environment.
The Learning Curve: Burned SD Cards and Bricked Pis
The path to a stable cluster was far from smooth. The Raspberry Pi 4s, particularly when running intensive workloads or experiencing power fluctuations, proved susceptible to SD card corruption. The author recounts burning through three SD cards, each failure a painful lesson in the fragility of flash storage under demanding conditions. These failures were compounded by occasional issues with the Pis themselves, leading to unexpected reboots and instability. Each instance of data loss or system downtime served as a critical learning opportunity. Understanding the nuances of power delivery to the Pis, the impact of I/O load on SD card longevity, and the importance of robust backup strategies became paramount. This iterative process of failure, diagnosis, and correction is a hallmark of deep technical exploration, transforming raw hardware into a resilient system through empirical understanding.
Why Bare-Metal Kubernetes?
The decision to run bare-metal Kubernetes, rather than utilizing cloud provider managed services or even a virtualized hypervisor like Proxmox on the main node, stems from a desire for complete control and a deep understanding of the underlying infrastructure. While cloud providers offer convenience, they abstract away critical operational details. Running bare-metal forces a confrontation with the realities of hardware management, networking, and operating system stability. For side projects and personal services, this level of control allows for fine-tuning performance, optimizing costs (especially with salvaged hardware), and building a more resilient system tailored to specific needs. It's an educational endeavor, providing hands-on experience with technologies that are fundamental to modern cloud-native development and operations. The author's homelab now serves as the production environment for their side projects, demonstrating the viability of this approach for serious workloads, provided the necessary learning and troubleshooting are undertaken.
The Road Ahead: Continuous Improvement
The journey doesn't end with a functional cluster. The author plans to continue refining the setup, exploring further optimizations for performance and reliability. This might include investigating more robust storage solutions, experimenting with different CNI plugins, or enhancing the cluster's observability. The experience underscores that building and maintaining a bare-metal Kubernetes cluster is an ongoing process, demanding continuous learning and adaptation. The salvaged hardware, once destined for landfill, now powers a sophisticated, self-hosted cloud, a testament to the power of ingenuity and persistence in the face of technical challenges.