Konrad Kowalski (rootsher)Principal Platform & Reliability Architect100100010011000111101000000000011000000010111010

How Kubernetes Components Work Together

date
category
Containers
reading
3 min / 511 words

Now that we know the main components, we can walk through the whole process from start to finish.

It is the best way to see that Kubernetes is not one big program.

It is a set of small components that cooperate through a shared API.

Let's say a user sends the cluster a declaration of a new workload.

Step 1: kubectl sends a request

The user runs, for example:

bash
kubectl apply -f app.yaml

kubectl sends a request to the API Server.

text
kubectl
   |
   v
kube-apiserver

The API Server checks, among other things:

  • who sent the request,
  • whether they are allowed to,
  • whether the data is valid.

If everything is fine, the state is accepted.

Step 2: the state is stored

The API Server stores the state in etcd.

text
kube-apiserver
      |
      v
     etcd

From this moment the control plane knows what the user expects.

Step 3: controllers detect the difference

Controllers watch the state through the API.

If they see that the desired state differs from the actual state, they take the appropriate action.

This is not a one-off reaction.

Controllers run in a loop and keep checking the state again.

Step 4: a Pod appears without a node

If a controller's work means a new Pod should be created, that Pod may initially have no node assigned.

That is when the scheduler takes over the next part of the process.

Step 5: the scheduler picks a node

The scheduler analyzes the available nodes.

After choosing, it records the decision:

text
Pod X
-> Node 3

That is where its job ends.

It doesn't start the container.

Step 6: the kubelet notices the change

The kubelet running on Node 3 watches the API.

Seeing a Pod assigned to its node, it gets to work.

text
API Server
   |
   v
kubelet

Step 7: the runtime starts the containers

The kubelet talks to the container runtime through CRI.

text
kubelet
  |
  v
 CRI
  |
  v
container runtime

The runtime pulls the required images and starts the containers.

Step 8: CNI prepares the network

The Pod needs a network.

The CNI plugin configures the relevant pieces:

  • interface,
  • IP address,
  • routing,
  • connectivity.

After that the Pod can communicate with other parts of the cluster.

Step 9: the status goes back to the API

The kubelet reports the state.

The control plane now knows whether the Pod is:

  • running,
  • pending,
  • failed.

The whole system keeps watching the state.

If something changes, the reconciliation loop kicks in again.

What happens during communication

When an application wants to connect to another service:

text
application
   |
   v
CoreDNS
   |
   v
Service IP
   |
   v
kube-proxy / eBPF
   |
   v
target Pod

This is a separate path from the one responsible for creating the Pod.

The whole picture

We can reduce it to two flows.

Creating a workload

text
kubectl
  |
  v
API Server
  |
  v
etcd
  |
  v
controllers
  |
  v
scheduler
  |
  v
kubelet
  |
  v
container runtime
  |
  v
CNI
  |
  v
Pod

Communication

text
Pod
 |
 v
CoreDNS
 |
 v
Service
 |
 v
network datapath
 |
 v
Pod

Why this model matters

Knowing this flow makes troubleshooting much easier.

If the Pod wasn't scheduled, you look at the scheduler.

If the Pod is assigned to a node but the container doesn't start, you look at the kubelet and the runtime.

If the Pod runs but has no network, you look at CNI.

If communication over IP works but by name doesn't, you look at DNS.

Instead of treating Kubernetes as a black box, you start seeing the layers of the system.