Monthly Archives: January 2018

Kubernetes Namespaces Compared To Docker Swarm Equivalent (If There Is Any)

This article is part of the series that compares Kubernetes and Docker Swarm features.

Docker Swarm does not have anything like Kubernetes Namespaces. We cannot split a Swarm cluster into sections. Therefore, we can finish this comparison by saying that Kubernetes is a clear winner regarding this feature since Docker Swarm doesn’t have Namespaces. But, that would not be entirely accurate.

Docker Swarm stacks are, in a way, similar to Kubernetes Namespaces. All the services in a stack are uniquely identified through a combination of a stack name and the names of services inside it. By default, all services within a stack can communicate with each other through the stack’s default network. Services can speak with those from other stacks only if they are explicitly attached to the same network. All in all, each Swarm stack is separated from other stacks. They are, in a way, similar to Kubernetes Namespaces.
Continue reading →

Kubernetes Secrets Compared To Docker Swarm Secrets

7 Replies

This article is part of the series that compares Kubernetes and Docker Swarm features.

Secrets are very similar to Kubernetes ConfigMaps and Docker Swarm configs. Everything we said for configurations applies to Secrets, with a few additional features.

Both Kubernetes and Docker Swarm stores Secrets in tmpfs inside containers. From that aspect, they are equally secure. The significant difference is in the way Secrets are stored internally.
Continue reading →

Kubernetes ConfigMaps Compared To Docker Swarm Configs

10 Replies

This article is part of the series that compares Kubernetes and Docker Swarm features.

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.
Continue reading →