Kubernetes Control Plane Components Explained

Originally published at GeekCoding101.

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.

---

🔐 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 (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, 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, 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, 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, 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!