Kubernetes Architecture Complete Guide: Control Plane, Node & Components Explained

To master Kubernetes, the first step is understanding its architecture.

Many people get stuck here: seeing a bunch of component names—API Server, etcd, kubelet—without knowing what each does or how they work together.

This article will walk you through every important Kubernetes component in the clearest way possible.

For a basic introduction to Kubernetes, see Kubernetes Complete Guide.

---

Architecture Overview: Control Plane vs Worker Node

A Kubernetes cluster consists of two types of roles:

Role	Function	Analogy
Control Plane	Decision center	Company headquarters
Worker Node	Execute work	Branch offices

Control Plane

The Control Plane is the brain of Kubernetes.

It's responsible for:

• Receiving user commands
• Storing the state of the entire cluster
• Deciding where Pods should run
• Monitoring and maintaining the desired state

Components included:

• API Server
• etcd
• Scheduler
• Controller Manager

Worker Node

Worker Nodes are where containers actually run.

They're responsible for:

• Running assigned Pods
• Reporting Pod status to the Control Plane
• Handling network traffic

Components included:

• kubelet
• kube-proxy
• Container Runtime

Architecture Diagram

┌─────────────────────────────────────────────────────────────┐
│                      Control Plane                          │
│  ┌──────────────┐  ┌────────┐  ┌───────────┐  ┌──────────┐ │
│  │  API Server  │  │  etcd  │  │ Scheduler │  │Controller│ │
│  │              │  │        │  │           │  │ Manager  │ │
│  └──────────────┘  └────────┘  └───────────┘  └──────────┘ │
└─────────────────────────────────────────────────────────────┘
                              │
                              │ API Communication
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                       Worker Nodes                          │
│  ┌─────────────────────────┐  ┌─────────────────────────┐  │
│  │       Node 1            │  │       Node 2            │  │
│  │  ┌───────┐ ┌─────────┐  │  │  ┌───────┐ ┌─────────┐  │  │
│  │  │kubelet│ │kube-proxy│  │  │  │kubelet│ │kube-proxy│  │  │
│  │  └───────┘ └─────────┘  │  │  └───────┘ └─────────┘  │  │
│  │  ┌─────────────────┐    │  │  ┌─────────────────┐    │  │
│  │  │Container Runtime│    │  │  │Container Runtime│    │  │
│  │  └─────────────────┘    │  │  └─────────────────┘    │  │
│  │  ┌─────┐ ┌─────┐        │  │  ┌─────┐ ┌─────┐        │  │
│  │  │ Pod │ │ Pod │        │  │  │ Pod │ │ Pod │        │  │
│  │  └─────┘ └─────┘        │  │  └─────┘ └─────┘        │  │
│  └─────────────────────────┘  └─────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘

Key understanding:

All communication between components goes through the API Server. No component directly communicates with another (except API Server accessing etcd).

---

Control Plane Four Core Components Explained

The Control Plane has four core components, each with clear responsibilities.

API Server (kube-apiserver)

One-sentence explanation: The front door of Kubernetes—all operations must go through it.

Responsibilities:

Function	Description
Request entry point	All kubectl commands are sent here
Request validation	Checks if requests are valid
Authorization check	Confirms user has permission to execute
Data access	Only component that can access etcd

How it works:

User → kubectl → API Server → etcd
                       ↓
              Other components Watch for changes

Important characteristics:

• RESTful API: All operations are standard HTTP requests
• Watch mechanism: Other components can subscribe to resource changes
• Horizontal scaling: Can run multiple API Servers for load balancing

Practical operations:

# Directly call API Server
kubectl get --raw /api/v1/namespaces/default/pods

# View API Server endpoint
kubectl cluster-info

etcd

One-sentence explanation: Kubernetes' database, storing the entire cluster state.

Responsibilities:

Function	Description
State storage	All resource configurations and states
Distributed	Multiple nodes ensure high availability
Consistency	Uses Raft protocol to guarantee data consistency

What it stores:

• Definitions of all resources like Pods, Deployments, Services
• ConfigMap and Secret contents
• Cluster configuration information

What it doesn't store:

• Container logs
• Application data
• Monitoring metrics

Why it's important:

If etcd goes down, the entire cluster cannot function.

Backup recommendation:

# Backup etcd
ETCDCTL_API=3 etcdctl snapshot save backup.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

Scheduler (kube-scheduler)

One-sentence explanation: Decides which Node a Pod should run on.

Responsibilities:

Function	Description
Monitor unscheduled Pods	Watch for Pods without assigned Nodes
Evaluate Nodes	Filter and score based on conditions
Bind Pods	Assign Pods to the most suitable Node

Scheduling flow:

New Pod created (no Node specified)
        ↓
    Filtering phase
    - Enough resources?
    - Any taints?
    - Affinity rules?
        ↓
    Scoring phase
    - Resource utilization
    - Pod distribution
    - Custom priorities
        ↓
    Select highest-scoring Node
        ↓
    Bind Pod to Node

Filtering conditions (Predicates):

Condition	Description
PodFitsResources	Is CPU/memory sufficient
PodFitsHostPorts	Any host port conflicts
PodMatchNodeSelector	Matches NodeSelector
PodToleratesNodeTaints	Can tolerate Node taints

Scoring factors (Priorities):

Factor	Description
LeastRequestedPriority	Prefer nodes with lower resource usage
BalancedResourceAllocation	CPU and memory usage should be balanced
SelectorSpreadPriority	Pods from same Service should be distributed

Controller Manager (kube-controller-manager)

One-sentence explanation: Ensures the cluster's actual state matches the desired state.

Responsibilities:

Function	Description
Monitor state	Continuously Watch resource changes
Compare differences	Actual state vs desired state
Execute adjustments	Make actual state approach desired state

Controllers included:

Controller	Responsibility
Deployment Controller	Manage Deployments and ReplicaSets
ReplicaSet Controller	Maintain Pod replica count
Node Controller	Monitor Node status
Service Controller	Manage cloud load balancers
Endpoint Controller	Maintain Service and Pod mappings
Namespace Controller	Handle Namespace deletion

Control loop concept:

while true:
    current_state = get from API Server
    desired_state = get from resource definition
    if current_state != desired_state:
        execute adjustment action
    sleep(short interval)

Example: Deployment Controller

You say "I want 3 Pods":

1. Controller sees currently 0 Pods
2. Creates a new Pod
3. Sees currently 1 Pod
4. Creates another
5. Sees currently 2 Pods
6. Creates another
7. Sees currently 3 Pods, matches desired state
8. Continues monitoring, creates new Pods if any die

---

Need Kubernetes architecture design?

From proof of concept to production environment, we help enterprises design K8s architectures that meet their needs.

Book an architecture consultation

---

Worker Node Component Analysis

Each Worker Node runs three core components.

kubelet

One-sentence explanation: The agent on the Node, responsible for managing all Pods on that Node.

Responsibilities:

Function	Description
Receive commands	Get Pod specs from API Server
Start containers	Execute through Container Runtime
Health checks	Run Liveness and Readiness Probes
Report status	Periodically report to API Server

Operation flow:

API Server
    ↓ Watch PodSpec
kubelet
    ↓ Call CRI
Container Runtime
    ↓ Create container
Container running

Health check types:

Type	Purpose	On Failure
Liveness Probe	Is container alive	Restart container
Readiness Probe	Is container ready	Remove from Service
Startup Probe	Is startup complete	Delay other checks

Important configuration:

# kubelet configuration example
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
maxPods: 110
imageGCHighThresholdPercent: 85
imageGCLowThresholdPercent: 80

kube-proxy

One-sentence explanation: Handles network rules, implementing Service load balancing.

Responsibilities:

Function	Description
Maintain network rules	iptables or IPVS rules
Implement Services	ClusterIP, NodePort, LoadBalancer
Load balancing	Distribute traffic to backend Pods

Operating modes:

Mode	Description	Performance
iptables	Default mode	Medium
IPVS	Large-scale clusters	Better
userspace	Legacy mode	Poor

iptables mode operation:

External traffic → Service IP → iptables rules → Pod IP

kube-proxy monitors Service and Endpoint changes, automatically updating iptables rules.

Container Runtime

One-sentence explanation: The program that actually runs containers.

Common choices:

Runtime	Description	Use Case
containerd	Open-sourced by Docker	Most common, default choice
CRI-O	Developed by Red Hat	OpenShift default
Docker	No longer directly supported	Via cri-dockerd

Why doesn't Kubernetes directly support Docker anymore?

Kubernetes 1.24 removed dockershim. But this doesn't mean you can't use Docker images.

Key understanding:

• Docker images (OCI format): ✅ Fully supported
• Docker as Runtime: ❌ Requires additional cri-dockerd

In most cases, just use containerd directly.

---

How Components Communicate

Understanding how components communicate is key to deeply understanding Kubernetes.

Communication Principles

Core principle: All communication goes through the API Server.

Communication Direction	Description
User → API Server	kubectl or API calls
API Server → etcd	Read/write cluster state
Controller → API Server	Watch resource changes
Scheduler → API Server	Get unscheduled Pods
kubelet → API Server	Report Node and Pod status

Why this design?

• Unified access point for easier authentication and authorization
• All operations are recorded
• Easy to scale horizontally

Request Flow Analysis

Example: Creating a Deployment

kubectl apply -f deployment.yaml

Complete flow:

1. kubectl sends POST request to API Server
   POST /apis/apps/v1/namespaces/default/deployments

2. API Server validates and processes
   - Validate YAML format
   - Check user permissions
   - Write to etcd

3. Deployment Controller receives notification
   - Watch mechanism detects new Deployment
   - Creates corresponding ReplicaSet

4. ReplicaSet Controller receives notification
   - Detects new ReplicaSet
   - Creates specified number of Pods

5. Scheduler receives notification
   - Detects unscheduled Pods
   - Selects suitable Node
   - Updates Pod's NodeName

6. kubelet receives notification
   - Detects assigned Pod
   - Calls Container Runtime to start container
   - Reports Pod status

Watch Mechanism

Watch is one of Kubernetes' core mechanisms.

How it works:

Controller                    API Server
    │                              │
    │── Watch /api/v1/pods ───────▶│
    │                              │
    │◀─── Initial data list ───────│
    │                              │
    │◀─── Change event (add) ──────│
    │◀─── Change event (modify) ───│
    │◀─── Change event (delete) ───│
    │                              │

Advantages:

• Real-time notifications, no polling needed
• Reduces API Server load
• Reduces network traffic

Reconciliation Loop

Each Controller runs a control loop:

┌────────────────────────────────────────┐
│                                        │
│   ┌──────────┐      ┌──────────┐      │
│   │ Desired  │      │  Actual  │      │
│   │  State   │      │  State   │      │
│   │  (Spec)  │      │ (Status) │      │
│   └────┬─────┘      └────┬─────┘      │
│        │                  │            │
│        └───────┬──────────┘            │
│                ▼                       │
│         ┌──────────┐                   │
│         │  Compare │                   │
│         └────┬─────┘                   │
│              │                         │
│              ▼                         │
│    ┌─────────────────┐                 │
│    │ Difference?     │                 │
│    │ Execute adjust  │                 │
│    └─────────────────┘                 │
│                                        │
└────────────────────────────────────────┘

This is the essence of "declarative":

You say "what you want," and Kubernetes figures out how to achieve it.

---

Having K8s architecture issues?

Architecture design affects future operational costs and stability. Let experts help you review.

Book a free consultation

---

High Availability Architecture Design

Production environments require high availability architecture.

Single Point of Failure Risks

Component	What happens if it fails
API Server	Can't issue commands, but existing Pods keep running
etcd	Cluster completely non-functional
Scheduler	New Pods can't be scheduled
Controller Manager	Can't auto-repair
kubelet	Pods on that Node can't be managed

Multi-Master Architecture

Production environments should have at least 3 Control Plane nodes.

Architecture diagram:

              Load Balancer
                   │
       ┌───────────┼───────────┐
       ▼           ▼           ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Master 1 │ │ Master 2 │ │ Master 3 │
│          │ │          │ │          │
│API Server│ │API Server│ │API Server│
│Scheduler │ │Scheduler │ │Scheduler │
│Controller│ │Controller│ │Controller│
│  etcd    │ │  etcd    │ │  etcd    │
└──────────┘ └──────────┘ └──────────┘

How it works:

Component	HA Mechanism
API Server	Multiple instances with load balancer in front
etcd	Raft consensus, requires majority of nodes
Scheduler	Leader Election, only one is active
Controller Manager	Leader Election, only one is active

etcd Cluster

etcd uses the Raft consensus protocol, requiring an odd number of nodes.

Node Count	Fault Tolerance	Recommendation
1	0	Test environment
3	1	Minimum for production
5	2	Large production
7	3	Very large scale

Why odd numbers?

Raft requires majority agreement. 3 nodes can tolerate 1 failure (2 > 3/2), 4 nodes can also only tolerate 1 failure (3 > 4/2).

Production Environment Recommendations

Control Plane:

Item	Recommendation
Node count	At least 3
Resources	4 CPU, 16GB RAM or more
Disk	SSD, especially for etcd
Network	Low latency, stable

etcd:

Item	Recommendation
Separate deployment	Consider for large scale
Backup	Regular automatic backup
Monitoring	Monitor latency and disk usage

Worker Node:

Item	Recommendation
Count	Based on load
Distribution	Across availability zones
Resource reservation	Reserve resources for system components

For more cloud service architecture choices, see Kubernetes Cloud Services Complete Comparison.

---

FAQ: Common Questions

Q1: Can Control Plane run Pods?

Not by default, but can be configured.

Control Plane nodes have Taints by default that prevent regular Pods from being scheduled there.

# View Taints
kubectl describe node master-node | grep Taints

# Remove Taint (not recommended for production)
kubectl taint nodes master-node node-role.kubernetes.io/control-plane:NoSchedule-

It's recommended to let Control Plane focus on management in production.

Q2: Should etcd data be backed up?

Absolutely.

etcd stores the entire cluster state; nothing can be recovered without it.

Backup strategy:

• Regular automatic backup (at least once daily)
• Backup to remote storage
• Periodically test restoration

Q3: Why do Scheduler and Controller Manager need Leader Election?

To avoid conflicts.

Imagine if 3 Schedulers were running simultaneously—the same Pod might be assigned to different Nodes, causing chaos.

Leader Election ensures only one instance is making decisions at a time; others are standby.

Q4: What happens if kubelet fails?

Pods on that Node become orphaned.

• Pods will continue running (unless the container itself fails)
• But can't be restarted, updated, or health-checked
• Control Plane will mark the Node as NotReady
• After a period, Pods will be rescheduled to other Nodes

Q5: How to check component status?

# Check component status
kubectl get componentstatuses

# Check Node status
kubectl get nodes

# Check system Pods
kubectl get pods -n kube-system

# Check etcd status (if you have permission)
kubectl exec -n kube-system etcd-master -- etcdctl endpoint health

---

Next Steps

After understanding Kubernetes architecture, you can:

Goal	Action
Learn core objects	Read Kubernetes Core Objects Tutorial
Understand network architecture	Read Kubernetes Network Architecture Guide
Choose cloud services	Read Kubernetes Cloud Services Comparison
Hands-on practice	Read Kubernetes Getting Started Tutorial

---

Need professional Kubernetes architecture consulting?

Whether building new clusters or optimizing existing architecture, CloudInsight provides professional assistance.

Book a consultation now

---

Further Reading

• Kubernetes Complete Guide - K8s introduction overview
• Kubernetes Core Objects Tutorial - Pod, Deployment, Service explained
• Kubernetes Network Architecture Guide - CNI, Service, Ingress
• Kubernetes Cloud Services Comparison - EKS, GKE, AKS

---

References

• Kubernetes Official Documentation - Architecture
• Kubernetes Components
• etcd Official Documentation
• Kubernetes API Server