Kubernetes From First Principles

How Kubernetes actually keeps distributed systems alive

In the previous articles, we explored why Kubernetes became inevitable.

**Non-member link**

Containers made applications portable. Docker made deployments consistent. But once companies started running hundreds or thousands of containers across many machines, managing everything manually became impossible. That’s where Kubernetes entered the picture.

But for many beginners, Kubernetes feels intimidating almost immediately.

People hear terms like:

• API Server
• Pods
• kubelet
• etcd
• Services
• Deployments
• Scheduler

…and suddenly Kubernetes feels less like infrastructure and more like a giant wall of terminology.

The problem is most tutorials start by throwing component names at you before explaining the bigger picture. So, in this article, we’ll do the opposite.

Instead of memorizing Kubernetes terminology, we’ll slowly rebuild the system from first principles using one simple question:

If I ask Kubernetes to run my application… what actually happens behind the scenes?

That single question explains almost the entire Kubernetes architecture. And once you understand the flow, the components stop feeling random. Once that idea clicks, Kubernetes starts becoming much easier to understand. This article opens the Kubernetes “black box” and rebuilds its internal architecture from first principles.

Kubernetes

The Most Important Kubernetes Mental Model

Before learning Kubernetes components, we need to understand how Kubernetes thinks.

Kubernetes is not fundamentally:

• a Docker wrapper
• a command runner
• a YAML engine

Kubernetes is fundamentally a distributed control system.

Its job is simple in theory:

Desired State
    vs
Actual State

Then continuously:

• observe reality
• detect differences
• correct the system

This process never stops. That’s the core of Kubernetes. Everything else exists to support this reconciliation loop.

Let’s Follow One Deployment Through Kubernetes

Instead of explaining components in isolation, let’s follow one simple example.

Suppose a developer tells Kubernetes:

Run 3 replicas of my API application

That single request triggers an entire chain of distributed coordination inside the cluster. By tracing this request step by step, Kubernetes architecture becomes far easier to understand.

First, What Is a Kubernetes Cluster?

A Kubernetes cluster is simply a group of machines working together. These machines are usually divided into two categories:

Cluster
├── Control Plane 
└── Worker Nodes

• The control plane acts like the brain of Kubernetes.
• Worker nodes act like the machines that actually run applications.

This separation is extremely important.

Worker Nodes: Where Applications Actually Run

Worker nodes are the machines responsible for running workloads.

This is where:

• containers execute
• applications consume CPU
• memory gets allocated
• networking happens

If you deploy an application into Kubernetes, the actual containers eventually run on worker nodes. But worker nodes themselves do not make high-level decisions. Those decisions come from the control plane.

The Control Plane: The Brain of Kubernetes

The control plane is responsible for:

• cluster coordination
• scheduling decisions
• monitoring cluster state
• maintaining desired state
• orchestration logic

Without the control plane:

• the cluster loses intelligence
• workloads stop coordinating
• self-healing disappears

The control plane continuously watches the cluster and makes decisions about how the system should behave. This is where Kubernetes becomes much more than “just containers.”

The API Server: The Front Door of Kubernetes

At the center of the control plane sits the API Server. Almost everything in Kubernetes flows through it.

Whenever you:

• deploy applications
• scale workloads
• create services
• update configurations

…you are communicating with the API Server.

Think of it like this:

User
  ↓
API Server
  ↓
Kubernetes Cluster

The API Server acts as:

• communication hub
• cluster gateway
• coordination center

It exposes the Kubernetes API that all components use to interact with the cluster. This makes Kubernetes highly modular internally.

What Happens When You Submit a Deployment?

Suppose you apply a deployment configuration that says:

Desired State:
3 replicas of API application

The API Server receives this request first. But Kubernetes still needs somewhere to store this information persistently. That’s where etcd enters the picture.

etcd: Kubernetes Memory

Kubernetes needs a reliable way to remember:

• desired configurations
• cluster state
• metadata
• workload information

That responsibility belongs to: etcd

etcd is a distributed key-value database. You can think of etcd as: Kubernetes’ memory.

Whenever cluster state changes:

• deployments
• nodes
• services
• secrets
• configurations

…the information gets stored inside etcd.

This is critically important because distributed systems constantly change. Machines may fail. Components may restart. But Kubernetes must still remember what the cluster is supposed to look like. That persistent memory lives in etcd.

Kubernetes Is Constantly Watching Itself

One of Kubernetes’ most important design ideas is: continuous observation. Different Kubernetes components constantly watch the API Server for changes.

Whenever new desired state appears:

• schedulers react
• controllers react
• kubelets react

The cluster behaves like many specialized control loops working together. This architecture is one reason Kubernetes scales so effectively.

The Scheduler: Choosing Where Workloads Should Run

At this point, Kubernetes knows: “3 replicas should exist.” But where should they run? The scheduler solves this problem.

The scheduler examines:

• available CPU
• available memory
• node health
• placement constraints
• workload balancing

Then selects the best worker nodes.

For example:

Node A → enough resources
Node B → overloaded
Node C → healthy

The scheduler might choose:

• Node A
• Node C

for workload placement. This is one of Kubernetes’ most important responsibilities. Because poor scheduling decisions can:

• overload systems
• waste resources
• reduce reliability

Kubelet: Kubernetes’ Representative on Each Machine

Every worker node runs a component called kubelet. The kubelet acts like the local Kubernetes agent for that machine.

Its job is to:

• receive instructions
• start containers
• monitor workloads
• report status back to the cluster

Once the scheduler chooses a node, the kubelet takes over locally.

The kubelet then:

• pulls container images
• creates pods
• starts containers
• monitors application health
• reports status back to Kubernetes

This is where containers finally begin running. Without kubelet worker nodes would not know what to run.

But Kubernetes Doesn’t Run Containers Directly

Wait — Why Pods Instead of Containers?

This confuses many beginners initially. Kubernetes does not deploy containers directly. Instead, Kubernetes deploys *pods*. A pod is the smallest deployable unit in Kubernetes**.

Usually: one pod contains one container, so think Pod ≈ Container

But Kubernetes intentionally introduced pods as a higher-level abstraction. Why? Because distributed systems often require tightly coupled containers that share:

• networking rules
• storage
• lifecycle coordination

Pods provide that grouping abstraction. You can think of a *pod as a wrapper around one or more containers*.

The Container Runtime Still Matters

Even though Kubernetes manages orchestration, containers still need to run somewhere. The kubelet itself does not create containers directly. The kubelet communicates with the container runtime.

This runtime is responsible for:

• actually, starting containers
• interacting with Linux kernel primitives
• managing container lifecycle

Examples include:

• containerd
• CRI-O

And underneath all of this we eventually reach:

• namespaces
• cgroups
• Linux process isolation

The same concepts we learned in the very first article. This is why understanding containers first makes Kubernetes much easier to reason about.

Controllers: The Self-Healing Engine

Now we reach one of Kubernetes’ most powerful ideas: *controllers. *Controllers continuously watch cluster state.

They constantly compare: Desired state vs actual state

Suppose Kubernetes expects 3 running pods, but one pod crashes. Actual state becomes only 2 running pods. The controller notices the mismatch immediately.

Then Kubernetes automatically:

• creates replacement pods
• reschedules workloads
• restores the desired state

This is the heart of Kubernetes self-healing behavior.

Kubernetes Never “Finishes”

This is one of the biggest conceptual differences beginners must understand.

Traditional scripts often behave like:

Run task
Complete task
Exit

Kubernetes does not work like this.

Kubernetes continuously:

• watches
• compares
• reacts
• reconciles

The reconciliation loop never stops. That’s why Kubernetes clusters feel “alive.” The system is constantly monitoring itself.

Services: Stable Networking for Unstable Systems

Containers and pods are ephemeral means they are temporary.

They:

• restart
• move between machines
• receive new IP addresses

This creates networking problem. How can applications reliably communicate if workloads constantly change? Kubernetes solves this using Services.

A Service provides:

• stable networking identity
• traffic routing
• load balancing

Even if the underlying pods constantly change. This abstraction becomes essential in distributed systems.

So Far, Here’s the Flow

At this point, the deployment flow looks like this:

User submits deployment
        ↓
API Server receives request
        ↓
etcd stores cluster state
        ↓
Scheduler selects worker node
        ↓
kubelet receives instructions
        ↓
Container runtime starts container
        ↓
Application becomes live

This is the core Kubernetes workflow. Most Kubernetes architecture diagrams are simply expanding this flow in more detail.

What Happens When a Machine Dies?

Now let’s revisit the original problem. Suppose an entire worker node suddenly crashes.

Without orchestration:

• applications disappear
• traffic fails
• engineers intervene manually

With Kubernetes:

• node failure gets detected
• affected pods become unavailable
• controllers notice missing workloads
• scheduler selects healthy nodes
• kubelets launch replacements

The cluster automatically works toward restoring desired state. This is the operational power Kubernetes introduced.

Why Kubernetes Feels Complex

Kubernetes is solving one of the hardest problems in software engineering:

coordinating distributed systems automatically across many machines.

That naturally introduces complexity:

• scheduling
• networking
• service discovery
• storage coordination
• failure recovery
• distributed state management

The important thing to realize is that most Kubernetes abstractions are not random. They exist because distributed systems themselves are inherently difficult. Kubernetes is essentially packaging decades of infrastructure lessons into one orchestration platform.

The Bigger Picture

At this point, the evolution of modern infrastructure becomes much clearer:

Linux kernel isolation
    ↓
Containers
    ↓
Docker portability
    ↓
Distributed operational complexity
    ↓
Kubernetes orchestration
    ↓
Self-healing distributed infrastructure

Every layer emerged because the previous layer created new scaling challenges. That’s exactly how modern cloud-native infrastructure evolved historically.

The Mental Model to Keep

If the earlier articles taught:

Containers isolate applications Docker packages applications

Then this article should leave you with one final foundational idea:

Kubernetes continuously coordinates applications across many machines and keeps the system running even when failures happen.

That single idea explains:

• self-healing
• scheduling
• autoscaling
• orchestration
• deployments
• cluster coordination

Once you truly understand that…

The Kubernetes architecture stops feeling like random component names. And starts feeling like a giant distributed operating system built to keep modern applications alive.

If you enjoyed reading this article, you might be curious to know how we ended up here:

[embed]Containers From First Principles The clearest explanation of containers, Docker, and why modern infrastructure depends on themmedium.com

[embed]Docker From First Principles How isolated Linux processes became portable softwaremedium.com

[embed]Why Kubernetes Became Inevitable Containers solved deployment. They accidentally created a distributed systems explosion.medium.com

If you’re building data platforms, exploring analytics, or just love thinking about how data actually tells a story, feel free to follow or leave a clap 👏. It’s a small signal, but it helps me keep writing honest, example-driven content about data modelling, fact tables, dimensions, and the patterns that make analytics work.

Thanks for reading and for keeping curiosity alive ❤️.

Visit my site:

**Data Engineering Roadmap — Guru, Eerla | Data Engineering**

**Data Engineering Skills Guide — Guru, Eerla | Data Engineering**