Building a Self-Hosted Kubernetes Platform with Proxmox and K3s

A small multi-node personal K3s environment, with explicit ingress and service-IP decisions and a separate monitoring layer.

Kubernetes / Platform Engineering / Virtualization · 2 min read

Proxmox VEK3sHelmNGINX IngressMetalLBLinuxTailscale

These are personal lab projects and learning notes. Architecture diagrams are simplified for publication; internal addresses and sensitive configuration are omitted. Professional work is documented separately.

Conceptual architecture

Proxmox hostVirtual machinesK3s control plane + worker

Personal workstationPrivate LAN / VPNIngress address

NGINX IngressKubernetes ServicesWorkload pods

MetalLB provides local LoadBalancer service addresses. Ingress handles HTTP routing.

Kubernetes metricsPrometheusGrafana

Simplified conceptual diagram — not a complete production topology. Monitoring is a separate conceptual layer; no HA, public exposure or exact network layout is implied.

Why I built it

Managed Kubernetes abstracts away many platform decisions. I wanted hands-on experience with the virtualization layer, cluster nodes, networking, traffic ingress and Helm-based add-ons—and a way to inspect system health when something fails.

Environment and context

My personal lab uses an ASUS NUC 14 Pro with an Intel Core Ultra 5 125H and 48 GB of RAM. Proxmox runs on dedicated SSD storage, with separate NVMe capacity available for virtual-machine data. These are documented setup details, not a statement that every service is currently running.

I set up K3s across a control-plane node and a worker node. This is a resource-conscious home lab, not a highly available or multi-zone production cluster.

Implementation and engineering decisions

Separate host management from cluster VMs so that individual cluster nodes can be rebuilt.
Disable bundled Traefik and ServiceLB; deploy NGINX Ingress to study HTTP routing explicitly.
Use MetalLB for LoadBalancer service addresses on the local network, where no cloud-provider load balancer exists.
Use Helm-based add-ons and kube-prometheus-stack for cluster metrics and dashboards.
Use Tailscale for private connectivity and routing experiments; private access is not evidence of hardened public exposure.

Tradeoffs and failure boundaries

Explicit ingress and service-IP management make controller behavior easier to study but create more configuration to maintain. Virtual machines separate the lab's layers; they do not remove the physical host as a shared failure point.

Service exposure and secure external publication are different problems. No public router forwarding, production failover, distributed control-plane resilience or disaster-recovery objective is claimed.

Outcome and evidence boundary

The documented setup includes the K3s nodes, NGINX Ingress, MetalLB and monitoring components. The source material describes setup and troubleshooting activities; it does not establish uptime, user traffic, benchmarks or current availability. Original command output, screenshots and a sanitized public repository have not been supplied.

Lessons learned

LoadBalancer service addressing, ingress controllers and Kubernetes Services solve different parts of the traffic path.
Host, VM, network and Kubernetes layers all matter during diagnosis.
Recovery notes are valuable in a lab where hardware and configuration change.

Next iterations

Version-control a sanitized bootstrap example.
Demonstrate one application deployment and rollback.
Document backup and restore of a non-sensitive test workload.
Publish personal GitOps work only after implementation and verification.