Kubernetes aka K8s (8 Letters between letter K & s) is a :
- Open Source container management tool.
- Developed by Google.
- manage containerized applications.
Did not understand the above terminology? It's okay.
What basically we do (in general)
- Write a Code
- Create an Image using Dockerfile
- Run the Image using Docker (or we called it container (running instance of image))
- and Application is UP because the container is UP and the user can access the application
But what happens if the particular container gets crashed? End users will start facing timeout. and then you will re-start the container. So there is downtime for end-users, which is not good. Also, you need to manage everything.
To sort this problem, we have a tool called Kubernetes which will manage containers, if one container crashed - the tool will automatically redirect user requests to its replica and along with that it starts another container.
Components
There are tons of components in Kubernetes. But we will look below components -
- NODE
- POD
- SERVICE
- INGRESS
- CONFIG-MAP
- SECRET
- VOLUMES
- DEPLOYMENT
- STATEFUL-SET
NODE
To run your application or container - we need a machine. And that machine/Server is called a Node which is a Virtual Machine.
POD
It's just a layer over the container. POD is the smallest unit of Kubernetes.
Pod is usually meant to run one application inside container. So in above figure, we have one application container and other database container. If our application have to access the database container, application POD needs to communicate with database POD. So How they communicate.
Each POD has it's own IP and it's Internal IP (Not the Public IP)
But in Kubernetes, pod can dies easily, So if DB pod dies, Kubernetes will create the new POD and that get new IP address. And we know our app-pod was communicating with earlier POD using IP only. Now new POD created having new IP, so we need to adjust the IP, which is not a good and feasible approach.
To overcome this problem, we have another component called SERVICE
SERVICE
Service is basically a Static IP address. Or permanent IP address that can be attached to each POD. So app-pod has own Service, DB-pod has own service.
So, now even if DB POD get died and new one get created, there will be no impact. Because we have SERVICE still in place and it has Static-IP and POD not directly communicating with other POD, It's communicating via Service. So no need to adjust the end-points (even if POD dies).
End-Point of service will be something like that IP_of_Node:Port_of_service
So if we want to test, our application, we can test using above end-point. But generally when we gave end-point to users we gave something like that - abc.com (we not gave VM IP address)
So, for this, we have another component in place called INGRESS
INGRESS
So instead of going request directly to Service, Request will go to Ingress first and then it will forward the request to Service.
Generally in code, we hard-code the Database End-point , Username and Password. So if our Service name (which attaches) with DB POD get changed. We need to update our code, and then need to recreate image and then again do the deployment which is a very lengthy process.
For this problem, we have 2 more components - CONFIG MAP & SECRET-KEY
CONFIG-MAP & SECRET KEY
In Config-Map - we will store our Database Service Name, So if DB service name changes in future, we just need to update our config-map, and config-map also attached with application-POD.
But, we can't store the password in config-map as config-map is a read able format. so to store secret information like password and Certificates , we have another component SECRET-KEY, where we can store such secret information and that in encrypted format. SECRET also attached with application-POD.
What will happen to Data, if my DB-POD dies ? Will data get lost ? No, to sort this issue, we have another component called VOLUMES
VOLUMES
It's just a persistent disk it could be in a Server(Virtual Machine) or at remote location. We need to connect the volume with DB-POD. Kubernetes is not responsible for Data, So we as a user or administrator need to take care of Data (like its storage, backup etc)
Now everything ready, USER can access my application via Browser.
So what happen if my application POD dies ?
Do I recreate the container if that will be the case , User will not able to access the application for a period of time and again downtime. So to sort this problem, we have concept of replication. (Distributed System) We will replicate our application to another server as well. So now if one of the pod will die – service will forward the request to another POD on anther Node and our application will be available for end-user.
Similarly if our DB-POD dies, So we need to replicate our DB-POD as well to another node (virtual machine)
The 2nd node also connected with SERVICE as shown in diagram below.
SERVICE also act as a LOAD-BALANCER, when the request came from end-user, it will not put forward request to same POD every-time. It will check which POD is empty - and forward the request to that POD (on particular server), thus it act as a Load-Balancer as well.
But, How we will do all these ?
- Like create node, create Pod, create replica of application-pod, replica of DB-pod, Service etc.
Ideally, we not do anything, deployment will do everything for us. We just need to define the blueprints of POD (there we can specify how many replica we need and other things).
So, Ideally we will not create any of these things, we will just create Deployments. and we can scale-up and scale down the replicas.
But
We can't replicate DATABASE-POD, using Deployment. Because database has it's state, i.e. if we clone database, they should share same storage, So we need some kind of mechanism which POD is writing to the Database/Storage and which is reading from storage (to avoid data inconsistency)
So, we have another component called StatefulSet - This component especially for such things like database. StatefulSet take care of database replica.
Now, if we even whole NODE died, Still user can access the application (and no downtime) (because of another Node).
There are more components. But above are the basic and powerful ones.
We will see the DEMO of all these things in Next-Blog. There we will Deploy one application and we will see - Whether VM created or not, whether Load-Balancer Created or Not. And we will Destroy POD and see whether still we able to access app or not (i.e. whether Service is forwarding the request to another POD or not)