When I started learning Kubernetes, I kept coming across terms like Cluster, Node, Pod, API Server, Scheduler, and Controller Manager.
At first, these concepts seemed confusing. What is the difference between a Node and a Pod? Where do containers actually run? And how do all these components work together?
In this article, I'll explain the fundamentals of Kubernetes architecture using simple examples.
1. What Is Kubernetes?
Kubernetes is an open-source platform for deploying, managing, and scaling containerized applications.
Imagine you have developed a REST API using Java and Spring Boot. You package the application into a container, but you still need to manage its deployment, availability, scaling, and networking.
Kubernetes helps automate many of these tasks.
For example, you can tell Kubernetes that you want three instances of your application running. Kubernetes works to maintain that desired state and can create replacement Pods when necessary.
Now, let's understand the building blocks that make this possible.
2. What Is a Kubernetes Cluster?
A Kubernetes cluster is a group of machines that work together to run and manage applications.
A cluster generally consists of two main parts:
- Control Plane: Manages the cluster and coordinates workloads.
- Worker Nodes: Provide the environment where application workloads run.
Think of a cluster as the entire system.
The control plane manages the cluster, while worker nodes provide the resources needed to run applications.
3. What Is a Node?
A Node is a physical or virtual machine in a Kubernetes cluster.
Each node provides resources such as CPU, memory, and networking.
There are two common node roles:
Control Plane Node
The control plane runs components responsible for managing the cluster, such as the API Server and Scheduler.
In production environments, the control plane may consist of multiple machines for high availability.
Worker Node
Worker nodes run application workloads, usually through Pods.
For example, one worker node might run two Pods containing instances of a Java application, while another worker node runs a third instance.
The key idea: A Node is a machine that belongs to the Kubernetes cluster.
4. What Is a Pod?
A Pod is the smallest deployable unit in Kubernetes.
A Pod contains one or more containers. These containers share certain resources, including the Pod's network namespace, and can communicate with each other through localhost.
For example, imagine a Java Spring Boot REST API packaged into a container.
Kubernetes can run that container inside a Pod.
If we want multiple instances of our application, Kubernetes can run multiple Pods.
Although a Pod can contain multiple containers, many applications use one main application container per Pod.
Pods are also relatively temporary. They can be replaced when an application is rescheduled or when a workload needs to recover from a failure.
The key idea: A Pod is the unit Kubernetes schedules onto a Node to run your application containers.
5. Understanding the Relationship: Cluster vs. Node vs. Pod
Let's put these concepts together.
Imagine a Kubernetes cluster with two worker nodes:
- Worker Node 1 runs two application Pods.
- Worker Node 2 runs one application Pod.
- Each Pod contains a container running an instance of our Spring Boot application.
The simplified hierarchy looks like this:
Cluster → Worker Nodes → Pods → Containers
Remember that the cluster also contains the control plane, which manages the workloads.
This example illustrates the relationship between the concepts; the actual placement of Pods depends on the cluster configuration and available resources.
6. What Is a Kubernetes Namespace?
A Namespace is a way to organize and separate resources within a Kubernetes cluster. It allows multiple applications, teams, or environments to share the same cluster while keeping their resources logically separated.
For example, a team might use separate namespaces for development, testing, and production.
Kubernetes Cluster
│
├── Namespace: development
│ ├── Pod: app-pod
│ └── Pod: database-pod
│
├── Namespace: testing
│ └── Pod: app-pod
│
└── Namespace: production
├── Pod: app-pod
└── Pod: database-pod
Although two Pods can have the same name in different namespaces, their names must be unique within the same namespace.
Why are namespaces useful?
- Organization: Group related Kubernetes resources together.
- Isolation: Separate resources belonging to different teams or environments.
- Access control: Apply permissions to resources within a namespace using Kubernetes RBAC.
- Resource management: Apply resource quotas and limits to a namespace.
Kubernetes includes namespaces such as default, kube-system, and kube-public. Most application resources are created in default unless another namespace is specified.
For example, create a namespace and deploy a Pod into it:
kubectl create namespace development
kubectl run my-app --image=nginx --namespace=development
kubectl get pods --namespace=development
Remember: A namespace provides logical organization and separation, but it does not automatically guarantee network isolation. Network policies and appropriate access controls may be needed for stronger isolation.
Cluster vs. Namespace Architecture
┌────────────────────────────────────────────────────────────────────────┐
│ ONE KUBERNETES CLUSTER │
│ (Shares the same physical hardware, nodes, memory, and CPU) │
│ │
│ ┌─────────────────────────┐ ┌──────────────────────────┐ │
│ │ "development" Namespace│ │ "production" Namespace │ │
│ │ │ │ │ │
│ │ ┌────────┐ ┌────────┐ │ │ ┌────────┐ ┌────────┐ │ │
│ │ │ Pod A │ │ Pod B │ │ │ │ Pod X │ │ Pod Y │ │ │
│ │ └────────┘ └────────┘ │ │ └────────┘ └────────┘ │ │
│ └─────────────────────────┘ └──────────────────────────┘ │
│ │
│ ┌─────────────────────────┐ ┌──────────────────────────┐ │
│ │ "testing" Namespace │ │ "kube-system" Namespace│ │
│ │ │ │ (Internal K8s systems) │ │
│ └─────────────────────────┘ └──────────────────────────┘ │
└────────────────────────────────────────────────────────────────────────┘
7. What Are the Core Components of Kubernetes?
Now that we understand clusters, nodes, and Pods, let's look at the components that make Kubernetes work.
Control Plane Components
The control plane manages the cluster and helps maintain its desired state.
7.1 kube-apiserver — The Entry Point
The API Server exposes the Kubernetes API.
Tools such as kubectl communicate with the cluster through it.
When you submit a configuration to create an application, the API Server processes the request, including the relevant validation and access-control checks.
It acts as the main communication hub for Kubernetes API operations.
7.2 kube-scheduler — The Decision Maker
The Scheduler selects a suitable Node for each newly created Pod that needs scheduling.
It considers factors such as available CPU and memory, scheduling constraints, and other placement rules.
An important distinction: the Scheduler chooses the Node. It does not start the container itself.
7.3 kube-controller-manager — The Reconciliation Engine
Kubernetes works toward maintaining the desired state of the cluster.
For example, suppose you request three replicas of your application. If one Pod disappears, the relevant controller can work toward restoring the requested number.
The controller manager runs several controllers that continuously observe the cluster and take action when the actual state differs from the desired state.
7.4 etcd — The Cluster Data Store
etcd is a distributed key-value store used to persist Kubernetes cluster state and configuration data.
It stores information about Kubernetes resources, including Deployments and other objects.
The control plane relies on this stored information to coordinate the cluster.
Worker Node Components
Worker nodes run the workloads and include components that help manage their execution.
7.5 kubelet — The Node Agent
The kubelet runs on each node and communicates with the control plane.
When a Pod is assigned to a Node, the kubelet works with the container runtime to ensure that the containers described by the Pod are running as expected.
It also reports relevant status information.
6.6 Container Runtime — Running Containers
The container runtime is responsible for running containers.
Examples include containerd and CRI-O.
The kubelet communicates with the runtime through the Container Runtime Interface (CRI).
7.7 kube-proxy — Service Networking
In many Kubernetes clusters, kube-proxy maintains network rules that support Kubernetes Service traffic.
However, kube-proxy is not required in every cluster. Some networking implementations provide equivalent functionality without it.
8. How Do These Components Work Together?
Let's walk through a simplified example of deploying a Spring Boot REST API.
Step 1: Submit the configuration
You create a Deployment manifest and run:
kubectl apply -f deployment.yaml
Step 2: The API Server processes the request
The API Server validates and processes the request. Kubernetes persists the relevant cluster state in etcd.
Step 3: Controllers work toward the desired state
The Deployment controller creates or updates a ReplicaSet, which works to maintain the requested number of Pods.
Step 4: The Scheduler selects a Node
The Scheduler assigns each newly created, unscheduled Pod to a suitable Node.
Step 5: The kubelet starts the workload
The kubelet on the selected Node works with the container runtime to pull the required image when necessary and start the containers.
Step 6: Kubernetes monitors the workload
Kubernetes continues monitoring the state of the cluster. Controllers work to keep the actual state aligned with the desired state.
Step 7: The application becomes accessible
When configured appropriately, a Kubernetes Service provides a stable way to access the application Pods.
This is the important point: Kubernetes does not simply start containers and stop working. Its components continuously cooperate to manage the application lifecycle.
9. What Happens If a Pod or Node Fails?
Imagine you have requested three replicas of your application.
If a Pod fails, Kubernetes can work to replace it, depending on the workload configuration.
If a worker Node becomes unhealthy, Kubernetes can eventually arrange for replacement Pods to run on other suitable Nodes.
However, recovery is not instantaneous or guaranteed. It depends on factors such as cluster capacity, scheduling rules, health detection, storage requirements, and application configuration.
This is why running multiple replicas across suitable Nodes can be important for application resilience.
10. Final Summary
Let's summarize the main concepts:
- Cluster: The complete Kubernetes environment.
- Node: A physical or virtual machine in the cluster.
- Pod: The smallest deployable unit, containing one or more containers.
- API Server: Exposes and processes Kubernetes API requests.
- Scheduler: Selects suitable Nodes for unscheduled Pods.
- Controller Manager: Runs controllers that reconcile the cluster toward its desired state.
- etcd: Persists cluster state.
- kubelet: Ensures assigned Pods run as expected on a Node.
- Container Runtime: Runs containers.
- kube-proxy: Supports Service networking in clusters that use it.
Understanding these components provides a foundation for learning more advanced Kubernetes concepts, such as Deployments, Services, ConfigMaps, Secrets, health probes, and autoscaling.
For me, the most useful way to understand Kubernetes is to connect each component to the problem it solves rather than memorize a list of names.
I'm continuing to explore Kubernetes and cloud-native development, and I'll be sharing more practical concepts as I learn.
Top comments (0)