Explaining Kubernetes in 10 minutes using an analogy | Opensource.com

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.

Houses in a row
Image credits : 

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

x

Subscribe now

Get the highlights in your inbox every week.

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.

api-server.png

API server connecting components together

(Satyajit Das, CC BY-SA 4.0)

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

Deployment

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.

kubeproxy.png

Kube-proxy and deployment

(Satyajit Das, CC BY-SA 4.0)

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.

Shipping containers stacked in a yard

Understanding the building blocks of container orchestration makes it easier to get started with Kubernetes.
Ship captain sailing the Kubernetes seas

On its anniversary, get to know Kubernetes with these deep-dives and hands-on projects.

Topics

About the author

Satyajit Das
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. Follow my YouTube channel for regular videos on the above topics: https://www.youtube.com/c/Tennexas/?sub_confirmation=1 I did my bachelors from IIT Kharagpur, Masters from Ecole Polytechnique, Masters thesis from Caltech and PhD...