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.