Kubernetes - ashwani-cse/next-gen-pizza-backend GitHub Wiki

Let's Start: "Journey to Kubernetes"

1. What is a Server (Very Basic)

πŸ‘‰ Server = A computer that runs your application.
Example:

  • You create a website β†’ you need a server to host it.

  • Server = RAM + CPU + Storage, like your laptop, but for serving others.

Bare Metal Server = A real, physical machine.
(e.g., Dell/HP rack server sitting in a data center.)

2. Problem with Only Servers (Physical Machines)

Earlier, people bought 1 physical server for 1 application.

  • Wasted space (Server CPU 20% used, 80% idle).

  • Expensive.

  • Difficult to manage multiple applications.

3. Virtualization (Hypervisors)

To fix this waste, we invented Virtualization.

πŸ‘‰ Hypervisor = Special software that runs multiple virtual computers (VMs) on 1 physical server.

Examples of Hypervisors:

  • VMware vSphere

  • KVM

  • VirtualBox (you might have used this on your laptop!)

Now:

  • 1 physical server β†’ run 10 virtual machines β†’ save money, better use.

πŸ’‘ Think: Hypervisor = "Magician" that shows 10 computers from 1 real computer.

4. Problem with Virtual Machines (VMs)

VMs were good but:

  • Heavyweight β†’ each VM needs a full OS (Linux/Windows).

  • Slow boot time (takes minutes).

  • High RAM and CPU usage.

In short: Overkill for small apps.

5. Evolution: Containers

Now enters Containers (like Docker).

πŸ‘‰ Container = Light-weight alternative to VM.

  • No full OS inside.

  • Just your app + its dependencies.

  • Shares the main host’s OS.

Result:

  • Starts in seconds.

  • Very little RAM/CPU needed.

  • Easy to move (portable).

6. Docker: The Container Hero

Docker = Tool to create, run, and manage containers.

  • Package your app once β†’ run anywhere (laptop, server, cloud).

  • Solves the famous "it works on my machine" problem.

Example:

 docker run --name my-nginx -p 80:80 -d nginx

Above command downloads a web server (nginx) container and runs it in seconds.

7. Problem When Containers Become Many

Okay, now imagine:

  • You have 5 containers β†’ easy.

  • You have 500 containers β†’ difficult!

Challenges:

  • How to start/stop them?

  • How to restart if they crash?

  • How to balance load (traffic)?

  • How to upgrade them without downtime?

  • How to monitor health?

Solution Needed β†’ Some "manager" for containers.

8. Enter Kubernetes! (Finally πŸ˜„)

πŸ‘‰ Kubernetes = A Container Orchestrator.

Means:

  • It automatically manages your containers.

  • It restarts them if they fail.

  • It can create thousands of containers on hundreds of servers.

  • It does scaling, load balancing, updates, health monitoring.

πŸ’‘ "Kubernetes = Army General managing all soldiers (containers)."

πŸ”₯ SUMMARY: Flow of Learning

Step Technology Why it came
1 Bare Metal (Physical Servers) Needed to run apps
2 Hypervisor (VMware/KVM) Solve hardware wastage
3 Virtual Machines (VMs) Run multiple OS on one server
4 Containers (Docker) Lighter, faster, portable apps
5 Kubernetes (K8s) Manage 100s/1000s containers easily

πŸš€ Kubernetes (K8s) Structure β€” Step-by-Step

1. First, Big Picture:

πŸ‘‰ Kubernetes = Manages your containers across many servers.

It uses a special structure:

Cluster β†’ Nodes β†’ Pods β†’ Containers

  • Cluster = Whole system.

  • Node = A single machine (server).

  • Pod = Smallest unit in Kubernetes.

  • Container = Your app (inside Pod).

2. What is a Cluster?

πŸ‘‰ Cluster = Group of machines (servers) working together.

In Kubernetes:

  • One machine is called Master Node (or Control Plane).

  • Other machines are Worker Nodes.

Cluster = Master Node + Worker Nodes.

3. What is a Node?

πŸ‘‰ Node = A single machine (physical or virtual) inside the Kubernetes cluster.

Two types of nodes:

Node Type Purpose
Master Node (Control Plane) Controls the whole cluster.
Worker Node Runs your actual apps (containers).

πŸ’‘ Think of Master as Manager and Workers as Laborers.

4. What is a Pod?

πŸ‘‰ Pod = Smallest unit Kubernetes manages.

  • A Pod = 1 or more Containers bundled together.

  • Pod shares:

    • Same IP Address

    • Same Storage

    • Same Network

Usually: 1 Pod = 1 Container (but not always).

πŸ’‘ Pod = Room where your app (container) lives.

5. What is a Container (in Kubernetes context)?

πŸ‘‰ Container = Your actual application running inside a Pod.

Examples:

  • Nginx container (web server)

  • Redis container (database cache)

  • Spring Boot container (Java app)

6. Visual Diagram

  • Cluster
    • Master Node
      • Controls everything
    • Worker Node 1
      • Pod 1 -> Container (App)
      • Pod 2 -> Container (App)
    • Worker Node 2
      • Pod 3 -> Container (App)
      • Pod 4 -> Container (App)

πŸ”₯ Quick Real-World Example:

Imagine you are running an online store (Amazon-like):

  • 5 Servers = Cluster

  • 1 Server (Master) manages the others.

  • Other 4 Servers (Workers) run:

    • Pod 1: Website app

    • Pod 2: Payment app

    • Pod 3: Notification app

    • Pod 4: Database app

Kubernetes:

  • Will keep your store running even if 1 server goes down.

  • Will add more Pods automatically if too many people visit your site.

  • Will upgrade your app without downtime.

🌟 Up to here, you now understand:

  • What is Kubernetes

  • Why it exists

  • Basic architecture: Cluster β†’ Nodes β†’ Pods β†’ Containers

architecture_kube

Component workings

Component Role
kube-apiserver Brain: Accepts commands.
kube-scheduler Decides where to run pods.
kube-controller-manager Watches and fixes problems.
etcd Database: Saves cluster state.
kubelet (on Worker Node) Talks to Master, runs Pods.
kube-proxy (on Worker Node) Manages network traffic to Pods.

Overall Flow

  1. The user initiates an action using the kubectl command.
  2. The request is sent to the kube-apiserver, which serves as the front-end for the Kubernetes control plane.
  3. The kube-apiserver checks the request and may interact with etcd to retrieve or store cluster state information, if necessary.
  4. The request is forwarded to either:
    • kube-scheduler (for scheduling Pods) or
    • kube-controller-manager (for managing replica sets or other cluster tasks).
  5. The kube-scheduler determines the most appropriate worker node and schedules the Pod to run on that node.
  6. The kubelet on the worker node ensures the Pod and its containers are running and healthy as per the specification.
  7. kube-proxy manages network rules to ensure proper communication between Pods and external services.

Master Node – Contains 4 Major Components

a. kube-apiserver

πŸ”Ή Role:
The Gatekeeper – All operations on the cluster pass through it.

πŸ”Ή How it works:

  • You send a request (e.g., kubectl create deployment).
  • API Server:
    • Validates the request.
    • Authenticates (Are you who you claim?)
    • Authorizes (Are you allowed to do this?)
    • Updates etcd (if needed).
    • Notifies Controllers to take action.

πŸ”Ή Example:

kubectl apply -f app.yaml

Flow: Request β†’ kube-apiserver β†’ Validation β†’ Stored in etcd β†’ Controllers informed β†’ Scheduler starts.

b. etcd

πŸ”Ή Role:
The Brain Database – A super reliable key-value store for all cluster data.

πŸ”Ή How it works:

  • Stores everything: Pods, Services, ConfigMaps, Nodes.
  • Uses Raft algorithm for consistency and leader election.
  • If etcd survives, your cluster can be fully recovered.

πŸ”Ή Example: Create a Pod β†’ Its details are saved inside etcd.

c. kube-controller-manager

πŸ”Ή Role:
Maintains the Cluster's Health – Ensures the actual state matches the desired state.

πŸ”Ή How it works:

  • Continuously watches the API server.
  • If something is wrong, it fixes it automatically.

πŸ”Ή Key Controllers:

  • ReplicationController: Maintain number of Pod copies.
  • NodeController: Monitor node health.
  • DeploymentController: Handle rolling updates, rollbacks.
  • JobController: Manage one-time/batch jobs.

πŸ”Ή Example: A Pod crashes β†’ ReplicationController detects β†’ Creates a new Pod.

d. kube-scheduler

πŸ”Ή Role:
The Pod Placement Expert – Decides where new Pods should run.

πŸ”Ή How it works:

  • Looks at:
    • CPU/Memory availability
    • Node Labels
    • Taints/Tolerations
    • Affinity Rules
  • Picks the best Worker Node.
  • Updates the Pod with the Node's name.

πŸ”Ή Example: Pod needs 4GB RAM β†’ kube-scheduler finds a node that fits!

Worker Nodes – "Employees" Executing the Work

a. kubelet

πŸ”Ή Role:
The Pod Caretaker – Talks to the API Server and manages Pods.

πŸ”Ή How it works:

  • Receives tasks from API server.
  • Pulls necessary container images.
  • Starts and monitors containers inside Pods.
  • Reports health status.

πŸ”Ή Example: A container crashes β†’ kubelet restarts it automatically.

b. kube-proxy

πŸ”Ή Role:
The Network Mastermind – Manages networking on the node.

πŸ”Ή How it works:

  • Sets up iptables or IPVS rules.
  • Routes:
    • Pod-to-Pod
    • Pod-to-Service
    • External-to-Pod traffic
  • Handles load balancing internally.

πŸ”Ή Example: Your web app is exposed via a Service β†’ kube-proxy makes sure requests find the right Pod.

c. Pods

πŸ”Ή Role:
Smallest Deployable Unit – Runs one or more containers together.

πŸ”Ή How it works:

  • Shared IP and Storage among containers.
  • Managed completely by Kubernetes.
  • Ephemeral: If a Pod dies, Kubernetes creates a new one (not resurrects the old).

πŸ”Ή Example: Frontend + Backend container needing tight communication β†’ Same Pod!

d. Containers

πŸ”Ή Role:
The Real Applications – Actual software running inside Pods.

πŸ”Ή How it works:

  • Isolated using cgroups and namespaces.
  • Pulled from container registries (DockerHub, AWS ECR, etc.)
  • Managed by container runtime (Docker, containerd, etc.)

πŸ”Ή Example: You can run manually:

docker run nginx

But in Kubernetes, containers run inside Pods automatically.

⚠️ **GitHub.com Fallback** ⚠️