Most discussions about the merits of Docker Swarm vs. Kubernetes focus on large-scale deployments. But, what if you’re running your containerized app on a single host or a small cluster? In that case, the considerations for choosing Swarm or a Kubernetes implementation tend to be different.
With that reality in mind, here’s a look at the benefits and drawbacks of Docker Swarm vs. Kubernetes for single-host environments. We’ll consider not just vanilla Kubernetes but also lightweight Kubernetes variants like k3s, Minikube, and MicroK8s. We’ll also touch on where Docker Compose fits within all of this too.
A general comparison of single-host Docker Swarm vs. Kubernetes
I don’t think it’s going too far to say that, at this point, many folks have almost written off Docker Swarm as a production-grade container orchestration tool. Kubernetes ate Docker’s lunch a year or two ago and Kubernetes has become the go-to orchestration solution for most large-scale container deployments.
Docker Swarm benefits for lightweight environments
But, that doesn’t mean Docker Swarm has nothing to offer. There are several reasons why you might consider using Swarm, especially for small-scale deployments:
Swarm is simpler
At the end of the day, Swarm is less complicated to configure and manage than Kubernetes. This might be a downside in a highly complex, large-scale deployment where you need all of Kubernetes’s features. But, for a simpler, single-host environment, there’s an argument to be made that Swarm has just the right amount of functionality to do what you need without making things too complicated for you.
Swarm is easy to install
On most Linux distributions, installing Swarm is as simple as installing the Docker Engine package. This means that, on a single host, you can install Swarm in just a few commands and be up and running in minutes. Kubernetes is more complicated to install, even if you use one of its lightweight variants.
Swarm involves fewer tools
When you use Swarm, you can work from the Docker CLI that you probably already know how to use (assuming you have worked with containers previously). If you use any form of Kubernetes, you need to master additional Kubernetes CLI tools.
Swarm is widely used and widely supported
Although mainstream Kubernetes is a well-supported tool, the same cannot always be said of its lightweight variants. Thus, if you want a lightweight orchestrator that’s also well-documented and well-integrated with other tools, Swarm is a better choice overall.
On the other hand, a few cons of Swarm can make a case against choosing Swarm over one of the lightweight Kubernetes implementations. The biggest drawback of Swarm is that, following the Mirantis acquisition of Docker Enterprise in November 2019, the future of Swarm remains somewhat uncertain.
To be clear, this doesn’t mean Swarm has no future, despite rumors that you may have heard to the contrary. At the time of the writing of this article, no one has officially announced the discontinuation of Swarm, and there is good reason to believe that if Mirantis isn’t interested in helping to maintain it, the community would.
Still, if you had to place money on whether Swarm or Kubernetes (and its lightweight variants) are going to be around in five, ten, or twenty years, the smarter bet would be on Kubernetes. So, although this consideration has nothing to do with Swarm’s actual functionality, it may be a reason to opt-out of relying on Swarm for production deployments.
You could also make a case that Kubernetes skills are in greater demand than expertise in Docker Swarm (and that was the case even before Mirantis’s acquisition of Docker Enterprise). For that reason, you might choose to avoid Docker Swarm and use a lightweight Kubernetes distribution instead, because teaching yourself Kubernetes may prove more valuable than honing your Swarm skills.
With that being said (and putting aside any worries about the future of Swarm), I tend to think that Swarm is a better fit for single-host environments, even though I prefer Kubernetes for larger-scale deployments. But, it’s a close call; depending on your preferences and priorities (not to mention where Swarm stands development-wise in a year or two from now), a lightweight Kubernetes implementation might be a better fit.
Why not just use Docker Compose?
If you’ve read this far, you might be wondering, “Why not just use Docker Compose to manage your single-host environment?”
That’s a fair question. Compose has some obvious selling-points (some of which overlap with those of Swarm and some of which double-down on Swarm’s benefits):
- It’s as easy to install as Docker Engine and Swarm
- It’s extremely lightweight
- It’s easy to use if you already know Docker
- It was one of the earliest management tools for Docker, so many developers already know how to use it (even if some may not have used it in a while)
So, for single-host environments, Compose can be a good fit. On the other hand, it’s so simple that it may not provide all of the automation you need. Compose doesn’t smoothly support rolling updates (technically it can do them, but it’s tricky). Container restarts are also iffy with Compose.
Basically, Compose provides very little automation. This is fine if your environment is so small that you can manage things manually – which may be the case if the purpose of your single-host deployment is simply to run dev testing, for example. But, if you’re dealing with more than a handful of containers, Compose may not cut it.
Resilient single-host environments with Swarm and Kubernetes
Choosing between Swarm and Kubernetes (and Compose) for single-host environments is tough. Each of these tools are capable of getting the job done. However, Swarm and Compose have the advantage of being simpler to set up and use in many respects, whereas Kubernetes and its variants tend to offer more features – not to mention a greater assurance they’ll remain actively developed for years to come.