Portainer is the definitive open source container management tool for Kubernetes, Docker, Docker Swarm and Azure ACI. It allows anyone to deploy and manage containers without the need to write code.
Continue reading
This article is part of the series that compare Kubernetes and Docker Swarm features.
Resource management can be divided into a few categories. We need to define how much memory and CPU we except a container will use and what are the limits. This information is crucial for a scheduler to make “intelligent” decisions when calculating where to place containers. In this aspect, there is no essential difference between Kubernetes and Docker Swarm. Both are using requested resources to decide where to deploy containers and limits when to evict them. Both of them are, more or less, the same in this aspect.
Continue reading
This article is part of the series that compare Kubernetes and Docker Swarm features.
Docker has RBAC. Just as Kubernetes, it is organized around subjects, roles, and resource collections. In many aspects, both provide a very similar set of features. Should we quickly declare it a tie?
There is one crucial difference between Kubernetes RBAC and the one provided by Docker. The latter is not free. You’d need to purchase Docker Enterprise Edition (EE) to secure your cluster beyond “only those with the certificate can access it.” If you do have Docker EE, you already made up your mind, and the discussion whether to use one or the other is over. Docker EE is great, and soon it will work not only with Swarm but also with Kubernetes. You bought it, and there’s not much reason to switch to something else. However, this comparison focuses on what open source core versions can offer. It ignores third party and enterprise additions.
Continue reading
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
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
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
This article is part of the series that compares Kubernetes and Docker Swarm features.
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.
Continue reading
This article is part of the series that compares Kubernetes and Docker Swarm features.
If you already used Docker Swarm, the logic behind Kubernetes Deployments should be familiar. Both serve the same purpose and can be used to deploy new applications or update those that are already running inside a cluster. In both cases, we can easily deploy new releases without any downtime (when application architecture permits that).
However, unlike the previous comparison between Kubernetes Pods, ReplicaSets, And Services, on the one hand, and Docker Swarm Stacks on the other, Deployments do provide a few potentially important functional differences. But, before we dive into functionals comparison, we’ll take a moment to explore differences in how we define objects.
Continue reading
This article is part of the series that compares Kubernetes and Docker Swarm features.
Starting from this article, we’ll compare each Kubernetes feature with Docker Swarm equivalents. That way, Swarm users can have a smoother transition into Kubernetes or, depending on their goals, choose to stick with Swarm.
Please bear in mind that the comparisons will be made only for a specific set of features. You will not (yet) be able to conclude whether Kubernetes is better or worse than Docker Swarm. You’ll need to grasp both products in their entirety to make an educated decision. The comparisons like those that follow are useful only as a base for more detailed examinations of the two products.
For now, we’ll limit the comparison scope to Pods, ReplicaSets, and Services on the one hand, and Docker Service stacks, on the other.
Continue reading
The article that follows is an extract from the last chapter of The DevOps 2.2 Toolkit: Self-Sufficient Docker Clusters book. It provides a good summary into the processes and tools we explored in the quest to build a self-sufficient cluster that can (mostly) operate without humans.
We split the tasks that a self-sufficient system should perform into those related to services and those oriented towards infrastructure. Even though some of the tools are used in both groups, the division between the two allowed us to keep a clean separation between infrastructure and services running on top of it.
Continue reading
Technology Conversations 