See https://pythonspeed.com/articles/dont-need-kubernetes/ for some of the reasons NOT to use Kubernetes for this.
With, of course, a giant exception for two cases. The first is, as with the author, if the purpose of using Kubernetes is to learn how to use Kubernetes. The second is if you are aware of the tradeoffs and have specific reason to say that Kubernetes really is appropriate for your circumstance.
And if you think that Kubernetes is always the right approach, then you clearly are NOT aware of the tradeoffs.
Yeah, we did, and they were complicated then and they're complicated now. The difference is some of us have decades of experience which make them feel simpler.
> And if you think that Kubernetes is always the right approach, then you clearly are NOT aware of the tradeoffs.
I was very explicit that Kubernetes isn't always the right approach. Allow me to quote myself: "If all you're ever doing is hosting a static blog, then yeah, you don't need something like Kubernetes". My point is that things like Kubernetes and Docker Compose are increasingly viable defaults for nontrivial cases. In other words, if you know you're going to have a bunch of services to manage, it's a lot easier for most people (i.e., those lacking decades of experience) to manage them with the aforementioned tools rather than trying to build an equivalent "platform" from scratch.
From what I've seen, even people without "decades of experiment" find the non-abstracted system easier to understand and reason about than the Kubernetes version. And the difference in ease is dramatic.
Examples where it makes sense include:
1. You need to deploy multiple independent systems with similar configurations. (Even then, consider ansible.)
2. You have to deploy different clusters of connected systems with related, but different, components.
3. You need to scale up and down what needs to be deployed. (Except don't try to use autoscale. That only works in marketing blurbs.)
4. Somebody else has set it up and you never need to actually understand it. (Good luck if you need to debug.)
But there is no reason to introduce Kubernetes because you need a database, a few webservers, front end proxy, failover, etc. And if you are using Kubernetes for that, odds are that you'll save yourself a world of headaches (and potential security holes!) by migrating away. No matter how much the "chief architect" may claim otherwise. I've seen how this plays out in practice.
Moreover, for single-server use cases, Docker Compose eschews a lot of the complexity that Kubernetes brings for HA purposes while also masking over much of the complexity of managing bare servers.
The Kubernetes (and other container orchestrators) learning curve is substantial, but it masks a lot of incidental complexity that operators would otherwise need to understand to do it themselves.
A 50 person company with <10 developers has very different problems.
I have another server ssh in every night and drop everything to a folder in my dropbox account. Replicates to computers that have incremental backups and less granular off-site backups.
After working with Docker and Kubernetes for some years, i consider that a huge win. Heck, even a cgi-bin script hacked together in perl is better documented and more reliable!