I guess we worked at different Fortune 500 companies. What I see are companies adding complexity to their web infrastructure where none needs to exist.

A vanishingly small number of use cases require 100's of nodes, and the accompanying orchestration. Stack Overflow runs a top 25 website on 9 webservers, and most of those are just redundancy. Nothing Ansible/Bash or Powershell/MSDeploy can't solve in orders of magnitude less time. And debugging/diagnosing problems is much easier.

Were the Fortune 500 companies hosting k8s on-prem or on a cloud provider? From an operational standpoint, I can see where GP is coming from, especially if you are hosting on-prem, for non-greenfield projects.

Trying to integrate a k8s cluster into legacy infrastructure is non-trivial, and requires knowledgeable operations teams to deploy. Troubleshooting k8s requires extensive domain knowledge, in addition to foundational understanding of fairly advanced networking and distributed systems concepts. In my experience, working with k8s also requires much more vigilant watching of the project space for (breaking) changes, updated docs, SIG news, and github issues. Even if Google or Amazon is managing the k8s management, troubleshooting your app using kubectl, etc. is a new skill to learn.

I actually like a lot about using k8s, but I understand when people complain about the complexity.

Singley rooted Debs or RPMS with a nice single symlink init system and a log shipping system that is unified across the app stack will get you 90% of the way there. Add in a build system that ships "the world" inside your deb and you are 99% of the way there. Add in a cluster wide config system and you are 100% of the way there.

K8S forces people to use an algebra, the expression of that algebra can take many forms. Containers are _just_ trees of processes with ... contained separation boundaries.