DEV Community

Fred Richards
Fred Richards

Posted on • Updated on

Stuff in my Lab, it Evolves

I realized recently I haven't written much. Subject matter came to mind about specific situations, or recent experiments, but then I thought why not just talk about the Lab. It's constantly changing and evolving, and besides, it will be a fun thing to drone on about.

One of my main philosophies is keeping things as simple as possible, to the lowest common denominator. Considering I work with Kubernetes, with its massive amounts of abstractions, you'd think this is a paradox. These philosophies, or tenets, or principals, whatever you'd like to call them, will sometimes pop in my head as simple sentences. "Keep it simple". "Follow the convention". You get the idea.

Years ago my lab was a mess. For a living, I build stuff. Sometimes it was building Linux servers, or network services. Sometimes building networks themselves. Sometimes it was building cloud architecture. So I had to decide, what did I want out of my lab?

I wanted a quick way to test VMs. New version of Debian released? Ok, spin up a small vm and test it out. I wrote some scripts to call qemu-kvm on the commandline, made a dedicated routed vm-only network and connected it with a virtual switch, namely OpenVSwitch. These scripts were normally ansible and/or bash. There is not much these scripts do that one cannot get out of libvirt tools these days. My tooling was just born before libvirt was popular and matured.

This worked for a great while, but again, introduce Kubernetes. It is by it's very nature an affront to my minimalist habits!

So the next great step? K3s. I could run the very same guest VMs I have always, pop k3s on them and now, BOOM, they're a single-node cluster. This also works well, because one can create automation that spins up the vms, installs k3s and then applies manifests or other api-like behavior. The whole stack can spin up onsite, and with a bit of tweaking, under your favorite cloud provider.

Recently it's evolved even further. Sometimes I need not only a minimal cluster of 1-2 nodes, but an ephemeral one, something that will not live long. Spin up a cluster, run some experiment, or QA-like operation, capture result data, then destroy everything. This may just be peak-minimalism.

So now I use k3d and skip the guest VM middle man. OR get this, maybe run k3d inside the VM, if for some reason the single-node-lab-in-a-box needs to be fungible.

Some people run clusters of huge boxes, or massive datacenters filled with physical machines, or even clusters with thousands of nodes. Not me, I'll have dozens of optimized clusters and guest VMs in my lab, along with their resulting data, configs, backups, and the automation to create it all over again if needed.

Top comments (0)