Docker Swarm vs Kubernetes

Need advice about which tool to choose?Ask the StackShare community!

Docker Swarm

775
974
+ 1
282
Kubernetes

58.2K
50.4K
+ 1
677
Add tool

Docker Swarm or Kubernetes — Help me decide


High Availability

Both Docker Swarm and Kubernetes provide High Availability and both support the inclusion of multiple Manager nodes, required to ensure high availability should the Leader Manager node fail.

Docker Swarm recommends an odd number of Manager nodes (1 of 3, 3 of 5 etc.) with no more than seven in a given swarm. Each Manager node can be configured to run application services, though this should be applied with caution. Kubernetes Manager nodes run additional containers, known as Pods, that facilitate core Kubernetes functionality. As such, it is considered bad practice to run application services on Kubernetes Manager nodes. Kubernetes Manager nodes are marked with a NoShedule taint to prevent accidental deployment of services to these nodes.

Both Docker Swarm and Kubernetes utilise Ingress networking, which allow the routing of external traffic to internal services. However, while Kubernetes Ingress is standardised, flexible and extensive, the Docker Swarm implementation aims for simplicity and ease of use.

Kubernetes can be configured to use a local Ingress load balancer, such as Ingress-Nginx, a simple exposed public port using NodePort, or a third-party load balancer, such as Amazon’s ELB.

Docker Swarm uses Raft Consensus to manage cluster state. Each Manager node is kept up-to-date with state information so that, should the Leader Manager fail, another Manager can be delegated as Leader and continue the role without significant changes to application stability. This is the reason for a maximum number of Managers. Maintaining state consistency between large numbers of nodes without a third-party store is problematic.

Kubernetes uses Etcd to manage cluster state. An Etcd Pod is deployed to each Manager node as replicated units. Data stored within one Pod instance is distributed to each of the other instances. As Etcd is an open-source data store, it can be utilised by the deployed application to store custom application configuration data.

Kubernetes provides greater configuration for management of service deployment to nodes when scaling or when nodes fail. As such, the decision to choose Kubernetes over Docker Swarm might be relevant when building applications that require fine tuning in order to ensure optimal use of available resources.

Service Discovery

Both Docker Swarm and Kubernetes provide DNS based service discovery. Docker Swarm utilises a DNS service integrated within the Docker Engine. Each service host domain name is equivalent to the provided service name. There is no notion of namespaces. In order to separate connectivity between services, each service can belong to one or more overlay networks. Direct calls to containers can be achieved by using the container alias as the domain or by using the containers assigned IP address.

docker-swarm-vs-kubernetes_docker-swarm-overlay-networks.png

Kubernetes service domains are maintained by the KubeDNS Pod. Each Pod and service receive an IP address relative to its parent. Thus, Pods within a service can communicate by IP address, too. Kubernetes provides numerous additional means to reference Pods and services through metadata, such as labels and annotations. Like Docker Swarm, Kubernetes services may be referenced by its simple service name. However, Kubernetes also provides for namespacing and use of Fully Qualified Domain Names (FQDN).

docker-swarm-vs-kubernetes_kubernetes-pods-and-services.png

The Kubernetes platform also provides a number of environment variables for use in referencing Pods and services in a cluster.

Communicating between services in Docker Swarm is relatively easy when you are aware of the service relationships during orchestration. However, when dealing with runtime service discovery and cross-cluster service discovery, Kubernetes provides more options.

Deployment

Docker Swarm deployments are managed using the Docker utility via the Stack commands. A Stack is a collection of services that form a deployment unit in Docker Swarm.

A Stack deployment is described using the docker-compose specification in YAML files. These files define the services to be deployed within a stack, their source repositories and their relationships to one another. The YAML files also detail the overlay network configurations and which services to assign to them, allowing for compartmentalization and security. A collection of services can be deployed using a single docker-compose.yaml file and additional files are often created to modify values for other deployments, such as testing, staging and production.

Kubernetes deployments are also described using YAML, but can be described using JSON if preferred. The deployment specification is extensive, but minimally requires definitions for Pods and Services. Deployments in Kubernetes are typically much more verbose than those of Docker Swarm, due to the increased configurability.

Both Docker Swarm and Kubernetes provide a means to apply rolling updates and for rolling back those updates as required. If an update deployment fails in Docker Swarm, the update is automatically rolled back to the previous version. Docker Swarm provides no endpoints to query an update status. A failed Kubernetes update will result in both the failed Pods and the original Pods existing side by side. A status endpoint does exist in Kubernetes. Once identified, rollbacks need to be requested explicitly.

As Kubernetes provides a means to select Pods, Services and other assets in a deployment using labels and annotations, running staging containers alongside production ones in the wild is easier in Kubernetes. This way, DevOps can roll out a single unit and test how it works in the production environment before committing to a cluster wide update. Performing the same feat in Docker Swarm is not so easy and is not typically done for this reason.

Docker Swarm deployments are considered much more user-friendly than Kubernetes. A misconception of Docker Swarm is that it cannot support large volumes of nodes and containers. It has been proven to support one thousand nodes and tens of thousands of containers in a single cluster. However, it is important to note that Docker Swarm does have a task limit. Kubernetes, on the other hand, has been documented as supporting ten times this number. With a recommended maximum of seven Managers in a cluster, Docker Swarm might not be sufficient for everyone’s needs, but this should only matter in the very largest of projects.

Performance

Comparing Docker Swarm and Kubernetes for performance is interesting, as both platforms utilise Docker containers and, for the most part, only manage the orchestration aspect of applications. Therefore, applications deployed with Docker Swarm and Kubernetes will operate with similar speed and efficiency.

When analysing orchestration performance, it has been documented that Docker Swarm will deploy and start containers as much as five times more quickly than Kubernetes when under heavy load, mainly due to the fewer moving parts within Docker Swarm and because of its tight integration with the Docker Engine.

docker-swarm-vs-kubernetes_deploy-graph.png

This same investigation also highlights Docker Swarms ability to respond to API calls much more quickly. While the responsiveness differences are negligible, the investigation does show that Docker Swarm performs without degradation at up to around 90% load, while Kubernetes degrades once it reaches only around 50% load.

docker-swarm-vs-kubernetes_api-graph.png

In a minimal Kubernetes installation, several containers are deployed to each Manager node, including:

- Etcd manager Pod
- API server Pod
- Kube Controller Pod
- KubeDNS Pod
- A network Pod, such as [Flannel](https://github.com/coreos/flannel) (optional)
- Kube Proxy Pod
- Scheduler Pod

On the worker nodes, Kubernetes will install the Kube Proxy and Kubelet Pods.

Each of these Pods use resources from the machine they are deployed to. In comparison, Docker Swarm doesn’t require the deployment of any containers as the Swarm functionality is built into the Docker service itself.

For most web applications, this should not pose a problem. The resources used by the default Kubernetes Pods is minimal and doesn’t perform much of an impact on the running application. However, this may indeed pose a problem for resource restricted environments, or environments that run on low power, such as Internet-of-Things (IoT) projects.

By Lee Sylvester

Docker Swarm vs Kubernetes: What are the differences?

  1. Scalability: Docker Swarm is designed for small-scale deployments, while Kubernetes is built with scalability in mind. Swarm can manage a maximum of 2000 nodes, whereas Kubernetes can handle tens of thousands of nodes. This makes Kubernetes a better choice for large-scale deployments where scalability is a primary concern.

  2. Networking: Docker Swarm relies on basic overlay networking, which can lead to performance issues in larger clusters. On the other hand, Kubernetes uses a more advanced networking model called Container Network Interface (CNI), which provides more flexibility and better performance for networking across clusters.

  3. Load Balancing: Kubernetes includes a built-in load balancer that can distribute incoming traffic across multiple pods, providing better load balancing capabilities out of the box. Docker Swarm, on the other hand, requires an external load balancer for distributing traffic, adding complexity to the setup process.

  4. Service Discovery: In Docker Swarm, service discovery is based on DNS resolution, which can be slower and less reliable compared to Kubernetes. Kubernetes includes its own service discovery mechanism called DNS service discovery, which provides automatic DNS resolution for services running within the cluster.

  5. Rolling Updates: Kubernetes supports rolling updates out of the box, which allows you to update your application containers without downtime. Docker Swarm also supports rolling updates, but it requires additional configuration and scripting to achieve the same level of automation and control.

  6. Documentation and Community: Kubernetes has a larger and more active community compared to Docker Swarm. This means that there are more resources, documentation, and support available for Kubernetes. Docker Swarm, while still actively supported, may have fewer community-contributed plugins and integrations compared to Kubernetes.

In Summary, Kubernetes offers better scalability, advanced networking, built-in load balancing, more reliable service discovery, simplified rolling updates, and a larger community compared to Docker Swarm.

Advice on Docker Swarm and Kubernetes

Hello, we have a bunch of local hosts (Linux and Windows) where Docker containers are running with bamboo agents on them. Currently, each container is installed as a system service. Each host is set up manually. I want to improve the system by adding some sort of orchestration software that should install, update and check for consistency in my docker containers. I don't need any clouds, all hosts are local. I'd prefer simple solutions. What orchestration system should I choose?

See more
Replies (1)
Mortie Torabi
Recommends
on
Docker SwarmDocker Swarm

If you just want the basic orchestration between a set of defined hosts, go with Docker Swarm. If you want more advanced orchestration + flexibility in terms of resource management and load balancing go with Kubernetes. In both cases, you can make it even more complex while making the whole architecture more understandable and replicable by using Terraform.

See more
Decisions about Docker Swarm and Kubernetes
Michael Roberts

We develop rapidly with docker-compose orchestrated services, however, for production - we utilise the very best ideas that Kubernetes has to offer: SCALE! We can scale when needed, setting a maximum and minimum level of nodes for each application layer - scaling only when the load balancer needs it. This allowed us to reduce our devops costs by 40% whilst also maintaining an SLA of 99.87%.

See more
Simon Reymann
Senior Fullstack Developer at QUANTUSflow Software GmbH · | 30 upvotes · 8.9M views

Our whole DevOps stack consists of the following tools:

  • GitHub (incl. GitHub Pages/Markdown for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
  • Respectively Git as revision control system
  • SourceTree as Git GUI
  • Visual Studio Code as IDE
  • CircleCI for continuous integration (automatize development process)
  • Prettier / TSLint / ESLint as code linter
  • SonarQube as quality gate
  • Docker as container management (incl. Docker Compose for multi-container application management)
  • VirtualBox for operating system simulation tests
  • Kubernetes as cluster management for docker containers
  • Heroku for deploying in test environments
  • nginx as web server (preferably used as facade server in production environment)
  • SSLMate (using OpenSSL) for certificate management
  • Amazon EC2 (incl. Amazon S3) for deploying in stage (production-like) and production environments
  • PostgreSQL as preferred database system
  • Redis as preferred in-memory database/store (great for caching)

The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:

  • Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
  • Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
  • Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
  • Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
  • Scalability: All-in-one framework for distributed systems.
  • Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.
See more
Get Advice from developers at your company using StackShare Enterprise. Sign up for StackShare Enterprise.
Learn More
What are some alternatives to Docker Swarm and Kubernetes?
Docker Compose
With Compose, you define a multi-container application in a single file, then spin your application up in a single command which does everything that needs to be done to get it running.
Rancher
Rancher is an open source container management platform that includes full distributions of Kubernetes, Apache Mesos and Docker Swarm, and makes it simple to operate container clusters on any cloud or infrastructure platform.
Ansible
Ansible is an IT automation tool. It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates. Ansible’s goals are foremost those of simplicity and maximum ease of use.
Apache Mesos
Apache Mesos is a cluster manager that simplifies the complexity of running applications on a shared pool of servers.
CoreOS
It is designed for security, consistency, and reliability. Instead of installing packages via yum or apt, it uses Linux containers to manage your services at a higher level of abstraction. A single service's code and all dependencies are packaged within a container that can be run on one or many machines.
See all alternatives