Kubernetes: Control Planes and Workers

In Kubernetes, the control plane and worker nodes are two key components that together form the foundation of a Kubernetes cluster.

They play distinct roles in managing and running containerized applications.

Here’s an explanation of each component along with examples and YAML configurations where relevant:

Control Plane

The control plane is the brain of the Kubernetes cluster. It manages the overall state of the cluster, makes decisions about where to schedule workloads, and ensures that the desired state (defined in your YAML manifests) matches the actual state of the cluster.

The control plane components include the following objects:

API Server

The API server is the entry point for all communication with the cluster. It exposes the Kubernetes API and is responsible for validating and processing requests.

Etcd

Etcd is a distributed key-value store that stores the entire configuration and state of the cluster. It is used by the control plane components to read and write cluster data.

Controller Manager

This component watches the cluster’s desired state through the API server and ensures that the actual state matches it. For example, it manages replication controllers, ensuring the specified number of pod replicas are running.

Scheduler

The scheduler is responsible for determining where to place newly created pods based on resource requirements, constraints, and policies. It assigns pods to worker nodes.

Here's an example of a YAML file for a Kubernetes deployment that specifies a control plane component:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-controller-manager
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-controller-manager
  template:
    metadata:
      labels:
        app: my-controller-manager
    spec:
      containers:
      - name: my-controller-manager
        image: my-controller-manager-image:tag

Worker Nodes

Worker nodes, also known as minions, are responsible for running containers and hosting the application workloads.
They receive instructions from the control plane components and execute them.
Each worker node typically runs a container runtime (e.g., Docker or containers) to manage containers and the kubelet, which communicates with the control plane.

A minimal explanation is necessary to enforce the concept. So, we need aboard about Kubelet and Container runtime, without forgetting storage, network, node management and maintenance. I start with two mains, and then we will continue to expand in depth in the next articles.

The Kubelet is an agent that runs on each worker node. It communicates with the control plane and ensures that containers are running in a pod as expected.

It also reports the node’s health and resource usage.

The Container Runtime is responsible for managing containers on the node. Kubernetes supports various container runtimes, including Docker and contained.

Here’s a table listing the main functions of worker nodes in Kubernetes along with a brief explanation of each function, including the cordon and uncordon features:

Function	Description
Container Runtime	Manages containers on the node, including starting, stopping, and monitoring them.
Kubelet	Acts as an agent on each node, responsible for ensuring pods are running as expected, and reporting node health and resource usage to the control plane.
Proxy (kube-proxy)	Maintains network rules on the node to enable communication between pods and services within the cluster.
Volume Management	Manages storage volumes and attaches them to pods as necessary.
Cordon/Uncordon	`Cordon` is a feature that marks a node as un-schedulable, preventing new pods from being scheduled onto it. `Uncordon` reverses this and allows new pod scheduling on the node. Useful for maintenance or troubleshooting.

These functions collectively enable worker nodes to execute and manage containers while maintaining the health and availability of applications within the Kubernetes cluster.