Something Else

Kubernetes [1] is king of the hill in the orchestration universe. Invented by Google and now under the auspices of the Linux Foundation, Kubernetes has not only blossomed quickly but has led to a kind of monoculture not typically seen in the open source world. Reinforcing the impression is that many observers see Kubernetes (Figure 1) as a legitimate OpenStack successor, although the solutions have different target groups.

Figure 1: Kubernetes ranks top in container orchestration.

Against this background, it is not surprising that Kubernetes' presence sometimes obscures the view of other solutions that might be much better suited to your own use case. In this article, I look to put an end to this unfortunate situation by introducing Kubernetes alternatives Docker Swarm, Nomad, Kontena, Rancher, and Azk and discussing their most important characteristics.

Docker Swarm

Docker Swarm [2] (Figure 2) must be top of the list of alternatives to Kubernetes. Swarm can be seen as a panic reaction from Docker when the container builders realized that more and more users were combining Docker with Kubernetes.

Figure 2: Docker Swarm is a swap-in alternative to Kubernetes and thus offers a directly comparable feature set.

With Swarm, Docker is demoted to a plain vanilla container format that Kubernetes can use; not every user is satisfied with the Docker format, as demonstrated by Red Hat, who has been working for years on a Docker alternative named Rocket.

The people at Docker headquarters had to be on their guard: If more and more people were to roll out their containers with Kubernetes, it would be conceivable that a new and better container format would replace Docker, and the company would end up empty-handed. Docker Swarm can therefore also be seen as an attempt to tie in customers more tightly to Docker's own technology.

Little wonder, then, that Kubernetes and Docker Swarm are similar in many ways. Kubernetes relies on a pod concept to deploy apps, with a pod being a group of containers co-located on a host. Replicas distributed across the cluster can be created from deployments. Docker Swarm also offers various possibilities to roll out applications as a multicontainer masterpiece distributed across the entire cluster; Docker Compose is often the tool of choice.

Being able to scale virtual container environments well is inherent to both Kubernetes and Swarm: Pods scale horizontally, just like services in Docker. Kubernetes, like Docker Swarm, offers a high availability mode out the box to make both the solution infrastructure and the containers themselves highly available. Load balancers offer additional functionality in Kubernetes; Swarm uses a DNS-based mechanism instead. Despite all the technical differences, at the end of the day, both solutions achieve comparable results.

Storage and Network Differences

Significant differences between Kubernetes and Swarm can be seen in storage and network operations. Kubernetes comes with two storage APIs: one to connect existing storage back ends (e.g., Ceph) and one to provide a kind of abstraction layer for storage requests that containers can use to query storage resources. Swarm keeps things a bit simpler and uses the volume API already available in Docker, which allows additional storage technologies to be integrated with plugins, for example.

When it comes to the network, however, it is exactly the other way around: Kubernetes assumes that the whole network is flat; that is, all pods reside on the same logical network segment and therefore can communicate easily.

Swarm, on the other hand, ensures that each node in a Swarm cluster becomes part of an overlay network, so that Docker traffic is routed separately from the rest. Unlike Kubernetes, Swarm also offers encryption for this network, and if you use the Swarm plugin interface, you can even connect complete container network solutions with external software-defined network plugins; an equivalent feature is missing in Kubernetes.

Performance and Stability

Both Kubernetes and Docker Swarm claim to scale far beyond the limits of what is usually required. In the case of Kubernetes 1.6, the solution supports up to 5,000 physical nodes. Swarm can control 1,000 nodes per Swarm manager and supports up to 30,000 containers per Swarm manager instance.

Such a setup should be sufficient most of the time – if only because many companies do not use their Kubernetes or Swarm clusters in client operations but prefer to build a separate infrastructure for each customer.

Technically, the solutions differ very little, even if some functions are implemented or named differently on one side or the other. Whether you rely on Kubernetes or Swarm is a matter of taste.