In like 90% of the cases when someone used Kubernetes, Docker Swarm would have easily sufficed.
Docker Swarm is much more deserving of this kind of cynicism -- a weak, badly designed solution forced on users by a company that's realizing their invention has been commoditized and is no longer a platform they control. Swarm was redesigned at one point to work more like Kubernetes because they realized it was a much saner model.
Kubernetes has more complexity, but it does scale down to single-node clusters.
Docker Swarm might be incomplete and missing quite a few features, and it won't scale to thousands of nodes with dozens of independent apps, but the use-cases I've seen are far from that. A single engineer can basically get a "good-enough" moderately scaled system going.
If you have Google-scale problems with Google-caliber engineers and SREs backing you, use Kubernetes. Otherwise, using something else (Docker Swarm "just worked" for the cases I've seen) is easier.
The core of Kubernetes is super simple and all the hard parts are hidden away on actually setting up and maintaining kubernetes the hard way on bare metal machines. Odds are, if you're doing that, you have the resources to take some time to dive deeper into how it works.
I've done multiple single engineer Kubernetes setups that are working on production today. So far I've had only a few problems with it. I know it's not a huge data range, but I'm not the smartest person in the world (or a true infrastructure guy) and still found it easy to work with.
Swarm has always been a rushed afterthought IMO. Although I have way less experience with it than k8s, so I'm biased on this.
I moved to Swarm a year ago and have had a grand total of 0 issues. It can do everything I need.
The ingress story in kubernetes is bring-your-own and usually people run their clusters behind Google or AWS LB which are supported as ingress in k8s. Running k8s on metal is a super daunting task. Choosing your network plugin is another task and usually you have to install a different system service on each of your nodes - Swarm has this built in.
And lastly the Compose file format. 10 lines of Swarm compose file literally translate into multiple dozens of separate k8s yml file. Creating this in k8s is super complex in itself.
Swarm is really pretty nice for someone setting up a few dozen nodes and services.
In my experience it's even like this: I have never seen any working kubernetes app. But I deployed my own hello world docker swarm app in 2 days. (And that is a fact, not an opinion. The opinion part is up to you.)
A penguin walks into a bar, goes to the counter, and asks the bartender, "Have you seen my brother?"
The bartender says, "I don't know. What does he look like?"
- Swarm does not have namespaces, a swarm cannot be divided into multiple independent ones.
- Swarm CE does not have per-operator Auth
And
- k8s has more moving parts
- has more complicated config files
To me swarm is to k8s like nginx is to apache. The former is lean and easy to setup, the latter has all the bells and whistles for enterprisey, service provider scenarios.