In a previous blog we discussed why you would need a container orchestration tool and followed that up with a blog comparing Kubernetes vs Mesos. Continuing the series, in this blog post we’ll give an overview of and compare Kubernetes vs Docker Swarm.
Overview of Kubernetes
We gave an overview of Kubernetes in the blog comparing it with Mesos. For the sake of completeness, we’ll cover it again here.
According to the Kubernetes website – “Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications.” Kubernetes was built by Google based on their experience running containers in production over the last decade. See below for a Kubernetes architecture diagram and the following explanation.
The major components in a Kubernetes cluster are:
Pods – Kubernetes deploys and schedules containers in groups called pods. A pod will typically include 1 to 5 containers that collaborate to provide a service.
Flat Networking Space – The default network model in Kubernetes is flat and permits all pods to talk to each other. Containers in the same pod share an IP and can communicate using ports on the localhost address.
Labels – Labels are key-value pairs attached to objects and can be used to search and update multiple objects as a single set.
Services – Services are endpoints that can be addressed by name and can be connected to pods using label selectors. The service will automatically round-robin requests between the pods. Kubernetes will set up a DNS server for the cluster that watches for new services and allows them to be addressed by name.
Replication Controllers – Replication controllers are the way to instantiate pods in Kubernetes. They control and monitor the number of running pods for a service, improving fault tolerance.
Overview of Docker Swarm
According to the Swarm website, Docker Swarm provides native clustering capabilities to turn a group of Docker engines into a single, virtual Docker Engine. Swarm uses the standard Docker API, so normal docker run commands can be used to launch containers and Swarm will take care of selecting an appropriate host to run the container on. Other tools that use the Docker API, e.g. Docker Compose, can use Swarm without any changes.
Each host in a Swarm cluster runs a Swarm agent and one host runs a Swarm manager. The manager will orchestrate and schedule containers on the hosts. Similar to other container orchestration tools, a Discovery service will find and add new hosts to the cluster. Third-party tools like Consul, ZooKeeper, etcd are required to ensure high availability and failover to a secondary Swarm manager. The table below gives a detailed comparison of Swarm features and compares them with Kubernetes.
Compare Kubernetes vs Docker Swarm
Kubernetes
Docker Swarm
Types of Workloads
Cloud Native applications
Cloud Native applications
Application Definition
A combination of Pods, Replication Controllers, Replica Sets, Services and Deployments. As explained in the overview above, a pod is a group of co-located containers; the atomic unit of deployment.
Pods do not express dependencies among individual containers within them.
Containers in a single Pod are guaranteed to run on a single Kubernetes node.
Apps defined in Docker Compose can be deployed on a Swarm cluster
The built-in scheduler has several filters such as node tags, affinity and strategies that will assign containers to the underlying nodes so as to maximize performance and resource utilization.
Application Scalability constructs
Each application tier is defined as a pod and can be scaled when managed by a Deployment or Replication Controller. The scaling can be manual or automated.
Possible to scale individual containers defined in the Compose file.
High Availability
Pods are distributed among Worker Nodes.
Services also HA by detecting unhealthy pods and removing them.
Containers are distributed among Swarm Nodes.
The Swarm manager is responsible for the entire cluster and manages the resources of multiple Docker hosts at scale.
To ensure the Swarm manager is highly available, a single primary manager instance and multiple replica instances must be created. Requests issued on a replica are automatically proxied to the primary manager.
If a primary manager fails, tools like Consul, ZooKeeper or etcd will pick a replica as the new manager.
Load Balancing
Pods are exposed through a Service, which can be a load balancer.
Load balancer is typically just another service defined in a Compose file. The swarm manager uses ingress load balancing to expose the services you want to make available externally to the swarm.
Internally, the swarm lets you specify how to distribute service containers between nodes.
Auto-scaling for the Application
Auto-scaling using a simple number-of-pods target is defined declaratively with the API exposed by Replication Controllers.
CPU-utilization-per-pod target is available as of v1.1 in the Scale subresource. Other targets are on the roadmap.
Not directly available. For each service, you can declare the number of tasks you want to run. When you scale up or down, the swarm manager automatically adapts by adding or removing tasks to maintain the desired state.
Rolling Application Upgrades and Rollback
“Deployment” model supports strategies, but one similar to Mesos is planned for the future
Health checks test for liveness i.e. is app responsive
At rollout time, you can apply service updates to nodes incrementally. The swarm manager lets you control the delay between service deployment to different sets of nodes. If anything goes wrong, you can roll-back a task to a previous version of the service.
Logging and monitoring
Health checks of two kinds: liveness (is app responsive) and readiness (is app responsive, but busy preparing and not yet able to serve)
Logging: Container logs shipped to Elasticsearch/Kibana (ELK) service deployed in cluster
Resource usage monitoring: Heapster/Grafana/Influx service deployed in cluster
Logging/monitoring add-ons are part of official project
Sysdig Cloud integration
Logging: Can ship logs to ELK deployed in cluster
Monitoring: Can use external tools, e.g. Riemann
Storage
Two storage APIs:
The first provides abstractions for individual storage backends (e.g. NFS, AWS EBS, ceph,flocker).
The second provides an abstraction for a storage resource request (e.g. 8 Gb), which can be fulfilled with different storage backends.
Modifying the storage resource used by the Docker daemon on a cluster node requires temporarily removing the node from the cluster
Docker Engine and Swarm support mounting volumes into a container.
A volume is stored locally by default. Volume plugins (e.g.flocker) mount volumes on networked storage (e.g., AWS EBS, cinder, ceph)
Networking
The networking model lets any pod can communicate with other pods and with any service.
The model requires two networks (one for pods, the other for services)
Neither network is assumed to be (or needs to be) reachable from outside the cluster.
The most common way of meeting this requirement is to deploy an overlay network on the cluster nodes.
Docker Engine can create overlay networks on a single host. Docker Swarm can create overlay networks that span hosts in the cluster. By default, nodes in the swarm encrypt traffic between themselves and other nodes.
A container can be assigned an IP on an overlay network. Containers that use the same overlay network can communicate, even if they are running on different hosts.
Service Discovery
Pods discover services using intra-cluster DNS
Swarm manager node assigns each service a unique DNS name and load balances running containers. You can query every container running in the swarm through a DNS server embedded in the swarm.
Docker Swarm comes with multiple discovery backends
Docker Hub as a hosted discovery service is intended to be used for dev/test. Not recommended for production
A static file or list of nodes can be used as a discovery backend. The file must be stored on a host that is accessible from the Swarm manager. You can also pass a node list as an option when you start Swarm.
The recommended way to do node discovery in Swarm is Docker’s libkv project. The project supports: Consul 0.5.1 or higher, Etcd 2.0 or higher, ZooKeeper 3.4.5 or higher.
Performance and scalability
With the release of 1.2, Kubernetes now supports 1000-node clusters. Kubernetes scalability is benchmarked against the following Service Level Objectives (SLOs):
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.
According to the Swarm website, Swarm is production ready and tested to scale up to one thousand (1,000) nodes and fifty thousand (50,000) containers with no performance degradation in spinning up incremental containers onto the node cluster.
Check out these other blogs on the topic-
https://blog.docker.com/2015/11/scale-testing-docker-swarm-30000-containers/
https://medium.com/on-docker/evaluating-container-platforms-at-scale-5e7b44d93f2c#.sblte6chl
In a follow up blog, we’ll answer why we chose to offer a Managed Kubernetes solution and explain the features and roadmap. Meanwhile, check out the free trial for the Managed Kubernetes Solution from Platform9.
[출처] https://platform9.com/blog/compare-kubernetes-vs-docker-swarm/