Back to Course

Certified Kubernetes Administrator CKA Exam Prep 2026

0% Complete
0/0 Steps
  1. Module 1 — Foundations of Kubernetes
    Why Kubernetes
  2. Cluster Architecture
  3. The API Server
  4. etcd
  5. Scheduler
  6. Controller Manager
  7. Kubelet
  8. Kube-proxy
  9. Container Runtime Interface (CRI)
  10. Module 2 — Core Objects & kubectl
    kubectl Fundamentals
  11. Pods
  12. Pods Lifecycle
  13. Namespaces
  14. ReplicaSets
  15. Deployments
  16. Rolling updates and rollbacks
  17. DaemonSets
  18. StatefulSets
  19. Jobs
  20. CronJobs
  21. Module 3 — Configuration & Application Lifecycle
    Imperative vs Declarative
  22. Labels and Selectors
  23. ConfigMaps
  24. Secrets
  25. Encrypting secrets at rest
  26. Injecting Configuration via Environment Variables
  27. Injecting Configuration via Volumes
  28. Liveness, readiness, and startup probes
  29. Init Containers
  30. Multi-container pod patterns
  31. Static Pods

Imagine you’re managing a city with thousands of workers and residents, each with their own tasks and responsibilities. To ensure that everything runs smoothly, the city has two major components: the Central Government (Control Plane) which makes all key decisions and sets the policies, and the Workers (Worker Nodes) who carry out the work that keeps the city running. Just like in this analogy, in Kubernetes, the Control Plane oversees the entire system, making decisions and maintaining the state, while the Worker Nodes actually run the containers, which execute the application workloads.

Learning Objectives:

By the end of this lesson, you will be able to:

  • Define what a Kubernetes cluster is and its basic architecture.
  • Understand the role of the Control Plane and its components in managing the cluster.
  • Learn about Worker Nodes and their responsibilities in executing workloads.
  • Identify the main components of both the Control Plane and Worker Nodes.
  • Understand how the Control Plane and Worker Nodes interact to maintain a healthy, functional Kubernetes cluster.

In this lesson, we’re going to explore the fundamental architecture of Kubernetes: Control Plane vs Worker Nodes, and break down what each part of the cluster does. This is the core foundation you’ll need to understand before diving deeper into the inner workings of Kubernetes.

What is a Kubernetes Cluster?

Before we dive into the specifics of Kubernetes architecture, let’s first understand what a Kubernetes cluster is.

A Kubernetes cluster is a set of machines (physical or virtual) that work together to run containerized applications. Kubernetes itself is responsible for managing and orchestrating these containers across all the machines in the cluster. It does so by splitting the responsibilities between two main components:

  • Control Plane — The brain of the cluster, responsible for making decisions and managing the state of the cluster.
  • Worker Nodes — The muscle of the cluster, responsible for running the actual containers (via Pods), executing the workloads.

Together, these components ensure that your containers run smoothly and scale based on your application’s needs. Kubernetes handles everything from deploying applications to managing failures and scaling up or down as needed.

1. The Control Plane — The Brain of the Cluster

The Control Plane is responsible for controlling and managing the Kubernetes cluster. It is in charge of making global decisions about the cluster, such as:

  • What should run where.
  • How resources should be allocated.
  • When to scale applications.

Key components of the Control Plane include:

  • API Server (kube-apiserver): The front door to the Kubernetes cluster. All commands and requests made to the cluster, whether from users, applications, or other components, are sent to the API Server. It acts as the central communication hub, receiving requests from users or other systems and forwarding them to the appropriate components. The API Server exposes the Kubernetes REST API, making it the primary way to interact with the cluster. Think of it as the traffic controller: it ensures that everything is directed to the right place.

  • etcd: etcd is the key-value store for Kubernetes. It holds all the state data of the cluster, such as information about the cluster’s nodes, Pods, and services. The etcd database is critical for the consistency of the cluster. If the cluster state gets lost or corrupted, the entire system could fail. It’s essentially the memory of Kubernetes, storing all configuration data and state information. Without etcd, Kubernetes cannot manage its resources effectively because it has no record of its state.

  • Scheduler (kube-scheduler): The Scheduler is responsible for deciding which node will run a Pod. It looks at various factors such as available resources (CPU, memory, etc.), pod affinity/anti-affinity rules, and other constraints to determine the most appropriate Worker Node for each Pod. It’s like a project manager deciding where each task should be performed based on resources and priorities.

  • Controller Manager (kube-controller-manager): The Controller Manager watches the state of the cluster and ensures it matches the desired state. If there’s any mismatch, the controller manager takes action to bring the cluster back to the desired state. For example, if a Pod crashes, the controller manager ensures a new Pod is started to replace it. It’s like a taskmaster ensuring everything in the cluster is running as expected.

2. Worker Nodes — The Muscle of the Cluster

The Worker Nodes are where the actual applications (containers) run. These nodes are responsible for executing workloads and running the containers that make up your applications. Each Worker Node has the following key components:

  • Kubelet (kubelet): The Kubelet is an agent that runs on each Worker Node. It ensures that containers are running as specified by the Control Plane. The Kubelet watches the API Server for PodSpecs assigned to its node, then takes action to ensure those containers are running correctly. It is responsible for the health of the containers running on its node and makes sure they are up to date and functioning correctly. Think of it as a worker supervisor, ensuring tasks are carried out properly on each node.

  • Kube-Proxy (kube-proxy): The Kube-Proxy is responsible for handling network traffic to and from the containers. It routes traffic to the correct container based on IP addresses and ports, ensuring that communication between services and Pods is seamless. It also handles load balancing and manages network policies that define how containers can communicate with each other. You can think of it as the network dispatcher, ensuring that the right requests get to the right containers.

  • Container Runtime: The Container Runtime is responsible for running containers on the Worker Nodes. It pulls container images from a container registry, starts containers, and manages their lifecycle. Modern Kubernetes uses containerd or CRI-O as container runtimes, with containerd being the most widely used today. This is the engine that powers the containerized applications and ensures they are running correctly.

How Control Plane and Worker Nodes Work Together

cluster-architecture

In this diagram, you can see the separation between the Control Plane and Worker Nodes in a Kubernetes cluster. The Control Plane (API Server, etcd, Scheduler, and Controller Manager) is shown at the top, overseeing the entire cluster, while the Worker Nodes run the actual workloads, with the Kubelet and Kube-Proxy ensuring proper execution and networking. This architecture ensures that the Control Plane can handle decisions and orchestration, while the Worker Nodes focus on execution.

The Control Plane and Worker Nodes are intricately connected and work together to maintain a healthy and functional cluster:

  • The Kubelet on each Worker Node watches the API Server for PodSpecs assigned to its node and ensures the specified containers are running correctly.
  • The Scheduler assigns Pods to Worker Nodes based on resource availability and the configuration defined by the user.
  • The Controller Manager continuously monitors the cluster through the API Server and takes corrective action whenever the actual state drifts from the desired state.
  • The Kube-Proxy ensures that network communication flows smoothly between Pods, Services, and external resources.

Summary:

To summarize the key points:

A Kubernetes cluster consists of two main components:

  • Control Plane (brain): It manages the cluster’s state and makes global decisions, such as which nodes should run which Pods.
  • Worker Nodes (muscle): These nodes execute the actual workloads, running the containers and performing the tasks assigned by the Control Plane.

Control Plane includes:

  • API Server: Handles all requests and communication in the cluster.
  • etcd: Stores all configuration data and state information.
  • Scheduler: Decides where to run the Pods based on available resources.
  • Controller Manager: Ensures the desired state of the cluster is maintained.

Worker Nodes include:

  • Kubelet: Watches the API Server for assigned PodSpecs and ensures containers are running correctly.
  • Kube-Proxy: Handles networking and routing traffic between Pods.
  • Container Runtime: Runs the containers on the nodes (commonly containerd or CRI-O).

These components work together to ensure the reliability, scalability, and performance of your containerized applications.

Next Steps:

Now that you have a deep understanding of the Kubernetes cluster architecture, including the roles of the Control Plane and Worker Nodes, the next lesson will dive into the API Server, the core component of the Control Plane, and explore its critical role in managing requests and state across the cluster.

Skip to content