Kubernetes Architecture (Kubernetes course – 8 )

Welcome to this post on Kubernetes Architecture! In the last post we deployed a simple containerized static website to Kubernetes. I am sure you are now eager to understand what Kubernetes really is. We will split the architecture into multiple videos and this first video gives a brief overview of the various components of Kubernetes.

Kubernetes Architecture
Kubernetes Architecture

We refer to Kubernetes as a cluster since it contains multiple nodes. Each node can be an independent physical machine or a Virtual instance. For example, in AWS a m2.medium is one node and we would use multiple such instances to form a cluster.

Kubernetes architecture components

The cluster is divided into two major parts. The control plane and the worker nodes. kubectl or kube-ctl is the command line client used to communicate with Kuberentes.

Kubernetes control plane

The control plane is also known as the master. A single master node is enough to run a cluster, however for higher availability more than one master node can also be installed.

Kubernetes API Server

The first component in the control plane is called the API server. It exposes a restful API to manage Kubernetes objects such as pods, services and ingress. We will understand what those components are later but for now all that we need to know is that the API is our window into the Kubernetes cluster. Every action that we want to perform on the cluster goes via the API. In fact, the API is also the only way by which the various components of Kubernetes can talk to each other and can access the shared state

In the previous post we used a command line client called kubectl to deploy our static webiste. kubectl accomplishes the deployment by firing a series of requests to the API. The API definition is exposed on the master using swagger at the /swagger endpoint and OpenAPI at the /openapi/v2 endpoint. The API server serves REST operations. It is accessible from outside the cluster whereas the nodes and containers may not be accessible from outside the cluster.

Kubernetes cluster store – etcd

The next important component is the cluster state store. The state of the cluster is stored in a key-value storage known as etcd. etcd stores the cluster state in a consistent and fault tolerant way. Any change to configuration is persisted in etcd and then propagated to the other components.
etcd functions as a distributed data store and uses the concept of leader election. etcd therefore is most stable if it uses an odd number of nodes. Internally etcd is implemented as an immutable key value store. Any change to key value pair is stored as a new entry with a new version.In production systems it is important to backup etcd. The etcd client tool provides a backup utility that can be used.

Kubernetes Controller Manager Server

The third component in the control plane is the Controller Manager Server or kube-controller-manager. It performs lifecycle functions such as namespace creation or garbage collection. It also performs certain business logic such as scaling of pods. It is run as a daemon and is responsible for regulating the state of the system. The controller manager is a single binary that includes multiple controllers such as the
1. Node controller which manages various aspects of the nodes, such as responding when the nodes go down.
2. Replication Controller – Maintains the number of pods as specified in the replication controller object.
3. Endpoints Controller – Creates the endpoint object that joins services to pods.
4. Service account and Token Controllers that creates default account.
The controller watches some object for the systems desired state and it watches the systems actual state too. It then sends instructions to try and make the systems current state to be more like the desired state.

Kubernetes Scheduler

The last component of the control plane is the Scheduler. It is responsible for figuring out which node a particular pod should run on. It looks for pods that haven’t been scheduled and nodes that have capacity to host that pods. It considers various factors such as hardware or software constraints or data locality when assigning nodes to pods. It then tell those nodes to run the pods. Although the default Kubernetes installation provides a scheduler it is possible to use a user-provided scheduler.

Kubernetes worker nodes

Next lets look at the components present in the nodes. Each node contains Kubelet, container runtime and the kube proxy.


A kubelet is responsible for running the containers that a user specifies. The fundamental unit of execution is called a pod. A pod contains one or more containers and volumes. The kubelet runs a pod based on the specification provided by the user. This specification is known as PodSpec. The Containers that the kubelet runs are isolated from each other and also from the host. It is the kubelet that ultimately decides what pod can or cannot run on a given node and not the scheduler.

Kubernetes Container Runtime

Container Runtime – The nodes run a container runtime that is responsible for downloading images and running containers. This container runtime implements a container runtime interface or CRI that specifies requirements for a container runtime to integrate with kubelet. The most widely known container runtime is Docker, however the container runtime interface supports interchangeable container runtimes. Internally the kubelet communicates with the container runtime over unix sockets using the gRPC framework where the kubelet is the client and the CRI is a server. in CRI the pod environment is called PodSandBox. Before starting a pod, the kubelet creates the PodSandBox and sets up networking. The Kubelet is responsible for maintaining the lifecycle of the containers through RPC.

Kube proxy

The final component in the node is the kube proxy. The kube proxy allows to balance load between the various pods in the node. The main task of kube proxy is to program the iptables so that it captures the traffic to the service’s clusterIP and port and forwards the request to one of the service’s pods.

We have covered a lot of material in this post. We will go through some of the components in detail in the later posts. As we progress through the course, you will get more familiar with the various components. It would be worth coming back to this post after a while just to get reoriented.

The next short post introduces what Kubernetes objects are.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.