Context
A reference build showing how KubeKraft stands up a new Kubernetes platform for a team moving off a single-cluster, hand-applied-manifests setup.
Problem
Clusters that start as a handful of `kubectl apply` commands tend to stay that way — no audit trail for what changed, no consistent namespace/RBAC model, and no guardrails stopping a bad manifest from reaching production. Retrofitting GitOps and policy onto a live cluster is far more disruptive than starting with it.
Approach
Cluster provisioning via OpenTofu, application delivery via Argo CD reading from a Git repository (so the cluster's actual state is always a diff against a reviewable commit), namespace-per-team isolation with baseline RBAC and resource quotas applied uniformly, and autoscaling (HPA plus cluster autoscaler) configured before the first real workload lands — not after the first capacity incident.
Outcome
Every change to the cluster is a pull request, not a shell command against production. New workloads onboard against an existing namespace/RBAC template instead of one-off configuration, and capacity scales automatically within guardrails set up front.
Why GitOps first
Retrofitting a GitOps workflow onto a cluster that’s already running hand-applied manifests means reconciling drift between what’s live and what’s in Git before the pipeline can be trusted. Starting with Argo CD reading from Git from day one avoids that reconciliation problem entirely — the cluster’s state is always traceable to a commit.
Guardrails
Namespace-per-team isolation, baseline RBAC, and resource quotas are applied as part of the bootstrap, not added after the first noisy-neighbor incident. Autoscaling policy is configured before real workloads land, so capacity planning isn’t a fire drill the first time traffic spikes.
← All projects