Running one Flux-managed cluster is useful.
Running three Flux-managed clusters from the same repository is where the repository structure starts to matter.
The moment you have dev, test, and prod, you need to answer a very practical question:
Which cluster should receive which namespace, app, policy, and controller?
A local Flux setup becomes much more interesting once it manages more than demo applications.
In the previous article, Learning GitOps with Flux, k3d, and the Flux CLI, I used a small k3d repository to explain the basic reconciliation loop. This article builds on that idea and adds two tools that make a cluster feel more like a platform:
GitOps is one of those ideas that sounds more complicated than it has to be.
The useful version is simple: Git becomes the desired state for your cluster, and a controller inside Kubernetes keeps the real cluster aligned with that desired state.
That is what Flux does.
Read moreMost Linux installations still treat the filesystem as an afterthought.
You make one root partition, maybe one home partition, format everything as ext4, and move on. That works. But once you start doing frequent package upgrades, distro experiments, workstation tuning, or homelab maintenance, the lack of cheap snapshots becomes very noticeable.
This is where BTRFS becomes practical.
Read moreIf you only ever build one image with one Dockerfile, Docker Bake can look a bit underwhelming.
You move a docker build command into a docker-bake.hcl file, type docker buildx bake, and at first glance it feels like you just created one more file for no obvious reason.
That is the wrong way to evaluate it.
Read more