Inside the Kubernetes Master: A Complete Breakdown of Core Components

Introduction

The Master node is the control plane of a Kubernetes cluster, responsible for management, scheduling, monitoring, and maintaining the desired state. Worker nodes run the actual application containers.

Core Components of the Master

kube-apiserver Acts as the unified entry point and communication hub for all REST API requests (kubectl, kubelet, scheduler, controllers). Its responsibilities include:

API gateway for all requests.

Authentication and authorization.

Request validation and admission control (supports Admission Webhooks).

Event distribution to other components.

Aggregation layer for extending the API server with CRDs.

Analogy: the front desk or switchboard of a company.

etcd The single source of truth for cluster state, a distributed key‑value store based on the Raft consensus algorithm providing strong consistency.

Stores node information, all Kubernetes objects (Pod, Service, Deployment, ConfigMap, Secret, etc.) and cluster configuration.

Designed for high availability (typically 3‑5 nodes) to avoid single‑point failure.

Security recommendations: enable TLS encryption and encrypt Secrets.

Backup and restore: regular snapshots (e.g., etcdctl snapshot save) are required in production.

Analogy: the brain’s memory center.

kube-scheduler Assigns newly created Pods to suitable nodes.

Listening: watches the API server for unscheduled Pods.

Filtering: selects candidate nodes based on resource requests, node labels, affinity/anti‑affinity, and taints/tolerations.

Scoring: ranks candidates and picks the best node.

Binding: writes the binding decision back to the API server → etcd.

Extensibility: supports custom scheduling plugins via the Scheduler Framework.

Analogy: a human‑resources scheduler assigning tasks to the right employee.

kube-controller-manager Runs a collection of controller processes that continuously drive the actual state toward the desired state.

Control loops: watch resource changes, compare desired vs. actual, take action.

Built‑in controllers include Node Controller, Replication Controller, Deployment Controller, Endpoint Controller, Service Account/Token Controller, Job/CronJob Controller, Namespace Controller, PV Controller, etc.

Analogy: department managers ensuring their areas meet targets.

cloud-controller-manager (optional) Decouples cloud‑provider specific logic from the core Kubernetes code.

Manages cloud resources such as load balancers, storage volumes, and routes.

Can be disabled in bare‑metal environments.

Typical Workflow Example

Creating a Pod with kubectl create -f nginx.yaml follows these steps:

User submits the request; kubectl sends a Pod creation request to the API server.

API server validates the request and writes the object to etcd.

Scheduler detects the unscheduled Pod, selects a node, and writes the binding back to etcd.

The target node’s kubelet sees the binding, pulls the container image, and starts the container.

Kubelet reports the Pod’s running status to the API server → etcd.

Controllers continuously monitor the status and ensure it matches the desired state.

Master High‑Availability Architecture

Deploy at least three Master instances to avoid single‑point failure.

Component deployment patterns:

API server placed behind a load balancer (HAProxy, Nginx, or Keepalived + LVS).

etcd runs as an independent cluster on SSDs with regular snapshots.

Master nodes are usually tainted to prevent regular Pods from being scheduled on them.

Security and Operational Best Practices

RBAC for fine‑grained access control.

Admission Webhooks for custom policies (security audits, automatic sidecar injection).

Encrypt Secrets to avoid storing sensitive data in plain text in etcd.

Regular etcd backups (e.g., etcdctl snapshot save) possibly combined with Velero.

Performance tuning:

Enable caching and horizontal scaling for the API server.

Use scheduler plugins to optimize scheduling decisions.

Adjust concurrency parameters in the controller manager.

Evolution and Trends

Enhanced multi‑tenant isolation via stronger API server isolation mechanisms.

Serverless integration (e.g., Knative) to combine event‑driven workloads with Kubernetes.

Exploration of alternative storage backends beyond etcd.

Increased plugin‑based extensibility for the scheduler, facilitating custom strategies for large‑scale or AI workloads.

Conclusion

The Master node functions as the brain and nervous system of a Kubernetes cluster, orchestrating all control loops and ensuring the cluster’s desired state. In production, a multi‑replica high‑availability setup with load‑balanced API servers, independent etcd clusters, RBAC, encryption, and regular backups is essential for stability and security.