The Kubernetes Checklist for Teams Without a Platform Team

Most Kubernetes advice assumes you have a platform team. A group of specialists who own upgrades, ingress, security policies, and the 2 a.m. pages. Most small companies don't have that. They have three to ten engineers, one of whom "knows Kubernetes," and a cluster that everyone depends on and nobody fully owns.

I work in enterprise environments where platform teams are large and everything is process. This article is the opposite exercise: what is the minimum discipline a small team needs to run Kubernetes in production — and what enterprise baggage they should refuse to copy.

The question that matters more than any tool

Before any checklist: who owns the platform after the migration is finished?

Not "who set it up." Who owns upgrades next year, cert renewals, the CNI version, the deprecated APIs? If the answer is one person's name, you don't have a platform — you have key-person risk with YAML on top. If the answer is "nobody, really," Kubernetes is invisible operational debt accumulating interest.

The rest of this checklist exists to make that ownership cheap enough that a small team can actually carry it.

1. Deployments: Git is the only door

• Everything that runs in the cluster is described in Git. No exceptions, including "temporary" fixes.
• One GitOps tool (Argo CD or Flux — pick one, don't debate it for a month) applies what's in Git. Humans don't kubectl apply to prod.
• Every service can be rolled back by reverting a commit, and someone has actually done it.

Why this first: it converts your cluster from a mystery into a diff. Every other practice gets easier once "what is running?" has an answer.

2. The rollout basics that prevent 3 a.m. incidents

• Readiness probes that check real dependencies, not just "process is up."
• Graceful shutdown: handle SIGTERM, add a short preStop sleep so load balancers stop sending traffic before the pod dies. This single item eliminates most "we still get 503s during deploys" complaints.
• Resource requests set from measured usage. Limits where they make sense. No workload without requests — it's how you get evicted at the worst moment.
• PodDisruptionBudgets on anything customer-facing.

3. Security: the boring baseline, not the service mesh

Small teams over-index on exotic security (mTLS everywhere, eBPF everything) and skip the basics that actually block enterprise deals:

• RBAC scoped per human and per workload. Nobody lives in cluster-admin.
• Secrets via External Secrets Operator, Vault, or SOPS. Never plaintext in Git, and check who can kubectl get secret in shared namespaces — the default answer will surprise you.
• Admission policy (Kyverno is the gentlest start): block :latest, block privileged, require requests/limits.
• API server not on the public internet.

That's four bullets. It covers ~80% of what a customer security review will ask a company your size.

4. Observability: answers, not data

You do not need every log, metric, and trace. You need to answer three questions fast: is it broken, where, and since when.

• Prometheus (or your managed equivalent) + golden-signal dashboards for your top services.
• Alerts on symptoms users feel — error rate, latency, saturation — not on every metric that exists. If an alert didn't cause action in two weeks, delete it.
• Centralized logs with a retention policy. "Keep everything forever" is how observability becomes your second-biggest bill.
• Tracing only if you have real multi-service debugging pain and the budget. It's a fine thing to consciously not do yet.

5. Backup: a backup you haven't restored is a rumor

• Velero (or cloud-native equivalent) for cluster state and volumes; database-native backups for databases.
• Backups stored outside the cluster and account they protect.
• Test a restore. Put it in the calendar. The first restore test always fails; better on a Tuesday afternoon than during the incident.
• One page titled "the cluster is gone": how long to rebuild from Git + backups, and who does what.

6. Upgrades: a schedule, not an emergency

Kubernetes releases three times a year and versions fall out of support fast. Teams that upgrade "when forced" do it with maximum risk and zero practice.

• Upgrade at least twice a year, on the calendar.
• Run pluto or kubent for deprecated APIs before every upgrade.
• Add-ons (ingress controller, cert-manager, CSI, CNI) are part of the upgrade, not an afterthought — they break more upgrades than the control plane does.
• Test the upgrade on a throwaway or staging cluster first. IaC makes this cheap.

What NOT to copy from enterprises

• Multi-cluster, multi-region setups before you have multi-customer problems.
• A service mesh "because security." Start with NetworkPolicies.
• An internal developer platform / portal for five engineers.
• Change advisory boards. Your Git history + PR review is the change process.
• Every CNCF landscape logo. The landscape is a map, not a shopping list.

Copy the discipline (ownership, rollback, tested restore, upgrade cadence). Refuse the complexity (headcount-shaped architecture).

The one-hour exercise

Sit the team down and score yourselves 0–2 on each area above. Anything scoring 0 in backup, rollback, or secrets is your next sprint's priority — before any new feature of the platform. I've turned this into a 50-question scorecard with a 0–100 score; it's free — take it here.

The goal isn't a perfect platform. The goal is Kubernetes boring enough that your team can go back to shipping product.