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?
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.
This does require management who won't punish you for recording it as your fault, though. I've been fairly lucky in that regard.
Steve usually said that Microsoft should ask for a confirmation before deleting anything, even with the "-Force" parameter.
It was Microsoft's fault when the whole test environment, that he spent two days setting up, was deleted with the "-Force" parameter. He said something along the lines of "Microsoft shouldn't let me do this".
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.