Kubernetes is an open-source orchestrator for deploying and managing containerized applications at scale. If you are building cloud native applications, Kubernetes is a game changer in this space and lets you build and deploy reliable, scalable and highly available distributed systems.

In this blog, we will discuss about the Kubernetes architecture and look at the various components of the Master and Worker Nodes.

At a high level, K8s Architecture has 2 main components — Master and Worker nodes

The Master is the entry point and is responsible for managing the entire Kubernetes cluster. It takes care of scheduling, provisioning and exposing the API to the client.
You can communicate with the K8s master via the K8s CLI or via the API.

K8s objects are created/updated/deleted in a declarative manner by using configuration files which are submitted to the Master. Container Images for your application are stored in the registry – which can be either a Private Registry or DockerHub.

Master node has 4 components —

• API Server
• Scheduler
• Controller
• Etcd

API Server
Front end of the K8s control plane that exposes the K8s API and consumes the Manifest file provided by the user. It is the gatekeeper for the entire cluster and all the administrative tasks are performed by the API Server.
All the user requests needs to pass through this. After the requests are processed, the cluster state is stored in the distributed key-value store.

Scheduler
Schedules the work to different worker nodes based on the cluster resource usage and constraints mentioned in the application manifest file by the user. For example – There might be scenarios where the user wants the work to be scheduled on pods having a specific label.

Controller
Responsible for maintaining the state of the K8s cluster all the time. It tracks the current state of the objects, watches for changes and ensures that the current state is equivalent to the desired state.

Etcd
Distributed Key value store to store the current state of the K8s cluster, along with the configuration details. It is treated as the single source of truth of the K8s cluster.
Worker Nodes does all the heavy lifting work. It runs the applications using Pods and is controlled by the Master node. Users connect to the worker nodes to access the applications.

Worker Nodes have the following components —

• Kubelet
• Kube-Proxy
• Container Engine
• Pods

Kubelet
The main Kubernetes agent which runs on each node.
Responsible for communicating the health of the node to Kubernetes Master and Etcd.
It fetches the pod definition mentioned in the manifest file and instantiates the pods.
Manages the Pod and reports back to Master.

Kube-Proxy
Core networking component of Kubernetes. Communication is maintained seamlessly across all elements of the cluster. It is responsible for maintaining the network configuration and ensure that pod can talk with another pod, node can talk with another node, container can talk with another container.

Container Engine
Responsible for running the containers. Docker can also be treated like a container runtime. 

Pods
Smallest deployable unit that can be created & managed in Kubernetes.
Pods are atomic and can also be defined as group of one or more containers that run in a shared context. It is important to note that each Pod gets a unique IP.
Containers inside the pods are able to communicate with each other and share the pod environment.

Pod States —

• Pending
• Running
• Succeeded
• Failed
• CrashLoopBackOff

If you are interested in learning more about Kubernetes, do not forget to check out my other articles in the Kubernetes series —

Local Development Environment Setup for Kubernetes using Minikube

Automate Kubernetes and Istio Environment Setup

Load Testing in Kubernetes using Siege

End to End Testing in Kubernetes

End to End Testing in Kubernetes – Part II

Crash Loop Detection in Kubernetes

Categories: Kubernetes