A private Kubernetes cloud
Built a private Kubernetes platform with separate Dev, Test and Prod environments, and managed the clusters and releases with Helm.
Running Kubernetes in a public cloud is mostly clicking a button. Running it privately, for a team that needs Dev, Test and Prod to behave the same way, is a different job. This is how I approached it.
The problem
The team had applications moving into containers, but every environment was set up a little differently. Something that worked in Test could still surprise us in Prod. We needed one platform, three environments, and the confidence that a release would behave the same in each.
What I built
- Three clusters, one shape. Dev, Test and Prod were built from the same definitions, so the only differences were the ones we chose on purpose, like size and access.
- Helm for every release. Each application had a Helm chart with values files per environment. Promoting a release meant changing a version, not rewriting YAML.
- Docker images built once. The same image moved from Dev to Test to Prod. We never rebuilt for a new environment.
What I learned
- Boring is the goal. The best compliment a platform can get is that nobody talks about it.
- Namespaces and access come first. Deciding who can deploy where saves more pain than any clever automation.
- Helm charts are code. Review them, version them, and keep them small. A 500-line values file is a smell.
If I did it again
I'd add GitOps from day one, with a tool like Argo CD watching a repo, so the cluster always matches what's in Git. I used exactly that later on Google Cloud, and it removes a whole class of "who changed this?" questions.