Who is the king of container orchestration: Kubernets or Docker Swarm?

Docker has been high-profile as the most popular container technology at present.
Many enterprises in China have adopted Docker into their businesses as a container for better services.

Cluster orchestration, the container's core technology, naturally becomes the key concerns.
The current container orchestration techniques can be mainly divided into two camps: Kubernetes and Docker Swarm.
Kubernetes: based on Google's container manager Borg. The strength of leading manufacturers should not be underestimated.
Docker Swarm: developed by the Docker official team. It is more closely connected with the Docker core.
As an architect, how do you choose the Docker cluster orchestration tool?
Share your selection and your reasons.

For example,
I choose Kubernetes, because Kubernetes enables more possibilities. I can implement more capabilities with Kubernetes APIs. On the contrary, Docker Swarm is launched by the official Docker team but is not mature enough for the time being. In comparison, I am inclined to trust the years of accumulation of Google. Besides, the Kubunetes community is very active, providing many useful features.

In fact, I am not very familiar with Docker, but I just learned something about it out of interest. I read some materials and would like to say something about it.
Kubernetes is based on the powerful and rich Linux container management experience of Google. It is available for Docker 1.0 onwards, providing a better user experience. For example, Kubernetes can solve some problems of the Docker itself. It can mount (bind) persistence storage volumes to prevent data loss during Docker migration.
Kubernetes uses flannels to structure inter-container network communications. It has a built-in load balancer, and adopts etcd for service discovery.
Kubernetes uses a different command line interface, a different programming interface and a different YAML file definition. You cannot use the Docker command line interface or the Docker Compose tool to define the container. To use Kubernetes, you have to learn everything from the beginning to some extent. It feels like this tool is not written for Docker. Kubernetes elevates the cluster to a new height, with the cost being the increased difficulty in learning to use it.
Docker Swarm utilizes a different approach. It is the native cluster tool of Docker. The command line interface, Docker Compose, Dokku, and Krane of Docker can all be used seamlessly on Docker Swarm. It does feel nice to use tools with great facility. However, things will get complicated if these APIs fail to meet some special needs due to the Docker API compatibility constraints.
It is very easy to install and set up Swarm, and Swarm is flexible to use. But the installation of Kubernetes is comparatively complicated. Swarm owns well-designed manuals, while Kubernetes requires you to constantly search for solutions. At the same time, Kubernetes is configurable, which may be a headache for new starters, while Swarm is very straightforward for use.
With the development of the Docker engine, I believe the difference between the two will narrow down. The advantages of Kubernetes over Swarm will recede. For a beginner like me, I prefer Swarm which is easier to configure and use, without too much repeated work, and the learning cost is greatly reduced, too. If a high availability is required in the later stage, I may change to Kubernetes. But no one will assert that the difference between the two will stay forever.

Monopoly by Mesos, K8S and Swarm in the industry
Mesos is like a city-state system where every cluster (Hadoop cluster, Spark cluster, and Web cluster) is a state opening part of the territory for scheduling by the central council. It supports stateful services.
K8S is a monarchy system where a leader (or a group of leaders) manages the vast land. It has an experienced forefather - Borg. However, complicated logic is designed to manage the large number of subjects. It is reinforcing its support for stateful services.
Swarm is of a classical republican system, also with central authority. Compared with the other two, it is compact and elegant. It has simple configurations and architecture and can better blend into the Docker ecology. But it lacks the experience to manage a large number of subjects, which still remains to be observed.
If you have stateful services such as databases, make up your mind to use Mesos.
If you have a large cluster of more than 100 servers, you can look into K8S.
Otherwise, and if you are a geek, choose Swarm without hesitation.

I think what’s the coolest about Docker Swarm release is the “batteries included but swappable”. In simple words, it means when you need to launch scaled production, you can start to use Docker Swarm, and swap in the Mesosphere. We think they’ve made a great decision in the community, encouraging users to perform personalized selection and innovation in container cluster scheduling and coordination, instead of relying on one method.

K8S is the work of a powerful manufacturer and seizes the market first. It enjoys widespread favor among domestic companies. Its overall architecture is heavy-weighted.
Swarmkit is the official product of Docker with more integration with Docker. It is very easy to install and operate. Its overall functions are not as complete as K8S, but with lighter architecture. Sometimes the service may fail to obtain the real client IP address.
If you want to establish small clusters quickly, you can try Swarmkit. Both of the two architectures are worth researching for learners.

By the way, I am not quite for the idea that the three have open conflicts. Because they display obviously different development directions.
Docker Swarm is a key connecting step in the Docker ecology. If you want an out-of-box cluster, go with Docker.
For K8S, what you need is a large, comprehensive and customizable solution to manage a number of servers (more than 1,000). You can make adaptations based on your own needs without being dependent on other ecologies.