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 →
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 →
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 →
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 →
Picture me as a young teenager. After school, we’d go a courtyard and play soccer. That was an exciting sight. A random number of us to be running around the yard without any orchestration. There was no offense and no defense. We’d just run after a ball. Everyone moves forward towards the ball, someone kicks it to the left, and we move in that direction, only to start running back because someone kicked the ball again. The strategy was simple. Run towards the ball, kick it if you can, wherever you can, repeat. To this day I do not understand how did anyone manage to score. It was a complete randomness applied to a bunch of kids. There was no strategy, no plan, and no understanding that winning required coordination. Even a goalkeeper would be in random locations on the field. If he’d catch the ball around the goal he’s guarding, he’d continue running with the ball in front of him. Most of the goals were scored by shooting at an empty goalpost. It was “every man for himself” type of ambition. Each one of us hoped to score and bring glory to his or her name. Fortunately, the main objective was to have fun so winning as a team did not matter that much. If we were a “real” team, we’d need a coach. We’d need someone to tell us what the strategy is, who should do what, and when to go into the offense or fall back to defend the goalpost. We’d need someone to orchestrate us. The field (a cluster) had a random number of people (services) with the common goal (to win). Since everyone could join the game at any time, the number of people (services) was continually changing. Someone would be injured and would have to be replaced or, when there was no replacement, the rest of us would have to take over his tasks (self-healing). Those football games can be easily translated into clusters. Just as we needed someone to tell us what to do (a coach), clusters need something to orchestrate all the services and resources. Both need not only to make up-front decisions, but also to continuously watch the game/cluster, and adapt the strategy/scheduling depending on the internal and external influences. We needed a coach and clusters need a scheduler. They need a framework that will decide where a service should be deployed and make sure that it maintains the desired run-time specification. 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 →
If you liked this article, you might be interested in The DevOps 2.2 Toolkit: Self-Sufficient Docker Clusters book. The book goes beyond Docker and schedulers and tries to explore ways for building self-adaptive and self-healing Docker clusters. If you are a Docker user and want to explore advanced techniques for creating clusters and managing services, this book might be just what you’re looking for.
Please get a copy from Amazon, LeanPub, or look for it through your favorite book seller.
Give the book a try and let me know what you think.
A self-sufficient system is a system capable of healing and adaptation. Healing means that the cluster will always be in the designed state. As an example, if a replica of a service goes down, the system needs to bring it back up again. Adaptation, on the other hand, is about modifications of the desired state so that the system can deal with changed conditions. A simple example would be increased traffic. When it happens, services need to be scaled up. When healing and adaptation are automated, we get self-healing and self-adaptation. Together, they both a self-sufficient system that can operate without human intervention.
How does a self-sufficient system look? What are its principal parts? Who are the actors? Continue reading →
Any system that intends to be fully automated and self-sufficient must be capable of self-healing and self-adaptation. As a minimum, it needs to be able to monitor itself and perform certain actions both on service and infrastructure levels.
Two axes can represent the set of actions a system might execute. One group of actions be represented through the differences between infrastructure and services. The other axis can be explained by the type of activities, with self-healing on one end, and self-adaptation on the other. Continue reading →