In Present days, container-based microservice architectures have drastically changed the way development and operations teams (DevOps) work, test and deploy applications. Containers help organizations to scale and deploy applications on the fly, but containers have also brought the organizations new additional challenges and complexity.

Many businesses are now deploying lots of containers daily as it is effortless & requires fun-size time in setting up the infrastructure, but wait, how do they really manage it?

The answer is Kubernetes.

Yes, you heard that right. Kubernetes is Everywhere now.

So what is Kubernetes? Why do people use them? What does it do? Lots of question eh. Here are the answers.

THE WHAT?

Kubernetes is originally developed by Google and is primarily designed for large scale applications which comprises of tons of services, mostly microservices. You really don’t need a Kubernetes environment for monolith applications or apps with predictable or low demands.

THE WHY?

But Why Kubernetes is so popular and lots of organizations does use it? There are several factors which support the statement but below are few of them which has been hand-picked for simplicity.

Cost – Containers are light-weight in nature, which means they require less CPU & memory to operate when compared with the VMs & other Hypervisor technologies like VMware ESX, Hyper-V etc.
Stay Updated – Now you don’t have to wait/chase vendors for procuring new machines to spin up your applications when in need, Just provision & move ahead with Kubernetes to Develop, Deploy & Test your applications and speed up your release cycles.
WORA – Write Once, Run Anywhere – Tightly coupled architectures make DevOps team jobs difficult as every application depends on the underlying architecture but Kubernetes as said its omnipresent, it can run anywhere call it in AWS, GCP, Azure and On-Premise as well.

THE HOW?

Kubernetes is an open source distributed system that abstracts the underlying physical infrastructure, making it easier to run containerized applications at scale.

Kubernetes High Level Architecture

Here’s the breakdown of the above Architecture (Note: Attributed to a Restaurant for Quick & Easy Understanding)

Imagine a Restaurant Kitchen: Think of Kubernetes as the manager of a busy restaurant kitchen. In this kitchen, you have chefs preparing various dishes, and there’s a lot happening at once.

Kubernetes as the Kitchen Manager: Kubernetes plays the role of the kitchen manager. Its job is to make sure everything runs smoothly, efficiently, and without any chaos. It helps manage the chefs (containers) and the ingredients (resources) they need.

Containers as Chefs: Containers are like chefs in the kitchen. Each chef specializes in making a specific dish (an application). Containers are isolated, so they don’t interfere with each other’s cooking.

Nodes as Workstations: In the kitchen, you have multiple workstations where chefs can cook. These workstations are called “nodes” in the Kubernetes world. Each node can have multiple containers.

Pods as Plates: Kubernetes groups containers together into units called “pods.” You can think of pods as plates that carry one or more dishes (containers) that need to be served together. This helps ensure that related parts of an application are always together.

Replication as Preparing Multiple Plates: Sometimes, a restaurant needs to serve the same dish to many customers. In Kubernetes, this is like preparing multiple identical plates (replica pods) with the same food (containers) to serve to different diners.

Load Balancer as a Waiter: Imagine a busy restaurant with many customers. To make sure every customer gets their food, there’s a waiter (load balancer) who takes orders and distributes them to available chefs (nodes) or plates (pods). This ensures that no single chef gets overwhelmed.

Configurations as Recipes: In Kubernetes, you have configurations that act like recipes for your dishes (applications). These configurations describe how the dish should be cooked, what ingredients (resources) are needed, and how many servings (replicas) to prepare.

Scalability as Adding More Chefs: If the restaurant gets busier, you can tell Kubernetes to add more chefs (scale up) to handle the load. Similarly, you can also reduce the number of chefs (scale down) when things are quieter.

Health Checks as Taste Testing: Kubernetes regularly checks the health of the dishes (containers) by “taste-testing” them. If a dish doesn’t taste right (if a container fails), Kubernetes can replace it with a fresh one automatically.

Storage as the Pantry: Kubernetes also manages the pantry (storage) where ingredients (data) are stored. Chefs (containers) can access the pantry to get what they need.

To extend the restaurant-themed explanation of Kubernetes, here are a few additional technical components and concepts that ive included for better completeness.

🧾 Service Discovery as the Order Display System: Just like a digital kitchen order screen shows chefs what needs to be prepared, Kubernetes services help pods discover each other and communicate within the kitchen. Services ensure that even if a plate (pod) changes or moves to a new station (node), the order (request) still reaches the right chef.

🧠 Kube Scheduler as the Kitchen Dispatcher: The scheduler decides which workstation (node) each new chef (pod) should work at, based on the current load and available tools. It ensures the workload is fairly distributed across all cooking stations.

🕵️‍♂️ Kubelet as the Sous-Chef: On each node, the Kubelet acts like a local sous-chef, making sure all assigned chefs (containers) are working properly, have the right ingredients, and follow the recipe (manifest). It reports status back to the kitchen manager (control plane).

📦 Kubernetes API Server as the Order Counter: The API server is the main counter where orders are placed and updates are requested. It’s the single source of truth for all restaurant operations. Every chef, recipe, and dish must pass through this counter for instructions or status updates.

🧂 Secrets & ConfigMaps as Special Ingredients: Sometimes dishes need secret sauces (API keys, passwords) or variable ingredients (config values). Kubernetes uses Secrets and ConfigMaps to supply this — securely and separately from the recipe itself.

🔁 DaemonSets as Dishwashers at Every Station: Some tasks — like cleaning or monitoring — need to run at every workstation. DaemonSets are like dishwashers or timers that exist at every station to support kitchen operations without being tied to a specific dish.

📦 Namespaces as Separate Kitchens: Imagine one restaurant with multiple kitchens running in parallel for different cuisines (e.g., Italian, Chinese). Namespaces in Kubernetes logically isolate different projects or teams — like separating kitchens to avoid mixing up ingredients and orders.

🔐 RBAC as Staff Access Rules: Not everyone in the kitchen should have access to all areas. Kubernetes Role-Based Access Control (RBAC) is like a rulebook that defines who can cook what, access which ingredients, or modify recipes.

In a nutshell, Kubernetes is like a restaurant kitchen manager that keeps everything organized, makes sure dishes are cooked correctly, and ensures that customers (users) get their food (applications) without any hiccups, no matter how busy the restaurant (data center) gets.