Kubernetes running on small, quiet, always-on nodes.
- 3 × Raspberry Pi
- Kubernetes
- Pi-hole / AdGuard
Hardware / the workbench
I started by opening things.
A VAIO at eleven, a lot of family machines in between, and now a small Kubernetes cluster in the house. The answer used to be on the board.
01 / The first laptop
A VAIO, a false contact, and a week without internet.
The first machine I opened was a VAIO with an old Pentium running at 0.6 GHz and 256 MB of RAM. The display connector had a false contact. The screen worked, then it didn't, then it worked again if you held it at the right angle — the kind of fault that makes you suspect everything except the actual problem.
I didn't have internet. I had a week, a multimeter, and a lot of guesses. I traced the connector, checked continuity, cleaned the contacts, and eventually resoldered the joint for stability. It worked.
The internet wasn't the answer. The board was.
That was the moment hardware stopped being a black box. It was also the beginning of a pattern: open it, understand it, fix it, then do it again on something harder.
02 / The years between
Family machines, first builds, and the long way around.
After the VAIO came the usual trail: family laptops that needed cleaning, reinstalling, upgrading, or rescuing. Then building machines, setting up networks, recovering data, and learning why the cheapest power supply is not a bargain.
This was long before the AI era. The answer came from reading the board, trying the obvious thing, breaking it, and trying again. I didn't know the word “failure domain” yet, but I was already learning it one dead machine at a time.
That habit never went away. It is the same one I use on software now: understand the system before changing it, then make the change small enough to reverse.
The current rig.
A Lenovo LOQ that does the daily work: code, builds, music, and the occasional game.
Machine
Lenovo LOQ
CPU
AMD Ryzen 7 7435HS · 3.10 GHz
GPU
NVIDIA RTX 4060 Mobile
RAM
16 GB · 6000 MHz
Storage
1 TB NVMe
OS
Windows + Linux, depending on the job
The cluster.
The always-on layer is a cluster of Raspberry Pis running Kubernetes. The heavy machine wakes up when it is needed, and the GPU work gets split between two cards.
Home lab / always onOn demand when needed
Ryzen 7 2700X and 32 GB DDR4, woken by Wake-on-LAN.
- RTX 2060 · heavy work
- GTX 1050 · light work
- Plex scheduling
TrueNAS, Jellyfin, and the services the house actually uses.
- 2 × 2 TB HDD
- 256 GB NVMe
- Family users
Control plane
Raspberry Pi cluster · Kubernetes
Wake
Wake-on-LAN, on demand
CPU
AMD Ryzen 7 2700X
Heavy GPU
NVIDIA RTX 2060
Light GPU
NVIDIA GTX 1050
RAM
32 GB DDR4 · 2666 MHz
Storage
2 × 2 TB HDD + 256 GB NVMe
Services
TrueNAS, Jellyfin, Pi-hole/AdGuard, Kubernetes workloads
The Plex scheduling is the part I like most. A custom Docker scheduler watches the load. When the 1050 is handling too many users, the work moves to the 2060. The server itself does not stay on all day; Wake-on-LAN brings it up when a workload needs it. It is a small system, but it has real failure modes, real power constraints, and real users — my family.
What hardware taught me about software.
01
Find the failure domain before you replace the part. The same rule applies to a service and a display connector.
02
Power and thermal budgets are not optional. Neither is the performance budget.
03
Document the weird fix. Future-you will not remember why the cable is routed that way.
04
Test the unhappy path. A machine that boots is not the same as a machine that survives.
The longer version
From a VAIO to a cluster.
The same curiosity runs through the software work. If you need someone who is comfortable with the whole stack — including the machine it runs on — that is the job I want.