What if you could control hundreds of computers like a single smart machine, without logging into each one?
Why Kubernetes architecture (control plane and nodes)? - Purpose & Use Cases
Imagine you have dozens or hundreds of computers, each running different apps and services. You try to manage them all by logging into each one, starting or stopping apps manually, and checking if everything is working.
This manual way is slow and confusing. You might forget to update some computers, apps could crash without you noticing, and fixing problems takes a lot of time. It's like trying to control a big orchestra without a conductor.
Kubernetes architecture solves this by organizing your computers into a system with a control center (control plane) and workers (nodes). The control plane tells the nodes what to do, watches over them, and keeps everything running smoothly automatically.
ssh node1
start app
ssh node2
start app
... (repeat for each node)kubectl apply -f app-deployment.yaml
kubectl get pods
kubectl scale deployment app --replicas=5With Kubernetes, you can easily manage many computers and apps at once, making your system reliable and scalable without extra manual work.
A company running an online store uses Kubernetes to keep their website and services running smoothly, even when thousands of customers visit at the same time.
Manual management of many computers is slow and error-prone.
Kubernetes uses a control plane to automate and coordinate worker nodes.
This architecture makes managing apps easier, faster, and more reliable.
Practice
Solution
Step 1: Understand Kubernetes architecture roles
The control plane manages the cluster and makes decisions about scheduling and managing workloads.Step 2: Identify the component that schedules workloads
The control plane includes the scheduler which decides what runs and where.Final Answer:
Control plane -> Option DQuick Check:
Control plane = workload decision maker [OK]
- Confusing nodes with control plane
- Thinking containers decide scheduling
- Mixing pods with control plane
Solution
Step 1: List control plane components
Control plane includes etcd, kube-apiserver, kube-controller-manager, and kube-scheduler.Step 2: Identify which option is part of control plane
etcd stores cluster data and is part of the control plane.Final Answer:
etcd -> Option AQuick Check:
etcd = control plane data store [OK]
- Confusing kubelet as control plane
- Thinking kube-proxy is control plane
- Mixing container runtime with control plane
Solution
Step 1: Identify node components
Nodes run components like kubelet and kube-proxy to manage containers and networking.Step 2: Determine which component manages container lifecycle on nodes
kubelet runs on each node and ensures containers are running as expected.Final Answer:
kubelet -> Option AQuick Check:
kubelet = node container manager [OK]
- Confusing kube-apiserver as node component
- Thinking scheduler runs on nodes
- Mixing etcd with node components
Solution
Step 1: Understand pod startup process
Pods are started and managed on nodes by the kubelet component.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.Final Answer:
kubelet -> Option BQuick Check:
kubelet manages pods on nodes [OK]
- Checking scheduler instead of kubelet
- Looking at etcd for node pod errors
- Confusing apiserver with node issues
Solution
Step 1: Understand control plane failure impact
The control plane manages scheduling and cluster state but nodes run pods independently.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.Final Answer:
Existing pods continue running but no new scheduling occurs -> Option CQuick Check:
Control plane down = no new scheduling, pods run [OK]
- Thinking pods stop immediately
- Assuming nodes become control planes
- Believing new pods schedule without control plane
Ready to prove it?
Pass the test and this pattern moves unknown
