The deployment of a portable Kubernetes cluster leveraging the Raspberry Pi 4 architecture represents a significant shift in how home-lab environments and edge computing prototypes are developed. By utilizing the ARMv8 instruction set inherent in the Raspberry Pi 4, developers can construct a highly resilient, multi-node environment that mimics professional cloud infrastructures while remaining physically compact. The integration of Rancher K3s allows for a lightweight Kubernetes distribution that reduces the overhead typically associated with standard K8s, making it viable for hardware with limited resources. This architectural approach enables the transition from a static home server to a portable unit, where the entire cluster can be moved with minimal connectivity requirements—specifically, only power and network cabling. Such a setup provides an ideal playground for testing microservices, exploring container orchestration, and implementing distributed storage solutions like GlusterFS, all while maintaining a low power profile.

Hardware Architecture and Component Specifications

Building a portable cluster requires a meticulous selection of hardware to ensure stability, power delivery, and physical organization. The Raspberry Pi 4 serves as the compute engine, providing the necessary ARMv8 processing power and memory capacity to run containerized workloads.

The following table outlines the comprehensive hardware bill of materials required for a four-node portable cluster:

The hardware strategy centers on the use of Power over Ethernet (PoE), which eliminates the need for four separate power adapters, thereby reducing cable clutter and simplifying the portability of the unit. The Tp-Link TL-SG1005P switch acts as the central power and data hub, delivering electricity and network connectivity through a single cable to each node.

The physical organization is managed by the 52Pi ZP-0088 Rack Tower. This chassis is critical for maintaining the structural integrity of the cluster. One of its most practical features is the inclusion of SD card adapters, which solve the ergonomic challenge of accessing microSD slots once the Raspberry Pi boards are mounted within the case.

To optimize the hardware, specific modifications are often necessary. For example, the U6109 POE hats may arrive without soldered connectors on their two rows, requiring manual soldering to enable the attachment of fan and LED connector cables. Furthermore, while the 52Pi rack tower ventilator is efficient and quiet, the fans on the U6110 POE hats are often reported as having an annoying sound, leading some administrators to remove them to improve the acoustic profile of the cluster.

OS Layer and K3s Distribution Configuration

The software foundation of the cluster depends on the choice of operating system and the Kubernetes distribution. For a modern ARM64 deployment, Ubuntu Server 24.04.2 LTS (64-bit) is a primary recommendation, as K3s requires a 64-bit environment to function optimally.

The deployment of K3s (version 1.31) follows a specific hierarchy to ensure high availability and resiliency. A minimum of one instance is required for the cluster to exist, but a minimum of three Raspberry Pis is strongly recommended to provide a base level of resiliency.

The node roles are divided as follows:

• Control Plane: The primary Raspberry Pi serves as the K3s server. This node manages the cluster state, schedules pods, and handles the API server. It must be assigned a static or reserved IP address to ensure that worker nodes can always locate the control plane.
• Worker Nodes: The secondary Raspberry Pis act as K3s agents. These nodes execute the actual containerized workloads.

The initial setup process involves flashing the microSD cards with Ubuntu 24.04.2 Server 64-bit. Once the OS is live, each node must be assigned a unique hostname to prevent collisions within the cluster. To facilitate management and the deployment of applications, Helm is installed on the control plane using Snap.

To enhance the functionality of the K3s cluster, several critical components are integrated:

• MetalLB: This provides a network load balancer, allowing the cluster to handle external traffic effectively.
• Nginx: Used as the ingress controller to manage how external requests reach the services inside the cluster.
• Cert-manager: This component automates the issuance and renewal of TLS certificates, ensuring secure communication.
• Rancher: Provides a graphical user interface (GUI) for the management of the Kubernetes environment, simplifying the administration of pods, deployments, and nodes.

RancherOS Installation and Storage Optimization

For those utilizing RancherOS (v0.5.0 and later), a dedicated Raspberry Pi image is available. However, the installation process differs from standard distributions, as there is no initial ability to pass in a cloud-config. Users must boot the system, modify the configuration manually, and then reboot to apply the changes.

A significant limitation of RancherOS is that it does not automatically expand the root partition to fill the remainder of the SD card. This can lead to storage bottlenecks, especially when running multiple Docker containers. To resolve this, a manual partition expansion and redirection of the Docker root are required.

The process for expanding the Docker storage involves the following technical sequence:

1. Use sudo fdisk /dev/mmcblk0 to create a new partition.
2. Press [Enter] four times to accept default values.
3. Write the table and execute sudo reboot to reload the partition tables.
4. Create a directory for the new root using sudo mkdir /mnt/docker.
5. Configure Docker to use the new root with sudo ros config set rancher.docker.extra_args [-g,/mnt/docker].
6. Format the new partition using sudo mkfs.ext4 /dev/mmcblk0p3.
7. Preserve the mount after reboot using sudo ros config set mounts "[['/dev/mmcblk0p3','/mnt/docker','ext4','']]".
8. Mount the Docker root using sudo mount /dev/mmcblk0p3 /mnt/docker.
9. Restart the Docker service using sudo system-docker restart docker.

If the installation is not new, existing data must be migrated from the old root to the new partition using the command sudo cp -R /var/lib/docker/* /mnt/docker, followed by another restart of the Docker service.

Network Connectivity and Wi-Fi Integration

While a wired connection via a POE switch is the most stable configuration for a cluster, wireless connectivity is available as of RancherOS v1.5.2. Enabling Wi-Fi requires specific manual commands or the use of a cloud-config file.

To enable Wi-Fi manually, the following commands are executed:

• Load the driver: modprobe brcmfmac
• Create the configuration: wpa_passphrase <ssid> <psk> > /etc/wpa_supplicant.conf
• Start the supplicant: wpa_supplicant -iwlan0 -B -c /etc/wpa_supplicant.conf
• Request an IP address: dhcpcd -MA4 wlan0

Alternatively, Wi-Fi can be configured via a cloud-config file using the following structure:

```yaml

cloud-config

rancher:
network:
interfaces:
wlan0:
wifinetwork: network1
wifinetworks:
network1:
ssid: "Your wifi ssid"
psk: "Your wifi password"
scan_ssid: 1
```

It is important to note that Raspberry Pi devices may automatically drop Wi-Fi connections over time due to power management settings, which can lead to node instability in a Kubernetes cluster.

Physical Assembly and Case Integration

The final physical assembly of the cluster involves integrating the electronic components into the 52Pi rack tower. The case serves as more than just a housing; it is a functional part of the cluster's thermal and power management.

The construction includes the following details:

• Ventilation: The rack tower is equipped with a ventilator that is described as powerful yet quiet, ensuring that the four Raspberry Pi 4 units do not overheat during intensive container operations.
• Chassis Modification: To further secure the setup, a simple wooden plate with holes is connected to the base of the 52Pi rack tower using four blue cable ties.
• Mounting: Two screws in the middle of this assembly are connected to the wall-mount recess of the POE switch, ensuring the switch and the tower are physically linked.
• Storage Cluster: The final assembly includes the four 64GB USB sticks, which are utilized for creating a storage cluster.

This physical configuration allows for a "portable" experience where only two cables—power and network—need to be connected to bring the entire cluster online. Future expansions may include the attachment of a mobile router, though this would require verifying if the POE switch can provide the additional power needed for such a device.

Analysis of Cluster Resiliency and Storage Evolution

The transition from a single-node K3s setup to a multi-node cluster on Raspberry Pi 4 hardware introduces several layers of redundancy. By deploying three or more nodes, the failure of a single Pi does not result in the total loss of the cluster's availability. The control plane manages the redistribution of workloads to the remaining healthy worker nodes, ensuring that services remain accessible.

The storage strategy is particularly critical in a Kubernetes environment. While SD cards provide the boot drive, they are not suitable for high-frequency I/O operations associated with distributed databases or persistent volumes. The use of 64GB USB sticks allows for the implementation of a storage cluster.

The evolution of storage for this cluster follows a specific trajectory:

• Basic Storage: Initial use of SD cards for the OS and basic application data.
• NFS Provisioner: Implementation of a network file system to provide shared storage across nodes.
• Gluster Volume: Setting up a four-times redundant Gluster volume using the USB sticks. This ensures that data is replicated across all four nodes, providing high durability.
• Heketi: The use of Heketi to automatically provision Gluster volumes, which abstracts the complexity of storage management for the end-user.

This layered approach to storage, combined with the lightweight nature of K3s and the physical organization of the 52Pi rack, transforms the Raspberry Pi 4 from a simple hobbyist board into a professional-grade, portable infrastructure. The synergy between ARMv8 hardware and a managed Kubernetes environment demonstrates that the barriers to entering cloud-native development are now primarily focused on configuration and orchestration rather than expensive hardware acquisitions.

Sources

1. blog.loitzl.com
2. gist.github.com
3. rancher.com
4. rancher.com