# Kubernetes Control Plane Components Explained

*Originally published at [GeekCoding101](https://geekcoding101.com/posts/kubernetes-control-plane-components).*

# Intro: So… What Powers the Kubernetes Brain?

Everyone loves to show off their YAML-fu and talk about Pods and Deployments, but what’s actually _running_ behind the scenes? What's keeping track of all your services, secrets, and scheduled chaos? Today I'd like to bring your a quick introduction about the **Kubernetes control plane components**—the brains of the operation. It’s made of several server-side components that work together like an orchestra of background daemons with trust issues and strict roles.

In this post, we’ll demystify **each core server** running in a Kubernetes control plane:  
✅ `etcd`  
✅ `kube-apiserver`  
✅ `kube-scheduler`  
✅ `kube-controller-manager`  
✅ `cloud-controller-manager`  
✅ `kubelet`  
✅ `kube-proxy`  
✅ `coredns`  
✅ Optional players (metrics-server, CRI, CSI, etc.)

Let’s start with the foundation: how these pieces talk.

* * *

# 🧩 Kubernetes Architecture in a Nutshell

Kubernetes has two main types of nodes:

- **Control Plane Nodes** (aka “masters”): run the brain (scheduler, API, etc.)
    
- **Worker Nodes**: run your actual workloads (pods)
    

> Think of the control plane as **mission control** and the worker nodes as **spacecraft**. One issues orders, the other executes.

They talk over HTTP/gRPC and communicate securely via TLS.

Now let’s break down the core components—what they are, what they do, and how they fit together.

![Kubernetes Control Plane Components ascii art diagram](https://geekcoding101.com/_astro/ascii-art-diagram.C8eS_lMK_hvVDH.webp "Kubernetes Control Plane Components ascii art diagram")

* * *

## 🔐 1. Kubernetes Control Plane Components - etcd

**What it is:**  
A distributed key-value store used to store _all_ cluster data: objects, state, configs.

**Think of it as:**  
The **brain’s hard disk**.

**What lives inside etcd?**

- Pod definitions
    
- ConfigMaps
    
- Secrets
    
- Cluster state
    
- Node info
    
- RoleBindings, CRDs, everything
    

**Backed by:**  
[etcd](https://etcd.io/) (from CoreOS), written in Go, uses the Raft consensus algorithm for HA and consistency.

**Why it matters:**  
You _never_ talk to etcd directly. The **API server** does only.

* * *

## 🧭 2. Kubernetes Control Plane Components - kube-apiserver

**What it is:**  
The main RESTful API that all clients (kubectl, controllers, kubelet) talk to.

**Think of it as:**  
The **gatekeeper** and **translator**.

**Responsibilities:**

- Validates incoming requests
    
- Authenticates + authorizes them
    
- Talks to etcd to read/write state
    
- Notifies other components via the Watch API
    

**It’s stateless**, and often run behind a load balancer for HA.

* * *

## ⏱ 3. Kubernetes Control Plane Components - kube-scheduler

**What it is:**  
Assigns unscheduled pods to nodes, based on constraints.

**Think of it as:**  
The **Tinder for workloads**. It matches pods to nodes based on:

- CPU/memory availability
    
- Node taints/tolerations
    
- Affinity rules
    
- Pod priority
    
- Custom scoring plugins
    

**The flow:**

1. A pod is created with no `nodeName`.
    
2. API server stores it in etcd.
    
3. Scheduler sees it, scores possible nodes.
    
4. It picks a winner and updates the pod with `nodeName`.
    

* * *

## 🧙 4. Kubernetes Control Plane Components - kube-controller-manager

**What it is:**  
A daemon that runs **many controllers** in one binary.

**Think of it as:**  
The **cluster babysitter**—constantly checking for drift and correcting it.

**Runs controllers for:**

- Deployments
    
- Replicasets
    
- Nodes (watching for crashes)
    
- Endpoints
    
- Persistent Volumes
    
- Certificates
    

**How it works:**  
Each controller watches a specific object type via the API server and ensures the desired state matches reality. If not, it acts.

* * *

## ☁️ 5. Kubernetes Control Plane Components - cloud-controller-manager

**What it is:**  
An optional component for clusters running on public clouds (AWS, GCP, Azure).

**Think of it as:**  
The **bridge between Kubernetes and your cloud infrastructure**.

**Responsibilities:**

- Creating LoadBalancers
    
- Managing cloud-based node info
    
- Attaching volumes (via CSI)
    
- Updating routes
    

You won’t see this in bare-metal clusters unless you set up external integrations manually.

* * *

## Beyond the Control Plane: Node Components and Add-ons

Strictly speaking, the control plane is the five components above: etcd, kube-apiserver, kube-scheduler, kube-controller-manager and cloud-controller-manager. The next three run on **every node** (kubelet, kube-proxy) or as a **cluster add-on** (CoreDNS). They are not part of the control plane, but you can't understand how the control plane's decisions turn into running pods without them, so they get their own sections here.

## 🧍 6. Node Component - kubelet

**What it is:**  
A daemon that runs on _every_ worker node.

**Think of it as:**  
The **node’s supervisor**.

**What it does:**

- Watches for pods assigned to its node
    
- Pulls container images via the CRI
    
- Starts/stops containers using container runtimes (containerd, CRI-O)
    
- Sends status updates back to API server
    

**Important:**  
kubelet does _not_ manage containers you started outside of Kubernetes.

* * *

## 🌐 7. Node Component - kube-proxy

**What it is:**  
Runs on each node to implement **service networking**.

**Think of it as:**  
A **port-forwarding ninja** that handles cluster IP routing rules.

**Modes:**

- iptables (legacy, still common)
    
- ipvs (newer, faster, uses Linux’s IPVS)
    
- eBPF (if you’re fancy and using Cilium)
    

**What it does:**

- Maintains network rules to forward traffic to the correct pod behind a Service
    
- Enables internal DNS (via CoreDNS)
    
- Helps implement ClusterIP, NodePort, LoadBalancer behavior
    

* * *

## 🧠 8. Cluster Add-on - CoreDNS

**What it is:**  
Default DNS service in Kubernetes.

**Think of it as:**  
Your cluster’s internal **phone book**.

**What it does:**

- Resolves pod/service names to cluster IPs
    
- Works with kube-dns-compatible tools
    
- Responds to all `*.svc.cluster.local` domain lookups
    

**Runs as a Deployment + Service**, just like any other app—because Kubernetes eats its own dog food.

* * *

## 🛠 Supporting Components

| Component | Role |
| --- | --- |
| **metrics-server** | Collects CPU/mem stats for autoscaling (HPA) |
| **CRI runtimes** (containerd, CRI-O) | Interface between kubelet and container engines |
| **CSI drivers** | Handle volume mounting for storage backends |
| **CNI plugins** | Provide networking (Calico, Flannel, Cilium, etc.) |
| **Admission controllers** | API gatekeepers that enforce rules (e.g., resource limits, policies) |
| **API Aggregation layer** | Supports extending the Kubernetes API (like metrics.k8s.io) |

* * *

# 📦 Kubernetes Control Plane Components Diagram

```
+--------------------------------------------------+
|                  Control Plane                   |
| +-----------------+      +--------------------+  |
| | kube-apiserver  | <--> |  etcd              |  |
| +-----------------+      +--------------------+  |
|        ^                                         |
|        |                                         |
| +----------------------------+                   |
| |  kube-controller-manager   |                   |
| +----------------------------+                   |
| +----------------------------+                   |
| |       kube-scheduler       |                   |
| +----------------------------+                   |
| +----------------------------+                   |
| | cloud-controller-manager   |                   |
| |       (optional)           |                   |
| +----------------------------+                   |
+--------------------------------------------------+

+-------------------------------------------------+
|                Worker Node                      |
| +---------+  +-----------+  +-----------------+ |
| | kubelet |  | kube-proxy|  | containerd/CRI  | |
| +---------+  +-----------+  +-----------------+ |
| +---------------------------------------------+ |
| |                Pods (your app)              | |
| +---------------------------------------------+ |
+-------------------------------------------------+

```

I really like this simplifed diagram!

* * *

## 🧠 A Quick Reference

| Component | Where it runs | Purpose |
| --- | --- | --- |
| `etcd` | Control plane | Key-value store (source of truth) |
| `kube-apiserver` | Control plane | Cluster API gateway |
| `kube-scheduler` | Control plane | Assigns pods to nodes |
| `kube-controller-manager` | Control plane | Maintains cluster state |
| `cloud-controller-manager` | Control plane (cloud clusters only) | Connects to cloud provider |
| `kubelet` | Every node | Manages node and runs pods |
| `kube-proxy` | Every node | Handles Service networking and routing |
| `CoreDNS` | Add-on (pods in `kube-system`) | Resolves internal service names |

## How Many Control Plane Nodes Do You Need?

For a lab, one control plane node is fine (that's what I use in this series). For production, run **three** (or five) control plane nodes. etcd uses the Raft consensus algorithm and needs a majority (quorum) to accept writes: with 3 members the cluster survives losing 1, with 5 it survives losing 2. An even number adds no extra tolerance, which is why you never see 2 or 4. kube-apiserver is stateless and runs behind a load balancer; kube-scheduler and kube-controller-manager run on every control plane node but use leader election so only one instance acts at a time.

On managed services such as EKS, GKE and AKS, the provider runs and scales the control plane for you, and you only see the API endpoint.

## FAQ

### What are the components of the Kubernetes control plane?

etcd, kube-apiserver, kube-scheduler, kube-controller-manager and, in cloud clusters, cloud-controller-manager.

### Is kubelet part of the control plane?

No. kubelet is a node agent that runs on every node, including control plane nodes, and turns the pod specs assigned to its node into running containers.

### Which component talks to etcd?

Only kube-apiserver. Every other component reads and writes cluster state through the API server, which is why it is the single gateway to the cluster.

> You're on a roll! Don't stop now—check out the full series and level up your Kubernetes skills. Each post builds on the last, so make sure you haven’t missed anything! 👇
>
> 🚀 In **[Part 1](https://geekcoding101.com/posts/kubernetes-tutorial-part1)**, I laid out the **networking plan**, my **goals for setting up Kubernetes**, and how to **prepare a base VM image** for the cluster.
>
> 🚀 In **[Part 2](https://geekcoding101.com/posts/tutorial-part2-dns-server-ntp)**, I walked through **configuring a local DNS server and NTP server**, essential for stable name resolution and time synchronization across nodes locally. These foundational steps will make our Kubernetes setup smoother
>
> 🚀 In **[Part 3](https://geekcoding101.com/posts/part3-kubernetes-cluster-setup)**, I finished the Kubernetes cluster setup with Flannel, got one Kubernetes master and 4 worker nodes that’s ready for real workloads.
>
> 🚀 In **[Part 4](https://geekcoding101.com/posts/part3-kubernetes-cluster-setup)**, I explored NodePort and ClusterIP,understood the key differences, use cases, and when to choose each for internal and external service access!🔥
>
> 🚀 In Part 5, Current one. I dived into `ExternalName` and `LoadBalancer` services, uncovering how they handle external access, DNS resolution, and dynamic traffic distribution!