Kubernetes Architecture

Kubernetes is a powerful container orchestration platform that automates the deployment, scaling, and management of containerized applications. At its core, Kubernetes follows a client-server architecture consisting of master and worker nodes that work together to maintain the desired state of your applications.

1. Master and Worker Nodes

Kubernetes clusters are composed of two types of nodes:

1.1. Master Node (Control Plane)

The master node is the brain of the Kubernetes cluster. It makes global decisions about the cluster, detects and responds to cluster events, and manages the worker nodes. A cluster typically has multiple master nodes for high availability.

Master Node (control plane)

2.1. Worker Nodes

Worker nodes are the machines (VMs or physical servers) that run your containerized applications. Each worker node contains the necessary services to manage the networking between containers, communicate with the master node, and assign resources to the containers scheduled on them.

Worker Nodes

2. Key Components of the Control Plane

2.1. API Server

The API Server is the front-end of the Kubernetes control plane and the only component that communicates directly with the etcd datastore. It exposes the Kubernetes API which is used by:

• Internal cluster components
• External users via kubectl
• Other applications through API calls

API Server

It processes REST operations, validates them, and updates the corresponding objects in etcd.

2.2. Controller Manager

The Controller Manager runs controller processes that regulate the state of the cluster. Each controller is a separate process but they're compiled into a single binary. Key controllers include:

• Node Controller: Manages node status
• Replication Controller: Maintains correct pod count
• Endpoint Controller: Populates Endpoint objects
• Service Account & Token Controllers: Create default accounts and API access tokens

Controller Manager

2.3. Scheduler

The Scheduler watches for newly created Pods with no assigned node, and selects a node for them to run on. Factors taken into account for scheduling decisions include:

• Resource requirements and limits
• Hardware/software policy constraints
• Affinity and anti-affinity specifications
• Data locality
• Deadlines

Scheduler component

3. Etcd and Kubelet

3.1. Etcd

Etcd is a consistent and highly-available key-value store used as Kubernetes' backing store for all cluster data. It stores the entire configuration and state of the cluster. Etcd is the source of truth for the cluster, and all other components watch etcd for changes to bring the current state of the cluster to the desired state.

Etcd

3.2. Kubelet

The Kubelet is an agent that runs on each worker node in the cluster. It ensures that containers are running in a Pod. The Kubelet takes a set of PodSpecs (provided through various mechanisms) and ensures that the containers described in those PodSpecs are running and healthy. The Kubelet doesn't manage containers that were not created by Kubernetes.

Kubelet

4. Putting It All Together

When a user submits a deployment request via kubectl, the API server validates and stores it in etcd. The controller manager detects the change and works to achieve the desired state, while the scheduler assigns pods to appropriate nodes. On each node, the kubelet works with the container runtime to ensure the specified containers are running and healthy.

This architecture allows Kubernetes to provide a robust, scalable platform for deploying and managing containerized applications with high availability and resilience.

5. Hands-On Exercise: Explore Kubernetes Components with kubectl

Now that you understand the Kubernetes architecture, let’s practice by exploring its components using the kubectl command-line tool. Run the following commands step by step to check each part of the cluster:

Component	kubectl Command	What It Shows
Nodes	kubectl get nodes -o wide	Lists all master and worker nodes with details (status, roles, resources).
API Server	kubectl cluster-info	Shows the API server address and cluster information.
Controller Manager	kubectl get pods -n kube-system | grep controller	Checks if the controller manager pod is running in the control plane.
Scheduler	kubectl get pods -n kube-system | grep scheduler	Verifies that the scheduler is active in the cluster.
Etcd	kubectl get pods -n kube-system | grep etcd	Shows the etcd pod responsible for storing cluster state.
Kubelet	kubectl describe node <node-name>	Displays detailed node info, including kubelet status.
All System Pods	kubectl get pods -n kube-system	Lists all Kubernetes system components running in the cluster.

Try running each command and note the output. This exercise helps reinforce the concepts you just learned by connecting them to real cluster components.

Note: To understand any kubectl option, you can use the built-in help or the official docs. For example, if you see -o wide in a command and want to know what it does, run:

kubectl get nodes --help

This will display all available options for kubectl get nodes, including the -o flag (output format), which can be wide, json, yaml, etc. You can also check the official documentation here: kubectl Command Reference.