There’s a joke that Kelsey Hightower wrote Kubernetes The Hard Way because there isn’t an easy way. While this may be less true today, Kubernetes can still be incredibly complex. Kubernetes is essentially a platform for creating platforms. The core functionality doesn’t require a large amount of understanding. However, Kubernetes brings a lot of additional components. Its pods and services are compartmentalized in a microservices format. It doesn’t hide the operational aspects around deploying and maintaining network-accessible applications. These pieces, while not considered ‘core Kubernetes,’ are essential to understand in order to use it effectively.
Project Homelab
There are many good resources available for learning the basics of Kubernetes, such as the syntax, setting up pods and networks, and tying everything together. However, there’s much more to learn. I am redoing my homelab and will be starting a series of blog posts on the setup process. This includes:
- Creating a reusable and shareable dev environment
- Automating every aspect of the cluster using tools like Ansible, ArgoCD, and Terraform
- Implementing Build pipelines using GitHub actions
- Baseline services, such as service mesh, secret store, certificate management, logging, observability
- Securing Kubernetes
I’ll be using a “bare metal” setup with VMs on top of Proxmox. There are different concerns when using Kubernetes on bare metal compared to the cloud. In the cloud, you can benefit from a managed Kubernetes cluster and offload state to cloud-based databases, allowing you to focus on stateless applications. On bare metal, you may need to run databases within the cluster.
Hardware
I’m trying to keep my setup small. For my initial setup, I’ll be using three machines:
- A Raspberry Pi 4 8GB to run DHCP, DNS, installation images, and Authentication services
- An Intel box with 64GB of RAM that will be used as a development / workstation machine.
- An AMD box with 128GB of RAM that will run Proxmox for the Kubernetes VMs
What’s next
The initial setup requires quite a bit of preparatory work, sometimes called “yak shaving.” I’m not looking to create a bespoke Kubernetes cluster by hand. Instead, I will be automating as much as possible and providing a good developer experience for working with the automation.
In my next post, I’ll discuss setting up a Git repository for Ansible, including devcontainers, GitHub Actions, and pre-commit hooks. This will be used to manage the configuration of the Raspberry Pi and workstation nodes.
Top comments (0)