Kubernetes and Swarm – different philosophies to solve different problems

Which is better (for you)? Well, it depends…

Getting started with Kubernetes is pretty challenging. This is somewhat because in addition to a container runtime (such as Docker Engine-Community), you need to install and configure kubectl, kubeadm, and kubelet, but that's just the beginning. You also have to make some decisions up front, such as picking a networking model and configuring/installing the provider's container CNI implementation. Kubernetes does not usually provide default options (some cloud services do this for you), which gives you some great flexibility, but naturally forces you to make upfront decision and complicates installation. Again, this is great if you need this flexibility and you know exactly what you are doing.

On the other hand, if you have Docker 1.12 or newer (we strongly recommend having something much newer), you only need to activated it with the docker swarm init command. It creates a certificate authority, an encrypted Raft store, and overlay networking automatically, as well as a tokenized join command for securely adding additional nodes to your cluster. However, in the spirit of simplicity and security, Docker made some default choices for you. That's great if you can live with those choices, at least while you get up to speed on enterprise container platforms.

Beyond installation, describing application deployment (using YAML files) in Kubernetes is inherently more complex. When it comes to styles of deployment, Kubernetes deploys discrete components and wires them up with a collection of YAML files that rely on labels and selectors to connect them. Again in Kubernetes style, when creating components, you have to define a wide range of behavior parameters to describe exactly what you want, rather than assuming some default behavior. This can be verbose, but it is very powerful, precise, and flexible!

Kubernetes also includes the pod as the atomic deployment unit, which can be handy for isolating a bundle of containers from the flat networking model. This leads to the use of sidecar containers that essentially interface pods to the rest of the world. This is very cool and a great way to handle networks of loosely coupled, shared, long-running services in a flat address space:

Swarm takes an application-centric, monolithic approach by defining a stack of related services in a .yaml file. Swarm stacks assume you are running a collection of related services, isolated by overlay networks, to support specific functionality in the context of an application. This makes it easy to deploy a typical application stack such as an Angular frontend with an application's RESTful API and a Postgres database.