Isn't that what the managed kube offering you switched to gave you?
Managing your own kube deployment is very easy if you are only worried about that component.
> I'm worried that as an engineering culture we're not pushing back enough and saying, "Yeah K8s is cool but look: do you really need it? It's very likely you don't"
The benift in kube isn't the cluster management. It's the abstractions. Let's say "I don't need kube." Now we need to have this series of conversations...
- "The client said we need to make sure the site doesn't go down during deployments."
- "Can we deploy something that needs to be rolled out, restarted, upgraded, and use persistent disk" (like MySQL)
- "We need to monitor some metrics from the machines"
- "We need to scale the number of machines based on system utilization."
- "We need to hire an engineer to manage our infrastructure, so we need to bring them up to speed with our tooling"
- "We need to switch from cloud A to cloud B to save x/year"
- "We need to run on two clouds to fulfil some legal requirements"
There are all documented, standardized, and hireable (engineers already know it) tooling to do. Also it's all declarative so it's just YAML and no magic needed or manual management.
That's the magic of kube. That, the tooling, the shared vocabulary (no ramp up time for engineers), the platform Independence, the automatic scaling, the network security features, and the ability to define your own internal constructs (CRDs).