So they made bad architecture decisions, blamed it on Kubernetes for some reason, and then decided to rebuild everything from scratch. Solid. The takeaway being what? Don't make bad decisions?
My personal takeaway, when it fails and you can't blame anyone for any reason, blame a tool.
You'll get the whole team helping you when replacing the tool and setting up a better solution.
If you blame anyone, people will start to be extra cautious and won't take any initiative.
But don't overuse it, if you always blame the tool, you'll end up like my ex colleague "Steve" where every failure was Microsoft's fault.
I've always been fond of blaming myself and asking everybody else to help make sure I don't cock it up a second time - when it works out I get lots of help, lots of useful feedback, and everybody else feels good about putting the effort in.
This does require management who won't punish you for recording it as your fault, though. I've been fairly lucky in that regard.
Your ex-colleague may not be factually correct, but I agree with him in spirit.
I think the takeaway was Kubernetes did not work for their team. Kubernetes was probably not the root problem but it sounds like they simplified their infrastructure greatly by standardizing on a small set of technologies.
Kubernetes is not an easy to use technology and sometimes its documentation is lacking. My gut feeling is Kubernetes is great if you have team members who are willing to learn how to use it, and you have a LOT of different containers to run. It probably is not the best solution for small to medium sized teams because of its complexity and cost.
It highlights a classic management failure that I see again and again and again: Executing a project without identifying the prerequisite domain expertise and ensuring you have the right people.
Well understanding the problem and finding competent people is hard, riding on tool marketing and hiring bootcampers to do as you say is easy.