I had been tasked with creating up a kubernetes cluster and setting up deployment of a Node JS API project. At that point, I was aware of kubernetes but did not have a complete understanding of how it worked. I started reading about how to setup a cluster and how to deploy a project to the cluster. After my introduction, I have thought about a metaphor for how to think about the cluster and deployment that I used to explain it co-workers.
Say for example you create a flyer that about a topic you are very passionate about. You work very hard, put in a huge amount of effort in the hopes that your flyer will attract the attention of many people. After you are done creating this flyer, you post it on a bulletin board or the people to see. Then, you see your hard work gain attention and now there is a mass of people who would like to view the flyer you created. Lets see how this is handled in an environment using kubernetes.
First you have to build your flyer(project). This will vary based on the technology you are using, but the important thing to do here is you need to create a template that will allow for easy reproduction. You will need to make a master flyer that you can use to make more copies of your flyer. This is where something like Docker will come in to allow you to make a docker image out of your project. You will need a file cabinet to store your master flyer and any previous versions of your flyer. For us, this will be a container registry which will keep the latest copy of your image with some amount of previous versions. When you build your project, you will need to push the latest image to the container registry.
Now that we have created our flyer and stored the master version, along with previous versions, in our filing cabinet, we are ready to post it up to the bulletin board. Posting our flyer to a bulletin board is the process of deploying our image to the kubernetes cluster. A very simplified metaphor of how a pod is deployed in kubernetes is to think of it as taking your master flyer, making a copy of it then posting the copy to the bulletin board. For us, this means that kubernetes will go to the container registry, get the latest image then use that image to create a new pod which is where our application will be running. The environment of the pod is defined by image, for example a docker image will use the Dockerfile to define and setup the environment. So now the flyer we have worked very hard to create and perfect is posted on the bulletin board, now we wait to see if anyone comes to view our creation.
Our flyer has been posted for some time now, we have had a steadily growing amount of people to come and view our flyer. The crowd is getting to the point that it is hard for everyone to read the flyer at once, there are just too many people crowding around. This is a good problem, but still a problem. It would be great if we could have another instance of the flyer so that everyone does not need to crowd around one flyer. Then we remember we have a master copy of the flyer so we decide to make a new copy which we then post on a second bulletin board. Perfect! Kubernetes to the rescue again. We can set kubernetes to scale up and down based on traffic to our application. What that means is that kubernetes will take the application image from our container registry, make a copy of it and create a new pod which can have traffic directed at it (I will cover directing traffic next). So now we have two pods with a copy of the same master image running which will allow the traffic to be split between the two pods. If the traffic is still too much for two pods, kubernetes can create more pods with the same copy of the master image. Then, once the traffic slows down, kubernetes can scale down back to one pod.
So, now that we have multiple flyers posted on separate bulletin boards, we need a way to let people know they can go view the flyer on the other bulletin board. That is where we have a person who is sitting at the entrance who can direct people to the least populated bulletin board so that they get the best viewing experience. We do not want people to have a bad experience when they come to view our flyer. Even though it is not our fault there is a large group of people crowded around the bulletin board, people will remember their bad experience when thinking about our flyer. That is where the load balancer comes in. This is the entrance to our application which is taking requests to get to our application and directing them to the best pod to service that request. This load balancer has knowledge of the pods that are running in the cluster along with other metadata to help the load balancer to transfer a request to the appropriate pod keeping it so that everyone has the quickest response time as possible.
This is the metaphor that I developed to help myself understand kubernetes and then explain kubernetes to others. I hope that this helps someone who is trying to understand kubernetes at a high level. I also welcome any feedback on ways to improve my metaphor or to let me know if I am misunderstanding how something is working.
Top comments (0)