Building a Kubernetes Delivery Platform
View source on GitHub- 1
I Wanted Kubernetes Without an Always On EKS Bill
I wanted a persistent Kubernetes environment without an always-on managed-cluster bill or compromising the Docker workloads already running on my Debian home server. I chose k3s, defined explicit resource boundaries, disabled components that conflicted with the host, and validated the design through deployment, networking, rollout, rollback, and desired-state checks.
- 2
The Rollback Worked. My Next Deploy Could Break It Again.
My Kubernetes rollback restored Version 2, but it did not update the YAML that still declared Version 3. I corrected the file manually, then designed a delivery process in which Git recorded the chosen version and the cluster followed it automatically.
- 3
Argo CD Fixed My Drift, Then Deployed My Bad Release
I first built an always-on k3s lab, then discovered that a successful rollback could leave its saved YAML behind. After designing a safer GitOps path, I implemented it and tested three real behaviors: drift correction, a correctly deployed bad release, and durable recovery through a Git revert.
- 4
My Kubernetes App Moved to EKS Unchanged. Everything Around It Didn't.
I moved the application and delivery contract from my home k3s server to temporary EKS infrastructure. The workload stayed familiar, but AWS introduced new decisions around networking, identity, compute and load balancing. I tested the complete path, measured drift correction and then removed the environment.