Understanding DNS: The Internet’s Phone Book

Ever wondered what happens when you type google.com into your browser? Behind that simple action lies one of the most elegant distributed systems ever created: the Domain Name System (DNS). Think of it as the internet’s phone book, but instead of looking up phone numbers, it translates human-readable domain names into IP addresses that computers can understand.

What Exactly is DNS?

DNS is essentially a hierarchical, distributed database that maps domain names to IP addresses. When you visit a website, your computer needs to know the exact IP address of the server hosting that site. Since remembering 142.250.80.14 is much harder than remembering google.com, DNS acts as the translator.

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).