Kubernetes is a phenomenal piece of infrastructure when you have the right team running it. When you don’t, it’s a support burden that grows faster than your application does. This post is for the second group.
We see the pattern often enough to describe it precisely. A team of six adopts Kubernetes because the CTO used it at their last company. Eighteen months later one engineer has become the de facto cluster owner, spends half their week on upgrades and certificate renewals, and is the only person who can deploy on a Friday. That is not Kubernetes’ fault; it is what happens when a platform is adopted without a platform team.
The honest assessment first
Before anything else: do you actually need Kubernetes? If you’re running fewer than 8 services, have a stable team of under 10 engineers, and your deployment complexity is low — you probably don’t. A well-managed ECS setup or even a disciplined EC2 + deployment pipeline will serve you better and cost less to operate.
The question to ask is not “could we use Kubernetes?” but “what problem do we have that only Kubernetes solves?”. Good answers exist: you run workloads that need to be portable across clouds or on-premises; you have many small services with genuinely different scaling profiles; you depend on an ecosystem tool that only ships as a Kubernetes operator. “We want to be ready for scale” is not a good answer. Scale is a problem you will be glad to have, and you can migrate then.
If you’re past that threshold, read on.
Managed over self-managed, always
EKS, GKE, or AKS. Pick the one that matches your cloud provider. Do not run your own control plane unless you have a specific reason that isn’t “we want more control.” More control means more ops burden — and ops burden is exactly what you can’t afford.
The control plane is the part that hurts when it breaks: etcd backups, API server certificates, version skew between components, the upgrade that takes the scheduler down with it. A managed service takes all of that off your plate for a modest hourly fee on EKS and GKE, and none at all on the basic AKS tier. Against one engineer’s salary, the arithmetic isn’t close.
Two things the managed service does not take off your plate. First, upgrades: each provider supports a Kubernetes version for roughly a year, and after that you are either forced onto the next one or paying for extended support. Put the upgrade cadence in the calendar now, and keep the cluster within two minor versions of current so no single upgrade is a big-bang event. Second, node management: use managed node groups or, better, Karpenter on EKS and Autopilot on GKE, so that nodes are provisioned, patched and replaced without a human choosing instance types.
GitOps from day one
The single biggest mistake small teams make with Kubernetes is manual deployments. ArgoCD or Flux. Pick one. Set it up before you deploy your first workload. The discipline it forces — every change in git, reconciliation automated, drift detected — is what keeps a two-person ops function from becoming a firefighting rotation.
“A cluster that can’t explain its current state from a git commit is a cluster that will surprise you at 2am.”
The mechanism matters more than the brand. A GitOps controller runs inside the cluster, watches a repository, and continuously makes the live state match what is committed. Nobody runs kubectl apply from a laptop. If someone does, the controller notices the drift and, if you let it, puts things back. Turn that on:
syncPolicy:
automated:
prune: true
selfHeal: trueWith prune, deleting a manifest from git deletes the resource; with selfHeal, a hotfix applied by hand gets reverted within minutes. Both feel aggressive for a week; then they are why Monday’s cluster looks like Friday’s.
The choice between the two tools is mostly taste. ArgoCD gives you a UI that shows every application’s sync and health state, which is worth a lot when the on-call engineer is not the person who set the cluster up. Flux is leaner, composes better with existing CI, and has no UI to maintain. We usually recommend ArgoCD for teams in this position, because of the UI, but Flux used properly is fine.
What to buy, what to build
Buy: ingress (use an off-the-shelf ingress controller), cert-manager, external-dns, a logging stack (Grafana Cloud or Datadog, not self-hosted ELK unless you have ops headcount to match).
Build: your deployment manifests, your Helm values, your GitOps repo structure. These are the things that need to reflect your specific architecture and can’t be bought.
The test for “buy” is whether the component would look the same in any other company’s cluster. TLS certificates, DNS records, a metrics pipeline: nothing about your business lives in those, so every hour spent building them is an hour not spent on things that do. Install them from their upstream Helm charts, pin the versions in git, and let Renovate or Dependabot open the upgrade pull requests.
Self-hosted observability is the trap we see most. Prometheus, Loki and Grafana are excellent, and running them well is a job. A small team that self-hosts its logging stack ends up with a second cluster to look after, and it is the one that goes down at the moment you need it to diagnose the first. Pay the vendor, cap the ingest volume, and revisit when you have someone whose job it is.
Guardrails that stand in for a platform team
A platform team’s real product is not tooling. It is defaults that stop application teams from hurting themselves. You can get most of the value with four rules, enforced in the repo rather than by a person.
- Every container sets resource requests and limits. No requests means the scheduler is guessing, and guessing is how one runaway job evicts your payment service.
- One namespace per team or product, with a ResourceQuota and a LimitRange, so a mistake stays contained.
- A PodDisruptionBudget on anything customer-facing, so node upgrades cannot take every replica at once.
- Images are pinned by tag or digest, never
latest, so a rollback is a git revert and nothing else.
Enforce these with a policy engine such as Kyverno or an admission check in CI, not with a wiki page. The reviewer who would catch a missing limit is the same person who is on holiday when it matters.
Where to start on Monday
If you already have a cluster and none of the above, the order is: GitOps first, because everything else becomes a reviewable pull request once it is in place. Then guardrails, then the buy list, then upgrades. Not all four in one sprint.
If you are starting fresh, the order is the same but the first commit is the empty GitOps repo, before there is a single workload to deploy. Write down who owns upgrades and put the next one in the calendar. Then build your first service.
None of this makes Kubernetes simple. It makes Kubernetes boring, which for a team without a platform team is the only version worth running.
