Why Mastering It Gives You 80% of Kubernetes** If you can understand the **Control Plane**, you can understand **80% of Kubernetes**. Strip away the endless YAML, CRDs, cloud-provider integrations, and ecosystem tools — at its core, Kubernetes is a beautifully simple system built on a few powerful concepts: **desired state**, **continuous reconciliation**, and **declarative infrastructure**. Once you see how the Control Plane works, the entire architecture becomes clear. ![[Pasted image 20251119125043.png]] --- ## **The Big Picture: Two Halves of a Kubernetes Cluster** Every Kubernetes cluster is divided into two logical components: ### **1. The Control Plane** Responsible for _thinking, decisions, and maintaining the desired state_. ### **2. The Worker Nodes** Responsible for _running containers_. This separation is intentional: Kubernetes is an **orchestrator**, not a container engine. Your nodes run workloads; the Control Plane ensures the cluster behaves exactly as declared. --- # **The Control Plane: The Brain of Kubernetes** The Control Plane handles all cluster-wide decisions, including: - Scheduling Pods - Watching for failures - Enforcing desired state - Providing the Kubernetes API - Reconciliation loops that constantly correct drift Let’s break down each Control Plane component. --- ## **API Server — The Front Door of Kubernetes** The **kube-apiserver** is the beating heart of the entire system. Everything—kubectl commands, controllers, operators, schedulers—talks to Kubernetes _exclusively_ through the API Server. It is responsible for: - Validating and processing API requests - Persisting cluster state (via etcd) - Serving as the communication hub for all internal components If you understand the API Server workflow, you understand Kubernetes itself. --- ## **etcd — The Source of Truth** **etcd** is a distributed, reliable, and highly available key-value store. It stores: - Deployments - ConfigMaps - Node information - Secrets - Cluster configuration - Desired and current state for every object In short: **everything in Kubernetes lives in etcd** — directly or indirectly. This is why etcd backups are essential for disaster recovery. --- ## **Scheduler — Where Workloads Are Assigned** The **kube-scheduler** continuously scans for Pods that don’t have an assigned node. It chooses nodes based on: - Resource availability (CPU, memory) - Taints & tolerations - Node affinity / pod affinity - Storage requirements - Custom scheduling policies This is one of the most elegant parts of Kubernetes: scheduling is decoupled from running. --- ## **Controller Managers — The Continuous Reconciliation Engine** Controllers are what make Kubernetes **self-healing**. The **kube-controller-manager** contains multiple control loops: - **Node Controller** – reacts when nodes go offline - **Job Controller** – manages job completions - **Replication Controller** – ensures correct replica counts - **Service Account Controller** – manages service account tokens - **Endpoint Controller** – manages service endpoints There is also a **cloud-controller-manager** when using AWS, GCP, Azure, etc. Together, these controllers watch the world and try to make it match your declarative configuration. --- # **Worker Nodes: Where Your Containers Live** Worker nodes do not make decisions. They simply execute what the Control Plane instructs. Each node contains three critical components. --- ## **1. Kubelet — The Enforcer** The **kubelet** is a node-level agent that: - Watches for PodSpecs assigned to its node - Ensures containers are running - Restarts them when needed - Reports status back to the API Server If the kubelet disappears, the node effectively becomes invisible to the cluster. --- ## **2. kube-proxy — The Networking Layer** kube-proxy manages: - iptables or IPVS rules - Service load-balancing - Pod-to-Service traffic routing In modern clusters, CNI plugins supplement or replace parts of kube-proxy functionality. --- ## **3. Container Runtime — The Engine That Runs Containers** Kubernetes no longer talks to Docker directly. Instead, it uses the **Container Runtime Interface (CRI)**. Common runtimes: - **containerd** (default in most clusters) - **CRI-O** (popular in OpenShift) - **Docker Engine** (deprecated but still viable via shim layers) These runtimes pull images, start containers, manage namespaces, and handle low-level execution. --- # **Add-Ons: Optional but Essential for Real Clusters** Most clusters include built-in add-ons that extend functionality: - **CoreDNS** – internal DNS resolution - **Metrics Server** – resource monitoring - **Dashboard** – web UI (less common in production) - **Ingress Controllers** - **CNI Plugins** (Calico, Weave, Cilium) These are not strictly part of the Control Plane — but without them, Kubernetes would feel incomplete. --- # **Deployment Models: Same Concepts, Different Packaging** Regardless of where Kubernetes runs, the architecture stays the same. ### **1. systemd services** Bare-metal or VM-based clusters often use systemd to manage kubelet, API server, etc. ### **2. Static Pods** Control-plane components can be started as static pods in `/etc/kubernetes/manifests`. ### **3. Managed Control Planes** Cloud providers (EKS, GKE, AKS) hide the control plane entirely, but the architecture is identical. The **principles never change**: - Declarative intent - Automated reconciliation - Consistent state management - Reliable workload placement This is the foundation of Kubernetes. --- # **Why Understanding the Control Plane = Understanding Kubernetes** Kubernetes is not complicated once you recognize that: ✔ Everything flows through the API Server ✔ etcd stores the entire truth ✔ Controllers continuously enforce your desired state ✔ Scheduler assigns pods to nodes ✔ Kubelet executes instructions locally ✔ Runtime launches the containers When you master these components, the rest of Kubernetes — Operators, CRDs, Helm, GitOps, service meshes — becomes much easier to understand. --- ## 1. Control Loops — Desired vs Actual State (Reconciliation) ```mermaid flowchart LR User[User / GitOps / CI Pipeline] -->|Apply YAML<br/>kubectl/apply| APISrv[kube-apiserver] APISrv -->|Persist desired state| ETCD[(etcd<br/>Desired Cluster State)] subgraph Controllers[Controller Managers] RC[ReplicaSet / Deployment Controller] NC[Node Controller] JC[Job Controller] SCC[Service / Endpoint Controller] CCC[Cloud Controller] end %% Controllers watch the API RC <-->|Watch API / List+Watch| APISrv NC <-->|Watch API / Heartbeats| APISrv JC <-->|Watch API| APISrv SCC <-->|Watch API| APISrv CCC <-->|Cloud events| APISrv %% Control loop concept RC -->|Detect drift:<br/>Replicas missing / extra| Diff[Compare Desired vs Actual] Diff -->|Create / Delete Pods| APISrv APISrv -->|Update state| ETCD APISrv -->|New PodSpecs| Kubelet[kubelet on nodes] Kubelet -->|Start / Restart containers| Runtime[Container Runtime] Runtime --> Pods[Running Pods] Pods -->|Status / Health| Kubelet --> APISrv --> ETCD ``` This diagram visually explains the **“self-healing / reconciliation”** part of your article. --- ## 2. Scheduling Flow — From Pending Pod to Running Pod ```mermaid sequenceDiagram participant Dev as Developer / CI participant API as kube-apiserver participant ETCD as etcd participant Sched as kube-scheduler participant Kubelet as kubelet (Node) participant RT as Container Runtime participant Pod as Pod / Containers Dev->>API: kubectl apply -f deployment.yaml API->>ETCD: Store PodSpec (phase: Pending) API-->>Sched: Notify: Unscheduled Pod detected Sched->>API: List / Watch Pending Pods Sched->>Sched: Score nodes<br/> (CPU, memory, taints, affinity) Sched->>API: Bind Pod to selected Node API->>ETCD: Update PodSpec with assigned Node API-->>Kubelet: New Pod assigned to your node Kubelet->>RT: Create containers from PodSpec RT-->>Pod: Start containers Pod-->>Kubelet: Status / readiness / liveness Kubelet-->>API: Pod status: Running API->>ETCD: Update Pod state Dev-->>API: kubectl get pods API-->>Dev: Pod status: Running ``` This fits perfectly into your section describing the **Scheduler + kubelet + runtime** interaction. ---