What is Kubernetes? Container Orchestration and Microservices Explained (2026 Guide)

PerfectNotes Team•Updated May 2026

Share

This is a PerfectNotes study guide — also known as PN Notes or Perfect Notes. PerfectNotes provides free computer science student notes, MCQs, and interview preparation guides at perfectnotes.org.

Download PDF

Introduction to Kubernetes and Microservices

Kubernetes is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. It groups software containers into logical units, ensuring that complex microservices run seamlessly, recover from failures instantly, and scale automatically to meet user demand.

What is Kubernetes (K8s)? (Simple Definition)

When a company builds a software application using Docker, they package their code into tiny, lightweight boxes called Containers. If you only have one or two containers, you can easily start and stop them manually on your laptop.

However, massive companies like Netflix or Spotify run millions of containers across thousands of servers simultaneously. A human being cannot possibly manage that many moving parts. Kubernetes is the highly intelligent robot manager that takes control of all these containers, automatically deciding where they should run, when to duplicate them, and how to fix them if they break.

The "Symphony Conductor" Analogy

Imagine a massive symphony orchestra with hundreds of musicians. Each musician (a container) knows exactly how to play their specific instrument perfectly. However, without a leader, the music would be a chaotic mess of overlapping noise.

Kubernetes is the Conductor of the orchestra. It does not play the instruments itself, but it holds the master sheet music. It tells the violinists when to play louder (scaling up), points out when a flute player has dropped their sheet music and needs a replacement (self-healing), and ensures every single section works together to create a flawless, unified performance.

Why Do We Need Container Orchestration?

If a website goes viral, the server hosting it can quickly become overwhelmed and crash. In the past, human engineers had to wake up in the middle of the night to physically turn on more servers.

Kubernetes handles this automatically. It constantly monitors the health and network traffic of your application. If it notices a sudden spike in users, it will instantly copy your containers and spread the workload across multiple servers. When the traffic dies down, it safely deletes the extra copies to save money on server costs.

The Shift from Monoliths to Microservices

For decades, software was built as a Monolith. This meant the entire application — the user login screen, the shopping cart, and the payment processor — was fused together into one giant block of code. If the payment processor broke, the entire website crashed.

Today, engineers use a Microservice Architecture. They break that giant block into small, independent puzzle pieces. The login screen is one container, and the shopping cart is a completely separate container. Kubernetes manages the invisible network wires between these pieces, ensuring that if the shopping cart crashes, the rest of the website stays online while Kubernetes automatically reboots the broken piece in the background.

Core Concepts: How Kubernetes Manages Containers

Kubernetes manages distributed applications using a cluster architecture. The master control plane dictates the desired state of the application, while worker nodes run the actual containerized workloads. It utilizes abstract networking layers to ensure constant connectivity, even as underlying containers are continuously destroyed and recreated.

Pods: The Smallest Unit of Kubernetes

Kubernetes does not interact with individual Docker containers directly. Instead, it wraps one or more containers into a digital envelope called a Pod.

The Pod is the smallest, most basic deployable object in Kubernetes. You can think of a Pod as a single instance of a running process. If two containers are placed inside the exact same Pod, they are guaranteed to run on the exact same physical server, share the same local network, and share the same storage volumes.

Nodes and Clusters: Where the Work Happens

A Kubernetes Cluster is the overarching term for the entire system. It is divided into two distinct roles:

• ● Master Node (Control Plane): The central brain of the cluster. It makes global decisions — figuring out which physical server has enough free memory to run a new Pod, and reconciling actual vs desired state.
• ● Worker Nodes: The actual physical or virtual machines that do the heavy lifting. They receive instructions from the Master Node via the kubelet agent and run the Pods.

Deployments and ReplicaSets: Ensuring High Availability

In Kubernetes, you never manually start a single Pod. Instead, engineers use a Deployment.

A Deployment is a declarative blueprint. You tell it: "I always want exactly five copies of my shopping cart Pod running." The Deployment creates a ReplicaSet to enforce this rule. If a Worker Node catches fire and destroys two of those Pods, the ReplicaSet instantly notices the deficit and forces a different, healthy Node to spin up two brand-new replacement Pods.

Services: How Containers Talk to Each Other

Because Pods are constantly dying and respawning across different servers, their internal IP addresses change every few minutes. This creates a massive problem: how does the front-end website know how to talk to the back-end database if the database's IP address is constantly changing?

Kubernetes solves this with a Service. A Service acts as a permanent, unchanging virtual address. It sits in front of a group of Pods and gives them a single, stable ClusterIP. When the website wants to talk to the database, it sends the request to the Service, and kube-proxy automatically routes the traffic to whichever database Pods are currently alive and healthy.

Advanced Engineering Concepts

Enterprise Kubernetes architecture relies on a highly distributed, declarative control plane. The API server acts as the central gateway, storing cluster state in a highly available etcd key-value store, while the kube-scheduler mathematically binds Pods to optimal Worker Nodes utilizing complex taints, tolerations, and node affinity rules.

Architectural Breakdown of the Kubernetes Control Plane

The Kubernetes Control Plane is not a single application — it is a composition of distinct microservices that collectively maintain the cluster's global state. All components communicate exclusively through the Kube-API Server, which exposes a RESTful interface and strictly prevents direct component-to-component communication to ensure authorization and admission control.

The Kube-Controller-Manager runs continuous control loops (like a thermostat) that monitor the actual state of the cluster against the declarative desired state written in YAML manifests. If a drift is detected, it autonomously initiates API calls to reconcile the state.

Etcd, the Kube-API Server, and the Raft Consensus Algorithm

etcdis the distributed, highly consistent key-value store that serves as Kubernetes' ultimate source of truth. Every single configuration, secret, and state update is persistently logged in etcd.

Because etcd is a clustered database, it utilizes the Raft Consensus Algorithm to prevent split-brain scenarios during network partitions. It mathematically requires a strict majority quorum to commit a write operation, ensuring that the Kube-API Server never reads stale data regarding Pod scheduling or node availability.

etcd cluster size  →  fault tolerance (nodes that can fail)
  3 nodes           →  1 failure  (quorum = 2)
  5 nodes           →  2 failures (quorum = 3)   ← production standard
  7 nodes           →  3 failures (quorum = 4)

Rule: quorum = ⌊N/2⌋ + 1
→ Always deploy odd numbers (3, 5, 7) to avoid tie votes during leader election

The Kube-Scheduler and Node Scoring Mathematics

When a new Pod is created, it enters a Pending state. The Kube-Scheduler watches for unassigned Pods and mathematically determines the optimal Worker Node for placement.

This is a two-step process — Filtering and Scoring:

• ● Filter: Eliminates Nodes that lack required CPU/RAM, missing GPU, or violate taint/toleration rules.
• ● Score: Ranks remaining Nodes using a weighted scoring function based on spreading constraints, image locality, and resource utilization.

Score(node) = Σ ( Weight_i × FeatureScore_i )
  Where FeatureScore_i includes:
  · LeastRequestedPriority  (prefer nodes with most free CPU/RAM)
  · BalancedResourceAllocation (prefer nodes with balanced CPU:RAM ratio)
  · ImageLocalityPriority  (prefer nodes that already have the image cached)
  · NodeAffinityPriority   (prefer nodes matching spec.affinity rules)

Node with highest Score → Scheduler creates Binding object → kubelet starts Pod

Kubelet, Kube-Proxy, and the Container Network Interface (CNI)

Every Worker Node runs a Kubelet, the primary node agent responsible for listening to the API server and interacting with the local Container Runtime (containerd) to physically spawn and destroy the isolated Linux namespaces for each Pod.

Networking is abstracted via the Container Network Interface (CNI). Kubernetes does not provide native networking — engineers must plug in third-party CNI providers like Calico, Flannel, or Cilium. The CNI ensures every Pod receives a unique, routable IP address across the entire cluster.

The Kube-Proxy manages translation of virtual Service IPs (ClusterIPs) to physical Pod IPs, typically by manipulating the Linux kernel's iptables or utilizing highly performant eBPF programs.

Ingress Controllers and Layer 7 Traffic Routing

While a standard Kubernetes Service operates at Layer 4 (TCP/UDP), exposing enterprise web applications requires Layer 7 (HTTP/HTTPS) routing. This is achieved using an Ingress Controller (such as NGINX or Traefik).

The Ingress Controller acts as the global reverse proxy and API gateway for the cluster. It evaluates the URL path or hostname of an incoming web request and dynamically routes the traffic to the correct internal Service. It is also the architectural termination point for TLS/SSL certificates.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  tls:
    - hosts: [shop.example.com]
      secretName: tls-cert-secret
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /cart
            pathType: Prefix
            backend:
              service: { name: cart-svc, port: { number: 80 } }
          - path: /payments
            pathType: Prefix
            backend:
              service: { name: payment-svc, port: { number: 80 } }

StatefulSets, Persistent Volumes (PV), and Storage Classes

Running stateless web servers in Kubernetes is trivial, but running stateful databases (like PostgreSQL or MongoDB) requires advanced storage architecture. Because Pods are ephemeral, standard local storage is erased upon termination.

Engineers utilize Persistent Volumes (PV) and Persistent Volume Claims (PVC) to decouple storage from the Pod lifecycle. A StatefulSet guarantees that each Pod receives a sticky, predictable network identity (e.g., database-0, database-1) and securely binds the Pod to a permanent cloud storage volume (like an AWS EBS volume). If database-0 crashes, the StatefulSet respawns it and re-attaches the exact same storage volume, guaranteeing zero data loss.

Quick Reference Cheat Sheet

Frequently Asked Questions (FAQ)