How do Linux and virtualization concepts map to Kubernetes?

Instead of learning "what a Pod is," you should learn "how namespaces and cgroups allow a Pod to exist." This guide maps existing infrastructure knowledge of Linux daemons, hypervisors, switching, and storage arrays—directly to Kubernetes primitives.

---

Phase 1: Mapping the Mental Model (Architecture)

In Linux, we are used to Imperative commands: "Run this script," "Restart this service," "Mount this disk." Kubernetes is Declarative: We define "What the end result should look like" (YAML), and a robot (Controller) does the work to make it happen.

1. The Control Plane vs. The OS Kernel

• The Brain (/proc): Understand how the API Server acts as the entry point (like a kernel system call interface) and how etcd acts as the state store (like /proc or a registry on steroids).
• The Scheduler (DRS): Study the kube-scheduler. Compare it to a hypervisor scheduler (DRS/vMotion). It filters (predicates) and scores (priorities) nodes to place workloads.
• The Controller Manager (systemd): Understand the control loop pattern. It’s like a system daemon (e.g., systemd or init) that constantly checks "current state" vs "desired state". If a process crashes under systemd, systemd restarts it automatically.

2. The Node (The Hypervisor/Worker)

• The Kubelet: This is the primary "agent" on the node. It registers the node, sends heartbeats, and manages the Pod lifecycle. Think of it as the local hypervisor agent.
• CRI (Container Runtime Interface): You've used Docker, but Kubernetes abstracts this via CRI. Learn how containerd or CRI-O interacts with the kernel to spawn containers.
• Cgroups & Namespaces: Since you know Linux, dive into how resources are limited. Study Cgroups Architecture and how the kubelet manages resources under systemd slices to prevent noisy neighbors.

---

Phase 2: Storage

Leverage your storage background to understand persistence, which is often the hardest part for pure developers.

3. The Volume Abstraction

• PersistentVolume (PV): Mapping to the physical/virtual storage device (iSCSI LUN, NFS export, EBS volume).
• PersistentVolumeClaim (PVC): The "ticket" a user presents to request storage.
• StorageClass: The policy engine. How "Gold/Silver/Bronze" storage tiers are defined and how dynamic provisioning works.

4. CSI (Container Storage Interface)

Understand how CSI drivers replaced in-tree volume plugins. This is how storage vendors (NetApp, Dell, cloud providers) integrate their arrays into K8s without touching the K8s source code. You can learn the exact flow in our CSI Architecture Guide.

---

Phase 3: Networking & Services (Virtual Switching)

Map this to your networking knowledge (IPTables, Load Balancers, VLANs).

5. The Flat Network Model

• Pod-to-Pod: Every Pod gets an IP. No NAT between Pods. It’s like a flat L3 network.
• CNI (Container Network Interface): How Linux Networking Primitives and plugins (Calico, Flannel, Cilium) wire up the virtual ethernet pairs (veth) and handle IPAM (IP Address Management).

6. Service Discovery & Load Balancing

• Services: Understand how ClusterIP gives a stable VIP (Virtual IP) to a set of churning Pods.
• kube-proxy: The component on every node that programs the Linux kernel (using iptables or IPVS) to intercept traffic to that VIP and route it to a random backend Pod.
• DNS: How CoreDNS maps Service names to IPs, enabling internal service discovery.

---

Phase 4: Advanced Scheduling & Resource Management

Think of virtualization resource pools, and the following concepts will click instantly.

7. Resource QoS (Quality of Service)

• Requests vs. Limits: How cpu.shares (requests) and cfs_quota (limits) are applied.
• QoS Classes: Learn the difference between Guaranteed (Requests=Limits), Burstable, and BestEffort, and how this dictates eviction order during Node Memory starvation.

---

Summary: "Teaching Kubernetes New Words"

Out of the box, Kubernetes knows standard words like Pod, Service, and Deployment. A CRD allows you to teach Kubernetes a new word (a new kind of object).

• The Data: When you create a CRD, you are simply defining a new database schema. You are telling the API Server: "Please allow users to store YAML files where kind: Database."
• The Operator: To make a CRD useful, you pair it with a Custom Controller. This pattern (CRD + Custom Controller) is often called an Operator.

Linux Analogy: Imagine you installed a new piece of software, like Postfix.

• CRD: This is like adding the new config schema in /etc/postfix/main.cf. The system now recognizes these new configuration options.
• Custom Controller: This is the postfix daemon binary itself. It reads that new config and actually sends the emails based on the "Desired State" in the config file.