Skip to main content
Advanced Search
Search Terms
Content Type

Exact Matches
Tag Searches
Date Options
Updated after
Updated before
Created after
Created before

Search Results

228 total results found

Principles & Lessons Learned

The reasoning newcomers rarely see written down: least-privilege credentials, TLS at the edge, bastion-only access, capacity tradeoffs, and the mistakes made along the way.

Building a Kubernetes Platform on Proxmox

Designing and running a small but real Kubernetes platform on a Proxmox home lab, end to end.

Core Lab Infrastructure

The foundations under everything else: edge networking, provisioning, Git, docs, monitoring, logging, and the registry.

Start here: what this lab is

The Lab, End-to-End

This is a home lab. One Proxmox host, a pile of virtual machines, and a small-but-real platform running on top of them. I built it for two reasons: to have a place to practice the things I do (and want to do) as an infrastructure engineer, and to write down ho...

The big picture

The Lab, End-to-End

Everything lives behind one firewall, on one private network. The only things exposed to the outside world are a couple of public IPs on the gateway; every VM sits on a private 10.100.100.0/24 network with no direct route in. In...

How a request reaches an app

The Lab, End-to-End

Say you open https://app.example.com in a browser. Here's the whole journey: browser | https://app.example.com v DNS -> 203.0.113.10 (public IP on the gateway) | v pfSense / HAProxy terminates TLS (wildcard *.example.com), | ...

The address plan and naming

The Lab, End-to-End

A small, boring, consistent address plan saves you a surprising amount of grief. Here's the whole thing. Network: 10.100.100.0/24, private, no internet-facing addresses. Address Role 10.100.100.1 pfSense — the gateway/router for the subnet 10.100.100....

Service map

The Lab, End-to-End

Every box and what it does, with a pointer to the book that covers it in depth. VM Address What runs there Covered in pfSense .1 NAT, HAProxy, edge TLS Edge Networking with pfSense Jump host .254 SSH bastion The SSH Bastion GIT-Server .2 Gitea Self-...

Why kubeadm (and not k3s or a managed service)

Kubernetes Cluster (kubeadm + Calico)

There are easier ways to get a Kubernetes cluster. k3s is a single binary. A cloud provider will hand you one in ten minutes. I deliberately used kubeadm anyway. The reason is the goal. This lab exists to understand the platform, and to show that understanding...

Preparing the nodes

Kubernetes Cluster (kubeadm + Calico)

Before kubeadm will touch a machine, the machine has to be ready. The same prep runs on all four nodes: each node |- swap OFF (kubelet refuses to run with swap by default) |- kernel modules: overlay, br_netfilter |- sysctl: net...

Bootstrapping the control plane

Kubernetes Cluster (kubeadm + Calico)

With the master node prepped, one command brings the control plane to life: kubeadm init \ --apiserver-advertise-address=10.100.100.7 \ --pod-network-cidr=192.168.0.0/16 Two flags matter: --apiserver-advertise-address pins the API server to the node's pr...

Joining the workers (and the firewall that blocked them)

Kubernetes Cluster (kubeadm + Calico)

Each worker joins with the command kubeadm init printed: kubeadm join 10.100.100.7:6443 --token <REDACTED> \ --discovery-token-ca-cert-hash sha256:<REDACTED> The first time I ran this across the three workers, all three failed with: couldn't validate the id...

The network layer: Calico, installed from a manifest

Kubernetes Cluster (kubeadm + Calico)

Kubernetes deliberately ships without a network. You choose a CNI plugin and install it. I used Calico, applied from its plain manifest: kubectl apply -f https://.../calico/<version>/manifests/calico.yaml A couple of deliberate choices: Manifest, not the ope...

Keeping workloads off the control plane

Kubernetes Cluster (kubeadm + Calico)

By default kubeadm puts a taint on the control-plane node: node-role.kubernetes.io/control-plane:NoSchedule A taint is a "keep out" sign. NoSchedule means: don't place a pod here unless that pod explicitly tolerates this taint. The control plane's own compone...

Why size things at all?

Planning & Capacity

It's a home lab. Why not just give every VM "plenty" of everything and move on? Because the constraint is real, and pretending it isn't is how you wake up to an out-of-memory kill at 3am. One host has a fixed amount of RAM, CPU, and disk. Every VM you start wr...

The host, and the numbers

Planning & Capacity

The whole lab runs on a single Proxmox host with, roughly: 64 CPU threads ~125 GiB usable RAM A few hundred GB of fast local disk for the OS, plus a multi-TB ZFS pool for VM disks CPU stays comfortable — 64 threads is far more than the VMs will ever simultan...

The thing that quietly eats your RAM: ZFS ARC

Planning & Capacity

There's a second tenant on the host besides the VMs: ZFS. ZFS uses a chunk of RAM as a read cache called the ARC (Adaptive Replacement Cache), and by default it will happily grow to use up to half (or more) of the machine's memory. That's fine on a dedicated s...

Making room: right-sizing live VMs

Planning & Capacity

The cluster needed real memory: a control-plane node, three workers at 24 GiB each, a build runner, and later three database VMs. Adding all of that naively would have blown past physical RAM. So before adding, I went looking for slack in what already existed....