Skip to main content

Command Palette

Search for a command to run...

Kubernetes: The Backbone of Container Orchestration

Updated
5 min read
Kubernetes: The Backbone of Container Orchestration
B

As a DevOps enthusiast, I am embarking on a journey to become a skilled DevOps Engineer, and I plan to share my learning experiences through blog posts. As a DevOps Engineer, my primary goal is to bridge the gap between development and operations teams by leveraging automation, collaboration, and communication to streamline software development and deployment processes. I recognize that DevOps is not just a set of tools and technologies but also a cultural shift that emphasizes collaboration, agility, and a customer-centric approach. Therefore, in addition to technical skills, I will also focus on soft skills such as communication, teamwork, and problem-solving.

Through my blog posts, I aim to share my journey, insights, challenges, and successes as I navigate the world of DevOps. My goal is to provide value to my readers by offering practical advice, tips, and tricks, and inspiring them to embark on their own DevOps journey.

Kubernetes, It is a container Orchestration technology used to orchestrate the deployment and management of 100s and 1000s of containers in a clustered environment.

Nodes: The Foundation of Kubernetes

A node, whether physical or virtual, serves as the operational base where Kubernetes is installed. Termed as a worker machine, it's responsible for launching containers orchestrated by Kubernetes. Previously referred to as 'Minions,' these terms are occasionally used interchangeably.

However, in the event of a node failure where our application is operational, the application would inevitably experience downtime. To mitigate such risks, having multiple nodes becomes imperative to ensure the continuity of operations.

Clusters: Unifying Nodes for Resilience

A cluster is a set of nodes grouped together. This way even if one node fails you have your application still accessible from the other nodes. Moreover having multiple nodes helps in sharing load as well.

Master: Orchestrating the Kubernetes Symphony

Now we have a cluster, but who is responsible for managing the cluster? Were is the information about the members of the cluster stored? How are the nodes monitored? When a node fails how do you move the workload of the failed node to another worker node? That’s were the Master comes in. The master is another node with Kubernetes installed in it, and is configured as a Master. The master watches over the nodes in the cluster and is responsible for the actual orchestration of containers on the worker nodes.

Key Components within the Master Node:

API Server: The API Server operates as the central gateway through which various entities interact with the Kubernetes cluster. It functions as the primary interface, receiving and handling requests from users, command-line interfaces, management tools, and other components within the cluster. The API server exposes the Kubernetes API, enabling users to manage and control cluster resources, such as deploying applications, scaling deployments, or configuring cluster settings.

ETCD Service: ETCD serves as a distributed, consistent, and highly available key-value store that acts as the cluster's central database. It securely stores critical data required for the management and coordination of the Kubernetes cluster. ETCD maintains configuration details, metadata, and states of all cluster components, ensuring data consistency and reliability across all nodes. Its distributed nature guarantees fault tolerance and resilience against failures.

Controllers and Schedulers: Controllers are crucial components responsible for maintaining the desired state of the cluster and managing its various resources. They continuously monitor the cluster's state and respond to changes or failures by initiating corrective actions. For instance, if a node or a pod (a group of containers) fails, controllers detect these events and trigger actions to reconcile the state by creating new instances of pods or rescheduling them onto healthy nodes.

Schedulers, on the other hand, are responsible for optimizing resource allocation within the cluster. They decide which node should run a particular pod based on factors like resource availability, affinity/anti-affinity rules, and workload constraints. Schedulers distribute workloads across the cluster's nodes, aiming for efficient resource utilization and maintaining desired performance levels.

Container Runtime: The container runtime is the underlying software responsible for executing and managing containers within the Kubernetes environment. Kubernetes supports various container runtimes, with Docker being one of the most commonly used ones. The container runtime interacts with the host operating system, managing the lifecycle of containers, including their creation, execution, termination, and resource isolation.

Kubelet: The kubelet acts as the primary node agent that interacts with the Master node's control plane to ensure that containers are running as intended on the worker nodes. It plays a pivotal role in maintaining the desired state of the pods (groups of one or more containers) within the node.

These key components within the Master Node work synergistically to manage and control the Kubernetes cluster. They facilitate interactions, store crucial data, ensure cluster stability, maintain desired states, and efficiently manage containerized workloads, playing integral roles in the seamless operation of Kubernetes infrastructure.

Master vs Worker Nodes

So far we saw two types of servers – Master and Worker and a set of components that make up Kubernetes. But how are these components distributed across different types of servers. In other words, how does one server become a master and the other slave?

The worker node (or minion) as it is also known, is were the containers are hosted. For example Docker containers, and to run docker containers on a system, we need a container runtime installed. And that’s were the container runtime falls. In this case it happens to be Docker. This doesn’t HAVE to be docker, there are other container runtime alternatives available such as Rocket or CRIO.

The master server has the kube-apiserver and that is what makes it a master.

Similarly the worker nodes have the kubelet agent that is responsible for interacting with the master to provide health information of the worker node and carry out actions requested by the master on the worker nodes. 29

All the information gathered are stored in a key-value store on the Master. The key value store is based on the popular etcd framework as we just discussed.

The master also has the controller manager and the scheduler.

There are other components as well, but we will stop there for now. The reason we went through this is to understand what components constitute the master and worker nodes. This will help us install and configure the right components on different systems.

More from this blog

The DevOps Journey with Bhakti

25 posts

I'm a DevOps enthusiast sharing my journey to become a skilled DevOps Engineer through blog posts covering technical topics.I aim to offer guidance and motivate readers to pursue their own DevOps path