Overview

My homelab runs on five physical machines: a three-node Proxmox virtualization cluster, a Kubernetes control plane spread across two Raspberry Pi 5s and a Proxmox VM, and a dedicated NAS for storage. Routing is handled by a pair of VyOS virtual routers running with VRRP failover and BGP to dynamically route traffic into the Kubernetes cluster. Identity is centralised through LDAP backed by Kerberos, with Keycloak providing SSO across all internal services and even the AWS console and Google Workspace.

Server Nodes

Primary Node — AMD Ryzen 5 5600G

The main workhorse of the cluster. It hosts the NAS VM and carries the bulk of the heavier workloads.

Secondary Nodes — Intel N100 × 2

Two compact machines built around an ASUS mini-ITX board.

The 2.5 GbE NIC is an M.2 card from AliExpress, bought for about $15 each — genuinely one of the best value upgrades for a homelab node.

Virtualization — Proxmox VE

All three nodes run Proxmox VE and form a single cluster managed from one UI. All VMs default to Debian as the guest OS.

Each node also runs one Kubernetes worker VM, giving the cluster three workers in total — one per physical host, keeping workloads spread across the hardware. N100 node 2 additionally hosts a third Kubernetes control plane VM alongside its worker.

Kubernetes Cluster

The cluster uses a mixed architecture: two control plane nodes on Raspberry Pi 5s, a third control plane node as a Proxmox VM, and workers on Proxmox VMs.

Running two control plane nodes on the Pis keeps a majority independent from the virtualization layer — if a Proxmox node goes down, the Raspberry Pis still hold quorum and the Kubernetes API server keeps running. The third control plane VM adds capacity and redundancy across Proxmox nodes.

Routing — VyOS

Network routing is handled by two VyOS router VMs running in an active/backup configuration.

High Availability with VRRP

The two routers share a Virtual IP (VIP) via VRRP (Virtual Router Redundancy Protocol). All network traffic is sent to this single VIP rather than to either router directly. If the master router (vyos-01) becomes unavailable, vyos-02 detects the failure and takes over the VIP within seconds — with no manual intervention and no single point of failure.

Because the two VMs run on different physical hosts, a failure of any one Proxmox node only takes out one router at most.

Kubernetes Traffic Routing with BGP

BGP (Border Gateway Protocol) is used to dynamically route external traffic into the Kubernetes cluster. The VyOS routers peer with the cluster nodes over BGP, and Kubernetes (via a load balancer controller such as MetalLB) advertises the IPs of LoadBalancer services directly to the routers.

This means:

• No static routes need to be maintained manually
• New Kubernetes services are automatically reachable from the network as soon as they are created
• Traffic is load-balanced across healthy nodes at the routing layer

NAS — OpenMediaVault

Runs as a VM on the primary node. The two HDDs are passed through to the VM for direct ZFS access.

ZFS mirror means the two drives are kept in sync — if one fails, no data is lost. SMB shares are consumed by other VMs and containers in the cluster, and Proxmox uses it as shared storage for live migrations.

Networking

Two completely separate networks keep home traffic away from lab workloads.

The homelab network runs on a Ubiquiti 2.5 GbE switch. Every server node has a 2.5 GbE connection:

• 5600G node — PCIe x4 2.5 GbE card
• N100 nodes — M.2 2.5 GbE NIC ($15 each from AliExpress)
• Raspberry Pi 5 — onboard GbE (the Pi 5’s built-in port tops out at 1 Gbit)

The 2.5× speed bump over standard gigabit makes a real difference for NAS transfers and VM live migrations.

Power & UPS

A 100 Wh UPS protects the entire cluster. At ~60 W average draw, that gives roughly 1.5–2 hours of runtime during a power outage — enough to ride out brief outages or perform a graceful shutdown.

Infrastructure Services

Directory — LDAP + Kerberos

Identity is centralised through an LDAP directory backed by Kerberos for authentication. Passwords are stored and validated entirely in Kerberos — LDAP never handles credentials directly. Clients that need to bind to LDAP do so via SASL, which means the bind operation itself is authenticated through Kerberos rather than a plain LDAP password.

This separation keeps credentials out of LDAP and gives every service a single place to authenticate against.

SSO — Keycloak

Keycloak sits on top of the directory as the SSO layer. It federates user identities from LDAP, meaning accounts and group memberships are managed in one place and Keycloak reads them on demand. All internal services authenticate through Keycloak using OIDC — no service directly queries LDAP or Kerberos.

Keycloak is also configured as a SAML identity provider for AWS and Google Workspace. Logging into the AWS console or Google Workspace goes through Keycloak, which issues a SAML assertion that each platform trusts to grant access. This means both are subject to the same SSO session and MFA policy as everything else in the lab — no separate AWS IAM users or Google accounts needed.

Mail — IMAP, SMTP, and Token Authentication

A self-hosted mail server provides both IMAP (mail retrieval) and SMTP (mail delivery). Rather than using a shared password, each mail client authenticates with its own application token generated on demand through a custom web application. Tokens are shown only once at generation time and never again — if you lose it, you generate a new one. Each client or application gets a distinct token, so access can be revoked per-application without affecting anything else, and a leaked token cannot be linked back to the account password.

Architecture Diagram

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

                         Internet / Home Network
                                   │
                         ┌─────────▼─────────┐
                         │   VRRP Virtual IP  │
                         │ ┌───────────────┐  │
                         │ │  vyos-01 (M)  │  │  BGP peering
                         │ │  5600G node   │◄─┼───────────────┐
                         │ └───────────────┘  │               │
                         │ ┌───────────────┐  │               │
                         │ │  vyos-02 (B)  │  │               │
                         │ │  N100 node 1  │  │               │
                         │ └───────────────┘  │               │
                         └─────────┬──────────┘               │
                                   │                          │
                    ┌──────────────▼──────────────────┐       │
                    │    Ubiquiti 2.5 GbE Switch        │     │
                    │         (10.x.x.x / lab)          │     │
                    └──┬──────────┬──────────┬──────────┘     │
                       │          │          │                │
          ┌────────────▼──┐  ┌────▼───────┐  ┌▼───────────┐   │
          │  5600G Node   │  │ N100 Node 1│  │ N100 Node 2│   │
          │  Proxmox VE   │  │ Proxmox VE │  │ Proxmox VE │   │
          │               │  │            │  │            │   │
          │ ┌───────────┐ │  │ ┌────────┐ │  │ ┌────────┐ │   │
          │ │  NAS (VM) │ │  │ │k8s-wrk2│◄┼──┼─┤k8s-wrk3│◄┼───┘
          │ │  OMV/ZFS  │ │  │ │ Debian │ │  │ │ Debian │ │
          │ │  2× 8 TB  │ │  │ └────────┘ │  │ └────────┘ │
          │ └───────────┘ │  └────────────┘  └────────────┘
          │ ┌───────────┐ │
          │ │k8s-wrk1   │◄┼──── BGP (LoadBalancer IPs advertised to VyOS)
          │ │ Debian    │ │
          │ └───────────┘ │       ┌────────────┐  ┌────────────┐
          └───────────────┘       │  RPi 5 #1  │  │  RPi 5 #2  │
                                  │  k8s ctrl  │  │  k8s ctrl  │
                                  └────────────┘  └────────────┘

                    ┌─────────────────────────────────┐
                    │         100 Wh UPS              │
                    │      powers entire cluster      │
                    └─────────────────────────────────┘