Building a Four-Node ARM64 Kubernetes Platform

Project date: 2026-07-12 Role: Architecture, implementation, validation and operation

A power-efficient, highly available four-node Kubernetes platform built with Raspberry Pi 5 hardware, k3s, Longhorn and GitOps.

Environment and operating context

#

The homelab is the technical foundation for a longer-term goal of building a locally operated whole-house AI platform. Before any intelligence layer could be credible, the environment needed dependable compute, persistent storage, networking, monitoring, security and recovery. The Kubernetes project established that foundation.

The platform consists of four identical Raspberry Pi 5 Model B Rev 1.1 systems. Each node provides four ARM64 CPU cores, approximately 16 GB of memory, a 1.9 TB NVMe device and 1 Gbit Ethernet. Debian 13 and k3s provide a compact, power-conscious platform capable of running continuously without adding another high-power rack server.

Business and technical objective

#

The objective was not simply to demonstrate that Kubernetes could run on Raspberry Pi hardware. The goal was to create an operable environment that could survive an individual node outage, reschedule applications, protect persistent data, expose services consistently and be rebuilt from documented desired state.

• Maintain an odd-numbered etcd quorum.
• Use all four nodes effectively while retaining a dedicated worker.
• Provide replicated persistent volumes and external SMB storage.
• Support ingress, load-balanced addresses and internal DNS.
• Make readiness, workloads and failures observable.
• Create a platform suitable for later automation and AI services.

Operational value and risk reduction

#

Before: Services depended more heavily on individual hosts and manual deployment knowledge.

After: Four standardised ARM64 nodes provide a three-member control plane, reschedulable workloads, replicated storage and Git-managed operations.

Risk reduced: Loss of one server no longer means loss of the Kubernetes control plane, provided etcd quorum and the remaining dependencies stay healthy.

Architectural decisions and alternatives

#

Single-node k3s

Lower cost and simpler operation, but no control-plane resilience and limited failure testing.

One server with three workers

More worker capacity, but the server would remain a control-plane single point of failure.

Additional rack-server virtual machines

More raw capacity, but higher power use and less alignment with the low-power, always-on objective.

Selected design

Three embedded-etcd server nodes and one worker on identical Raspberry Pi 5 hardware balanced quorum, efficiency and practical learning.

Technical challenges

#

ARM64 compatibility, resource limits and distributed state introduced constraints not present in a single Docker host. High availability also required more than adding nodes: control-plane quorum, storage replicas, pod scheduling, application design and network reachability all had to work together.

The most difficult engineering problem was achieving useful high availability across the platform so that a node outage did not leave applications tied permanently to one device. This required three embedded-etcd server nodes, schedulable control-plane capacity, a dedicated worker and Longhorn volumes able to remain available as pods moved.

Proposed solution and architecture

#

Three nodes were configured as k3s server and embedded-etcd members, giving the control plane an odd-numbered quorum. Node 3 operates as the dedicated worker, while server nodes remain schedulable so their resources are not wasted. Traefik handles ingress, MetalLB provides selected service addresses, and Longhorn supplies three-replica Kubernetes storage.

Git and Flux
    |
Three k3s server/etcd nodes + one worker
    |-- Traefik and MetalLB
    |-- Longhorn replicated storage
    |-- Prometheus, Grafana and Loki
    |-- Wazuh, CrowdSec and MISP
    `-- Application workloads

Implementation

#

The build proceeded in controlled layers: operating-system and network preparation, k3s bootstrap, server and worker enrolment, ingress, load balancing, storage, monitoring, logging, security and finally application migration. This limited the number of variables introduced at once.

Longhorn uses an approximately 1.88 TiB storage allocation on each node and a default replica count of three. Kubernetes also has separate local-path, static Longhorn, SMB and workload-specific storage classes, allowing storage behaviour to match application requirements. Flux now owns application and infrastructure reconciliation.

Validation and measurable outcomes

#

The evidence snapshot was collected from the live cluster using Kubernetes and Longhorn APIs. All Deployments reported their desired ready replica count, and all four nodes ran the same k3s version on Debian 13 ARM64. These figures are point-in-time operational evidence, not synthetic portfolio metrics.

Outcome

#

The result is a compact cloud-native platform that supports real personal and household services while remaining power efficient. Applications are no longer constrained to one node, persistent data has defined replication and recovery layers, and the entire environment exposes enough operational evidence to diagnose rather than guess.

Skills demonstrated

#

• Kubernetes and k3s architecture
• ARM64 platform engineering
• etcd quorum and scheduling
• Traefik, MetalLB and service networking
• Longhorn and SMB storage
• Observability and security integration
• Failure analysis and operational validation

Lessons learned

#

High availability is a chain rather than a checkbox. A healthy control plane does not make an application highly available if its storage, scheduling or dependencies cannot move. The project reinforced the value of validating each layer and describing limitations honestly.

Current status and next steps

#

Operational. The platform now provides the runtime for LIP and the security, monitoring and documentation services. Its next major workload is the planned chatbot and locally oriented AI platform.

Explore the implementation

#

Read the Flux GitOps case study or review the recovery design.

How it was done

#

1. Defined the target architecture. The cluster was designed around four power-efficient Raspberry Pi 5 systems. Three nodes were assigned as k3s server and embedded-etcd members to maintain quorum, while the fourth became a dedicated worker. Server nodes remained schedulable so their capacity could still support workloads.
2. Standardised the node build. Each node was prepared with the same Raspberry Pi 5 platform, approximately 16 GB of memory, a 1.9 TB NVMe device, Debian 13 and gigabit Ethernet. Consistent hardware and operating-system configuration reduced node-specific troubleshooting.
3. Bootstrapped the control plane. The first k3s server was installed and used to initialise the embedded-etcd cluster. Two additional server nodes were joined to establish the three-member control plane, followed by the worker node.
4. Validated cluster membership. Node roles, versions, internal connectivity and readiness were checked before application services were introduced. This established a known-good control-plane baseline.
5. Added service networking. Traefik was used for ingress routing, MetalLB supplied addresses for selected services, and internal DNS records provided stable names for applications and management interfaces.
6. Introduced persistent storage. Longhorn was deployed across all four nodes with a default replica count of three. Separate storage classes were retained for local, Longhorn, SMB and workload-specific storage requirements.
7. Built the operating layer. Prometheus, Grafana, Loki, Wazuh, CrowdSec and supporting tools were added so that node health, workloads, logs and security events could be inspected rather than inferred.
8. Migrated applications incrementally. Databases, media services, networking, monitoring, security and internal applications were moved in controlled groups, with readiness and persistence checked after each change.
9. Moved ownership to GitOps. Flux became responsible for application and infrastructure reconciliation, ensuring that the working cluster could be reproduced from source-controlled desired state.
10. Performed acceptance validation. The final evidence snapshot confirmed four ready nodes, 66 ready Deployments, six StatefulSets, ten DaemonSets, 122 running pods and 24 healthy attached Longhorn volumes.

Evidence methodology

#

The figures in this case study were derived from reproducible source and runtime checks rather than estimates.

1. Node and workload totals were collected with Kubernetes API commands including kubectl get nodes, Deployments, StatefulSets, DaemonSets and running Pods.
2. Longhorn volume health, attachment, capacity and replica settings were collected from Longhorn custom resources.
3. Readiness was accepted only when all four nodes were Ready and every Deployment reported its desired ready-replica count.

Limitations and residual risks

#

• Three control-plane nodes protect quorum, but do not make every application highly available.
• Stateful resilience still depends on Longhorn replicas, scheduling, application architecture and external dependencies.
• All four nodes share the same power, network and physical location, so site-level faults remain outside the design.
• The evidence is a dated operational snapshot rather than a formal availability SLA.

Plain-English glossary

#

k3s

A lightweight, conformant Kubernetes distribution suited to edge and resource-conscious environments.

etcd quorum

The majority of control-plane database members required to continue making consistent cluster decisions.

Longhorn

Kubernetes-native distributed block storage that maintains replicas across nodes.

Independent validation

#

This was a self-directed engineering project rather than a client engagement. Credibility is established through deployed configuration, source history, successful builds, operational measurements, restoration tests and repeatable validation rather than a client testimonial.