Homelab Kubernetes Cluster

/ DevOps, Kubernetes / By

I’ve been building a Kubernetes homelab in my home office over the last few weeks so I thought I’d document what I’ve done and share my reasons for building it.

Purpose

I heard Kubernetes was difficult, complicated and overkill for most use-cases so I built a homelab to find out 😀 Having a homelab allows me to learn and have fun in an environment I have full control over. And, as a DevOps Engineer, I have to keep my technical skills sharp and relevant to industry best practices so this homelab gives me the opportunity to experiment with new technologies, frameworks and tools without any risk to client systems. Managing my own infrastructure forces me to think about best practices around security, deployments, backups and maintenance. The best part is that I get to learn things by doing. I’ll also use it to self-host personal projects and applications I need.

Guiding Principles

The following principles guide my approach to building the homelab out:

  • Use low cost and power-efficient hardware.
  • I’m currently AWS focused, so I leverage AWS solutions in the cluster where it makes sense. I currently use Route 53 for DNS and AWS Parameter Store to store secrets.
  • Prefer using and running open source tools
  • Deploy everything through GitOps
  • Follow security and deployment best practices

Cluster Set Up

To make this lab as realistic as possible, I created two environments in it; staging to test changes and production where I’ll deploy stable versions. The staging cluster runs on virtual machines and the production cluster that runs on physical hardware. The physical machines run Ubuntu Linux and K3s, a lightweight version of Kubernetes that is designed to run in low-resource environments.

Hardware

The production cluster runs on physical hardware:

  • Control Node: HP 635 Probook 8GB of Ram, 500GB HDD, dual core AMD CPU
  • Worker Node 1: Apple Mac Mini(2009), 2GB RAM, dual core Intel CPU

The staging cluster runs on Ubuntu VMs in a Hyper-V Host

Secrets

I use AWS Systems Manager Parameter store to store passwords, secrets, API keys and other sensitive information. I chose Parameter Store over Secrets Manager because , unlike AWS Secrets manager that charges $0.40 per secret, parameter store is free.

GitOps

I deploy changes to the cluster using git and Flux CD. Visit the repo here.