Kubernetes Without the Platform Team Burnout

Somewhere right now, a two person platform team is holding up forty microservices, a service mesh nobody remembers enabling, three ingress controllers, and a Slack channel where every question is urgent. Both engineers are good. Both are tired. Neither has shipped anything they are proud of in months, because the week disappears into unblocking other teams one kubectl command at a time.

Kubernetes did not do that to them. Their operating model did.

The trap is unlimited choice

Kubernetes is not too hard for a small team. What breaks small teams is that every knob they expose to application teams quietly becomes a support contract. Let one team pick its own ingress annotations, another write its own Helm chart from scratch, a third wire up its own Prometheus rules, and within a year you are not operating one platform. You are operating one platform per team, and you are the only people on call for all of them.

When we look at struggling platform teams, the pattern is almost always the same. Nobody decided to build a zoo. It grew, one reasonable exception at a time.

One paved path, enforced kindly

The fix is boring and it works: define one blessed way to get a service into production, make it genuinely good, and treat everything outside it as a special request rather than a right.

A paved path that has held up well for teams we work with looks like this: one repo layout, one base image, one shared Helm chart, one pipeline template, one promotion flow. The application team's entire interface to Kubernetes can be a file this small:

service:
  name: payments-api
  port: 8080
  replicas: 3
  size: small        # small | medium | large, nothing else
  alerts:
    owner: team-payments

Notice what is not in there. No pod specs, no affinity rules, no ingress annotations. If a team needs something the chart cannot express, that is a conversation with the platform team, not a fork. Nine times out of ten the conversation ends with the chart growing one carefully considered option that every team gets.

Let git do the operating

The second half of staying sane is refusing to operate the cluster by hand. Everything that reaches the cluster goes through git, and a reconciler like Argo CD keeps the cluster honest. If someone edits a deployment directly, the change is reverted within minutes, which sounds harsh until you realize what it buys you: the cluster is now a build artifact. You can reason about it, review it, and roll it back.

It also changes the shape of support requests. "Can you bump my memory limit" stops being a ticket for the platform team and becomes a one line pull request the requesting team opens themselves, with a diff anyone can read:

argocd app diff payments-api   # what would change
argocd app sync payments-api   # make it so

Do not run what you cannot wake up for

Every component you adopt is a pager commitment. That sentence should be printed above the desk of anyone evaluating cluster add-ons.

A service mesh is a pager commitment. An in-cluster database operator is a pager commitment. Self-hosted observability is a big one: teams routinely spend more engineering hours keeping their metrics stack alive than they would spend paying for a managed equivalent, and the platform team eats that cost at 3am. Before anything lands in the cluster, ask the only question that matters: when this breaks on a Saturday, who fixes it, and do they know that yet?

For a team of two or three, the honest answers usually point the same way. Managed control plane. Managed observability, or at least a hosted backend. Databases outside the cluster. One ingress controller. No mesh until a compliance requirement forces mutual TLS, and maybe not even then.

Boring is a feature

The teams that run Kubernetes without burning out are aggressively unexciting. They upgrade on a fixed cadence instead of when panic strikes. They read release notes before, not after. They soak new versions in staging for a week while deliberately restarting things. They keep a one page runbook for the five failures that actually happen: node pressure, stuck deployments, certificate expiry, image pull failures, and the ingress controller doing something creative.

None of that makes conference talks. All of it makes weekends quiet.

If you only do one thing this week

Count the distinct ways a service can reach production in your organization. Not the official ways, the real ones. If the answer is more than two, that number is your burnout forecast, and shrinking it is worth more than any tool you could install.

If this is on your plate, TecLeads does exactly this as part of our DevOps & Platform Engineering work. If you'd like a second pair of eyes on your setup, book a 30-minute call or explore what we do.