Docker Swarm vs Kubernetes: In-Depth Comparison and Tutorial

Containers have revolutionized how we develop, package, and deploy applications. However, running containers in production requires a distributed platform for scaling, scheduling, and managing containers across a cluster. This is where container orchestration comes in.

Two of the most popular choices for container orchestration are Docker Swarm and Kubernetes. In this article, we‘ll dive deep into both technologies, learn how to set them up on virtual machines, and compare their key features and use cases. By the end, you‘ll have a solid understanding of the differences and when you might want to use one over the other.

But first, let‘s clarify what we mean by "container orchestration." As you deploy more and more containerized applications, you quickly run into challenges managing all the containers and utilizing your infrastructure efficiently. Key considerations include:

• How do you deploy and connect containers across multiple hosts?
• How do you scale services up or down based on load?
• How do you perform updates and rollbacks without downtime?
• How do you monitor container health and automatically recover from failures?

Container orchestrators like Docker Swarm and Kubernetes aim to solve these challenges by providing a declarative way to manage containerized applications across a cluster. Instead of dealing with individual containers, you describe the desired state of your application (e.g. which services to run, how many replicas) and the orchestrator takes care of making it happen.

Docker Swarm Architecture and Features

Docker Swarm is the native clustering and orchestration solution from Docker, Inc. It allows you to create a cluster (or "swarm") of Docker hosts and deploy your application services to it.

Some key features of Docker Swarm include:

• Cluster management integrated with Docker Engine
• Decentralized design with no single point of failure
• Declarative service model
• Scaling and load balancing of services
• Rolling updates with healthcheck and rollback
• Service discovery and internal load balancing via embedded DNS
• Secure communication between nodes with mutual TLS
• Backwards compatibility with Docker Compose

In a Docker Swarm, there are two types of nodes: managers and workers. The managers are responsible for the control plane, accepting service definitions from the user, and scheduling service containers on the worker nodes. The workers simply run the service containers assigned to them. You can have a single manager or multiple managers for high availability.

All nodes participate in an overlay network called ingress which load balances traffic to published services. This mesh routing allows each node to accept connections on published ports for any service, even if the service isn‘t running on that node.

Setting Up Docker Swarm on Two VMs

Now let‘s see how to actually set up Docker Swarm. We‘ll create a simple two-node cluster running on VirtualBox VMs with Ubuntu.

Prerequisites:

• Two VMs running Ubuntu (I‘m using 18.04)
• Docker Engine installed on both VMs
• Both VMs able to communicate over a network

Step 1: Initialize the Swarm

On the first VM, initialize a new swarm:

docker swarm init --advertise-addr <MANAGER_IP>

Replace <MANAGER_IP> with the IP address of the first VM. This will initialize a new swarm and output a join token.

Step 2: Add a Worker Node

Copy the join token from the previous step. On the second VM, run:

docker swarm join --token <JOIN_TOKEN> <MANAGER_IP>:2377

This will join the second VM as a worker node to the swarm.

Step 3: Verify the Cluster

Back on the first VM (the manager), run:

docker node ls

You should see both nodes listed, with the first node marked as a manager.

That‘s it! You now have a functioning two-node Docker Swarm cluster. Next, let‘s deploy an application to it.

Deploying an Application to Docker Swarm

We‘ll deploy a simple web application using the Docker Compose syntax. Create a file called docker-compose.yml with the following contents:

version: ‘3‘
services:
  web:
    image: my-web-app
    deploy:
      replicas: 3
    ports:
      - 8080:80

This defines a service called web that runs 3 replicas of a hypothetical my-web-app image and publishes port 80 of the containers as port 8080 on the swarm nodes.

To deploy the stack, run:

docker stack deploy --compose-file docker-compose.yml myapp

Docker will pull the image and distribute the service containers across the swarm. You can verify the service is running with:

docker service ls

And that‘s how easy it is to deploy an application on Docker Swarm! The swarm will take care of distributing traffic to the three replicas and recovering from failures.

Next, let‘s compare this experience to using Kubernetes.

Kubernetes Architecture and Features

Kubernetes is an open-source orchestration system for containers, originally developed by Google. It has quickly become the industry standard, with a large ecosystem of supporting tools.

Like Docker Swarm, Kubernetes allows you to cluster multiple host machines and schedule containers to run on them according to declared rules. However, Kubernetes has a more extensive feature set and a different architectural approach.

Key features of Kubernetes include:

• Automated container deployment, scaling, and management
• Load balancing and service discovery through Kubernetes Services
• Storage orchestration for persistent volumes
• Automated rollouts and rollbacks
• Secret and configuration management
• Batch execution for long-running jobs
• Horizontal scaling of containerized applications

In a Kubernetes cluster, the control plane consists of several components including the API server, etcd key-value store, scheduler, and multiple controllers. These can run on a single master node or be split across multiple nodes for high availability.

The worker nodes run the containers (grouped into Pods) as instructed by the control plane. They also run the kubelet agent for communicating with the master, and the kube-proxy network proxy.

The basic workflow in Kubernetes is:

1. User defines a desired state in a declarative YAML or JSON manifest
2. User submits the manifest to the Kubernetes API server
3. Kubernetes stores the desired state in etcd
4. The controllers work to make the actual state match the desired state

This declarative, desired-state approach is a key advantage of Kubernetes compared to imperative, step-by-step approaches.

Setting Up Kubernetes on Two VMs

Setting up Kubernetes from scratch is more complex than Docker Swarm. However, we can use kubeadm to automate most of the process.

Prerequisites:

• Two VMs running Ubuntu (I‘m using 18.04)
• 2 GB or more of RAM per machine
• 2 CPUs or more on the master
• Swap disabled
• Unique hostname, MAC address, and product_uuid for every node
• Certain ports open on each node
• Docker installed on all nodes

Step 1: Install kubeadm

On both VMs, install kubeadm, kubelet, and kubectl:

sudo apt-get update && sudo apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

Step 2: Initialize the Master Node

On the first VM, initialize the Kubernetes control plane:

sudo kubeadm init --pod-network-cidr=192.168.0.0/16

This will perform set up and output a join command for worker nodes. Copy the join command.

Step 3: Set Up kubectl

On the first VM, set up kubectl:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Step 4: Install a Pod Network

Still on the first VM, install the Calico pod network add-on:

kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

Step 5: Join the Worker Node

On the second VM, run the join command copied in step 2. This will connect the worker node to the cluster.

Step 6: Verify the Cluster

On the first VM, verify all nodes are ready:

kubectl get nodes

You should see two nodes in the Ready state. Your Kubernetes cluster is now set up!

Deploying an Application to Kubernetes

To deploy the same example web application to Kubernetes, create a file called web.yaml with the following contents:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: my-web-app
        ports:
        - containerPort: 80
---
apiVersion: v1        
kind: Service
metadata:
  name: web
spec:
  selector: 
    app: web
  ports:
    - port: 8080
      targetPort: 80
  type: LoadBalancer  

This creates a deployment with 3 replicas of the my-web-app container, and exposes it externally via a load balancer service on port 8080.

Apply the manifest to the cluster:

kubectl apply -f web.yaml

Kubernetes will pull the image and create the necessary pods and service. You can monitor the progress with:

kubectl get deployments
kubectl get services

Once the external IP appears for the service, you can access the application on that IP and port 8080.

Comparing Docker Swarm and Kubernetes

We‘ve now seen how to set up clusters and deploy an application with both Docker Swarm and Kubernetes. So how do they compare?

Key similarities:

• Both are designed for managing containerized applications across a cluster
• Both provide functionality for scaling, load balancing, and rolling updates
• Both use a declarative desired-state model (Docker Compose vs. Kubernetes manifests)

Key differences:

• Kubernetes has a richer feature set and is more customizable
• Docker Swarm is easier to set up and get started with
• Kubernetes has a stronger focus on automation with controllers and operators
• Docker Swarm integrates tightly with the Docker API and tooling
• Kubernetes has a larger ecosystem and is seen as the de-facto standard

Essentially, Docker Swarm is simpler and more tightly integrated with the Docker ecosystem, while Kubernetes is more powerful and flexible but comes with increased complexity.

In general, Kubernetes is recommended for large-scale, production-grade deployments of complex applications. It provides more advanced automation, scalability, and flexibility.

Docker Swarm is well-suited for smaller deployments, development environments, or teams already heavily invested in Docker tooling. It‘s easier to get started with and provides a simpler experience.

The Future of Docker Swarm

In November 2019, Docker announced the sale of its Enterprise business to Mirantis. As part of this deal, Mirantis acquired the Docker Enterprise product as well as the responsibility to support Docker Swarm for at least two years.

However, this has led to uncertainty around the long-term future of Docker Swarm. While still supported, it‘s unclear how much investment it will receive going forward compared to Kubernetes.

Many see this as a further sign of Kubernetes‘ dominance in the container orchestration space. Kubernetes has won the mindshare of developers and the support of all major cloud providers.

That said, Docker Swarm remains a solid choice for now, especially for smaller scale use cases. It will continue to work and be supported. But if you‘re starting a new project, Kubernetes may be the safer long-term bet.

Conclusion

Both Docker Swarm and Kubernetes are powerful tools for managing containerized applications at scale. Docker Swarm provides a simpler, more integrated experience, while Kubernetes offers richer functionality and flexibility.

For production deployments, Kubernetes is generally recommended due to its extensive features, robustness, and large ecosystem. However, Docker Swarm remains a good choice for simpler use cases or teams heavily invested in the Docker platform.

Ultimately, the choice depends on your specific needs and existing environment. Hopefully this in-depth comparison has given you the information needed to make that decision.

Whichever you choose, both Docker Swarm and Kubernetes are solid solutions for running containers in production. Happy orchestrating!