Introduction

In this article, I will be discussing the essential parts of the Kubernetes brainbox, namely parts of the Kubernetes control plane. This article is a foundation for a deep dive into Kubernetes that I will be doing throughout the year. This piece of writing aims to give a clear foundation to the different parts of the Kubernetes control plane, and how they work individually and collectively to ensure pods are deployed smoothly and efficiently. This body of work is also solely focused on the master node components, other components that function on the worker nodes will be discussed in a later article. To get the best of this article you require no prior knowledge of Kubernetes or any programming experience.

Kindly note that the word "Kubernetes" is used interchangeably with the word "kube", especially when describing a core component of the control plane, this is an abbreviation that has been accepted as a standard in the community.

Understanding the Kubernetes Control Plane

Kubernetes is an open-source orchestration platform that is used to manage, deploy, and scale containerized applications anywhere. Kubernetes (short for k8s) is portable and extensible and can be used to manage workloads that facilitate both declarative configuration and automation.

Fun fact: The name Kubernetes originates from Greek, meaning helmsman or pilot

In this article, we are focused on a series of components in the Kubernetes ecosystem called the Control plane. The Kubernetes control plane is a set of components in Kubernetes that collectively work to reconfigure the state of a cluster with the main goal of achieving a desired state. The control plane utilizes information such as cluster activity and node date to ensure that deployed applications are fault-tolerant and highly available.

In this article, we will discuss the four major parts of the control plane namely,

• Kube api-server
• etcd
• Kube-scheduler
• Kube controller-manager

Caveat: I am not including the Cloud controller manager because this article is solely focused on native parts of Kubernetes, outside of any cloud provider or third-party system. 

Kube api-server

The Kube api-server exposes the Kubernetes API through multiple pathways (such as HTTP, gRPC, and kubectl), making it the only external-facing component of the control plane. The kube api-server validates and configures data for native Kubernetes objects such as pods, deployments, and services. The api-server is also solely responsible for authentication of API requests, authorization of roles and groups, and admission control of Kubernetes objects.

The api-server's state is stored in a distributed and highly consistent database (etcd) so the api-server itself is stateless and can be easily replicated across different machines. The api-server supports both the SPDY protocol, as well as HTTP2/WebSocket however, SPDY is being deprecated for HTTP2/Websocket.

etcd

etcd is an open-source, strongly consistent distributed key-value store that is used to store configuration, state data, and meta information for Kubernetes. Kubernetes utilizes the highly available nature of etcd to provide a single consistent source of truth about the status of its distributed clusters, this is inclusive of the pods and application instances deployed on the same pods.

etcd is designed to have no single point of failure and gracefully tolerate hardware failure and network partitions, it is also pretty fast as it has been benchmarked to be able to handle over 1,000 writes per second (https://etcd.io/docs/v3.5/benchmarks/etcd-2-1-0-alpha-benchmarks/).

Due to the highly sensitive nature of the data that resides in Kubernetes, etcd also supports automatic Transport Layer Security (TLS) and secure socket layer (SSL) client certificate authentication.

The kube api-server stores each cluster's state data in etcd, it also makes use of etcd's watch function to monitor saved state data and initiate a response when the state data deviates from the intended data.

Kube scheduler

The Kubernetes scheduler is the component of the control plane that is responsible for assigning pods to Nodes. The scheduler watches for newly created pods and then assigns the best possible available node to those pods. Multiple different schedulers can be used in the same cluster, depending on the intended scheduling algorithm.

In a cluster, nodes that satisfy the scheduling requirements of a pod are called feasible nodes, if none of the nodes are suitable the pod is left in a pending state until it is allocated to a node.

The process by which the kube-scheduler assigns pods to nodes is pretty straightforward. When a new pod is created, the scheduler picks up its requirements and proceeds to find feasible nodes for the pod in a process known as filtering. After filtering, the scheduler runs a set of functions to score feasible nodes in a process known as scoring. After scoring is complete, the scheduler then picks the node with the highest score among the feasible nodes to run the pod and proceeds to attach that node to the pod, this process is known as binding.

The kube scheduler assigns the pod to the node with the highest score, and if there is more than one node with the highest score, the scheduler selects one at random and attaches the pod to that node.

Kube controller-manager

To completely understand the role of the Kubernetes controller-manager, it is imperative that you understand the complete function of A controller.

A controller is a non-terminating loop that regulates the state of the Kubernetes system, a controller works to bring the whole system to the desired functioning state. When the current state of an object deviates from the desired state, the control loop takes corrective steps to make sure that the current state is the same as the desired state. A controller can perform the aforementioned duties with the help of the kube api-server.

An example of a controller is the node controller, which is responsible for monitoring the state of nodes and taking the necessary actions to keep applications running when a node is faulty. Another example is the replication controller, this controller monitors the state of the replica sets and ensures that the desired number of pods are available at all times within the set. If a pod terminates, another one will be created in its place.

The kube controller-manager is a core component of the control place that is responsible for running multiple controllers that maintain the desired state of a cluster. The kube controller manager runs as a daemon (on every node in the cluster) and it comes pre-packaged with the necessary controllers to successfully run a Kubernetes cluster.

Conclusion

In this article, we have described the core parts of the Kubernetes Control plane, their roles, and how they collectively function to ensure that the cluster is healthy. This article is a primer to a series of articles that I will be writing on Kubernetes through the course of the year. Thank you for reading! Please like, share, and subscribe to enjoy more articles from me. Thank you!