Konrad Kowalski (rootsher)Principal Platform & Reliability Architect100111010111010110011010000110001110111010101011

Kubernetes Cluster Architecture

date
category
Containers
reading
2 min / 473 words

Before we start taking Kubernetes apart into specific processes, it is worth building a simple map of the whole system first.

The most important split is:

  • control plane,
  • data plane.

These are two logical areas of the cluster with completely different jobs.

In a big simplification:

text
Kubernetes cluster
├── Control Plane
│   ├── kube-apiserver
│   ├── etcd
│   ├── kube-scheduler
│   └── kube-controller-manager
│
└── Worker Nodes
    ├── kubelet
    ├── container runtime
    ├── networking
    └── Pods

This doesn't necessarily mean that the control plane has to be one machine and the data plane another. It is a split of responsibilities more than a physical split of servers.

Control Plane: the steering part

The control plane is responsible for managing the state of the cluster.

This is where decisions are made about:

  • what should be running,
  • where it should be running,
  • whether the current state matches the expected one,
  • what to do when something stops working.

You could say that the control plane doesn't do the actual application work, it coordinates the whole system.

Example:

You declare that you want three instances of an application.

The control plane doesn't start those containers itself. Instead it:

  1. stores the expected state,
  2. checks whether three Pods exist,
  3. if not, initiates their creation,
  4. picks suitable nodes for them,
  5. watches whether everything runs as declared.

Data Plane: the executing part

The data plane is where workloads actually run.

Most often these are worker nodes.

Every node has components responsible for carrying out the control plane's decisions:

  • kubelet,
  • container runtime,
  • networking components,
  • running Pods.

The control plane may say:

text
Pod X should run on Node 2

but it is the kubelet on Node 2 that makes the runtime actually start the containers.

Desired state and actual state

This is one of the most important concepts in all of Kubernetes.

Kubernetes constantly compares:

  • desired state, the expected state,
  • actual state, the real state.

Example:

text
desired state: 3 Pods
actual state: 2 Pods

The system detects the difference and tries to correct it.

So it doesn't work like a simple script such as:

text
start container
done

It is closer to a continuous mechanism:

text
check the state
|
v
compare with the declaration
|
v
fix the difference
|
v
repeat

This is exactly why Kubernetes can react to failures.

Cluster and node

The whole thing is called a cluster.

A cluster is made of machines called nodes.

In a typical environment we have:

  • control plane nodes,
  • worker nodes.

In small lab environments one machine can play both roles.

In production they are often separated for better reliability and security.

The Pod as the unit of execution

A Pod is the smallest unit Kubernetes runs.

It is not, however, an infrastructure component in the same sense as the kubelet or the scheduler.

A Pod is a workload that the cluster manages.

In this series we mostly care about how the cluster's infrastructure gets a Pod to appear and keep running.

What to remember

The simplest model is:

text
Control Plane
-> decides and guards the state

Data Plane
-> does the work

In the next parts we will break both areas down into specific components and see what each of them is responsible for.