Introduction
Kubernetes (K8s) was announced by Google in June 2014, and its 10-year anniversary is coming up in June 2024. It has come a long way since then, and has evolved into the K8s we know today.
Although K8s has been widely adopted by many organisation and is becoming the main force in modern application development cycles, the term – “Kubernetes” is still a mystery to some people. Therefore, the purpose of this series is to dissect Kubernetes; understand how a Kubernetes cluster works, and explore the components within a cluster. Let’s dive in!
What is Kubernetes?
Kubernetes is a Greek word (κυβερνήτης), meaning “helmsman” or “captain” in English. Back then, it was developed by Google engineers to manage containerised workloads. The name – “Kubernetes” symbolises the role as a helmsman or captain of a ship, driving and managing containerised workloads.
To understand the role of Kubernetes in application development, it is important to first examine the rise of containerised applications. Nowadays, applications are increasingly being deployed in the form of containers due to their speed, portability and lightweight nature. This allows workloads to be deployed on any platform. Developers can write code, test it locally and achieve the same results regardless of the platform on which the workload runs. A container holds all necessary software dependencies and libraries for a workload to run. Additionally, the increasing popularity of cloud services has made containers a more viable option, enabling seamless integration between workloads and cloud services.
Now that the containerised applications have become de facto standard. It is important to fully utilise the power of containerisation. This requires a tool that can fully manage the entire container life cycle, allocate resources, dynamically scale containers and ensure 100% availability. K8s is the ideal tool for these tasks.
What is a K8s cluster?
Imagine you are Professor X from X-Men who can connect to all mutants in the world using Cerebro. Similarly, K8s operates in 2 important aspects: the master / control plane and the worker plane. Control plane comprises the master node (Cerebro) which acts as the central controller, commanding and instructing worker nodes (mutants) to operate under optimal conditions; Worker plane consists of all worker nodes which execute instructions sent by the master node to ensure workloads such as application runs correctly.
Architecture of a K8s cluster
The diagram below illustrates the basic architecture of a K8s cluster.
The diagram shows two boundaries separated by dotted lines, representing the master and worker planes. The control plane, it consists of one or more master nodes, while the worker plane consists of worker nodes. Each node, whether a master or worker node, can a physical server or a virtual machine hosting K8s resources.
Components found in a K8s cluster
A K8s cluster consists of a few hosts that contain both master and worker components. These essential underlying components enable a node to function correctly in a cluster, as listed in the table below:
Diagram | Name | Description |
---|---|---|
Pod | Think of pod as a box that hosts a collection of containers. It provides shared resources such as storage and network to all containers within. It is known as the smallest unit in a cluster. | |
Service | Think of service as an abstract layer that groups a collection of pod endpoints into a single resource. That single resourc could be exposed to the other clients in the cluster which allows network communication with the group of pod endpoints. It also helps in loadbalancing traffics to pod endpoints. | |
Kube-proxy | Kube-proxy is a network proxy that allows network communication within and from outside of a cluster. It runs on each node in a cluster | |
Kubelet | Kubelet is an agent running on each node. One of the role it plays is to register a node with the apiserver as part of the cluster. It also make sure a container defined in the form of declarative language such as YAML and JSON, is running as how it was defined. The container definition is also known as “ProdSpec”. | |
Kube-scheduler | If you have more than 1 worker nodes and you are going to deploy a workload in the form of a pod, which node should the pod be running on? Kube-scheduler, by it’s name, is a scheduler that manages resource scheduling. The scheduling decision is based on multiple factors which include hardware or software requirement and policy constraints | |
Etcd | Etcd is a data store that stores important data that a cluster needs to keep running. Information such as resource configuration, state and metadata are stored within an etcd data store. Think of it as human brain that stores memories that are critical to a human to function properly. Should any data is missing or corrupted, it could potentially bring down the entire cluster. | |
Kube-apiserver | Every single action in a cluster is performed through Kubernetes API in the form of REST API, which is serviced by Kube-apiserver. It plays a centric role in cluster operation where it validates an API object before an action can be performed. It also allow all other components in a cluster to interact with one another. |
This post provides an overview of the essential components found in a K8s cluster and discusses K8s’ background. The upcoming posts will explore how each component works with examples.