Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A Kubernetes cluster has two main parts: a control plane that manages cluster state and worker nodes that run application Pods. The API server is the control plane’s front door, etcd stores cluster data, and the scheduler assigns Pods to nodes. On each node, the kubelet works with a container runtime to run the containers in those Pods.
What are the components of a Kubernetes cluster?
The architecture is easiest to understand as a management layer and a workload layer. The control plane makes cluster-wide decisions and coordinates changes; worker nodes provide the compute capacity for application Pods. A cluster has one or more worker nodes, while production deployments commonly distribute control-plane components across machines for availability. The exact process layout varies by cluster. Kubernetes’ cluster architecture documentation describes the roles and deployment patterns.
| Part | Main responsibility | Typical components |
|---|---|---|
| Control plane | Expose the API, store cluster state, make placement decisions, and reconcile desired state. | API server, etcd, scheduler, controller manager; cloud-controller-manager in some cloud deployments. |
| Worker node | Run Pods assigned to that machine and provide node-level networking. | kubelet, container runtime, and often kube-proxy or equivalent Service forwarding from a network plugin. |
What does the control plane do?
The control plane is the cluster’s management layer. Its components coordinate through the Kubernetes API rather than acting as one monolithic process.
API server: the front end
The API server exposes the Kubernetes API and is the entry point for user requests and interactions among control-plane components. When you submit a Deployment, for example, the request is handled through the API server. Node and Pod API operations also go through it.
#1 Best Overall
etcd: persistent cluster data
etcd is the backing store for cluster data, including the state represented through the Kubernetes API. It is not merely a disposable cache: losing stored state can affect the cluster’s ability to recover its configuration and workload definitions. Operators of self-managed clusters should plan and test backups appropriate to their recovery needs.
Scheduler: choosing a node
The scheduler watches for Pods that have not yet been assigned to a node, then selects a suitable node. Placement can take account of resource requests, scheduling constraints, affinity rules, data locality, and deadlines. The scheduler chooses where a Pod should run; it does not start the Pod’s containers itself.
Controller manager: reconciling desired state
The kube-controller-manager runs built-in controllers. A controller watches an API resource and works to bring the observed state closer to the desired state declared by the user. It does this through API changes, not by directly running application containers. For example, the Job controller requests Pod objects for a Job; the scheduler and node components then handle placement and execution. Kubernetes’ controller documentation explains this reconciliation model.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Cloud controller manager: provider-specific integration
Some cloud deployments include a cloud-controller-manager for logic that interacts with a cloud provider’s APIs. It is not a required component of every cluster; on-premises and learning clusters may not use one.
Rank #3
What runs on each node?
A Kubernetes node is a physical or virtual machine that provides the services needed to run Pods. The control plane manages the node, while node-level components carry out the work assigned to it. The Kubernetes node documentation covers these roles.
kubelet: the node agent
The kubelet receives Pod specifications and makes sure the containers in those Pods are running and healthy. It coordinates with the container runtime; it is not itself the runtime. Kubernetes does not use the kubelet to manage containers that were not created as part of Kubernetes workloads.
Container runtime: executing containers
The container runtime is responsible for container execution and lifecycle on the node. The kubelet communicates with the runtime so the Pod’s containers can be created and kept running as specified.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Networking: Pod connectivity and Services
A network plugin provides Pod networking. kube-proxy, when present, maintains node network rules used to implement part of the Kubernetes Service abstraction. Some network plugins provide equivalent Service forwarding and make kube-proxy unnecessary. Pod networking and Service forwarding are related but distinct functions; neither should be confused with DNS or ingress, which are separate parts of a cluster’s networking setup.
Best Value
How does Kubernetes decide where a Pod runs?
Consider a Deployment that requests a particular number of application replicas. The Deployment is a Kubernetes object describing desired state, not a container. The path from that request to running Pods is a chain of API-driven actions:
- Submit desired state. A user or automation sends the Deployment request to the API server, which exposes and validates the Kubernetes API.
- Store the cluster data. The API server’s cluster data is held in etcd.
- Create Pod objects. A controller observes that the Deployment needs replicas and creates the corresponding Pod objects through the API server.
- Assign nodes. The scheduler evaluates each unassigned Pod and selects a suitable node.
- Run the containers. The kubelet on the selected node works with the container runtime to make the Pod’s containers run.
- Keep reconciling. Controllers continue watching for differences between actual and desired state and request changes through the API when needed.
This separation lets Kubernetes respond to changes without one component having to perform every step: controllers manage API objects, the scheduler places Pods, and node agents and runtimes execute them.
How do the control plane and nodes communicate?
Kubernetes communication follows an API-centered, hub-and-spoke pattern: nodes and other components interact with the API server rather than relying on arbitrary direct connections among every component. The API server also connects to kubelets for operations such as retrieving logs and supporting attach or port-forwarding sessions. The precise network and certificate configuration matters, especially across untrusted networks; the official control-plane and node communication documentation discusses certificate verification and SSH tunneling considerations.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Does every Kubernetes cluster use the same layout?
No. The component diagram describes logical roles, not a universal map of processes or machines. Control-plane components may run on dedicated machines or VMs, as static Pods managed by kubelet, or in self-hosted arrangements. In a managed Kubernetes service, the provider operates or abstracts the control plane, so users may not see or administer those components directly.
Small development clusters may colocate control-plane components and workloads. Production clusters commonly separate them and distribute control-plane components across machines to support availability. The appropriate arrangement depends on who operates the control plane, fault-tolerance needs, workload isolation, and whether the network plugin replaces kube-proxy’s Service forwarding.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
