If I can summarize your points in short, I'm getting that your view of Kubernetes is that it abstracts complexity that is inherent to our problem domain in an attempt to simplify it as best it can. In particular that is true around deployments.

Point taken, and it's a valid one. I'll throw some more of my perspective at you here (from a guy who mainly uses AWS managed services).

Let's talk scaling. Scaling is, and has been a solved problem before Kubernetes (see autoscaling groups). Imagine an autoscaling group whose instances launch and run one docker container -- your service (maybe also nginx, if you want). Maybe you even went the extra mile and baked your app's docker container into an AMI so you don't take a runtime dependency on Docker Hub or similar.

In an autoscaling group, you define where instances can launch and what type you want. You can get fancy about capacity by leveraging weighted capacities to increase instance type diversity. You set the amount of capacity you want, and it goes. ASG instances register with a target group behind a load balancer, and you're off to the races. Oh and by the way: if any of those things break, it's Amazon's problem, not mine (could be good or bad; I personally think it's good).

AWS has scaling figured out. Busy neighbors? Can't say that I have been impacted by that recently. Run out of disk? The impact of that is limited to one node that can be respun independently of everything else.

Kubernetes scaling is a similar story with a different interface... except now you have to worry about how services stack up on nodes. For example, suppose you have a node of size "4X" and a service of size "3X" (X can be whatever limiting factor you want - CPU or memory). You now have to deal with the potential issue of 1X being wasted on nodes that the 3X service is deployed to. Maybe there's a 1X service that can slot in there. Maybe the 1X service is not scaled as high as the 3X service, so some nodes just sit there with wasted utilization. You can deploy the 3X service to a correctly sized node group, but that's another thing to manage. You could go the route of oversubscribing resources, which would save money but it's another failure mode for your infrastructure.

If you run Kubernetes on AWS, it's probably using autoscaling groups anyway. And then on top it's doing its own orchestration. So to run Kubernetes on AWS, you have to understand both autoscaling AND how Kubernetes works.

How about security? The wisdom of the day is: don't colocate sensitive services on the same Kubernetes nodes due to container escape concerns (and probably some others). So now you're looking at running an entirely separate Kubernetes cluster, or at least segregating the sensitive service to a different set of nodes. That's more management that is simply a non-issue running a VM-focused workload.

How about load balancing? AWS can manage your load balancer and get you an SSL certificate that renews automatically. In Kubernetes, you can use the managed stuff or roll your own load balancing. If you elect to roll your own, you get the same functionality -- except if it breaks, it's your problem. If you roll with the managed stuff, you now have to understand not only how AWS load balancing works, but also how Kubernetes interacts with it. If the Kube interfaces breaks, it's probably your problem.

I could continue here, but I think you get the idea.

The central issue of Kubernetes is that you take on more problems than you otherwise have to versus using managed services. Amazon has entire teams working SPECIFICALLY on autoscaling, load balancing, SSL cert provisioning, etc. Any individual or team who thinks they can do better (in addition to their other job duties) probably has a bit of an ego issue.