I don't know if that's a fair comparison. If you deploy a monolith you have to set up a custom multi data center deploy and manage all the load balancing/disaster recovery/volume management(databases) yourself. Kubernetes isn't that hard to setup and gives you out of box solutions to all that.

It also gives more flexibility on adding additional services around your monolith. Elk stack, kafka, that kind of stuff. Also gives you a standard api to deploy against. I don't think your metaphor holds up.

This is a poor analogy. To quote a sibling comment:

"If you consider what it takes to manage the end-to-end lifecycle of a single application, monolith or micro-service, you need a solution for the following items: deployments, application configuration, high availability, log and metrics aggregation, autoscaling, and load balancing across multiple application instances.

Kubernetes provides an opinionated way of doing all of those things. For example, Kubernetes leverages container images and declarative configs for packaging and deploying applications. For many people this approach is much simpler than what Puppet, Chef, and Ansible bring to the table in terms managing applications."

Using Kubernetes even with a monolith can be pretty nice, if (big if here) Kubernetes behaves.

Ah, as someone not well versed with K8s, thanks for that analogy.