This article is part of the series that compares 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
• Kubernetes Namespaces Compared To Docker Swarm Equivalent (If There Is Any)
• Kubernetes RBAC Compared To Docker Swarm RBAC
• Kubernetes Resource Management Compared To Docker Swarm Equivalent

The mechanisms behind Kubernetes ConfigMaps and Docker Swarm configs are almost the same. At least, from the functional perspective. Both allow us to store some literal texts in scheduler’s internal data store, and both enable us to add them to containers. The syntax is equally simple and straightforward in both cases. Still, there are a few differences.

Docker Swarm’s Config is immutable. We cannot enter into a container and remove it. We cannot update it. All we can do is read it. Kubernetes will allow us to manipulate injected configuration files, only to revert changes soon after. It is acting like a cleaning lady. You can create any mess you want, she’ll clean it up. Or, maybe, that would be a butler? Not sure… Anyways, Kubernetes ConfigMap mounts are eventually immutable. Such a thing is not a big deal. We just need to understand how it works and to learn never to touch configuration files. Or, even better, we should change the default mount’s permissions to be read-only.

All in all, Docker’s Config is immutable by design. Kubernetes ConfigMap’s mounts are eventually immutable. If only Kubernetes made the default value of defaultMode set to 0444…

Docker is good at preventing people from doing silly things (the politically correct version of the word stupid). An example would be an attempt to delete a configuration. It cannot be deleted if there are Docker services with reference to to the configuration. Only after all the services that reference it are removed, we are allowed to remove the configuration source. Kubernetes, on the other hand, will let us delete a ConfigMap object without even a hint about the consequences.

Kubernetes ConfigMap, on the other hand, provides a wider variety of options. While Docker Swarm configuration can be created only from a file or stdin, Kubernetes equivalent can be generated from a file, from a directory, from a literal value, and from files with environment variables. Each of those sources can be used multiple times. We can even combine them. Further on, Kubernetes ConfigMaps can be converted not only to files, but also to environment variables. Flexibility and extra functionalities are available both at the source and the destination end-points.

Docker Swarm wins a user experience point. Kubernetes gains a star for providing more choices. Neither has a significant difference that would warrant a win, so I’m proclaiming it a tie.

There are many more features worthwhile comparing. We’re not yet finished. 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 goal of the book is not to convince you to adopt Kubernetes but to provide a detailed overview of its features. I want you to become confident in your Kubernetes knowledge and only then choose whether to embrace it. That is, unless you already made up your mind and stumbled upon this book in search of Kubernetes guidance.

The book is about running containers at scale and not panicking when problems arise. It is about the present and the future of software deployment and monitoring. It’s about embracing the challenges and staying ahead of the curve.

Give it a try and let me know what you think..