The Kubernetes Checklist for Teams Without a Platform Team

Most Kubernetes advice assumes you have a platform team: specialists who own upgrades, ingress, security policies, and the 2 a.m. pages.

The teams I am writing for usually have three to ten engineers, one of whom “knows Kubernetes,” and no dedicated platform team. They depend on a cluster that 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 should it 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, certificate renewals, the CNI version, and deprecated APIs?

If the answer is one person's name, you do not 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 small enough for a small team to carry.

For each item, score 0 if it does not exist, 1 if it exists but is informal or untested, and 2 if it is documented and tested. The purpose is not to produce a flattering number. It is to expose the next few conversations the team needs to have.

1. Deployments: Git is the source of truth

• Treat Git as the source of truth for workloads and cluster configuration, including temporary fixes.
• Use one reconciliation path—for example, Argo CD or Flux—so production changes are reviewed and reproducible. Keep emergency access, but reconcile every emergency change back into Git.
• Define and test a rollback path for every service. A Git revert is useful only if your delivery process can deploy it safely.

This 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 late-night incidents

• Readiness probes that answer one question: can this pod serve traffic now? Include a dependency only when the application genuinely cannot serve a useful response without it.
• Graceful termination: handle SIGTERM and allow in-flight requests to drain. Add a short preStop delay only when your routing path needs time to stop sending new traffic, then test the behavior under load.
• Resource requests based on measured usage so scheduling and capacity planning reflect reality. Add limits deliberately; the right choice differs for CPU, memory, and workload behavior.
• PodDisruptionBudgets for replicated workloads that must remain available during voluntary disruptions such as node drains. Size them from the replica count and failure tolerance.

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

Small teams can over-index on advanced security machinery while skipping basics that matter in a customer security review:

• RBAC scoped per human and per workload. Nobody uses cluster-admin for daily work.
• Secrets via External Secrets Operator, Vault, or SOPS. Never store plaintext secrets in Git, and check who can run kubectl get secret in shared namespaces.
• Admission policy: block :latest, block privileged workloads, and require resource requests. Kyverno is one approachable option.
• NetworkPolicies around sensitive namespaces and workloads, starting with the traffic paths you actually understand.
• Restrict control-plane access to the networks and identities that need it; use the private-endpoint options of your managed provider where they fit your operating model.

That is a stronger starting point than adding advanced machinery while basic access and secret handling remain unclear.

4. Observability: answers, not data

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

• Prometheus—or a managed equivalent—plus golden-signal dashboards for your most important services.
• Alerts on symptoms users feel: error rate, latency, and saturation. Regularly review alerts that never produce action.
• Centralized logs with an explicit retention policy.
• Tracing when you have real multi-service debugging pain and the budget. “Not yet” can be a valid architecture decision.

5. Backup: a backup you have not restored is a rumor

• Velero—or a cloud-native equivalent—for Kubernetes resources and supported persistent volumes; database-native backups for databases.
• Backups stored outside the cluster and account they protect.
• Test a restore. Restore tests regularly expose missing permissions, credentials, data, or instructions. Find that out on a Tuesday afternoon, not during an incident.
• Write one page titled “the cluster is gone”: how long rebuilding from Git and backups should take, and who does what.

6. Upgrades: a schedule, not an emergency

Kubernetes releases regularly and managed providers enforce their own support windows. Teams that wait until an upgrade is forced take on more changes at once and have less recent practice.

• Set a cadence that stays comfortably inside your provider's support window, and put it on the calendar.
• Run pluto or kubent for deprecated APIs before every upgrade.
• Treat add-ons—ingress controller, cert-manager, CSI, and CNI—as part of the upgrade. Their compatibility can be as consequential as the control-plane version.
• Rehearse on a throwaway or staging cluster first.

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 portal for five engineers.
• Change advisory boards. For many small teams, Git history and pull-request review are the change process.
• Every logo in the CNCF landscape. The landscape is a map, not a shopping list.

Copy the discipline: ownership, rollback, tested restores, and an upgrade cadence.

Refuse the complexity: architecture shaped by headcount you do not have.

The one-hour exercise

You do not need to implement all of this at once. The useful outcome is a short, ordered backlog—not a perfect score.

Sit the team down and score each item from 0 to 2. Anything scoring 0 in backup, rollback, or secrets is a candidate for the next sprint—before another platform feature.

I turned this exercise into a 50-question production readiness scorecard that runs in the browser. It covers deployment safety, ownership, cost, security, observability, disaster recovery, and upgrades.

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

References

• Kubernetes documentation: probes
• Kubernetes documentation: container lifecycle hooks
• Kubernetes documentation: disruptions and PodDisruptionBudgets
• Kubernetes documentation: resource management