Explaining Kubernetes in 10 minutes using an analogy

Having trouble understanding Kubernetes? Try this analogy of using a rental house to explain how it works.
106 readers like this.
Houses in a row

27707 via Pixabay, CC0. Modified by Jen Wike Huger.

The concepts behind the Kubernetes container orchestration system can be hard to understand. I created a simple analogy about renting out rooms in a house to help you learn how Kubernetes works.

How to rent rooms in your house

Imagine you own a house with 10 rooms. You want to rent out three of the rooms through an online accommodation service. You have two choices: you can post ads and manage everything yourself, or you can hire someone to do it for you.

Because it's simpler for you, you decide to hire a rental agent to take care of these things. Your contract with the agent states:

  • At all times, three rooms should be available to rent to guests.
  • Each room will have two beds.
  • Every time a guest books, the keys need to be handed over at the right time.
  • Every time a guest leaves, the rooms have to be cleaned.
  • If there are too many booking requests (during a holiday season, for instance), then booking availability can increase from three to ten.

That's it! Your responsibilities are mostly over, although you can use a phone to contact the agent to check in from time to time.

How to manage a rental property

The agent hires employees to take care of your requirements. Let's say there are three employees to manage three rooms: when room one is booked, employee one ensures it's in good condition, provides the keys, cleaning service, and so on.

The bed is the most basic entity because it's the minimum requirement needed by a guest to spend a night.

The agent keeps all the information about employees, rooms, beds, bookings, and so on, in a notebook. The agent also keeps track of employee time off in order to allocate another employee to the room should one employee fall ill or goes on holiday. The agent uses the phone to reach employees as needed.

When a guest books a room online, the booking is redirected to one of the employees, who ensures the room is ready. The guest arrives, gets the keys, and sleeps in the bed at night. The room is cleaned afterwards, and the cycle repeats.

This all sounds very simple, but what has it got to do with Kubernetes?

What Kubernetes has to do with this

The automation you achieved by hiring the agent who employs others is similar to what Kubernetes does with an application. Here's how it works.

Say you are an app developer instead of a rental-house owner. As the most basic entity in a rental room is the bed, your application (the most basic entity that serves your user's needs) runs inside a container. The application's "room" is called a pod, which is where your application runs.

A node or worker node is essentially a machine in which a pod runs.

The agent's employees ensure a guest room is fully functional. In Kubernetes, you don't have an employee but something called a kubelet. A kubelet is an agent inside a node that ensures the pods running inside that node are healthy.

The rental agent corresponds to two things in Kubernetes: kube-scheduler and kube-controller manager. Just as the agent decides which room should be assigned to which employee, the kube-scheduler decides which pod runs in which node, based on what resource is available and what its requirements are. Remember, a node is a machine, and the pod runs inside a node. Like the agent deciding what to do when an employee is off work, the kube-controller manager decides what to do when a node goes down or the machine stops working for any reason.

The agent's notebook, where all the details are recorded about how many rooms to rent, how many beds are available, which employee is doing what, and so on, corresponds to the etcd data storage. That's where configuration data is stored, for example, if you need three pods to be up all the time.

The main and worker nodes in Kubernetes operate like the phones that the agent and the employees use to communicate. The main api-server is like the agent's phone, while each worker node's kube-proxy is the like the employees' phones.

The api-server, etcd, kube-controller manager, and kube-scheduler comprise a sort of control center for this Kubernetes instance.


The contract between you (the house owner) and the agent is equivalent to a deployment in Kubernetes. A deployment includes your set of requirements, such as how many pods need to be running, what resources (CPU, for example) you need, and so on. Kubernetes ensures these requirements are satisfied without manual intervention.

Remember about the extra clause in the agreement about what to do if too many guests book? This is equivalent to autoscaling in Kubernetes. That means Kubernetes can scale your services, giving you more pods as your application users increase, just as you can make more rooms available if more guests are trying to book. Just as you can't extend your bookings beyond 10 rooms, you probably need to add a cap on autoscaling, because you can't arbitrarily continue to increase pods without running out of money for hosting your servers.

Learn more

This brief analogy about how Kubernetes works is a good place for beginners to start. To learn more, you might also enjoy my Kubernetes videos.

This article is based on Kubernetes: The Simplest Introduction for a Non-Programmer, originally published on the Tennexas blog, and is reused with permission.

What to read next
Satyajit Das
I am currently a Software Engineer, based on Cambridge, UK. I mainly work with Golang and a bit of React. My work also includes technologies like Kubernetes, Docker, gRPC, Elastic, RabbitMQ etc.


Well this makes understanding the components of Kubernetes really easier.
What still bugs me most is that I don't fully understand the use cases or real world scenarios for Kubernetes and everything which builds on it. Normally I would bring up a lab and try everything out; but here I don't know what to deploy.

That's a great question, maxim. I think Kubernetes gets so much attention sometimes that people forget to ask "why". It might help to remember that Kubernetes is a container orchestrator, meaning that its job is to help you manage containers.

This means that anything you can put into a container, you can run on your Kubernetes cluster. Whether that's a web server, or forum software, or a fancy web app, or anything else that you've ever seen offering a Docker install. It's a readjustment of how services are provided to a network, but once you start looking at what you can containerize, you start seeing all kinds of things you can run on Kubernetes.

Whether or not you actually *need* to is another question. Most home users probably don't have an urgent need for Kubernetes. But those aspiring to IT careers could benefit from learning about Kubernetes by running a cluster, and those who do provide services to family and friends could benefit from containers and Kubectl and so on.

In reply to by maxm

Hey Seth, thanks for your answer reply!
Perhaps I should just start at home and see where it goes; at the moment all my services are virtualized but some of those could sure be run inside a container.

In reply to by sethkenlon

Seth thanks for your explanation.. a good example of why do you need to put something inside a container, is a service that will be request from many user and that in sometime needs to scale or to be re-used many times.. in that case your need is to scale or to reuse that service.. and that case put that service in a container make sense!

In reply to by sethkenlon

I use open source BI tool Helical Insight and it offers so much more in terms of workflows, database driver support, adding own visualizations using JS and a whole lot of APIs.

I would like to download kubernetes or dockers on my pc to have access to my data to be able to work

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.