Beginner’s Guide to Kubernetes Architecture: How It All Works

Getting started with Kubernetes isn't easy, but a good first step is understanding its architecture at a high level. In this post, we'll walk through the different components that make Kubernetes work. Nodes First, Kubernetes has two types of nodes: control plane nodes (formerly called master nodes) and worker nodes. The control plane nodes are responsible for running the components that handle the orchestration of the entire cluster. These nodes manage the desired state, schedule workloads, and monitor the overall health of the system. On the other hand, we have worker nodes, which are responsible for hosting and running applications inside containers. The control plane nodes host the following components: etcd kube-scheduler controller-Manager kube-apiserver The worker nodes include: kubelet kube-proxy Container runtime We'll take a closer look at each of these components next. etcd Starting with etcd, it is a distributed, reliable key-value store that is simple, secure, and fast. In the context of Kubernetes, etcd is used to store the state of the cluster. It contains all the information about the resources that have been created, such as pods, services, deployments, and more. When you run a kubectl get command, the request goes through the Kubernetes API server, which retrieves the necessary data from etcd, where the cluster state is stored. kube-apiserver The kube-apiserver is the central component of the control plane and serves as the primary interface to the Kubernetes cluster. All communication—whether from internal components or external users—goes through the API server. Whether you use the kubectl CLI or send an HTTP request to the Kubernetes API, both are handled by the kube-apiserver, which acts as the entry point to the cluster and validates and processes all API requests. controller-manager The controller-manager runs a set of controllers that constantly observe the current state of the cluster and make the necessary changes to ensure it matches the desired state defined in the configuration. For example, the Node Controller monitors the status of nodes, and the Replication Controller ensures that the desired number of pod replicas are running—if a pod dies, it automatically creates a new one. kube-scheduler The kube-scheduler is responsible for deciding which pod should run on which node. It's important to note that the scheduler doesn't actually place the pod on the node—it only assigns the pod to a suitable node based on resource availability, scheduling policies, and criteria. kubelet On the worker node side, we have the kubelet. This component is responsible for registering the node with the Kubernetes cluster and enabling communication between the node and the control plane. It is also responsible for instructing the container runtime to pull the required image, run the container inside a pod, and monitor its state. kube-proxy Within a Kubernetes cluster, every pod can communicate with other pods thanks to the underlying pod network. A pod can reach another pod using its IP address, but this is not a reliable approach since pod IPs can change over time. To solve this, Kubernetes introduces Services, which provide stable networking endpoints for accessing pods. However, Services don't exist within the pod network themselves—they require a mechanism to route traffic. That's where kube-proxy comes in. kube-proxy is a network component that runs on each node. Based on the configured Services, it creates the necessary networking rules to forward traffic. So, when a pod tries to reach another pod through a Service, kube-proxy handles the traffic routing under the hood—forwarding it from the Service's virtual IP to the correct pod's IP address. Container Runtime Finally, we have the container runtime. This component is responsible for running our applications as containers inside pods. The most commonly used container runtime in Kubernetes is containerd. This is just the beginning of your journey into the world of Kubernetes. There's a lot more to learn, but remember—one step at a time is the best way forward. my LinkedIn

May 9, 2025 - 00:30

Beginner’s Guide to Kubernetes Architecture: How It All Works

Getting started with Kubernetes isn't easy, but a good first step is understanding its architecture at a high level. In this post, we'll walk through the different components that make Kubernetes work.

Nodes

First, Kubernetes has two types of nodes: control plane nodes (formerly called master nodes) and worker nodes. The control plane nodes are responsible for running the components that handle the orchestration of the entire cluster. These nodes manage the desired state, schedule workloads, and monitor the overall health of the system.

On the other hand, we have worker nodes, which are responsible for hosting and running applications inside containers.

The control plane nodes host the following components:

etcd
kube-scheduler
controller-Manager
kube-apiserver

The worker nodes include:

kubelet
kube-proxy
Container runtime

We'll take a closer look at each of these components next.

etcd

Starting with etcd, it is a distributed, reliable key-value store that is simple, secure, and fast.

In the context of Kubernetes, etcd is used to store the state of the cluster. It contains all the information about the resources that have been created, such as pods, services, deployments, and more.

When you run a kubectl get command, the request goes through the Kubernetes API server, which retrieves the necessary data from etcd, where the cluster state is stored.

kube-apiserver

The kube-apiserver is the central component of the control plane and serves as the primary interface to the Kubernetes cluster. All communication—whether from internal components or external users—goes through the API server.

Whether you use the kubectl CLI or send an HTTP request to the Kubernetes API, both are handled by the kube-apiserver, which acts as the entry point to the cluster and validates and processes all API requests.

controller-manager

The controller-manager runs a set of controllers that constantly observe the current state of the cluster and make the necessary changes to ensure it matches the desired state defined in the configuration.

For example, the Node Controller monitors the status of nodes, and the Replication Controller ensures that the desired number of pod replicas are running—if a pod dies, it automatically creates a new one.

kube-scheduler

The kube-scheduler is responsible for deciding which pod should run on which node. It's important to note that the scheduler doesn't actually place the pod on the node—it only assigns the pod to a suitable node based on resource availability, scheduling policies, and criteria.

kubelet

On the worker node side, we have the kubelet. This component is responsible for registering the node with the Kubernetes cluster and enabling communication between the node and the control plane.

It is also responsible for instructing the container runtime to pull the required image, run the container inside a pod, and monitor its state.

kube-proxy

Within a Kubernetes cluster, every pod can communicate with other pods thanks to the underlying pod network. A pod can reach another pod using its IP address, but this is not a reliable approach since pod IPs can change over time.

To solve this, Kubernetes introduces Services, which provide stable networking endpoints for accessing pods. However, Services don't exist within the pod network themselves—they require a mechanism to route traffic. That's where kube-proxy comes in.

kube-proxy is a network component that runs on each node. Based on the configured Services, it creates the necessary networking rules to forward traffic.

So, when a pod tries to reach another pod through a Service, kube-proxy handles the traffic routing under the hood—forwarding it from the Service's virtual IP to the correct pod's IP address.

Container Runtime

Finally, we have the container runtime. This component is responsible for running our applications as containers inside pods. The most commonly used container runtime in Kubernetes is containerd.

This is just the beginning of your journey into the world of Kubernetes. There's a lot more to learn, but remember—one step at a time is the best way forward.

my LinkedIn