The article complains that kubernetes requires installation but Swarm just runs a container. True, but kubernetes runs atop docker, not inside it (although the kubernetes components do run within docker). I think this is a better design, because it makes migrating off of docker easier.

The article complains that one must know everything in advance. That's not quite true: one is able to add nodes. But yes, they don't add themselves. That's also okay with me, since kubernetes in general seems to take an intentional approach.

The fact that kubernetes avoids using docker commands is a plus for us: we declare what we want to do, and kubernetes does it, rather than us imperatively instructing docker what to do.

Contrary to the article, we certainly don't have multiple definitions of anything. We don't have any Docker Compose definitions; we use kubernetes throughout, whether it's single-node running on a local laptop or multi-node in integration, staging and production. Thus, 'in other words, once you adopt Docker, Docker Compose or Docker CLI are unavoidable,' is pure and total nonsense.

In our experience, kubernetes just does things right. The service abstraction, and service discovery, are exactly what we need. The way that replication controllers work is great. The idea of pods of containers, all of which can communicate on the loopback interface, is extremely useful. It's certainly not perfect (c.f. installation, supra, and there're plenty of other warts), but it's going in the right direction.

As an aside, given my experience with docker itself, I'm not eager to adopt any more software from Docker; I'm looking forward to when kubernetes supports rkt or some similar container format.