Kubernetes architecture (control plane and nodes) - Step-by-Step Execution

Process Flow - Kubernetes architecture (control plane and nodes)

User/Client

↓

API Server

↓

Controller Manager

↓

etcd (Data Store)

↓

Kubelet

↓

Container Runtime

The control plane manages the cluster state and schedules work. Nodes run the actual containers. Communication flows from user to API server, then to scheduler and controllers, and finally to nodes.

Execution Sample

Kubernetes

# Control Plane Components
kubectl get componentstatuses

# Node Components
kubectl get nodes
kubectl describe node <node-name>

Commands to check the health of control plane components and view node details.

Process Table

Step	Component	Action	Input	Output/Effect
1	User/Client	Sends request	kubectl apply -f pod.yaml	Request received by API Server
2	API Server	Validates and processes	Pod spec from user	Stores desired state in etcd
3	Scheduler	Watches API Server	New pod without node assignment	Assigns pod to a suitable node
4	Controller Manager	Monitors cluster state	Pod assigned to node	Ensures pod is running, creates replicas if needed
5	etcd	Stores cluster state	Desired and current states	Persistent data storage for cluster
6	Kubelet (Node)	Receives pod assignment	Pod spec from API Server	Starts containers via container runtime
7	Container Runtime	Runs containers	Container images and commands	Containers running inside pods
8	User/Client	Checks status	kubectl get pods	Shows pod running status
9	Exit	No more actions	All pods scheduled and running	Cluster stable and operational

💡 All pods are scheduled and running; cluster state matches desired state.

Status Tracker

Component	Initial State	After Step 2	After Step 3	After Step 6	Final State
API Server	Idle	Received pod spec	Pod scheduled	Pod spec sent to node	Processed requests
Scheduler	Idle	No pod to schedule	Assigned pod to node	Waiting for next pod	Ready for next scheduling
Controller Manager	Idle	No action	Monitors pod state	Ensures pod running	Maintains desired replicas
Kubelet	Idle	No pod assigned	Waiting for pod	Starts container	Pod running
etcd	Stores cluster data	Updated desired state	Updated with node assignment	Updated with pod status	Persistent cluster state

Key Moments - 3 Insights

Why does the Scheduler assign pods after the API Server stores the pod spec?

Because the Scheduler watches the API Server for new pods without node assignments (see execution_table step 3). It needs the pod spec stored first to decide where to place the pod.

How does the Kubelet know what containers to run?

The Kubelet receives the pod spec from the API Server after scheduling (step 6). It uses this spec to start containers via the container runtime.

What role does etcd play in the cluster?

etcd stores the desired and current cluster state persistently (step 5). It acts as the single source of truth for the cluster.

Visual Quiz - 3 Questions

Look at the execution_table at step 3. What does the Scheduler do?

A Starts the container runtime

B Stores the pod spec in etcd

C Assigns the pod to a suitable node

D Validates the pod spec

💡 Hint

Refer to execution_table row with Step 3 under 'Action' and 'Output/Effect'

At which step does the Kubelet start containers on a node?

A Step 2

B Step 6

C Step 4

D Step 8

💡 Hint

Check execution_table row with Step 6 for Kubelet actions

If the etcd component fails, what is the likely impact?

A Cluster state cannot be stored or retrieved

B Pods will not be scheduled

C Containers will not start on nodes

D User requests will be ignored

💡 Hint

Look at the role of etcd in execution_table step 5 and variable_tracker

Concept Snapshot

Kubernetes architecture has two main parts:
- Control Plane: API Server, Scheduler, Controller Manager, etcd store cluster state and manage scheduling.
- Nodes: Run Kubelet and container runtime to run pods.
User requests go to API Server, which stores desired state in etcd.
Scheduler assigns pods to nodes.
Kubelet runs containers as per pod specs.

Full Transcript

Kubernetes architecture consists of a control plane and worker nodes. The control plane includes the API Server, Scheduler, Controller Manager, and etcd. Users send commands to the API Server, which validates and stores the desired state in etcd. The Scheduler watches for new pods and assigns them to nodes. The Controller Manager ensures the cluster state matches the desired state. Worker nodes run the Kubelet, which receives pod specs and starts containers using the container runtime. etcd stores all cluster data persistently. This flow ensures the cluster runs as expected with pods scheduled and containers running on nodes.

Practice

1. Which component of Kubernetes is responsible for deciding what runs and where?

easy

A. Container runtime

B. Node

C. Pod

D. Control plane

Solution

1. Step 1: Understand Kubernetes architecture roles

   The control plane manages the cluster and makes decisions about scheduling and managing workloads.

2. Step 2: Identify the component that schedules workloads

   The control plane includes the scheduler which decides what runs and where.

3. Final Answer:

   Control plane -> Option D

4. Quick Check:

   Control plane = workload decision maker [OK]

Hint: Control plane manages; nodes run workloads [OK]

Common Mistakes:

• Confusing nodes with control plane
• Thinking containers decide scheduling
• Mixing pods with control plane

2. Which of the following is a correct component of the Kubernetes control plane?

easy

A. etcd

B. kube-proxy

C. kubelet

D. containerd

Solution

1. Step 1: List control plane components

   Control plane includes etcd, kube-apiserver, kube-controller-manager, and kube-scheduler.

2. Step 2: Identify which option is part of control plane

   etcd stores cluster data and is part of the control plane.

3. Final Answer:

   etcd -> Option A

4. Quick Check:

   etcd = control plane data store [OK]

Hint: etcd stores data in control plane [OK]

Common Mistakes:

• Confusing kubelet as control plane
• Thinking kube-proxy is control plane
• Mixing container runtime with control plane

3. Given a Kubernetes cluster, which component runs on each node to ensure containers are running properly?

medium

A. kubelet

B. kube-apiserver

C. kube-scheduler

D. etcd

Solution

1. Step 1: Identify node components

   Nodes run components like kubelet and kube-proxy to manage containers and networking.

2. Step 2: Determine which component manages container lifecycle on nodes

   kubelet runs on each node and ensures containers are running as expected.

3. Final Answer:

   kubelet -> Option A

4. Quick Check:

   kubelet = node container manager [OK]

Hint: kubelet runs on nodes to manage containers [OK]

Common Mistakes:

• Confusing kube-apiserver as node component
• Thinking scheduler runs on nodes
• Mixing etcd with node components

4. You notice pods are not starting on a node. Which component should you check first for errors on that node?

medium

A. kube-scheduler

B. kubelet

C. kube-apiserver

D. etcd

Solution

1. Step 1: Understand pod startup process

   Pods are started and managed on nodes by the kubelet component.

2. Step 2: Identify component to check for node pod issues

   Since pods fail to start on a node, kubelet logs and status should be checked first.

3. Final Answer:

   kubelet -> Option B

4. Quick Check:

   kubelet manages pods on nodes [OK]

Hint: Check kubelet logs for node pod issues [OK]

Common Mistakes:

• Checking scheduler instead of kubelet
• Looking at etcd for node pod errors
• Confusing apiserver with node issues

5. In a Kubernetes cluster, if the control plane node fails, which of the following is true?

hard

A. New pods can still be scheduled on nodes

B. Nodes automatically become control planes

C. Existing pods continue running but no new scheduling occurs

D. All pods immediately stop running

Solution

1. Step 1: Understand control plane failure impact

   The control plane manages scheduling and cluster state but nodes run pods independently.

2. Step 2: Analyze pod behavior when control plane is down

   Existing pods keep running on nodes, but no new pods can be scheduled without control plane.

3. Final Answer:

   Existing pods continue running but no new scheduling occurs -> Option C

4. Quick Check:

   Control plane down = no new scheduling, pods run [OK]

Hint: Control plane down stops scheduling, not running pods [OK]

Common Mistakes:

• Thinking pods stop immediately
• Assuming nodes become control planes
• Believing new pods schedule without control plane