Let’s dive into the inner workings of a Kubernetes cluster.

The two main components of a Kubernetes cluster are:

Master node – which can be replicated across multiple nodes

Worker node
Master Node

etcd – Database used to store the entire configuration and state of the cluster.

controller – Checks the current state of the worker nodes and determines if there are any differences between how they should be and how they are, and resolves them.

API Server – Acts as the gateway to the cluster. Used as a proxy to nodes and pods.

scheduler – this one is responsible for the scheduling of containers across the nodes in the cluster. It takes various constraints into account: resource limitations, affinity specifications, etc.
Worker Node

pod – A pod is the smallest element of scheduling in Kubernetes. Without it, a container cannot be part of a cluster. If you need to scale your app, you can only do so by adding or removing pods.

kubelet – It watches for tasks sent from the API Server, executes the task, and reports back to the Master.

kube-proxy – The kube-proxy makes sure that each node gets its IP address, and implements local iptables and rules to handle routing and traffic load-balancing.

container runtime – The container runtime pulls images from a container image registry and starts and stops containers. A 3rd party software or plugin, such as Docker, usually performs this function.
Component diagram
Interaction diagram

Worker nodes listen to the API Server for new work assignments. They execute the work assignments and then report the results back to the Kubernetes Master node.

The kubelet runs on every node in the cluster. It is the principal Kubernetes agent. By installing kubelet, the node’s CPU, RAM, and storage become part of the broader cluster.

Based on that information, the Master can then decide how to allocate tasks and resources to reach the desired state.
Follow the Kubernetes 101 series on mindit.io.

Check out new-spike.net for other articles on Kubernetes and much more!