Are these extremely large shops in some sort of pocket universe? Because I've been around the block enough to regularly experience Kubernetes's issues over and over again, and I'd say that the GP comment you're critiquing is actually right on the money. In my experience, people downplaying Kubernetes's drawbacks have either never been bitten by them, or make a lot of money by getting people to use Kubernetes.
Complex systems are complex. If you don’t need it, don’t use it.
But you’re absolutely wrong to call it unreliable. I’ve also “been around the block”, and I’ve seen 50k lines of BASH fail in complex ways too.
A google search would show you plenty of extremely large shops using k8s, and dozens or hundreds of tech talks by their lead engineers saying how much better it made their lives.
No it's not. Kubernetes is not an equivalent of a car, it's an equivalent of Land Rover Discovery 5 in your scenario. There are plenty of cars which score differently on some pre-agreed reliability scale (and, specifically, this model of Land Rover scores very poorly).
Kubernetes is light years away from being a reliable system. It's a system to support Web sites, which don't need to do anything that would require a lot of investment into reliability. Nobody in their right mind would use Kubernetes to run highly-reliable systems that, eg. put human lives at risk.
PostgreSQL is in a completely different category from reliability standpoint: much more reliable. But, if you put it on Kubernetes footing, you give up that reliability.
Again, maybe your business is to make Web sites -- then nobody cares, it's good enough. Running a database of a bank on top of Kubernetes -- well, I hope nobody actually tries that. And size has nothing to do with that. Reliability is about all sorts of metrics like mean time to failure / recovery and guarantees that the system makes like once a particular condition is encountered, the system will halt and so on. Kubernetes never claimed anything in that category, and, in practice, it doesn't offer any satisfactory guarantees of its own performance.
Anecdotally, I saw Kubernetes fail due to its internal problems more times that I can count. Like, we are talking about at least hundreds of times. And by "fail" I mean that the system enters into a state that cannot be salvaged by a reboot or replacement a master node(s). Since my interaction with it involves a lot of testing, but I'm not testing Kubernetes, rather something else running on it, I'm all too used to deleting and deploying new clusters.
This does not sound like knowledgable feedback. You should consider investigating and fixing the problem next time. At least to the point where you can explain to others what failed. A problem that continually affected you thru many clusters sounds like a configuration issue. PEBKAC, etc.
I previously worked for a company that ran highly-reliable systems that put human lives at risk. We increased the reliability of deployments and rollbacks quite a lot by moving to K8s, and that was years ago, when K8s was much newer than it is today. A very good friend still works there and they have zero plans or desires to move off K8s, as it works fantastically for them. They maintain 5 nines uptime and are responsible for daily hospital operations.
Also - plenty of human lives rely on “websites”. Your car probably speaks HTTP. I don't understand this line of thinking at all.
Yes, orchestration requires the orchestration tool.
No, k8s api is not unreliable or “finicky”.
This is being downvoted because it’s the equivalent of saying “delivery requires the use of a car? But engines are so unreliable, bad idea!”
Saying k8s and “reliable” don’t belong together is just flamebait - k8s runs reliably for tens of thousands of extremely large shops.