When you hear Kubernetes, what comes to your mind first?

Another Docker? Hell No! Kubernetes is rather a system that can work for hand in hand with a docker, not one that depends on docker to work, docker is used for building and containerizing images right, those containers built, the function of Kubernetes is to manage them effectively, hence you can say Kubernetes is an orchestration tool. In proper definition: Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. Kubernetes is meant to run across across cluster while Docker runs on a single node. Kerbernetes is a tool built by engineers at google before being made an open-source project. However, before going into learning Kubernetes at full strength, it is highly important to know the basic concepts involved. Let’s start with pods.

POD

What is a pod? Kubernetes is using the concept of pods to interact with the container, pod is an abstraction of a container, each container is saved in the pod in its entirety for Kubernetes to interact with. We can say, the only way a Kubernetes system can interact with a container is through a pod

DEPLOYMENT

Deployment is a configuration in Kubernetes that provides declarative updates to applications. A deployment allows you to describe an application's life cycle, such as which images to use for the app, the number of pods there should be, and the way in which they should be updated. Deployment is a configuration where you can determine how many replica sets to be produced per pod. It helps maintain the cluster in other to avoid the smallest of downtime. We can say it is like a blueprint that dictates how every feature of a pod will behave.

REPLICA SETS

These are the abstraction of a pod, the way pods are abstractions of a container which is the running instance of an image. Why do we need a replica set? It is because we are trying as much as possible to ensure our application is running at all time and avoid downtime, in a situation where our pods are shutting down, we will be sure there are other copies of it as the replica sets stored elsewhere, we can have as many as possible replica set per pod saved somewhere in a node.

The major difference between a replica set and deployment is, 1.a replica set ensures that a specified number of pod replicas are running at any given time. However, a deployment is a higher-level concept that manages ReplicaSets and provides declarative updates to pods along with a lot of other useful features. 2.When updates are made to our image in a replica set, the application will shut down once it discovers an update because another one is being spun up but if it were to be a deployment, it will ensure that the old replica sets are still running pending the time the new image is being spun up, once the new one is working, it will shut down the old one entirely. Therefore ensuring no downtime at all.

NODE

A node is like a single PC in a cluster where pods reside. There can be multiple pods in a node, the least number of nodes you can have in a cluster is two. Inside a node, there consists at least a pod, a container which the pod abstracted. Many a time, there are situations when there can be more than one container in a pod, there is no need to show your DevOps muscles, the convention is one container per pod, but there can be several pods in a node, each pods having its own service. Because of our database, we need a SECRET configuration, the function is to house or store secret data that we do not want to expose.

SERVICE

It is just like an endpoint, API points for Kubernetes, Service has a permanent IP address when a pod is being updated, the IP of the pod will change but the IP of our services never change, that is why all pods are connected to a service and there can be several pods attached to one service, that is the essence of our replica sets when one goes down, others are being spun up.

CONFIGMAP

This is a configuration that stores all external configurations of the application, external configurations like all third party configurations like database URL and ports, etc.

INGRESS

This is an external service in our application, It addresses how the IP address in the browser is being linked to the right service in the node. Do not forget that services are attached to pods, they are just access point consisting of majorly ports to be able to interact with our pods, How pods are being scheduled across nodes in form of replica sets is through a process called the “Master Process”, with the aid of a “Scheduler”.

I hope this is helpful, the writer is a learner too, I am open to suggestions from seniors like you, feel free to use the comment box. Thanks for reading...

...

wizardcalidad | 2021