Kubernetes Control Plane: The Cluster's Brain
The Kubernetes control plane is the cluster's brain, making all global decisions like scheduling pods and responding to events. You interact with it via kubectl to manage your applications. The footgun: never run your own workloads on control plane nodes.
Why it exists
Kubernetes manages a distributed system of containerized applications, which requires a central authority for coordination. Without a control plane, you'd have a collection of disconnected nodes with no way to coordinate workloads, enforce policies, or recover from failures. The control plane provides the single source of truth and decision-making for the entire cluster.
The mental model
Think of the control plane as the management office for a large apartment complex. It doesn't live in the apartments (worker nodes) but holds the master ledger (etcd) of who lives where. It handles new tenant requests (API server), decides which empty apartment is best for a new tenant (scheduler), and periodically checks that all utilities are working and rules are followed (controller managers).
How it works
The control plane is a set of components that can run on a single master node or be replicated for high availability. The main components are: kube-apiserver: The front door for the cluster. It exposes the Kubernetes API, validating and processing all REST requests from tools like kubectl. It's the only component that communicates directly with etcd. etcd: The cluster's database and source of truth. It's a consistent, highly-available key-value store that holds the entire state of the cluster, including what's configured and what's currently running. kube-scheduler: The matchmaker. It watches for newly created pods that don't have a node assigned and selects the best worker node for them based on resource needs, policies, and other constraints. kube-controller-manager: The regulator. It runs background processes (controllers) that watch the cluster's state. If the current state doesn't match the desired state stored in etcd, a controller takes action to correct it. Examples include the Node Controller and Replication Controller.
When to use it
You are always using the control plane when you interact with a Kubernetes cluster. Every kubectl apply, kubectl get pods, or Helm chart installation sends requests to the API server, which are then processed by the other control plane components to enact changes.
When not to use it
You should never run your application workloads on the same nodes as the control plane components in a production environment. These nodes are critical infrastructure. Co-locating applications risks resource contention (CPU, memory, I/O) that can cripple the control plane and take down the entire cluster. Managed services like GKE or EKS handle this separation for you.
One canonical example
A developer runs kubectl scale deployment/my-app --replicas=5. This command hits the kube-apiserver, which updates the desired state in etcd. The controller manager sees the mismatch (e.g., only 3 pods exist). It creates two new Pod objects. The scheduler sees these new, unscheduled Pods and assigns them to suitable worker nodes. The kubelet on those nodes then starts the new containers.
Interview question
What is the main operational risk associated with running application workloads directly on Kubernetes control plane nodes?
- a.Resource contention from applications could destabilize critical control plane components, leading to cluster failure.Correct
- b.Control plane nodes are typically provisioned with insufficient disk space for application persistent volumes.
- c.The kube-scheduler would continuously attempt to re-schedule these applications to worker nodes, causing a loop.
- d.It compromises the security of the cluster's sensitive configuration data stored in etcd.
Why? this is the answer
The card explicitly states that co-locating applications on control plane nodes risks "resource contention (CPU, memory, I/O) that can cripple the control plane and take down the entire cluster." This directly addresses the primary operational risk. Other options describe plausible but secondary or incorrect risks not highlighted as the main concern.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles