This article is part of the series that compare Kubernetes and Docker Swarm features.
- Kubernetes Pods, ReplicaSets, And Services Compared To Docker Swarm Stacks
- Kubernetes Deployments Compared To Docker Swarm Stacks
- Kubernetes Ingress Compared To Docker Swarm Equivalent
- Kubernetes ConfigMaps Compared To Docker Swarm Configs
- Kubernetes Secrets Compared To Docker Swarm Secrets
Both Kubernetes and Docker Swarm have Ingress, and it might sound compelling to compare them and explore the differences. While that, on the first look, might seem like a right thing to do, there is a problem. Ingress works quite differently across the two.
Swarm Ingress networking is much more similar to Kubernetes Services. Both can, and should, be used to expose ports to clients both inside and outside a cluster. If we compare the two products, we’ll discover that Kubernetes Services are similar to a combination of Docker Swarm’s Overlay and Ingress networking. The Overlay is used to provide communication between applications inside a cluster, and Swarm’s Ingress is a flavor of Overlay network that publishes ports to the outside world. The truth is that Swarm does not have an equivalent to Kubernetes Ingress Controllers. That is, if we do not include Docker Enterprise Edition to the mix.
The fact that a Kubernetes Ingress equivalent does not ship with Docker Swarm does not mean that a similar functionality cannot be accomplished through other means. It can. Traefik, for example, can act both as a Kubernetes Ingress Controller, as well as a dynamic Docker Swarm proxy. It provides, more or less, the same functionality no matter which scheduler you choose. If you’re looking for a Swarm specific alternative, you might choose Docker Flow Proxy (written by yours truly).
All in all, as soon as we stop comparing Ingress on both platforms and start looking for a similar set of functionality, we can quickly conclude that both Kubernetes and Docker Swarm allow a similar set of features. We can use paths and domains to route traffic from a single set of ports (e.g.,
443) to a specific application that matches the rules. Both allow us to offload SSL certificates, and both provide solutions that make all the necessary configurations dynamically.
If on the functional level both platforms provide a very similar set of features, can we conclude that there is no essential difference between the two schedulers when taking into account only dynamic routing and load balancing? I would say no. Some important differences might not be of functional nature.
Kubernetes provides a well-defined Ingress API that third-party solutions can utilize to deliver a seamless experience. Let’s take a look at one example.
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: devops-toolkit spec: rules: - host: devopstoolkitseries.com http: paths: - backend: serviceName: devops-toolkit servicePort: 80
This definition can be used with many different solutions. Behind this Ingress resource could be nginx, voyager, haproxy, or trafficserver Ingress Controller. All of them use the same Ingress API to deduce which Services should be used by forwarding algorithms. Even Traefik, known for its incompatibility with commonly used Ingress annotations, would accept that YAML definition.
Having a well-defined API still leaves a lot of room for innovation. We can use
annotations to provide the additional information our Ingress Controller of choice might need. Some of the same annotations are used across different solutions, while the others are specific to a Controller.
All in all, Kubernetes Ingress Controller combines a well-defined (and simple) specification that all Ingress Controllers must accept and, at the same time, leaves ample room for innovation through custom
annotations specified in
Docker Swarm does not have anything resembling Ingress API. Functionality similar to Kubernetes Ingress Controllers can be accomplished either by using Swarm Kit or through Docker’s API. The problem is that there is no defined API that third-party solutions should follow, so each is a world in itself. For example, understanding how Traefik works will not help you much when trying to switch to Docker Flow Proxy. Each is operated differently. There is no standard because Docker did not focus on making one.
Docker’s approach to scheduling is based on reliance on the features baked into Docker Server. There is one way to do things. Often, that provides a very user-friendly and reliable experience. If Swarm does what you need it to do, it is an excellent choice. The problem occurs when you need more. In that case, you might experience difficulties finding a solution.
When we compared Kubernetes ReplicaSets, Services, and Deployments with their Docker Swarm equivalents, the result was the same set of features. There was no substantial difference on the functional level. From the user experience perspective, Swarm provided much better results. Its YAML file was much more straightforward and more concise. With only those features in mind, Swarm had the edge over Kubernetes. This time it’s different.
Kubernetes strategy is primarily based on API. Once a specific type of a resource is defined, any solution can utilize it to provide the given functionality. That is especially true with Ingress. We can choose among a myriad of solutions. Some of them are developed and maintained by Kubernetes community (e.g., GLBC and NGINX Ingress Controllers), while others are provided by third-parties. No matter where the solution comes from, it adheres to the same API and, therefore, to the same YAML definition. As a result, we have a more substantial number of solutions to choose from, without sacrificing consistency in how we define resources.
If we limit the comparison to Kubernetes Ingress Controllers and their equivalents in Docker Swarm, the former is a clear winner. Assuming that the current strategy continues, Docker would need to add layer 7 forwarding into Docker Server if it is to get back to the game on this front. If we limit ourselves only to this set of features, Kubernetes wins through its Ingress API that opened the door not only to internal solutions but also to third-party Controllers.
We are still at the beginning. There are many more features worthwhile comparing. We only scratched the surface. Stay tuned for more.
The DevOps 2.3 Toolkit: Kubernetes
The article you just read is an extract from The DevOps 2.3 Toolkit: Kubernetes. The book is still under development. If you buy it now from LeanPub.com, you’ll receive updates for each new chapter that is added.
Give the book a try and let me know what you think.