What is Kubernetes? | A Comprehensive Introduction to K8s

Kubernetes (K8s) has evolved from a container orchestration engine into the industry-standard universal control plane for modern cloud-native infrastructure. Originally developed at Google as an open-source offshoot of their internal Borg system, Kubernetes provides automated deployment, scaling, health management, and declarative state reconciliation across distributed systems.

1. The Core Problem: Why Do We Need Kubernetes?

To understand why Kubernetes exists, we must analyze how software architecture evolved from monolithic systems to microservices operating at scale.

The Monolith vs. Microservices Trade-off

• Monolithic Architecture: A single unified software application. It avoids inter-service network latency and can often outperform unoptimized microservices. However, scaling individual features independently is impossible, and a failure in one module can crash the entire monolith.
• Microservices Architecture: Applications are split into micro-components (e.g., Login, Home Feed, Billing). Each service can use a different tech stack (Python, Go, Java) and be scaled independently.

The Operational Friction at Scale

Running 2-3 containers using basic Docker commands is simple. However, running 50+ microservices across 4 different deployment environments (Development, Testing, Staging, Production) introduces severe operational challenges:

1. Self-Healing: If a container crashes at 3 AM, how is it automatically detected and restarted?
2. Scaling: How do you add container instances automatically when traffic spikes, and scale down when traffic drops?
3. Service Discovery & Load Balancing: How do microservices find each other's dynamic IP addresses?
4. Environment Drift: How do you guarantee exact replica environments across Dev, Staging, and Production without maintaining hundreds of custom Bash scripts?

Core Insight: Writing custom operational scripts for container health, routing, and deployment triggers is fragile and unmaintainable. Kubernetes replaces custom imperative scripts with an automated declarative control loop.

2. The Mental Model: Declarative Desired State Reconciliation

At the heart of Kubernetes is a simple control loop paradigm: Reconciliation.

Real-Life Analogy

Real-Life Analogy: The Thermostat Control Loop

Imagine an automated air conditioning unit set to $72^\circ\text{F}$.

• Desired State: $72^\circ\text{F}$
• Actual State: $78^\circ\text{F}$ (measured by sensors)
• Action: The controller turns on cooling until Actual State == Desired State.

Kubernetes works the exact same way. You declare in a YAML file: "I want 3 replicas of my Nginx application." Kubernetes constantly monitors the cluster. If 1 container dies (Actual State = 2), Kubernetes detects the drift and immediately launches a new container (Reconciled State = 3).

3. High-Level Kubernetes Cluster Architecture

A Kubernetes cluster is divided into two primary planes:

1. Control Plane (Master Nodes): The brain of the cluster making global decisions (scheduling, event handling, state storage).
2. Worker Nodes: The execution machines running the actual containerized workloads.

4. Control Plane Components Deep-Dive

The Control Plane manages the global state of the cluster.

1. Kube API Server (kube-apiserver)

The kube-apiserver is the central gateway for all cluster communication. No component interacts directly with etcd or node agents without going through the API Server.

When a client (kubectl) sends a request, kube-apiserver processes it through three sequential phases:

2. etcd (Distributed Key-Value Store)

etcd is a strongly consistent, distributed key-value store that serves as Kubernetes' single source of truth.

• It records every cluster object, spec, and state.
• High-Availability (HA) Setup: High Availability clusters run 3 or 5 etcd replicas using the Raft Consensus Algorithm to elect a leader and handle node failures safely.
• Note: Lightweight K8s distributions like K3s can swap etcd with relational stores like SQLite or PostgreSQL via Kine interfaces.

3. Kube Scheduler (kube-scheduler)

The scheduler watches for newly created Pods that have no assigned node (nodeName is empty). It determines the best node for the Pod using a two-step process:

1. Filtering (Predicates): Removes nodes that do not meet requirements (e.g., insufficient CPU/RAM, unsatisfied nodeSelector, active Taints).
2. Scoring (Priorities): Ranks remaining candidate nodes based on resource balance, affinity/anti-affinity rules, and image locality, then binds the Pod to the highest-scoring node.

4. Kube Controller Manager (kube-controller-manager)

Runs control loops that regulate cluster state. Each controller watches the API Server for changes to its assigned resource type:

• Deployment Controller: Manages rollout and updates of application replicas.
• Node Controller: Detects when worker nodes go offline.
• ReplicaSet Controller: Ensures the specified number of Pod instances are running at all times.

5. Worker Node Architecture Deep-Dive

Worker nodes run the workloads assigned by the Control Plane.

1. Kubelet

The kubelet is an agent that runs on every worker node. It reads PodSpecs provided by the API Server and ensures that the containers described in those specifications are running and healthy.

Container Execution Sequence

2. Container Runtime

The underlying software responsible for running containers. Common implementations include containerd and CRI-O. Low-level runtime engines like runc interface directly with Linux kernel primitives (namespaces, cgroups).

3. Kube-Proxy (kube-proxy)

A network proxy running on each node that maintains network rules (iptables or IPVS). It allows network communication to Pods from inside or outside the cluster by translating Virtual Service IPs to backend Pod IPs.

4. Modular Interfaces (CRI, CNI, CSI)

Kubernetes decouples container operations via standardized plugin specifications:

6. Workload Primitives: Pods, ReplicaSets & Deployments

Understanding how Kubernetes abstracts applications requires reviewing its fundamental workload objects.

• Pod: The smallest deployable computing unit in Kubernetes. A Pod encapsulates one or more containers that share storage, network IP address, and runtime configurations.
• ReplicaSet: Guarantees that a specified number of identical Pod instances are running at any given time.
• Deployment: A higher-level object that declaratively manages ReplicaSets, enabling zero-downtime Rolling Updates and instant rollbacks.

7. Kubernetes as a Universal Infrastructure Control Plane

Kubernetes is no longer just a container orchestrator. Its extensible architecture (Custom Resource Definitions / CRDs and Operators) allows it to control infrastructure far beyond standard Linux containers.

1. Cloud Integration via Cloud Controller Manager (CCM)

CCM bridges Kubernetes with cloud provider APIs (AWS, GCP, Azure). When you create a Service of type LoadBalancer or request a PersistentVolumeClaim (PVC), CCM interacts directly with cloud APIs to provision external Cloud Load Balancers and block storage disks.

2. Managing Virtual Machines with KubeVirt

Tools like KubeVirt allow users to run traditional Virtual Machines alongside container workloads within the same Kubernetes cluster.

• VMs are declared using standard YAML manifests (kind: VirtualMachine).
• Operators utilize standard K8s operations (scheduling, networking, storage) to manage VM lifecycles.

3. Managing Infrastructure via Crossplane

Crossplane extends Kubernetes into a cloud control plane. By defining Custom Resources in K8s, Crossplane provisions external resources (such as AWS S3 buckets, RDS databases, or managed firewall rules) directly through Kubernetes declarative API workflows.

4. Non-Container Runtimes (WASM)

Kubernetes can orchestrate WebAssembly (WASM) modules using custom low-level runtimes (e.g., wasmtime, wasmedge), allowing lightweight execution without full container OS overhead.

8. Step-by-Step Practical Walkthrough

Let me translate the real cluster interactions demonstrated in the lecture transcript into step-by-step terminal commands.

Phase 1: Inspecting the Control Plane (kube-system)

To view all system containers running the control plane:

kubectl get pods -n kube-system

Sample Output:

NAME                                     READY   STATUS    RESTARTS   AGE
coredns-768b85b76f-xk2l9                 1/1     Running   0          5d
etcd-control-plane                       1/1     Running   0          5d
kube-apiserver-control-plane             1/1     Running   0          5d
kube-controller-manager-control-plane   1/1     Running   0          5d
kube-proxy-8x7tz                         1/1     Running   0          5d
kube-scheduler-control-plane             1/1     Running   0          5d

Phase 2: Imperative Pod Launch & Lifecycle Tracing

Run a single Nginx pod imperatively:

kubectl run nginx --image=nginx

When this command runs, the internal event chain unfolds:

Verify Pod startup:

kubectl get pods -w

Phase 3: Creating a Deployment with Replicas

To manage multi-instance deployments declarative or imperatively:

kubectl create deployment demo --image=nginx --replicas=3

Inspect created ReplicaSets:

kubectl get replicaset

Output:

NAME              DESIRED   CURRENT   READY   AGE
demo-56cd6f549c   3         3         3       12s

Inspect active Pods created by the ReplicaSet:

kubectl get pods

Output:

NAME                    READY   STATUS    RESTARTS   AGE
demo-56cd6f549c-4kx2p   1/1     Running   0          25s
demo-56cd6f549c-8l9mn   1/1     Running   0          25s
demo-56cd6f549c-m9z4q   1/1     Running   0          25s

Phase 4: Demonstrating Self-Healing

If a Pod is manually killed or crashes, the Controller Manager immediately intervenes to restore the desired count of 3 replicas.

# Delete one pod
kubectl delete pod demo-56cd6f549c-4kx2p

# Immediately query pods
kubectl get pods

Observation:

NAME                    READY   STATUS        RESTARTS   AGE
demo-56cd6f549c-4kx2p   1/1     Terminating   0          90s
demo-56cd6f549c-8l9mn   1/1     Running       0          90s
demo-56cd6f549c-m9z4q   1/1     Running       0          90s
demo-56cd6f549c-v7p1z   1/1     ContainerCreating 0      2s

Kubernetes automatically detected that Actual Count (2) < Desired Count (3) and spun up demo-56cd6f549c-v7p1z instantly.

9. Monolith vs. Microservices vs. Kubernetes Architecture

Summary and Key Takeaways

• Beyond Container Orchestration: Kubernetes is an extensible, universal control plane platform—not merely a tool for running Docker containers.
• Origin: Built upon lessons learned from Google's internal Borg system over 10+ years, K8s became CNCF's first graduated project.
• Control Loop Paradigm: Operates on continuous state reconciliation, ensuring the Actual State of the cluster matches the Desired State defined in manifests.
• Control Plane Core: Composed of kube-apiserver (API Gateway), etcd (Key-Value Store), kube-scheduler (Node Assignment), and kube-controller-manager (State Loop Engine).
• Worker Node Core: Composed of kubelet (Node execution agent), containerd (CRI Runtime), kube-proxy (Network routing), and CNI/CSI plugins.
• Standardized Interfaces: Modular design via CRI (Container Runtime), CNI (Networking), CSI (Storage), and CCM (Cloud Provider Integration).
• Built-in Self-Healing: Automatically recreates failed containers or dead pods across healthy nodes without manual operational scripts.
• Platform Extensibility: Custom Resources allow K8s to manage Virtual Machines (via KubeVirt), external Cloud Storage/Services (via Crossplane), and WASM modules seamlessly.