Kubernetes Architecture: Control Plane and Worker Nodes
Kubernetes, the de facto standard for container orchestration, operates on a distributed architecture comprising two primary types of nodes: the Control Plane (formerly Master) and Worker Nodes. This division is fundamental to how Kubernetes manages, scales, and deploys containerized applications.
The Control Plane: The Brains of the Operation
The Control Plane is the central nervous system of a Kubernetes cluster. It makes global decisions about the cluster (for example, scheduling) and detects and responds to cluster events. It consists of several key components, each with a distinct responsibility:
API Server (kube-apiserver)
The API Server is the front end of the Kubernetes control plane. It exposes the Kubernetes API, which is used by all other components to communicate with each other. It is the only component that talks to etcd. All other components communicate with the API Server.
Scheduler (kube-scheduler)
The Scheduler is responsible for watching for newly created Pods that have no Node assigned. For every Pod that the scheduler discovers, it finds a suitable Node for that Pod to run on. The scheduler makes its decision based on resource requirements, policies, and affinity/anti-affinity specifications.
Control Manager (kube-controller-manager)
The Control Manager runs controller processes. Logically, each controller is a separate process, but to reduce complexity, they are compiled into a single binary and run in a single process. These controllers include:
- Node Controller: Responsible for noticing and responding when nodes go down.
- Replication Controller: Responsible for ensuring that the specified number of Pods for every Replication Controller object are running.
- Endpoints Controller: Populates the Endpoints object (which joins Services & Pods).
- Service Account & Token Controllers: Create default accounts and API access tokens for new namespaces.
etcd
etcd is a consistent and highly-available key-value store used as Kubernetes' backing store for all cluster data. It stores the configuration data, state, and metadata of the cluster. It is crucial for cluster operation, and its availability directly impacts the cluster's health. Think of etcd as the cluster's authoritative memory; if etcd is lost, the cluster's state is lost.
Worker Nodes: The Workhorses
Worker Nodes are the machines (physical or virtual) where your containerized applications actually run. Each worker node runs the necessary components to support Pods and is managed by the Control Plane. A typical worker node includes the following components:
Container Runtime
The Container Runtime is the software responsible for running containers. Kubernetes supports various container runtimes, including Docker, containerd, and CRI-O. Containerd is a popular choice due to its lightweight nature and integration capabilities. This component is essential as it allows Pods to execute their containerized workloads.
Kubelet
Kubelet is an agent that runs on each worker node. It ensures that containers described in PodSpecs are running and healthy. Kubelet communicates with the API Server to receive Pod definitions and reports the status of the node and its Pods back to the Control Plane. It does not manage containers that were not created by Kubernetes.
Kube-proxy
Kube-proxy is a network proxy that runs on each worker node. It maintains network rules on nodes, allowing network communication to your Pods from inside or outside the cluster. It handles network routing and load balancing for Services, ensuring that traffic directed to a Service is correctly forwarded to one of its backing Pods.
Pods and Node Processes
Every node in a Kubernetes cluster hosts multiple Pods. A Pod is the smallest deployable unit in Kubernetes, representing a single instance of a running process in a cluster. It can contain one or more tightly coupled containers that share resources like network namespace and storage volumes.
The three core processes that must be installed and running on every node (both Control Plane and Worker) are the API Server, Scheduler, and Control Manager (running on the Control Plane), and Kubelet and Kube-proxy (running on the Worker Nodes). These processes work in concert to ensure that applications are deployed, managed, and scaled effectively across the cluster.
The separation of concerns between the Control Plane and Worker Nodes allows for robust scalability and resilience. The Control Plane focuses on cluster management and orchestration, while Worker Nodes are dedicated to running the actual application workloads, making the system highly efficient.
The Interplay of Components
When a user or an automated process creates a new application deployment, the request first hits the API Server. The API Server validates the request and stores the desired state in etcd. The Scheduler then watches for new Pods without assigned nodes and selects the best worker node based on resource availability and policies. Once a node is selected, Kubelet on that node receives the Pod specification and instructs the Container Runtime to start the necessary containers. Kube-proxy ensures that network traffic can reach these Pods via Services. The Control Manager continuously monitors the cluster's actual state against the desired state stored in etcd, reconciling any discrepancies by triggering actions like restarting failed Pods or scaling deployments.
This intricate dance of components ensures that Kubernetes can manage complex distributed systems with a high degree of automation and reliability. Understanding these core architectural pieces is crucial for anyone looking to deploy and manage applications at scale.