Docker cluster tool comparison: Kubernetes vs Docker Swarm-Alibaba Cloud Developer Community

Currently, Kubernetes and Docker Swarm are the two most commonly used tools to create containers in a cluster environment. Both tools are created to manage container clusters, and they use all servers in the cluster as a unified device. However, they are greatly different in implementation methods.

Kubernetes

Kubernetes is created based on google's years of experience in using linux containers, so it can be said that it is a copy of Google's years of operating experience, but google has applied these operating experience to Docker. Using Kubernetes to manage containers brings great benefits in many aspects, and the most important of which is that Google has brought their years of experience in using containers into this tool. If you start using Kubernetes from Docker1.0 (or earlier), you will find it a pleasant experience to use Kubernetes to manage docker containers. Kubernetes solves many Docker problems. With Kubernetes, you can use physical storage units in containers, so that we can easily move containers to other machines without losing any data; kubernetes use flannel to create a network between containers; Kubernetes integrate load balancer;Kubernetes use etcd for service discovery. However, using Kubernetes requires a certain price. For example, Kubernetes uses a CLI (Command Line Interface) that is completely different from Docker, different APIs, and different YAML configuration definitions. In other words, if you use Kubernetes, you cannot use the CLI that comes with Docker or use Docker Compose to define (create) containers. Using Kubernetes, you must recreate everything related to Docker container management for Kubernetes, so we can think that Kubernetes is not created for Docker (in a sense, correct). Kubernetes improves the management level of Docker container clusters, but its learning curve is also very steep.

Docker Swarm

Docker Swarm is completely different. It is a cluster tool created for Docker container technology. The most important thing is that Dcoker Swarm provide complete standard Docker API externally, so any tool that uses Docker API to communicate with Docker (Docker ClI, Docker Compose, Dokku, Krane) can work seamlessly with Docker Swarm. This is both an advantage and a disadvantage for Docker Swarm. One thing is that you can use a familiar tool set, and the disadvantage is obvious, that is, you can only do Docker API the specified things. If Docker API does not support a certain function you want, you cannot directly use Docker Swarm to implement it. You may need to use some special techniques to implement it (or it may not be implemented at all).

In the following sections, we will introduce how to install the two tools separately, and do not separately describe the functions they provide in managing container clusters.

Mounting

the installation Docker Swarm is very simple, direct and flexible. What we need to do is to install the service discovery tool and run the swarm container on all docker nodes. Because it is a container, it runs as a container and has nothing to do with the operating system. After swarm is run, a port is exposed. We only need to notify it of the service address. There is nothing simpler than this. You can run swarm even without a service discovery tool to check whether you like it. If you really need a service discovery tool, you can install etcd,Consul, and other tools.

However, the installation of Kubernetes is complicated and difficult to understand. The installation instructions of each system and host vendor are different. They each have a set of instructions, using their own team to maintain instructions and solve problems. For example, you want to try Vagrant, but you give up because you are not familiar with Fedora's commands. However, this does not mean that you cannot run Vagrant. For example, you can try Ubuntu or CoreOS. You are sure to succeed, but you need to search for relevant commands outside the official document page of the Kubernetes Getting Started. Whether you need it or not, the community has solutions to these problems, but you still need a lot of time to search for problems related to the solution and hope it can be used in your first attempt. The bigger problem is that commands depend on bash scripts. If configuration management is not required, it does not matter. However, we do not want to run a script to make Kubernetes part of Puppet,Chef, or Ansible. Of course, this problem can also be solved. You can find Ansible document or write your own document to run the Kubernetes. These seem not to be big problems, but compared with Swarm, they seem to be troublesome. When using Docker, we should not operate the command line (except for some docker run parameters), but run the container. This is exactly what Swarm does, but Kubernetes is not.

However, some people do not care about what discovery tools to use. I like Swarm's simplicity and logic "including the battery but removable". Everything is out of the box, but I can still replace a component with other power. Unlike Swarm, Kubernetes is an arbitrary tool. You must adapt to the choices it provides. If you want to use Kubernetes, you must use etcd. If you like it, I won't try to say that etcd is not good. For example, Consul is used in a very complex environment and Kubernetes is required. One is used as a Kubernetes and the rest is used as a service discovery requirement. Another thing I don't like Kubernetes is to know advanced things before setting up. You need to tell the addresses of all nodes, their roles, and their responsibilities in the cluster. For Swarm, all I need to do is start a node and tell it to join the network. Other advanced settings are no longer needed, because the information about cluster reproduction is transmitted through gossip.

Assembly may not be the biggest difference between these tools. No matter which tool you use, sooner or later everything will be set up and run and you will forget all the difficulties you have dealt. You may say that we should not only choose one tool instead of other tools unless it is easier to assemble. It makes sense. Let me continue to talk about how to define the difference between containers that run with these tools.

Run container

how do you define all the parameters required by a large number of running Docker containers? Actually you don't need it, which is different from the way you defined them before. If you run containers with Docker CLI, you can continue to use the same (almost the same) commands. If you like to use Docker Compose to run containers, you can continue to use it to run a large number of clusters within them. You can run your containers in either way. What changes is that you can run larger clusters in the same way.

Kubernetes need to learn its CLI and configuration. You cannot use docker-compose.yml to define containers that you created earlier. You must create Kubernetes equivalent device. You cannot use the Docker CLI commands you learned before. You must also learn Kubernetes CLI, and you must ensure that the whole team learns it.

No matter which tool you use to deploy your cluster, you should be familiar with how to use Docker. You may have used Docker Compose to replace traditional Docker CLI. You can use Docker Compose to configure parameters of the Dokcer container, create Docker containers, and obtain container logs; you may just use traditional Docker CLI to perform all these operations, and you may even write your own dedicated script to run Docker CLI. But whether you use Docker CLI or Docker Compose, all these skills you use will be able to perfectly cooperate with Docker Swarm.

If you choose to use Kubernetes to manage your cluster, be prepared that you may need to do some repetitive work. Even if you select Kubernetes, you still need to use Docker Compose to run your defined containers. Developers will continue to run Docker containers locally, while the staging environment may only be a small cluster. In other words, once you decide to use Docker, Docker Compose or Docker CLI is an indispensable tool. Once you start using Kubernetes, you will find that you need to translate all Docker Compose definitions (or the script you are using) into Kubernetes descriptions, and you must maintain both versions at the same time. When using Kubernetes, you will find that everything must be in duplicate (this will bring extremely high maintenance costs). All the things mentioned here include not only the configuration file, but also all the commands required by the running cluster (Kubernetes, the commands used are completely different from the Docker CLI).

Those who created Kubernetes didn't mean to make you full of challenges when operating Docker. The reason why Kubernetes is so different from Swarm is that, that's because they used different methods to solve the problems they faced. The Swarm team decided to use the same API as Docker CLI. In this way, Swarm is fully compatible with Docker CLI. When you migrate from Docker CLI to Swarm, there is basically no need to do anything extra (that is, no need to modify any configuration or learn new things). The only problem with Swarm is that if you need Swarm to do something that is not supported by APIs, Swarm can do nothing. In a word, if you want a tool that can use Docker API to deploy containers in a cluster, Swarm is your first choice. On the contrary, if you want a powerful and customizable tool, then you should choose Kubernetes.

Let's take a look at the problems we encounter when using Swarm. As far as I know, two of the major problems are network problems and storage volumes. Before Docker Swarm 1.0 was released, we couldn't make it easy for two servers to communicate. In fact, even in Docker Swram 1.0, we still cannot directly connect two containers running on different servers. We implement indirect communication with the help of a tool called multi-host networking. After the Kubernetes is created, containers on different servers are interconnected through the built-in flannel. Since Docker 1.9, container interconnection has been integrated into Docker CLI.

In addition, the problem is that the volume Group is persistent. Docker introduced them in the 1.9 release. Until recently, if you use a volume group for persistence, the container is bound to the server that depends on the volume group. Containers cannot be moved. You need to turn to some annoying techniques, such as copying a volume directory from one server to another. That is a slow operation that despises tools such as Swarm. In addition, even if you have time to copy a volume group to another server. But you don't know where to copy it, because cluster tools tend to treat your entire data center as a single entity. Containers are deployed to the most suitable locations for them (with the least number of containers running, the most CPU or Memory available, and so on). Now we have a persistent volume group supported by Dockers original ecosystem.

For a long time, network and volume group persistence has been Kubernetes supported container features and why many people choose Swarm instead of Swarm. However, this advantage disappeared when Docker1.9 was released.

Selector

when trying to choose between Docker Swarm and Kubernetes. Consider several points. Do you want to rely on Docker itself to solve cluster-related problems. If yes, select Swarm. If Docker does not support something, Swarm may not support it because it depends on the Docker API. In addition, if you want a tool that is not limited by Docker, Kubernetes may be an appropriate choice. Kubernetes is not built based on Docker, but it is based on Google's container experience. It is arbitrary and tries to do things in its own way.

When choosing to use Kubernetes or Swarm, you need to ask yourself the following questions: 1) will some of the Kubernetes provide become an extra burden? 2) whether you have information that Docker Swarm will be better and better in the future, which can solve all the problems you encounter in the deployment process at present. It is strongly recommended that you look at the functions provided by Docker release 1.9 before you answer these questions. At least in Docker Release 1.9, we have volume group persistence and software-defined network. At the same time, 1.9 also provides the unless-stopped restart policy, which makes it easy for us to handle unexpected container faults. In Docker 1.9, the difference between Kubernetes and Swarm has been reduced by at least three. In fact, Kubernetes can provide fewer and fewer benefits. To take a step back, Swarm has a great advantage, that is, using Docker API means that you can reuse all Docker commands and Docker Compose configurations. From my personal point of view, I am highly optimistic about the future development of Docker and Docker Swarm running on Docker. Kubernetes and Swarm are mature systems that can run directly in the production environment. The difference between them has become smaller and smaller. However, Swarm is relatively easier to install and use, and we can reuse all scripts and configuration files that we have created.

I personally recommend that you use Swarm to manage Docker clusters. The Kubernetes is too complex, difficult to install, and difficult to use (because the API it uses is completely different from Docker CLI), compared with Swarm, Docker 1.9 does not provide many advantages. Of course, this does not mean that the functions of Kubernetes and Swarm are exactly the same. After all, the functions they implement are still different. Kubernetes, there are still some functions that Swarm does not have, but these gaps are not major. From my experience, with the release of the new version of Docker, the gap between Kubernetes and Swarm is becoming smaller and smaller in terms of its main functions. Finally, I have to say that Swarm is so easy to install, learn, and use. In many cases, you will not feel any difficulty in managing your Docker cluster.

The article is reprinted from The Open Source China community [https://www.oschina.net]