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
Short answer: Kubernetes does not hold an election in which one ordinary machine becomes “the master” and the rest become workers. A cluster is built by installing control-plane services on selected machines, installing node services on machines that will run Pods, and registering those nodes with the Kubernetes API. The labels describe responsibilities, not permanent identities.
In current Kubernetes terminology, the management side is the control plane and the machines that provide compute capacity are nodes. A node can host control-plane services, run application Pods, or do both, depending on the distribution and topology you choose.
What a Kubernetes cluster actually contains
The official architecture definition is concise: “A Kubernetes cluster consists of a control plane plus a set of worker machines, called nodes, that run containerized applications.” See Kubernetes Cluster Architecture. The control plane accepts desired state, stores it, decides where work should run and continually pushes the cluster toward that state. Nodes provide the operating-system and container capacity where Pods execute.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minute“Master” is older shorthand for a control-plane machine. It is not the name of a required Kubernetes component, and a cluster does not need one uniquely privileged computer. A small learning cluster may put every service on one machine. A production installation commonly spreads control-plane services across several machines or failure zones so that losing one host does not remove the management capability.
#1 Best Overall
Likewise, “worker” usually means a node intended to run application workloads. The official documentation calls the machines nodes: “Each node is managed by the control plane and contains the services necessary to run Pods.” (Kubernetes Nodes.) Whether a node is eligible for ordinary workloads is an operational choice made by the installation and scheduling configuration, not a permanent hardware property.
Control-plane components and their separate jobs
The control plane is a set of cooperating processes. Keeping their jobs distinct explains why Kubernetes can make decisions, store state and repair workloads without one giant “master” process.
| Component | What it does | Placement and operational notes |
|---|---|---|
| kube-apiserver | Exposes the Kubernetes API, authenticates and authorizes requests, and provides the front door through which clients and other components read or change cluster objects. | The implementation is designed to scale horizontally; multiple API-server instances can sit behind a load balancer. |
| etcd | Stores Kubernetes cluster data in a consistent, highly available key-value store. Objects such as desired workload configuration and node information are persisted here. | It is the backing store for cluster state, not a general container-image or application-data repository. If you operate it, plan backups and recovery. |
| kube-scheduler | Watches for newly created Pods that have no assigned node and selects a suitable node. | Its decision considers resource requests, hardware and software constraints, policy, affinity and anti-affinity, locality, interference and deadlines. |
| kube-controller-manager | Runs controller processes. Each controller is a control loop that observes current state and takes action until it matches the desired state. | Controllers react to changes; they do not replace the scheduler. The scheduler chooses a node for an unbound Pod, while controllers reconcile objects and relationships. |
| cloud-controller-manager | Connects Kubernetes to cloud-provider functions such as infrastructure-specific node, route or load-balancer operations. | It is optional. A cluster that does not need cloud integration does not universally require it. |
The component inventory and role descriptions are summarized in Kubernetes Components. In a highly available design, API servers can be replicated, controller-manager and scheduler instances can run with leader coordination, and etcd is deployed with an availability plan. The exact process layout depends on the distribution.
Free tools Windows power users keep installed
One-click scans. No signup required.
What runs on each node
A node can be a physical computer or a virtual machine. Its essential services turn a generic operating system into a Kubernetes execution target.
Kubelet
The kubelet is the node agent. It receives Pod specifications from configured sources and ensures that the specified containers are running and healthy. It reports node and Pod status back to the control plane. The kubelet does not manage arbitrary containers that were started outside Kubernetes.
Container runtime
The runtime downloads images when needed and creates, starts, stops and otherwise manages containers. Kubernetes communicates with runtimes through the Container Runtime Interface (CRI); containerd and CRI-O are examples of runtimes that implement that interface. The runtime is therefore a node prerequisite, not a control-plane service.
Rank #3
kube-proxy and service networking
kube-proxy traditionally maintains node-level network rules that implement part of Kubernetes Service behavior, forwarding traffic toward the appropriate backend Pods. It is optional when the chosen network plugin supplies equivalent Service-forwarding behavior; do not assume every modern cluster must run a kube-proxy process.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Network plugin (CNI)
A Container Network Interface (CNI) plugin allocates Pod IP addresses and enables Pod-to-Pod communication. Networking is a cluster layer that spans nodes; it is not one of the control-plane decision makers. The architecture overview documents these node and networking responsibilities at kubernetes.io/docs/concepts/architecture/.
How a machine becomes a Kubernetes node
There are two documented ways for a Node object to appear in the API server: the kubelet can self-register, or an administrator can create the Node object manually (Nodes documentation). In both cases, registration is only the beginning; the control plane must be able to communicate with the machine and observe usable status.
- Prepare the machine. Install a supported operating system configuration, a kubelet and a CRI-compatible container runtime. Install and configure the cluster’s networking components as required by the selected distribution.
- Provide cluster credentials and endpoint information. The kubelet needs a way to authenticate to the API server and, for self-registration, the address of that API server.
- Create or request registration. With self-registration enabled, the kubelet asks the API server to create its Node object. With manual registration, an operator creates a Node object whose name and identifying details correspond to the intended machine.
- Report health and capacity. The kubelet updates node status and sends Lease-based heartbeats. It also reports capacity and allocatable resources, such as available CPU and memory, which the scheduler uses when evaluating placements.
- Become schedulable when appropriate. Once the node is healthy, reachable and permitted by cluster policy, the scheduler can assign eligible unbound Pods to it. A node that is absent, unhealthy or constrained will not be selected for work that it cannot satisfy.
This explains the practical sequence: machine plus node services plus registration → Node object visible to the API server → health and capacity reported → scheduler may place Pods. No vote turns the machine into a worker; its installed services and registration make it a node.
How a machine becomes a control-plane host
There is no universal “master election” during ordinary cluster creation. The bootstrap tool or Kubernetes distribution you select installs and configures the control-plane services on designated machines. Managed Kubernetes services perform much of this work for you; self-managed installers leave more of it to the operator. The setup choices are outlined at Kubernetes Getting Started.
Recommended Free Tools
The kubeadm example
kubeadm init provides a concrete, widely used bootstrap sequence, but it is an example rather than a rule for every distribution.
- Initialize the first control-plane node. The operator runs the kubeadm initialization workflow with the cluster’s networking and endpoint choices.
- Generate control-plane manifests. kubeadm writes static Pod manifests for the API server, controller manager and scheduler. When external etcd is not configured, it also writes a static Pod manifest for a local etcd instance.
- Let the local kubelet supervise those Pods. The kubelet watches its configured static-Pod manifest directory and starts the listed control-plane containers. Static Pods are managed by the kubelet on that host rather than created by a deployment object; see Static Pods.
- Publish the control-plane endpoint and credentials. Initialization creates the certificates and configuration needed for cluster components and administrators to use the API.
- Mark the host’s role. kubeadm labels and configures the initialized machine as a control-plane node. Installations commonly prevent ordinary user workloads from landing there unless the operator explicitly changes that policy.
- Prepare additional nodes to join. kubeadm creates bootstrap-token and TLS-bootstrap mechanisms. A worker machine uses the generated join procedure, starts its kubelet and runtime, and registers as another Node object. Additional control-plane machines can be joined using the control-plane join process when the chosen topology supports them.
Other installers may use system services, containers, a managed control plane or an external etcd cluster instead of kubeadm’s static-Pod arrangement. The invariant is the responsibility: a control-plane host runs the API, persistence, scheduling and reconciliation services; a workload node runs the kubelet, runtime and networking needed for Pods.
What happens when you deploy a Pod
- A user, controller or automation submits a Pod or a higher-level workload object to the API server.
- The API server validates the request and records the resulting object in the cluster data store.
- The scheduler notices a Pod with no assigned node, filters and scores suitable nodes using resource, policy, affinity, locality and other constraints, then records its assignment through the API.
- The kubelet on the selected node observes the assignment, asks the container runtime to create the containers and reports progress and health.
- Controllers continue watching the objects. If a replica disappears or another part of the desired state changes, a controller takes corrective action; it does not directly perform the scheduler’s node-selection step.
This separation is why a node does not “decide” to become a worker after a Pod arrives. The control plane assigns work to a registered node, and the node agent executes that assignment.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Common cluster layouts
| Layout | How responsibilities are arranged | Why choose it | Main trade-off |
|---|---|---|---|
| Single-machine development cluster | Control-plane services, kubelet, runtime and networking run on one physical or virtual machine. | Fastest way to learn APIs, manifests and scheduling with minimal infrastructure. | One machine is a single failure domain and offers limited workload capacity. |
| Small self-managed cluster | One control-plane host manages one or more separate workload nodes; etcd may be colocated according to the installer. | Separates management overhead from application capacity while remaining understandable to operate. | The control plane can still be a single point of failure unless it is replicated. |
| Highly available self-managed cluster | Control-plane services are distributed across multiple machines, often across failure zones, with replicated API servers and an etcd availability and backup plan. | Continues management through the loss of an individual host or zone, subject to the design. | Requires more machines, networking, certificate, storage and operational expertise. |
| Managed Kubernetes service | The provider operates some or all control-plane infrastructure while you supply or select worker capacity and workloads. | Reduces the work of installing, upgrading and protecting control-plane components. | You accept the provider’s supported versions, policies, networking model and operational boundaries; exact capabilities vary by service. |
Kubernetes’ production guidance emphasizes availability, capacity, security, maintenance and operator expertise when selecting a topology (Production environment). CPU, memory, disk performance and special requirements such as GPUs, Windows nodes or VM isolation also influence which machines should run workloads. There is no universally correct count of control-plane or worker machines.
Why tutorials can make the roles seem more rigid than they are
- They use “master” as a noun. The current term is control plane, and it describes a set of services that may be replicated or colocated.
- They draw one box labeled master and several boxes labeled workers. That is a useful teaching layout, not a requirement. A one-node cluster and a multi-control-plane production cluster are both valid patterns.
- They collapse scheduling and reconciliation into one action. The scheduler assigns an unbound Pod; controllers continuously correct deviations from desired state.
- They omit registration. A machine is not usable merely because a kubelet binary exists. It must authenticate, appear as a Node object and report healthy status and resources.
- They call every networking process mandatory. kube-proxy can be omitted when the network plugin provides equivalent Service forwarding.
A practical diagnostic checklist
When a machine is not behaving as expected, check the responsibility boundary instead of asking whether it was elected master or worker.
- No Node object appears: verify the kubelet’s API-server endpoint, credentials and self-registration settings, or confirm that an administrator-created Node object matches the machine identity.
- The Node exists but is unavailable: inspect kubelet-reported status and Lease heartbeats, then check the runtime and node networking. A stale heartbeat means the control plane cannot reliably determine availability.
- Pods remain unassigned: confirm that the scheduler is running and that at least one node reports enough allocatable CPU and memory and satisfies the Pod’s hardware, policy, affinity and locality constraints.
- A scheduled Pod never starts: inspect the kubelet and CRI runtime on the selected node, image access and the node’s reported health. Assignment alone does not create a functioning container.
- Service traffic fails: verify the CNI/network plugin and determine whether kube-proxy or an equivalent Service-forwarding implementation is installed and configured.
- The API or state store is fragile: review control-plane replication, etcd placement, storage reliability and tested backups. Losing access to etcd or the API can prevent normal management even when already-running containers continue for a time.
The core idea to remember
A Kubernetes role is created by configuration and registration, not by a machine’s inherent identity. The chosen installer places control-plane services on designated hosts; kubelets and runtimes make other hosts (or the same hosts) capable of running Pods; Node objects, heartbeats and capacity reports make those hosts visible to the scheduler. Once you see the cluster as cooperating control loops and registered execution nodes, “how does one become the master?” has a precise answer: it is configured as a control-plane host by the distribution, while the others join as nodes and receive workload assignments.
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.
