The Kubernetes Control Plane

kube-apiserver: the central point of communication

kube-apiserver is one of the most important Kubernetes components.

All communication with the cluster goes through it.

When you run:

kubectl get pods

or:

kubectl apply -f app.yaml

kubectl doesn't talk directly to etcd, the scheduler or the kubelet.

It talks to the API Server.

kubectl
   |
   v
kube-apiserver

The API Server is responsible for, among other things:

• accepting the request,
• authentication,
• authorization,
• validating data,
• exposing the Kubernetes API,
• writing and reading cluster state.

It is the central point the rest of the system is built around.

Why everything goes through the API

Kubernetes is a strongly API-driven system.

The scheduler, controllers and kubelets also watch state through the API Server.

Thanks to that, individual components don't need to know each other's implementations.

They share a common contract: the Kubernetes API.

This simplifies the architecture and lets responsibilities be separated.

etcd: the cluster's memory

etcd is a distributed key-value store.

Kubernetes uses it to store its state.

You can treat it as the source of truth for the control plane.

etcd holds information about objects, configuration and the declared state of the cluster.

What matters, though, is what etcd does not do.

etcd:

• doesn't start containers,
• doesn't pick a node,
• doesn't manage network traffic,
• doesn't run controller logic.

Its role is to store consistent data.

If you lose etcd without a working backup, you can lose the knowledge about the state of the entire cluster.

That is why in self-managed Kubernetes it is one of the most critical pieces to protect.

kube-scheduler: picking a node

When a Pod is created, it may initially have no node assigned.

The scheduler watches such Pods and picks a suitable machine for them.

When choosing, it can take into account, among other things:

• available CPU,
• memory,
• labels,
• affinity,
• anti-affinity,
• taints,
• tolerations,
• topology constraints.

In a big simplification:

new Pod
   |
   v
scheduler
   |
   v
Node chosen

Very important:

the scheduler doesn't start the container.

It only decides which node the Pod should land on.

Starting it is the kubelet's job later on.

kube-controller-manager: keeping reality in check

kube-controller-manager runs many controllers.

Their shared job is making sure the actual state of the cluster matches the declared one.

This is the classic reconciliation loop.

Example:

desired state: 3
actual state: 2

A controller notices the difference and initiates the steps that lead to creating the missing resource.

Then it checks the state again.

And it does that all the time.

Controllers are one of the main reasons Kubernetes can react to failures and return to the expected state on its own.

cloud-controller-manager

In cloud environments cloud-controller-manager may run as well.

Its job is integrating Kubernetes with a specific provider's infrastructure.

It can be responsible, for example, for some operations related to:

• nodes,
• load balancers,
• information about the cloud infrastructure.

In modern environments many functions, for example around storage, are handled by separate interfaces such as CSI.

How the components work together

The simplest picture looks like this:

               ┌───────────────────────┐
               │    kube-apiserver     │
               └──────────┬────────────┘
                          │
             ┌────────────┼─────────────┐
             │            │             │
           etcd      scheduler    controller-manager

The API Server is the central point of communication.

etcd stores the state.

The scheduler picks a node.

The controller manager makes sure reality matches the declaration.

What to remember

The control plane is not one "brain", but a set of components.

Each has a separate responsibility:

API Server          -> communication
etcd                -> state
Scheduler           -> node selection
Controller Manager  -> reconciliation

Together they form the steering layer of Kubernetes.