Kubernetes Mental Model

When learning Kubernetes, connecting Containers, Pods, Nodes, Clusters, Deployments, Jobs, Services, ClusterIP, NodePort, and Gateway API can feel overwhelming.

Instead of one cluttered diagram, this guide breaks down their relationships into 3 simple, clean mental models:

1. The Physical Hierarchy: What contains what?
2. The Workload Controllers: Who creates and manages Pods?
3. The Traffic Pathway: How does internet traffic reach your application?

---

1. The High-Level Map

All Kubernetes concepts revolve around a single centerpiece: the Pod.

flowchart TD
    subgraph Traffic["1. Traffic Pathway (Outside-In)"]
        direction LR
        Client["🌐 Client"] --> GW["⚡ Gateway API / Ingress"]
        GW --> SVC["🎯 Service (ClusterIP)"]
    end

    subgraph Workloads["2. Workload Controllers"]
        direction LR
        DEP["🔄 Deployment (Long-running)"]
        JOB["⏱️ Job (Batch / Run to exit 0)"]
    end

    subgraph Compute["3. Compute Hierarchy"]
        direction LR
        POD["📦 Pods (with Containers)"]
        NODE["🖥️ Worker Nodes"]
        CLUSTER["☸️ Kubernetes Cluster"]
        POD --> NODE --> CLUSTER
    end

    SVC ==>|"Routes traffic to"| POD
    DEP ==>|"Manages replicas of"| POD
    JOB ==>|"Spawns & monitors"| POD

• Gateway API & Services direct traffic into the Pods.
• Deployments & Jobs manage the lifecycle of the Pods.
• Nodes & Clusters provide the physical compute where Pods run.

---

2. Dimension 1: The Compute Hierarchy

Think of Kubernetes compute infrastructure as a set of nested Russian dolls:

Container ⊂ Pod ⊂ Node ⊂ Cluster

flowchart LR
    C["🐳 Container<br/><i>Linux process + cgroups</i>"]
    P["📦 Pod<br/><i>Shared IP + localhost</i>"]
    N["🖥️ Node<br/><i>VM / Physical Host</i>"]
    K["☸️ Cluster<br/><i>Pooled compute fabric</i>"]

    C -->|"packaged inside"| P
    P -->|"scheduled onto"| N
    N -->|"joined into"| K

Why each layer exists:

Layer	What it is	Key Characteristic
🐳 Container	Isolated Linux process with its own filesystem layers and resource limits (cgroups).	Kubernetes never runs a container directly. It always wraps them in a Pod.
📦 Pod	The atomic unit of scheduling. Houses 1 or more tightly-coupled containers.	Containers in the same Pod share the same IP address, localhost networking, and storage volumes.
🖥️ Node	A single server or VM running kubelet, a container runtime (containerd), and kube-proxy.	Hosts multiple Pods. If a node crashes, all its Pods are rescheduled elsewhere.
☸️ Cluster	The entire pool of Nodes coordinated by the Control Plane (kube-apiserver, etcd, scheduler).	Aggregates all worker nodes into one unified compute surface.

How Pods Sit on Worker Nodes

In reality, Pods are distributed across nodes across the cluster:

flowchart TB
    subgraph Cluster["☸️ Kubernetes Cluster"]
        direction LR

        subgraph Node1["🖥️ Worker Node 1"]
            direction TB
            P1["📦 Web Pod (Replica 1)"]
            P2["📦 DB Migration Job Pod"]
        end

        subgraph Node2["🖥️ Worker Node 2"]
            direction TB
            P3["📦 Web Pod (Replica 2)"]
            P4["📦 Logging Daemon Pod"]
        end
    end

---

3. Dimension 2: Workload Controllers (Who Manages Pods?)

Pods are ephemeral—if a node reboots, the Pod dies. You almost never create bare Pods in production. Instead, you declare Controllers that manage Pods based on their lifecycle requirements.

flowchart LR
    subgraph Continuous["Long-Running Workloads (Never Stop)"]
        direction TB
        D["🔄 Deployment"] --> RS["⚙️ ReplicaSet"] --> P1["📦 Web / API Pods"]
    end

    subgraph Batch["Batch Tasks (Run to Exit 0)"]
        direction TB
        CJ["📅 CronJob"] --> J["⏱️ Job"] --> P2["📦 DB Migration Pod"]
    end

Deployments vs. Jobs

Feature	Deployment	Job
Primary Goal	Continuous Availability: Keep $N$ replicas running forever.	Run to Completion: Execute a task until it exits with code 0.
Typical Use Cases	Web servers, REST APIs, microservices.	Database schema migrations, batch image processing, data backups.
On Container Crash	Automatically restarts the container / replaces the Pod.	Retries failed executions up to backoffLimit, then marks Job failed.
On Successful Exit	Treats exit as a failure and restarts the container!	Marks the Pod as Completed and stops.
Scheduled Cousin	Horizontal Pod Autoscaler (HPA) scales by load.	CronJob triggers the Job on a time schedule (0 2 * * *).

---

4. Dimension 3: Networking & Service Types

Because Pods frequently restart and get new IP addresses, clients need a stable endpoint to talk to. That endpoint is a Service.

The “Russian Doll” of Service Types

Each Service type builds directly on top of the one below it:

ClusterIP ⊂ NodePort ⊂ LoadBalancer

flowchart TD
    subgraph LB["3. LoadBalancer (Cloud External IP)"]
        direction TB
        subgraph NP["2. NodePort (Port 30000-32767 on all Nodes)"]
            direction TB
            subgraph CIP["1. ClusterIP (Internal Virtual IP)"]
                direction TB
                Pods["🎯 Target Backend Pods"]
            end
        end
    end

Service Type	Scope	How It Works
1️⃣ ClusterIP (Default)	Internal Only	Assigns a stable virtual IP (10.96.x.x) accessible only within the cluster. Internal DNS (my-svc.default.svc.cluster.local) resolves to this IP.
2️⃣ NodePort	External (via Node IPs)	Builds on ClusterIP. Opens a dedicated port (30000-32767) on every node’s IP address. Traffic hitting NodeIP:NodePort forwards to ClusterIP $\rightarrow$ Pods.
3️⃣ LoadBalancer	External (Public IP)	Builds on NodePort. Calls your cloud provider (AWS/GCP/Azure) to spin up an external Load Balancer that forwards into the NodePort $\rightarrow$ ClusterIP $\rightarrow$ Pods.

---

5. Gateway API vs. Services: Why Layer 7 Routing?

If LoadBalancer gives us a public IP, why do we need Gateway API (or Ingress)?

• Cost: If you have 20 microservices, creating 20 LoadBalancer services provisions 20 cloud load balancers (costing $400+/month).
• Intelligence: Standard Services only understand IP addresses and ports (Layer 4). They cannot route based on hostnames (api.example.com), HTTP paths (/users vs /orders), headers, or manage SSL/TLS certificates.

Gateway API solves this by acting as a single, smart Layer 7 entry point at the edge of the cluster:

flowchart TD
    Client["🌐 External Users (HTTPS)"] --> GW["⚡ Gateway API (Single Public IP)<br/><i>Terminates TLS • Evaluates Host & Path</i>"]

    GW -->|"Host: app.example.com"| SvcWeb["🎯 Web Service (ClusterIP)"]
    GW -->|"Host: api.example.com/v1"| SvcAPI["🎯 API Service (ClusterIP)"]

    SvcWeb --> P1["📦 Web Pods"]
    SvcAPI --> P2["📦 API Pods"]

---

6. End-to-End: The Complete Request Journey

Here is how an incoming web request travels through every single layer down to your application container:

flowchart TD
    A["1️⃣ Client Browser requests https://api.example.com/checkout"] --> B
    B["2️⃣ DNS resolves api.example.com to Gateway API Public IP"] --> C
    C["3️⃣ Gateway API terminates TLS and matches path /checkout"] --> D
    D["4️⃣ Gateway forwards request to checkout-service (ClusterIP)"] --> E
    E["5️⃣ kube-proxy / eBPF load-balances packet to a healthy Pod IP"] --> F
    F["6️⃣ Worker Node CNI routes packet into Pod network namespace"] --> G
    G["7️⃣ Container process handles request & returns HTTP 200 OK"]

---

7. Quick Reference: The Mental Model Matrix

Concept	Layer / Domain	Core Purpose	Managed By
Container	Compute Runtime	Packages application code, dependencies, and filesystem.	Container Runtime (containerd)
Pod	Compute Unit	Atomic schedulable unit; co-locates containers on shared IP.	Workload Controllers
Node	Physical / VM Host	Runs the worker software (kubelet, kube-proxy, runtime).	Cluster Administrator
Cluster	Orchestration Fabric	The pooled collection of all nodes and control plane services.	Kubernetes API
Deployment	Workload Controller	Ensures long-running stateless Pods are always running.	Kubernetes Controller Manager
Job	Workload Controller	Runs batch/finite tasks to completion (exit code 0).	Kubernetes Controller Manager
ClusterIP	L4 Networking	Stable internal virtual IP load balancing to Pods.	Service Controller & kube-proxy
NodePort	L4 Networking	Opens high port (30000-32767) on all node physical IPs.	Service Controller & kube-proxy
Gateway API	L7 Routing & Ingress	Domain, path, header routing, and TLS termination at edge.	Gateway Controller (Envoy, Cilium, etc.)