Demystifying Kubernetes Architecture: Master Node/Control Plane, Worker Nodes, and Essential Components Explained
Table of contents
- What is a Control Plane, Master Node, and Worker Nodes?
- What are Pods and Containers in Kubernetes?
- Control Plane Components in Kubernetes
- Worker Node Components
- What Happens in the Cluster When a User Sends a Request Using the Kubectl Command?
- How Control Plane Components Interact with Each Other in a Kubernetes Cluster
- Pods and Containers: A Brief Write-up
- References
- Conclusion: Mastering Kubernetes Components
Welcome to Day 5 of #40DaysOfKubernetes! Today, we’re diving into the intricate world of Kubernetes architecture, focusing on the control plane, master node, worker nodes, and the core components that make Kubernetes such a powerful orchestration tool. Let's break down these concepts in the most straightforward language possible.
What is a Control Plane, Master Node, and Worker Nodes?
Control Plane: The control plane is the brain of the Kubernetes cluster. It makes global decisions about the cluster (like scheduling) and detects and responds to cluster events (like starting up a new pod when a deployment's replicas field is unsatisfied).
Master Node: This is the machine where the control plane components run, including the API server, scheduler, and controller manager. It’s responsible for managing the Kubernetes cluster.
Worker Nodes: These are the machines that run your applications. The worker nodes report to the master node and run the workloads (containers) that are assigned to them.
What are Pods and Containers in Kubernetes?
Pods: A pod is the smallest and simplest Kubernetes object. It represents a single instance of a running process in your cluster. A pod can contain one or more containers, which are tightly coupled and share the pod's resources.
Containers: Containers are lightweight, portable, and self-sufficient environments that run applications. They encapsulate everything needed to run an application, including the code, runtime, libraries, and dependencies.
Control Plane Components in Kubernetes
1. API Server:
Function: Acts as the front-end for Kubernetes control plane. It exposes the Kubernetes API, which allows users and controllers to interact with the cluster.
Responsibilities:
Validates and processes API requests, executing corresponding operations within the cluster.
Serves as the central management hub for all cluster resources, including pods, services, deployments, and replica sets.
Provides authentication, authorization, and admission control functionalities for cluster security.
2. Kube Scheduler:
Function: Manages the scheduling of pods onto nodes within the cluster, based on resource requirements and constraints.
Responsibilities:
Watches for newly created pods with no assigned node then selects an appropriate node based on scheduling policies (e.g., resource availability, affinity, anti-affinity).
Considers node conditions, pod affinity/anti-affinity rules, and resource requirements during pod assignment.
Ensures optimal workload distribution across the cluster while adhering to configured policies and constraints.
3. Controller Manager:
Function: Runs various controllers that regulate the state of the cluster, ensuring that the actual state matches the desired state defined in Kubernetes objects.
Responsibilities:
Includes controllers for nodes, endpoints, namespaces, service accounts, and others.
Monitors the cluster's state through the API server, continuously working to reconcile current state with the desired state.
Implements control loops that handle routine tasks and automate corrective actions based on observed cluster state deviations.
4. ETCD:
Function: Consistent and highly available key-value store used as Kubernetes' backing store for all cluster data.
Responsibilities:
Stores configuration data representing the state of the Kubernetes cluster.
Ensures data persistence and provides high availability and consistency guarantees.
Facilitates distributed locking and leader election among Kubernetes components to maintain data integrity.
Worker Node Components
Function: Kubelet is an agent that runs on each worker node and ensures communication between the Kubernetes master node and the containers running on the node.
Responsibilities:
Manages the state of containers, ensuring they are running and healthy.
Handles container lifecycle events such as starting, stopping, and restarting containers.
Implements container execution according to the instructions provided by the Kubernetes master node.
Monitors containers for resource usage and reports metrics back to the master node.
2. Kube-Proxy:
Function: Kube-Proxy is a network proxy that runs on each worker node and manages network communications between the Kubernetes services and containers running on the node.
Responsibilities:
Implements Kubernetes service abstraction by maintaining network rules on nodes.
Performs TCP, UDP, and SCTP stream forwarding or round-robin forwarding across a set of backend pods.
Provides network connectivity to services and load balances traffic between application components.
Supports the implementation of Kubernetes networking models such as Virtual IP-based service abstraction and kube-proxy-based service.
3. Container Runtime:
Function: The container runtime is responsible for executing containers on the worker node. It interacts directly with the operating system kernel to manage container processes.
Responsibilities:
Pulls container images from container registries (like Docker Hub) onto the worker node.
Creates and manages containers based on specifications provided by Kubernetes (via Kubelet).
Handles resource isolation and allocation for containers, ensuring they have access to necessary resources (CPU, memory, etc.).
Monitors container health and reports status information to Kubernetes components.
What Happens in the Cluster When a User Sends a Request Using the Kubectl Command?
When a user sends a request to the Kubernetes cluster using the kubectl
command, the following happens:
Kubectl communicates with the API Server.
The API Server authenticates and validates the request.
If valid, the API Server writes the desired state to ETCD.
The Scheduler is notified of a new pod that needs to be scheduled and selects an appropriate node.
The Controller Manager ensures that the current state matches the desired state by creating, updating, or deleting resources.
The Kubelet on the chosen node receives instructions to create the pod.
The Kube-Proxy updates network rules to ensure the pod can communicate with other services.
How Control Plane Components Interact with Each Other in a Kubernetes Cluster
The control plane components interact continuously to manage the state of the cluster. For instance, the API Server serves as the communication hub, ensuring other components like the Scheduler and Controller Manager are aware of the cluster's state. The Controller Manager reconciles the desired state stored in ETCD with the actual state by instructing the Kubelet to make changes. The Kube-Proxy manages the networking aspects to maintain connectivity.
Pods and Containers: A Brief Write-up
Pods in Kubernetes encapsulate one or more containers, storage resources, a unique network IP, and options that govern how the container(s) should run. They represent a logical host for applications.
Containers are the runtime environments within pods that include everything needed to run the application, from the operating system to the application code.
References
Conclusion: Mastering Kubernetes Components
Today's journey through Kubernetes control plane components has provided us with a deeper understanding of how Kubernetes orchestrates and manages applications. From the role of the master and worker nodes to the interactions between various control plane components, we've covered the essential aspects that keep a Kubernetes cluster running smoothly. Stay tuned for tomorrow's insights as we continue our #40DaysOfKubernetes journey!
For further reference: https://youtu.be/SGGkUCctL4I?si=28_Ks3prxuW0M-RY
Subscribe to my newsletter
Read articles from SHRIRAM SAHU directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by