With this post, I aim to explain Kubernetes to a developer who understands basics of Software Development but hasn’t laid out hands in infra. Having done multiple internships as an SDE, I have always been a rookie when it comes to deployment. Hence, the experience of Kubernetes was (is) overwhelming to me.
The first and basic thing to understand is that the world was fine even before Kubernetes: as it is with most of the tech. We had containers like Docker(I started with docker :p) which provides efficiency and consistency. Docker is used even today and it is not replaced by Kubernetes. In fact, the birth of Kubernetes was caused by the need of maintaining highly dynamic environments. It is obvious that if you have a server pool having a huge capacity, you will have dynamic environments and hence, the need to manage them. DevOps people were doing this maintenance task manually. The aforementioned automation is what Kubernetes has brought.
Now that you have a bird’s eye view of what Kubernetes is, let me discuss few basic concepts. Kubernetes comprises of Pods, Services, Volumes and Namespaces. These four are Kubernetes’ objects. Imagine a cluster(mathematically / topologically speaking), named “Racimo”. Racimo has several processes running in it. These processes are termed as Racimo’s pods. Each pod will have a guide with itself that would instruct the running (govern the usage) of containers and will use an allotted storage space.
As you can see, storage is shared and so is networking. Hence, a pod is a provider of 2 resources: networking and storage. Keep this in mind to understand the future construction and communication.
So, container(s) inside a Pod will use the shared volume and inter-pod communication will be carried out using the network resource(address) of pods.
I hope you have understood what are Pods, let us discuss Services.
Services are like a manager which would let the whole cluster work. How?
Pods are the applications running on instance(s), they will get terminated: either intentionally(after their execution) or as a result of scaling/failures. Now Kubernetes will take care of the pod’s restart but what would happen to the two resources that the pod has: storage and network. Although, storage was for the pod in itself, what about the network? The network resource of a certain pod vanishes the moment pod gets terminated. So, there must be something to ensure the communication of different pods to this newly generated pod(in place of the deleted pod). The communication is done by the abstraction provided by the Services.
Following two pictures will demonstrate the abstraction provided by Services.
Notice how the change of a pod does not raise an error. It is solved by Services present in the middle providing abstraction of pods.
The actual diagram from the docs is:
Describing Volumes is easy after explaining the usage of Services. Just note that the storage problem is solved by Volumes just like the network problem of Pods is solved by Services.
Quoting from the doc:
On-disk files in a Container are ephemeral, which presents some problems for non-trivial applications when running in Containers. First, when a Container crashes, kubelet will restart it, but the files will be lost — the Container starts with a clean state. Second, when running Containers together in a
Podit is often necessary to share files between those Containers. The Kubernetes
Volumeabstraction solves both of these problems.
It is noteworthy that why and how the volumes of Docker(container) is not used in Kubernetes for this purpose.
Namespaces are helpful in collaboration on a single cluster. It is nothing but a single physical cluster but by the virtue of the virtualisation, multiple virtual clusters are created for all the devs.
So, what is the need of having namespaces? A poor but understandable analogy would be git. Like you have multiple branches in git, you have multiple namespaces so that there are no name collisions.; it would be as if only your namespace exists and you don’t have to worry about names of resources in other namespaces.
Giving a non-cloud example, you put a namespace Messi and other guy puts a namespace, Ronaldo, you both don’t need to worry about any nomenclature as long as there is no collision within your development area(namespace).
I guess this was enough to get the engines started. No, you cannot skip the official documentation.