1.2 Kubernetes Control Plane & Worker Node Components

1.2 Kubernetes Control Plane & Worker Node Components

Kubernetes is a distributed, declarative orchestrator designed to maintain the desired state of containerized workloads across a cluster of compute instances. The architecture is strictly decoupled into two functional planes:

1. The Control Plane (Master Tier): Responsible for global cluster decision-making, event detection, workload scheduling, and maintaining cluster state consistency.
2. The Worker Node Plane (Data Tier): Responsible for running application container runtimes, executing network packet forwarding, and providing host-level compute/storage resources.

Understanding how each subsystem functions, where its configuration resides, and how components communicate is fundamental to diagnosing cluster failures on the CKA exam.

---

1. Control Plane Architecture & Component Deep Dive

+---------------------------------------------------------------------------------------+
|                                 CONTROL PLANE (MASTER)                                |
|                                                                                       |
|   +-------------------------------------------------------------------------------+   |
|   |                                KUBE-APISERVER                                 |   |
|   |  - Authentication (Certificates, Webhooks, ServiceAccounts)                   |   |
|   |  - Authorization (RBAC, Node, ABAC, Webhook)                                  |   |
|   |  - Admission Controllers (MutatingWebhook, ValidatingWebhook, ResourceQuota)  |   |
|   +-------------------------------------------------------------------------------+   |
|          ^                                    ^                        ^      |       |
|          |                                    |                        |      v       |
|          v                                    v                        |   +------+   |
|   +---------------+                   +-----------------+              |   | ETCD |   |
|   | KUBE-SCHEDULER|                   | KUBE-CONTROLLER-|              |   |  DB  |   |
|   | (Filter/Score)|                   |     MANAGER     |              |   +------+   |
|   +---------------+                   +-----------------+              |              |
+------------------------------------------------------------------------|--------------+
                                                                         | (HTTPS 6443) 
+------------------------------------------------------------------------|--------------+
|   WORKER NODE                                                          v              |
|   +-------------------------------------------------------------------------------+   |
|   |                                    KUBELET                                    |   |
|   |  - Static Pod Watcher (/etc/kubernetes/manifests)                             |   |
|   |  - CRI (gRPC -> containerd.sock) | CNI (/etc/cni/net.d) | CSI (Storage Plugins)|  |
|   +-------------------------------------------------------------------------------+   |
|          |                                          |                                 |
|          v                                          v                                 |
|   +--------------+                          +--------------+                          |
|   |  KUBE-PROXY  |                          |  CONTAINERD  |                          |
|   | (iptables/   |                          | (Application |                          |
|   |   IPVS)      |                          |     Pods)    |                          |
|   +--------------+                          +--------------+                          |
+---------------------------------------------------------------------------------------+

1. kube-apiserver (The Central Nervous System)

The API server is the stateless REST gateway for all administrative interactions and internal component communication. It is the only component that directly reads from and writes to etcd.

Request Processing Pipeline:

1. Authentication: Establishes client identity via X.509 Client Certificates, Bearer Tokens, OpenID Connect (OIDC), or Webhook tokens.
2. Authorization: Verifies permissions against configured authorization engines, primarily RBAC (Role-Based Access Control) and the Node Authorizer.
3. Mutating Admission Controllers: Intercepts requests to inject defaults or modify schemas (e.g., injecting sidecars, setting default StorageClasses).
4. Object Schema Validation: Enforces strict structural compliance with Kubernetes API resource schemas.
5. Validating Admission Controllers: Enforces cluster security baselines or business rules (e.g., checking if image registries are allowed, enforcing Pod Security Standards).
6. Storage: Serializes and commits the object to etcd.

2. kube-scheduler (Workload Placement Engine)

The scheduler monitors the API server for newly created pods that lack a .spec.nodeName assignment and identifies the optimal node for execution through a two-phase process:

• Phase 1: Filtering (Predicates): Evaluates whether a candidate node meets hard constraints (e.g., NodeResourcesFit, NodePorts, NodeName, NodeAffinity, and TaintToleration). Nodes failing any predicate are dropped.
• Phase 2: Scoring (Priorities): Ranks surviving candidate nodes on a 0–100 scale across weighting algorithms (e.g., NodeResourcesFit, ImageLocality, and InterPodAffinity). The pod is bound to the node with the highest aggregate score.

3. kube-controller-manager (Declarative State Reconciliation Loops)

The controller manager compiles numerous continuous control loops into a single binary. Each controller runs an infinite control loop comparing the observed cluster state against the desired state recorded in etcd:

• Node Lifecycle Controller: Monitors node heartbeats (via NodeLease objects in kube-node-lease). With the current default node-monitor grace period, marks a node NotReady after 50 seconds without status updates. The controller applies the not-ready or unreachable NoExecute taint; ordinary Pods have default 300-second tolerations before eviction begins.
• ReplicaSet / Deployment Controller: Ensures the exact number of desired pod replicas exist.
• EndpointSlice / Endpoints Controller: Populates IP endpoints for Kubernetes Service objects.
• ServiceAccount Controller: Creates the default ServiceAccount in each namespace. Modern short-lived Pod credentials are projected by kubelet through the TokenRequest API; they are not automatically created as long-lived token Secrets.

4. cloud-controller-manager

Decouples cloud-vendor-specific logic (e.g., provisioning AWS ELBs, Google Cloud routes, Azure managed disks) from core Kubernetes codebase.

---

2. Worker Node Components & Runtime Stack

1. kubelet (The Node Agent)

The kubelet is the primary node agent running as a standard host systemd daemon (systemctl status kubelet). It does not run as a containerized pod.

• Responsibilities:
  • Communicates upstream with kube-apiserver to report node status, capacity, and receive pod assignments.
  • Interacts with the local container runtime via the Container Runtime Interface (CRI) over a UNIX domain gRPC socket (/run/containerd/containerd.sock).
  • Invokes Container Network Interface (CNI) binary plugins located in /opt/cni/bin with configurations from /etc/cni/net.d to allocate pod IP addresses and configure virtual ethernet (veth) pairs.
  • Mounts volumes via the Container Storage Interface (CSI).
  • Performs local liveness, readiness, and startup probe executions.

2. kube-proxy (Network Proxy & Forwarding Engine)

Runs on every node (usually deployed as a DaemonSet in kube-system). It watches the API server for Service and EndpointSlice additions, modifications, and deletions, programming local Linux kernel packet filtering engines:

• iptables Mode (Default): Writes deterministic Netfilter PREROUTING and KUBE-SERVICES chains to perform DNAT (Destination Network Address Translation) on service VIPs, distributing traffic randomly across backend Pod IPs.
• nftables Mode (Stable in v1.33+): Uses the nftables API with efficient rule updates and is the recommended replacement for iptables in sufficiently new kernels. IPVS mode is deprecated in v1.35; do not design new clusters around it.

3. Container Runtime (CRI)

Modern Kubernetes utilizes CRI-compliant runtimes like containerd or CRI-O. Runtimes manage container images, root filesystems, Linux namespaces (net, pid, ipc, mnt, uts), and cgroups (CPU/Memory resource isolation).

# Inspecting runtime state using crictl (configured for containerd):
crictl pods
crictl ps
crictl logs <container-id>

---

3. Static Pods vs. DaemonSets

A critical topic on the CKA exam is the distinction between Static Pods and DaemonSets.

[!NOTE] Static Pod Configuration: The static pod manifest directory is defined in /var/lib/kubelet/config.yaml under the field staticPodPath: /etc/kubernetes/manifests. When any valid .yaml file is placed in this directory, kubelet immediately spawns the container. If the file is deleted or modified, kubelet deletes or restarts the container.

---

4. Cluster Add-ons: CoreDNS & Networking

• CoreDNS: Runs as a standard Kubernetes Deployment (commonly multiple replicas) in kube-system, exposed by a ClusterIP service (typically 10.96.0.10). It resolves internal DNS queries conforming to the format <service-name>.<namespace>.svc.cluster.local.
• Network Add-on (CNI Plugin): Kubernetes requires an external CNI plugin (e.g., Calico, Flannel, Cilium) to implement the flat pod-to-pod networking model where every pod receives a unique, routable IP without NAT.