Kubernetes: Learn DevOps Concepts like I’m five

Carl: (Thinking Loud) For many days Russ has not troubled me. Did he stop studying as I gave him quite a difficult task? Let’s go to him today.

Carl: Hey Russ!

Russ: Hey Carl! (Russ said In a Tone as he is trying to ignore Carl)

Carl: Why you haven’t come for a long time to my home, This is not your usual behavior.

Russ: Carl, I haven’t done any progress on my homework. That topic seems quite tuff to me.

Carl: No need to be ashamed, it is tuff. Let me explain to you Kubernetes with an analogy.

Russ: Like you always do. (Russ feels excited now)

Carl: 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.

Russ: I will definitely hire someone. Who will take all additional overhead of managing everything?

Carl: Hahaha! okay

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.

Russ: But it seems a difficult task for that rental agent alone too.

Carl: Ya correct. So 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 afterward, and the cycle repeats.

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

Carl: 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 like the employees’ phones.

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.

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.