Kubernetes has multiple moving parts.

Here is an short article aiming at mapping all this to create some clarity.

Some Basic Vocabulary

Nothing fancy but let’s get this out of the way.

  • Nodes

    A node can be a physical machine or a virtual machine.

  • Cluster

    A cluster is a group of nodes

  • Container runtime

    Docker (or runC)

  • Pod

    A pod is a group of containers - that together form a logical application. A Pod lives on a node.

  • Master Controller

    Control the cluster. Does many thing. We will get back to this.

  • Replication Controller

    Take care of scalling and pods scheduling.

  • Operators

    An Operator is a controller that extends the Kubernetes API. It is like a domain specific controller

Ok, that’s a lot of words, and that’s a simplified list. Now let’s dive into details.

Controle Plane

  • Where the master controller lives. Basically the same.
  • responsible for managing Kubernetes infrastructure.
  • It can run on a single server/node or multiple nodes (i.e a cluster)

Work Nodes

  • run the containerized applications inside pods

Understanding the control plane

api server



controller manager

Let’s dive in details in each of these.

API Server

It’s basically the API of K8s. That’s how k8s talk to the world.

You talk to the api server using kubectl or the REST api


Take care of orchestrating which pod goes in which nodes and wheather or not you need more nodes

Controller Manager

A controller in general is here to ensure the desired state and the current state are the same.

It breaks down into separate area, so we speak sometime of the node controller, the replication controller, ingress controller, etc.


The db storing the state of kubernetes

The worker nodes


Agent to communicate with the master node (though a manifest)

Kubelet talk to the container runtime on the node, which will pull the images required


Manage the traffic to the pod

Conatainer Runtime

Not necessarilly Docker, but often docker.


Ingress is a general term for kubernetes router/loadbalancer/api gateway/proxy. Ingress are implemented by various product (traefik, nginx, envoy…) but they all share a common api which is a nice way to abstract vendor dependancy and which product is taking care of which task

Here is a nice video explaining the thing in more details:


A workload is an app running.

There are more but I will stop here, and make a follow up post later to try to articulate how all these bits and pieces are working together

Go deeper with