Deconstructing Kubernetes Scheduling

Think of Kubernetes as a super-organized logistics manager. Its job? To ensure every Pod finds the perfect node to live on, based on its requirements, preferences, and constraints.

But Kubernetes isn’t just about making sure the Pod “finds a place.” It uses sophisticated scheduling mechanisms like affinity, anti-affinity, taints, tolerations, and even direct assignments with nodeName.

Let’s dive into how Kubernetes works its scheduling magic. Before we start with that, lets just get a brief idea on how the api server decides which node the application should be deployed into.

Deconstructing a Kubernetes Deployment

Think back to the first time you laid eyes on a Kubernetes deployment manifest. Did it make any sense to you apart from the image and container parameters? Wait, it did? Well, that makes one of us!

When I first saw a Kubernetes deployment, I was hit with a flurry of questions. Questions that made me feel like I had opened the Matrix. Now, after some much-needed experience (and a few existential crises), I think I can finally answer some of those burning questions.

TLDR

Kubernetes is a container orchestration tool in which you can use multiple machines/VM’s to create a cluster. When cluster is created, application deployed on it are distributed throughout the nodes and Kubernetes makes sure they are up and available depending on the provided configuration.

Architecture

Node: A physical machine or VM where our applications are run when deployed.

Cluster: A combination of nodes running together. It is best practice to have multiple nodes running at the same time to avoid a failure if any one of the nodes in the cluster stops working.

Overview

The builder creational design pattern is used to create a complex object, in a step by step manner.

You might have come across the same using while using some Java Clients or any other framework, lets us now see what problem it solves.

The core idea here is that if we need to send too many parameters in a constructor call,its hard to maintain the order of the call, and the constructor call itself is very difficult to read. And in most cases all the parameters are not necessary for object initialization and can be skipped instead of passing mandatory fields when object is created via a constructor.

Overview

As the wikipedia definition says:

The observer pattern is a software design pattern in which an object, named the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods.

To someone not familiar with this pattern the first thing that would come to their mind is Polling. If we want to know about changes that are done to a central body/system we continuosly send request to the server and check for changes based on the responses But the problem with this approach is, with a significant increase in clients that are polling the system, the continuous request going to the system will overwhelm the system. Also making huge amount of IO/Network requests is bad (Just take my word for it).

Overview

As the Wikipedia definition says:

The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application. The strategy pattern is intended to provide a means to define a family of algorithms, encapsulate each one as an object, and make them interchangeable. The strategy pattern lets the algorithms vary independently from clients that use them.

Or in simpler terms, Instead of hardcoding an implementation that can vary according to the various classes. We on runtime inject the appropriate algorithm/behaviour that the class will need.