2.1 Kubernetes Architecture & Control Plane Components

2.1 Kubernetes Architecture & Control Plane Components

Kubernetes follows a control-plane/worker architecture designed to automate container deployment, scaling, and operational management. The system is split into two primary operational tiers: the Control Plane (traditionally referred to as the master node) and Worker Nodes. The Control Plane makes global cluster decisions, responds to cluster events, and ensures the actual runtime state constantly matches the desired state specified by administrators.

+-----------------------------------------------------------------------+
|                         KUBERNETES CONTROL PLANE                      |
|                                                                       |
|  +-------------------+      +------------------+     +-------------+  |
|  |  kube-scheduler   |      | kube-controller- |     |    cloud-   |  |
|  |                   |      |     manager      |     | controller- |  |
|  +---------+---------+      +--------+---------+     |   manager   |  |
|            |                         |               +------+------+  |
|            +------------+            |                      |         |
|                         v            v                      v         |
|                   +------------------------------------+              |
|                   |          kube-apiserver            |              |
|                   |  (REST API, AuthN/AuthZ, Admission) |              |
|                   +------------------+-----------------+              |
|                                      |                                |
|                                      v                                |
|                           +---------------------+                     |
|                           |        etcd         |                     |
|                           | (Key-Value Store)   |                     |
|                           +---------------------+                     |
+--------------------------------------|--------------------------------+
                                       | HTTPS (Watch / API)
                                       v
+-----------------------------------------------------------------------+
|                             WORKER NODES                              |
|   +--------------------------+      +--------------------------+      |
|   |         Kubelet          |      |        kube-proxy        |      |
|   +--------------------------+      +--------------------------+      |
+-----------------------------------------------------------------------+

---

1. kube-apiserver (API Server)

The kube-apiserver is the central management gateway and communication spine of a Kubernetes cluster. It exposes the Kubernetes REST API to external clients (such as kubectl, CI/CD pipelines, and web dashboards) as well as internal cluster components.

Core Responsibilities

• Authentication & Authorization: Validates client identity (AuthN) via TLS certificates, bearer tokens, or OIDC providers, followed by checking access permissions (AuthZ) using Role-Based Access Control (RBAC).
• Admission Control: Intercepts requests after authorization but before object persistence. Admission plugins run in sequence: Mutating Admission Webhooks (modifying requests, e.g., injecting sidecars) followed by Validating Admission Webhooks (enforcing security and schema constraints).
• Schema Enforcement & Serialization: Validates incoming JSON/YAML object schemas against Kubernetes API spec definitions.
• Sole etcd Interface: The API server is the only component in the entire architecture permitted to read from or write to etcd directly. All other components must issue RESTful calls to kube-apiserver.

High Availability & Scaling

The kube-apiserver is entirely stateless. Multiple instances of kube-apiserver can be deployed concurrently behind an active-active network load balancer (e.g., HAProxy or AWS NLB) to provide high availability and scale horizontal throughput.

---

2. etcd (Distributed Key-Value Store)

etcd is a strongly consistent, distributed key-value store developed by CoreOS (now a CNCF graduated project). It serves as the single source of truth for all Kubernetes cluster state, configuration settings, secrets, and metadata.

Consensus Protocol & Quorum

etcd implements the Raft consensus algorithm to ensure data consistency across distributed instances. Raft requires a strict majority quorum to validate write operations and elect a cluster leader. Quorum is calculated using the formula:

quorum = floor(N / 2) + 1

Where N is the total number of etcd members in the cluster:

• 3-node cluster: Quorum is 2. The cluster tolerates 1 node failure.
• 5-node cluster: Quorum is 3. The cluster tolerates 2 node failures.
• 7-node cluster: Quorum is 4. The cluster tolerates 3 node failures.

Important: etcd clusters should always contain an odd number of members (3, 5, or 7). Growing from 3 members to 4 raises the quorum from 2 to 3 while fault tolerance stays at exactly one failure — the extra member buys write latency and cost, not resilience. The same holds at every even size: a 6-member cluster needs a quorum of 4 and still tolerates only 2 failures, identical to a 5-member cluster.

Backup, Restore, and Maintenance

Because etcd stores all cluster state, disaster recovery strategies rely on periodic snapshot backups created via etcdctl:

# Save a snapshot of the etcd database
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /tmp/etcd-backup.db

To prevent performance degradation over time, administrators execute periodic database compaction (reclaiming space from old key revisions) and defragmentation.

---

3. kube-scheduler (Kube Scheduler)

The kube-scheduler is the control plane component responsible for assigning newly created Pods that lack a designated nodeName to the most appropriate worker node in the cluster.

Scheduling Cycle Workflow

The scheduler operates through a two-phase workflow for every pending Pod:

1. Filtering Phase (Predicates): Evaluates nodes to filter out those that do not satisfy the Pod's hardware or operational requirements. Key predicate checks include:
   • PodFitsResources: Verifies if a node has sufficient allocatable CPU and memory.
   • NodeName: Checks if the Pod explicitly targets a specific host.
   • NodePorts: Ensures requested host ports are not already bound.
   • Taints and Tolerations: Excludes nodes with taints that the Pod cannot tolerate.
2. Scoring Phase (Priorities): Ranks the remaining candidate nodes on a scale from 0 to 100 based on weighting algorithms. Key scoring rules include:
   • NodeResourcesBalancedAllocation: Favors nodes with balanced CPU and memory resource utilization.
   • ImageLocality: Favors nodes that already have the Pod's container images cached locally.
   • NodeAffinity & PodAffinity/AntiAffinity: Grants higher scores to nodes matching preferred affinity rules.

Once the node with the highest score is identified, the scheduler creates a Binding object, issuing an API call to kube-apiserver to update the Pod's spec.nodeName field.

---

4. kube-controller-manager (Controller Manager)

The kube-controller-manager is a single binary that embeds multiple distinct control loops (controllers) running within a shared execution process.

The Reconciliation Loop Pattern

Each controller continuously executes a reconciliation loop based on three steps:

1. Observe: Query current cluster state from kube-apiserver using HTTP Watch streams.
2. Compare: Compare actual observed state against desired state specified in object manifests.
3. Act: Issue API requests to correct any drift between actual state and desired state.

Key Embedded Controllers

In high-availability setups, multiple kube-controller-manager instances run across control plane nodes, using leader election so that only one active leader performs reconciliation while others remain in standby mode.

---

5. cloud-controller-manager (CCM)

The cloud-controller-manager decouples cloud-provider-specific logic from the core Kubernetes codebase. Prior to CCM, control plane components contained vendor-specific code for AWS, GCP, and Azure. CCM allows cloud vendors to develop out-of-tree plugins independently.

Key CCM Controllers

• Node Controller: Interrogates cloud provider APIs to verify if a node instance has been terminated in the cloud when it becomes unresponsive.
• Route Controller: Configures network routing infrastructure within the underlying cloud Virtual Private Cloud (VPC).
• Service Controller: Communicates with cloud provider APIs to provision external cloud load balancers (e.g., AWS ELB/NLB, GCP Load Balancer) when a Kubernetes Service of type: LoadBalancer is created.

---

Control Plane Components Summary