Getting a container to run is one milestone. Keeping the service healthy through an upgrade, a failed node or an absent team member is another. A Kubernetes decision should include both the workload and the people responsible for operating it.
Describe the workload before the platform
List the services, their dependencies and the business impact of an interruption. Identify stateful data, expected traffic patterns, recovery needs and any integration constraints. Then compare ways of meeting those needs.
A static website, a scheduled job and a set of services with independent release cycles present different problems. Consider a simpler managed service alongside a container platform. The useful question is which option the team can operate well for this workload.
Assign the operating responsibilities
The Kubernetes production guidance distinguishes between running the environment yourself and using managed services. A managed control plane can take on some availability, patching and upgrade responsibilities. The service boundary still needs to be understood.
For each option, name who owns the application, container images, access controls, configuration, monitoring and data recovery. Record what the provider handles and what remains with your team. Avoid treating ‘managed’ as a complete operating model.
- Who plans and tests upgrades?
- Who responds when an alert arrives?
- Who owns secrets, identities and image updates?
- Who can restore the service when the usual operator is unavailable?
Count the effort around the infrastructure
Include time for maintenance, incident response, deployment tooling and documentation in the comparison. Existing hardware can make a trial inexpensive, but production ownership also includes power, connectivity, equipment failures and the availability of the person operating it.
For a small team, the ability to recover confidently may matter more than using the same platform as a much larger organisation. An infrastructure bill is only one part of the operating cost.
Prove recovery before expanding
Use a representative workload to rehearse a release, a rollback and restoration from backup. Check that someone other than the original builder can follow the runbook. Record the steps that require undocumented knowledge or elevated access.
If Kubernetes remains the best fit, agree the ownership and maintenance plan before adding more services. If the simpler option meets the requirements with less operating effort, that is a useful engineering outcome too.
A USEFUL NEXT STEP
Choose a platform together with its operating model. A named owner, a tested recovery path and a realistic maintenance plan belong in the decision from the beginning.
Further reading
Source links checked on 14 November 2026.