There's a lot of stuff in this thread. I've addressed some of them briefly by adding a Discussion section to the post. I'll go into a bit more depth here.

It is important to identity where the complexity is coming from. The post describes how to spin up various resources in a common IaaS provider. Does it appear complicated? Well, everything is relative. Is what is described in the post more or less complicated than purchasing physical servers, racking them, networking them, installing an operating system, configuring the servers, configuring the services running on those services, setting up and configuring a firewall, configuring a network proxy, managing access to theses components, etc.? We've not even gotten to anything Kubernetes-specific here. The complexity is there, we are really just talking about how and where the complexity manifests itself. If you aren't managing a lot of services with distinct requirements, you can avoid complexity by using a more "concierge" application service like Heroku, Elastic Beanstalk, App Engine, or Firebase. The trade-off is less control over the environment and increased costs at scale, i.e., running one service is cheaper on these app services, running 100 will be more expensive.

If you decide you do need flexibility or your scale is such that Kubernetes makes sense, then be aware that the complexity is not in Kubernetes requirements for running an application. The complexity comes from the inherent complexities in running an application and the overhead in mapping common application requirements to the Kubernetes application model. Things like load balancers, TLS certificates, and DNS are part of the former and will be part of any solution. You must mentally map how you have traditionally managed applications to the Kubernetes concepts of deployments, pods, services, and ingresses. This can be challenging and confusing. Other runtime platforms, e.g., Docker Swarm, Cloud Foundry, and Mesos, have similar concepts and require similar mental effort. The reason that Kubernetes has won the open source platform competition is because its application model solves a large number of use cases, its abstractions provide an excellent balance between granularity, complexity, & flexibility, and it provides a platform upon which higher-order, i.e., simplified or "rolled-up", solutions can be created. Your relative familiarity and comfort with other runtime solutions should not cloud your judgement about which is best, and any consideration of best must consider more than just perceived "complexity".