Kubernetes Concepts and their related Docker swarm terminologies

With the increase in the adoption of microservices, people use docker to isolate containers and better handle resources. With Kubernetes being a popular Orchestration tool, more and more people adopt it. Unfortunately, Kubernetes being a bit complex due to various functionalities being offered, Starters may feel it difficult or they take more time to understand it. Time is precious. Some people might opt for docker swarm due to its simplicity, Later they might think of moving to Kubernetes. I was one of them.

Photo by Joseph Barrientos on Unsplash

Due to docker swarm being simple and straight forward. It is easy to implement. It suits for managing simple applications. As Simplicity is the ultimate Sophistication most of the configurations/controls are abstracted and are handled by Docker Swarm. On the Other side, Kubernetes is complex in its own ways. My justification for this complexity is due to the providence of better control over the configurations.

As a part of this evolution at One point, your application becomes complex and needs a better orchestration to handle workloads or you might need better control over your deployments. At this point, you might think of moving to Kubernetes. But it might be a little difficult initially to co-relate docker swarm and Kubernetes concepts. When I wanted to move from docker swarm to Kubernetes I found a lot of resources explaining about Kubernetes concepts. But, I couldn’t find anything giving an overall picture of Kubernetes functionalities in Docker swarm terms. Hence this article.

Kubernetes Pod — Docker Swarm?

Pods are the fundamental starting point in Kubernetes. In Docker Swarm, We run each docker container as a swarm service. These swarm services are grouped under a Stack. The only means of the relation between all the containers are either they will be attached to the same network or all of them share a volume. But in Kubernetes, containers can be grouped under a single object called Pod. i.e We can run a single container or a group of containers under a Pod. All these containers share the same container namespace. i.e same network namespace (same IP address and port space), IPC, and, optionally, they can use shared volumes. It is like running a single Docker swarm service with multiple containers in it.

Photo by Ishant Mishra on Unsplash

Kubernetes Deployments — Docker Swarm Services

Once we understand about Pods, The next confusion comes about handling Replicas. This is the part where I got confused to the core. Kubernetes have Replicaset, Deployments, Statefulset, Daemonsets to handle container replication whereas Docker swarm has only Swarm Services. All these tend to do the same(i.e controlling replication and High Availablity), Then what’s the difference?

To be simple, In Kubernetes, we actually have Replicaset to handle container replication, Deployment is just an upgraded version of ReplicaSet which additionally handles rollout and rollback of the new versions. Stateful sets are meant specifically to handle Stateful applications like Databases. For simplicity, It can be considered as an upgraded version of Deployments 😜

What about Daemonsets?

These do the same work when we specify Docker swarm services with mode: global. I.e Running one replica of the container per node.

Kubernetes Services — Docker?

Before understanding Services, We need to understand how service discovery works. In Docker swarm, you can connect to any container if it is mounted to the same network either by using a container name or network alias. You can’t connect to the container attached to another network directly. In Kubernetes, everything runs under a namespace. To use Service Discovery, You need to explicitly create a service with ports that you want to expose. Pods/Deployments/ReplicaSets/DaemonSets/StatefulSets can be associated with these services by using labels. You can query these services and the exposed ports directly. When you want to connect to a Pod you can query the service name. You can query for services on other namespaces by using <service_name>.<namespace_name>.svc.cluster.local. Even if you query for services in the same namespace internally it gets translated to this format.

Ok, coming back to Kubernetes Services. Handling of open ports, network communication across pods, hosts are handled by Services, whereas in Docker Swarm we directly do the port binding. In Kubernetes, you will have two types of services, a Normal Service, and a Headless Service. The normal Service is as same as docker swarm service with endpoint_mode: vip , in which docker assigns a single IP and does load balancing across the replicas. Kubernetes Headless Service is an equivalent of docker swarm service with endpoint_mode: dnsrr which results in unique IPs for each replica. This results in interchanging IPs every time a service is queried.

Photo by Caleb Russell on Unsplash

Kubernetes Probes — Docker Health Checks

Docker uses health checks to determine whether a container is healthy, can service requests. In docker services, traffic will be routed only to healthy containers. In Kubernetes, this health check is further classified into different probes. You have livenessProbe to check whether a pod is alive, readinessProbe to tell whether a container can start serving requests, startupProbe to inform whether a pod has started. As long as readinessProbe returns success traffic is routed to it. As soon as it reports failure the pod gets removed and a new pod is scheduled. This new pod’s readinessProbe returns success traffic is not routed here. Just like docker routing traffic to healthy containers.

Kubernetes Affinity, Anti-Affinity, Tolerations - Docker placement constraints

In Docker swarm, we use placement preferences and placement constraints to control where a container gets deployed. The same can be mapped to Kubernetes to specify conditions to place and run a pod. We can even specify conditions like schedule pod only if 60% of node resources are free. Don’t schedule more than two replicas in the same node.

Of course, All multiple ways to achieve the same functionality makes Kubernetes more complicated. But you have better control of things when you get a fair idea of what you are doing. In nutshell, Docker swarm is like Windows which is easy to use and has limited functionalities, whereas Kubernetes is like Linux which is a bit difficult to start with. But once you understand it, You can do wonders with it.

A developer cum DevOps engineer. Forever in love with Linux. Interested in #Devops #chaosEngineering #Docker #Kuberbetes #AWS.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store