What's the connection between Kubernetes and chocolates? Bet you don't know. Read on to find out.
Have you ever watched Willy Wonka (or Charlie) and the Chocolate factory? I read the book (way better by the way!) and it's surely a timeless children's classic. A "rags to riches" type of story of a poor boy who gets a chance to visit a mysterious and fascinating chocolate factory owned by an even more mysterious Mr. Wonka. and ends up winning it in the end!
So why are we talking about a children's movie that involves a trip to a chocolate factory?
Because it's the 'Golden Ticket' to explain the concepts of Kubernetes.
That's why we're telling you. If you haven't read the book or watched the movie, then maybe you should! Because you're going to need it!
The Chocolate Factory Epilogue & its Kubernetes Connection
The story of Charlie and the Chocolate Factory ends with Mr. Wonka handing over his beloved Chocolate empire to Charlie. (Was that a spoiler?). But what happens next? That's for us to decide.
And that's why we're going to write our own little epilogue to the story. Don't worry, we're going to connect it back to Kubernetes at each step. This is a tech blog. We aren't digressing. Ok? Let's start
PS: Watch out for the snippets in the quoted blocks. That's where our "epilogue story" unravels! Like this one here:
Mr. Wonka had finally retired, handed over his precious chocolate empire to Charlie and was now vacationing in the Bahamas. It was all upto to Charlie now to manage all the bustling chocolate factories.
Now, Charlie was smart one! And he went immediately into "action mode" and turned around the inner workings of the entire business.
Clusters & Nodes
Charlie had to manage four factories that were clustered together in an open filed just on the outskirts of the city.
He rechristened one of them as his "Headquarters" and handled all the administrative tasks from there. While the other three factories continued to pump out their signature chocolates every day.
Look closely here. We're going to help you make the connections.
A factory was mostly the one responsible for producing chocolates. And there were three of them that were working in tandem.
Likewise, A "NODE" in Kubernetes is an entity that is responsible for carrying out some computational work. (Just like a single factory that produces chocolates).
A NODE can be a physical server. A computer. An instance on the cloud. Choose whichever option you like.
And multiple nodes working together to carry out various tasks is called a CLUSTER
Factory = Node
Multiple Factories working together = Cluster
By the way, what can we say about our hero Charlie? He's the one managing everything right? You can say Charlie sort of emulates the role of Kubernetes itself. After all, Kubernetes is a software that manages containerized applications on a cluster for you so that you don't have to worry about all the little details? So imagine Kubernetes to be like an umbrella, spread over a cluster of nodes.
Master-Slave Concept
The Headquarters, was where major administrative decisions were taken and the other factories worked in accordance with these. All the new requests for chocolates first came in at the Headquarters which would be then propagated to the other factories. Employees were hired and assigned to factories by the headquarters.
The headquarters also kept a tab on how each factory was doing. Like whether any one of them needed equipment repairs or maintainence?Or at what capacity was each factory running? Could it produce more or was it already at its peak capacity?
Like the Headquarters, there is one node in a Kubernetes cluster that is responsible for managing all the other nodes. This specific node is called the "MASTER" Node while all the other nodes are called WORKER nodes. This is called the "MASTER-SLAVE" concept.
Headquarters = Master Node
Other Factories = Worker Nodes
And just like the Headquarters had a ton of tasks to do, the master node too carries out various functions like
All the new requests for chocolates first came in at the Headquarters
= Accepting Client Requests
Employees were hired and assigned to factories
= Scheduling to Nodes
The headquarters also kept a tab on how each factory was doing = Monitoring Overall Health of the Nodes
Exactly how does the Master Node carry out these tasks? You'll know that very soon in one of our upcoming blogs in this series.
Pods
Now, of course, no organization can work without employees. And the factories too had a large share of workers working tirelessly day in and out. Mind you, they weren't humans ( remember the Oompa Loompas?). In reality they were these different creatures and rather resembled little pea pods.
The chocolate factories had their workers while Kubernetes clusters have PODS to carry out all the tasks and run applications.
In a way you can say like an employee is a basic unit of any organization, a pod is a basic unit of deployment in any Kubernetes cluster.
In reality, a pod is just a set of one or more containers. And the containers within the pod run a particular application.
Also, a pod is said to be "self-sufficient". That means it creates an environment within it that is just suitable to run the one particular application container assigned to it. Kinda like a mini-computer created just for the application!
It's a simple enough definition of pods and it's okay to get started with it for now. But we'll delve deeper and explore more on pods in our upcoming blogs. (Otherwise this one will get a bit longer)
Pod Networking and Services
Mr. Wonka had always ensured the well-being of his employees and that's why the workers were offered a few perks. One of these was that each new employee was given a cell phone with his on personal phone number to use.
There were also a few measures put in place for employee support. One of these included a "Complaint Guy".
Basically, an employee was given the role of the "Complaint guy" and all the other workers could call this guy on his personal phone number and put in their queries and complaints. Sort of like a Grievance Officer
In the same was as each employee (including the Complaint Guy) had his own phone number, each pod is assigned its own IP Address which can be used by other pods to communicate with each other. See, if a pod is self-sufficient then it's bound to have some networking capability!
Personal Phone Number = Pod's IP Address
But there was a little problem here. In case the current "Complaint Guy" left, a new one took his place and this new guy had a totally different phone number.
But the others didn't know that, and they continued to call on the earlier number which was now invalidated.
Ah, pods are ephemeral creatures. So if a pod dies, a new one is created to take its place. But a new pod means a new IP address. And when that happens, the other pods don't know about this change and keep trying to connect to the older IP.
Just like our poor workers who were trying to call the older Complaint Guy but they never knew that there was a new one in town!
That's when Charlie decided to shake things up. In addition to a Complaint Guy, he created a "Complaint Helpline" which was just a single phone number anybody could call on. Now, even if a new employee was assigned the role, nobody faced any issues as the helpline number remained the same. It didn't matter who they spoke to as long they was someone to listen!
Likewise, Kubernetes allows us to attach a "SERVICE" resource to a pod. A Service, will always have a fixed IP address. All the other pods just need to know the Service's IP Address instead of the Pod's IP.
And say if the pod the service is attached to dies, it simply re-attaches itself to the new pod created. The service doesn't die with the pod and that's how the IP address remains constant.
It's kinda like our little "Complaint Helpline". No matter who is on the line, the number stays the same!
Helpline Number = Service
We know, we know. This isn't enough. There's a ton of information on Kubernetes Networking that we'd like to share with you and we will in our upcoming blogs.
Namespaces
Things were going great but a few months later, a new challenge came up. The factories produced different types of chocolates and candies and things were getting complicated.
The main concern was that different products required different ingredients and were produced in different quantities. Milk chocolates were number one on the demand list and required required cocoa, milk (and sugar). Candies came in second which required flavors (and sugar). Jellies were made in small quantities that required needed gelatin (and sugar).
Acquiring raw material and distribution of these resources was becoming troublesome. Sometimes milk chocolates ran out of sugar because it was used up for candies. Or sometimes, there was an excess of workers making jellies but no one to make candies.
If you'd notice all the products were using sugar as their raw material. But when a bag of sugar came in, there was no way of knowing where it had to be used. In Milk chocolates? or candies? Maybe the jellies needed it?
We don't know! It's open to everyone!
There will be a time when a cluster will be used by multiple users and teams who run their own applications (the time can be now too). But things get difficult when there are a lot of applications running and you don't which application belongs to whom.
Consider this. There are three teams using one cluster: the microservices, the database team, and the logging team. Now if both the services team and the database team have an application called "the-duplicate-application-name". How should we know to which team it should belong?
That's where NAMESPACES come in.
Charlie decide to shake things up a little. He divided up his company into three different departments. So there were separate departments for milk chocolate, candies and jellies
Each department was given a fixed quota of raw materials, resources and even employees depending on the demand and production.
Since Milk chocolates were in high in demand, they were given a larger quota as compared to Jellies which had a lower share in the overall sales.
In this way individual resources were kept separate for each of the department and they never interfered with each other!
The Chocolate factories got a department for each type of chocolate and each one got its own share of raw materials.
That's how namespaces work too. A NAMESPACE is a way in which a cluster's resources can be divided up between users or teams. So there can be one namespace dedicated to each of the services,database and the logging team in our previous example.
Departments = Namespaces
Each team will work within its own namespace and since the namespace has its own share of resources, it won't interfere with the other resources.
Now even if two teams have an application with the same name, "the-duplicate-application-name", it won't matter because the two applications will run in isolation in their own namespace.
What's Next?
And that's how Charlie managed to manage his inherited chocolate company. The factories or "nodes" working in tandem with the headquarters "master node" with all the little "pods" running around busily, trying to get the work done.
The End. It was a happy ending after all!
Our little story about a chocolate company has kinda summarized most of the basic concepts related to Kubernetes. You just need to make the right connection! But we've just scratched the surface. This post just gets you familiarised with the basic terms and concepts that are required when starting with Kubernetes. But that's not gonna be enough is it?
We told you the Kubernetes world is quite overwhelming at first. But stay with us and you'll soon master it like a pro!
We have a great mix of both concept-driven blogs to get your basics right and practical blogs to put those concepts in use coming up for you. Stay tuned for more on this series!
Join the conversation