Docker Swarm

vs

Kubernetes

Swarm
Kubernetes
Comparison
wrap-up

SWARM

Swarm Components

Node : Bare-metal machine or VM or Cloud instance.
Swarm : A cluster of nodes
Manager Nodes : Understand the desired configuration and give the job to the workers but could be a worker as well (bad practice)
Worker Nodes : These nodes collect and run tasks from manager nodes.
Service : Container (based on image) with metadata like replicas, networks and volumes.

Swarm Cluster Architecture

Kubernetes

def.

(Opinionated) Orchestration framework to organise and deploy container-based applications

Agnostic sandbox where you provide the desired state of your services/apps. Kubernetes aims to take care of everything else

Let's see how it works

Nodes

CLUSTER

PERSISTENT VOLUMES

OTHER Kubernetes components

etcd : Distributed database to store configuration
API Server : Entry point of the entire cluster, it exchanges with etcd. Manage the authorizations and implement a watch mechanism.
Controller Manager : Make the necessary change to reach the desire state. Manage the replication and endpoints controller.
Scheduler : Control the nodes resources and handle the assignment of the pods.
Kubelet : Monitor the pod activity (health check) . Stop /start and update the running pods.

Let's see how apps runs

Container

PODS

DEPLOYMENT

KUBERNETES COMPONENTS

Pods : A pod is a group of one or more containers (such as Docker containers), with shared storage/network, and a specification for how to run the containers. A pod’s contents are always co-located and co-scheduled, and run in a shared context.
Deployments : You describe a desired state in a Deployment object, and the Deployment controller changes the actual state to the desired state
Services : Network endpoints that can be reach by external service. The service will automatically round-robin requests between pods. Kubernetes embed a DNS server for the cluster that watches for new services (discovery service).
Labels : Key-value information to search and update the components.

KUBERNETES ARCHITECTURE

Let's see how access/run it

kubectl is your local CLI command center.
You can issue commands to the cluster either by kubectl or directly calling REST APIs exposed by the master

Let's try it

THE Battle !

Common

Open source projects (Go Language)
Compatible with storage providers
Load balancing and DNS «out of the box»
Compatible with almost monitoring tools

What is an application ?

Kubernetes

Applications can be deployed into a pod which are the smallest component of Kubernetes.
A Service is the access point for the application.
A pod may have one or many containers inside

SWARM

Application is detailed in a yaml file (docker-compose) with one or many containers
A service is generated from the declarative text and deployed into the cluster.

Scaling

Kubernetes

The scaling value is defined for the pod. Manually or automatic.
Set with replica command or in the deployment (Yaml file)

SWARM

A service can be global : 1 task for every node within the cluster.
Or managed by replicas : 3 replicas on 1,2 or 3 nodes max.
Scaling manually !

High-Avaibility

Kubernetes

Multiple pods can be distributed among nodes to provide HA.
Multiple master nodes and worker nodes can be load balanced for request.
Etcd is natively distributed
API server can be replicated

SWARM

Swarm use Raft consensus (HA).
Mandatory : an odd number of manager.
Swarm uses the Ingress network to manage the services.

Load Balancing

Kubernetes

Pods are exposed through a service, which can be used as a load-balancer within the cluster. Typically, an ingress is used for load balancing.
Auto-scaling using a simple number-of-pods target is defined declaratively using deployments. CPU-utilization-per-pod target is available. Other targets are on the roadmap.

SWARM

Swarm mode has a DNS component that can be used to distribute incoming requests to a service name. Services can run on ports specified by the user or can be assNot directly available. For each service, you can declare the number of tasks you want to run. When you manually scale up or down, the Swarm manager automatically adapts by adding or removing tasks.igned automatically.

Rolling update

Kubernetes

Supports multiple modes for rolling update (number of pods offline, parallelism ..)

SWARM

Rolling update are applied on services with many strategies (ex : delay between nodes)

Health Check

Kubernetes

Different health check (container , pod, node, cluster …)
K8s aggregates by default the logs

SWARM

Only one health check (by service)

STORAGE

Kubernetes

Many storage API
K8s supports different type of persistent volumes (iSCSI, NFS, S3 , GCP , Azure …)
The emptyDir volume is non-persistent and can used to read and write files with a container.

SWARM

Compatible Docker volume (in container or docker-compose)
Swarm supports different type of persistent volumes (iSCSI, NFS, S3 , GCP , Azure …)

Text

NETWORKING

Kubernetes

All components in a pod could communicate each other and each pod has an IP address.
The service is like a VIP with a load-balancer

SWARM

Overlay network
Encrypted by default

Reliability

Kubernetes

Kubernetes scales to 5,000-node clusters.
API responsiveness: 99% of all API calls return in less than 1s.
Pod startup time: 99% of pods and their containers (with pre-pulled images) start within 5s.

SWARM

Docker Swarm has been scaled and performance tested up to 30,000 containers and 1,000 nodes with 1 Swarm manager.

RELiABILITY

Kubernetes

Google Borg
Red Hat
Autoscaling
Largest community

SWARM

Rookie
Only Docker containers management
Services can be scaled manually.
Smaller community

Miscellaneous

Kubernetes

Installation can be hard ! (except in Cloud services)
Hard learning curve

SWARM

Included with docker engine
Easy to learn

IS THERE OTHER SOLUTIONS ?