Kubernetes and Docker’s Swarm mode are two container orchestration tools that let you scale workload replicas across multiple physical machines. Although Kubernetes is the more popular choice, Docker Swarm has some unique benefits that are worth considering too.
Here’s a look at how these two technologies compare across their key functions. Both have the same end goal – letting you scale containers – but achieve it in sometimes quite different ways. No matter which you choose, you’ll be able to launch and scale containers created from images built with Docker or another popular container engine.
Overview
Kubernetes was initially developed as an open-source project at Google. It now resides at the Cloud Native Computing Foundation (CNCF), a cross-industry effort to promote and maintain widely used cloud native projects.
Getting set up with Kubernetes requires you to create a cluster of physical machines called nodes. These machines run your containers and are controlled by a centralized primary node that issues container scheduling instructions. Worker nodes act on those instructions to pull images from registries and start your containers.
Kubernetes is meant to be enterprise-grade and production-ready. Its scheduling capabilities incorporate auto-scaling, auto-placement, load distribution, and continual monitoring for container terminations and restarts.
Swarm mode is Docker’s built-in orchestrator, included as part of the standard Docker distribution. Any machine with docker installed can create or join a swarm cluster.
Swarm also lets you link multiple independent physical machines into a cluster. It effectively unifies a set of Docker hosts into a single virtual host. There’s a relatively shallow learning curve and users familiar with single-host Docker can generally get to grips with Swarm mode quickly.
Like Kubernetes, a single Swarm manager node is responsible for scheduling and monitoring containers. The manager can react to incidents in the cluster, such as a node going offline, and reschedule containers accordingly. It supports rolling updates too, letting you scale workloads without impacting availability.
Adding New Workloads
Kubernetes applications are deployed by creating a declarative representation of your stack’s resources in a YAML file. The YAML is “applied” to your cluster, typically using a CLI such as kubectl, then acted upon by the Kubernetes control plane running on the primary node.
Additional tooling via projects like Helm lets you “install” applications using preconfigured “charts.” These are collections of YAML files that have been packaged for easy addition to your cluster.
Kubernetes offers dozens of resource types that abstract cluster functions such as networking, storage, and container deployments. Learning the different resource types and their roles presents a fairly steep learning curve to a newcomer. You’re encouraged to look at your system’s overall architecture, not just the nuts and bolts of individual containers.
Docker Swarm also uses YAML files but simple deployments can be created without them. The Swarm CLI offers imperative commands as an alternative so you can launch a trio of NGINX containers by running:
When YAML files are used, the format is still much more concise than Kubernetes resources. Swarm stack definitions are very similar to Docker Compose files; Swarm can deploy most Compose files as-is, which lets you easily transition your existing Dockerized workloads into scaled operation in a multi-node Swarm cluster.
Kubernetes works with abstractions which sit a long way above your actual containers. You need to understand terms like Replica Set, Deployment, and Pod, and how they relate to the containers you’re running. By contrast, defining Swarm services will feel familiar to anyone who’s already used Docker and Docker Compose.
Scaling Containers
Kubernetes and Docker Swarm are both built with scalability as their main objective. At a basic level, they let you replicate your containers across multiple isolated worker nodes, improving your resiliency to hardware failure and letting you add new container instances to meet demand.
Kubernetes provides strong guarantees around replication, consistency, and distribution. It can automatically scale your services based on external factors, ensuring your workloads remain accessible even during times of peak demand. This automation can be a deciding factor for busy operations teams.
Docker Swarm requires scaling to be conducted manually, either by updating your stack’s Compose file or using a CLI command to change the replica count. It’s simple but effective: changes apply much more quickly than Kubernetes, as Swarm is a less complicated system. This means it can be the better choice if you need extreme responsiveness.
Both orchestrators are also effective at maintaining high availability. Kubernetes and Docker Swarm will each reschedule containers if one fails or a worker node goes offline. This behavior automatically maintains your specified replica count, assuming sufficient resources are available on your other nodes.
Networking and Load Balancing
Kubernetes exposes workloads via “services” which act as in-cluster load balancers. Traffic usually reaches the service via an Ingress, a resource that lets you filter incoming requests based on properties such as their hostname and URL.
As usual with Kubernetes, this means there are several steps and abstractions to learn. Your container Pods need to reference a Service, which is itself referenced by an Ingress defining your routing rules. The upside is that all of this is built into Kubernetes; the only prerequisite is an external load balancer pointing at your cluster’s primary IP address. Managed Kubernetes cloud providers usually offer a one-click method to create such a load balancer.
Networking behaves differently in Docker Swarm. In a similar fashion to regular Docker containers, you can easily publish ports to an ingress network that’s accessible across all the hosts in the swarm. This incorporates a routing mesh that ensures incoming requests reach an instance of your container on any of the available nodes. Swarm also offers a per-host networking mode where ports are only opened on the individual hosts on which containers run.
What Swarm lacks is a built-in way of routing traffic to containers based on request characteristics like the hostname and URL. To achieve this, you’d usually add a reverse proxy such as NGINX, Traefik, or HAProxy that acts as the entrypoint to your swarm, matches incoming requests, and forwards them to the appropriate container. Adding an additional infrastructure component to expose services behind different domain names can make Swarm less suitable for multiple production workloads.
Observability
Kubernetes and Docker Swarm both have built-in logging and monitoring tools that let you inspect container logs and resource consumption. In the case of Kubernetes, you can observe your cluster using popular CLI tools like kubectl, or switch to a web-based interface such as the official dashboard. Swarm exposes logs through its CLI similarly to regular Docker container logs – use docker service logs to stream from a service.
Where Kubernetes’ observability support extends beyond Swarm’s is in its integrations with third-party tools. Adding a monitoring system such as Prometheus lets you query, visualize, and store metrics and alerts, while aggregators like Fluentd provide similar capabilities for logs. These help you develop a highly observable cluster which you can readily inspect from the outside.
These tools can still be used with Docker Swarm but you’ll need to set up your own procedures to move data from your swarm into your aggregation platforms. Kubernetes provides a more seamless experience where the tools run inside your cluster, inspecting it from within.
Conclusion
Kubernetes and Docker Swarm are two container orchestrators which you can use to scale your services. Which you should use depends on the size and complexity of your service, your objectives around replication, and any special requirements you’ve got for networking and observability.
Kubernetes is a production-grade system which includes auto-scaling, network ingress, and easy observability integrations in its default installation. That installation can be trickier to achieve as you’ll need to maintain your own cluster or create one with a public cloud provider. Self-managing the control plane can be quite involved, with Kubernetes administration now commonly seen as a job title in its own right.
Deploying to Kubernetes requires an understanding of the underlying concepts, how they abstract container fundamentals, and the resource type you should use in each scenario. This makes for a relatively steep learning curve; Kubernetes has a reputation for complexity and causing confusion to newcomers, which is worth bearing in mind if you don’t have a dedicated operations team.
Docker Swarm is much simpler to get running. If you’ve got Docker installed, you’ve already got everything you need. Swarm can horizontally distribute your containers, reschedule them in a failover situation, and scale them on-demand.
Day-to-day use is very similar to established Docker workflows. The core CLI commands are reminiscent of regular Docker container operations and there’s compatibility with your existing Docker Compose files. This makes Swarm ideal for quick use in internal environments and developer sandboxes that are already heavily Dockerized.
You don’t need to put everything into one platform: many teams use both Swarm and Kubernetes for different systems, allowing the benefits of both to be realized. Swarm is simpler, easier to maintain, more familiar to developers, and quicker to scale your services. Kubernetes is more demanding to operate and founded on its own abstractions but gives you automation, a fully integrated networking solution, and access to a growing ecosystem of supporting tools.
