What are the main components of the Kubernetes architecture and what is each responsible for?

A Kubernetes cluster consists of a control plane plus a set of worker machines, called nodes, that run containerized applications in Pods. Every cluster needs at least one worker node to run Pods.

Conceptually, Kubernetes is declarative: you submit desired state to the API server (stored in etcd), and controllers run continuous reconciliation loops that watch for differences and act to drive actual state toward desired state.

Control plane components

The control plane makes global decisions about the cluster (such as scheduling) and responds to cluster events. In production it usually runs across multiple machines for high availability.

• kube-apiserver — the core component that exposes the Kubernetes HTTP API. It is the front end of the control plane and the single point of contact: all authentication, authorization, request validation, and reads/writes of cluster state flow through it. It scales horizontally. In normal deployments it is the only Kubernetes component that reads and writes cluster state directly in etcd; all other components interact with state through the API server.
• etcd — a consistent and highly-available key-value store used as Kubernetes' backing store for all cluster data: configuration, state, and metadata. etcd is mandatory and is the single source of truth — losing it means losing all cluster state, so it must run with quorum (an odd number of members) and be backed up regularly.
• kube-scheduler — watches for Pods not yet bound to a node and assigns each Pod to a suitable node, considering resources, constraints, and policies.
• kube-controller-manager — runs controllers that implement Kubernetes API behavior (e.g., Node controller, Job controller, EndpointSlice controller). Each controller watches the desired state and reconciles the actual state toward it.
• cloud-controller-manager (optional) — integrates with the underlying cloud provider, isolating cloud-specific logic from the core Kubernetes components.

Node components

These run on every node, keeping Pods running and providing the runtime environment.

• kubelet — the agent that ensures Pods are running, including their containers. It watches the API server for Pod assignments, starts containers via the runtime, mounts volumes, runs liveness/readiness probes, and reports node status.
• kube-proxy — implements Service networking by programming iptables or IPVS rules on nodes so traffic to a Service is forwarded to the correct Pod IPs. It is marked optional because some CNI plugins (e.g., Cilium in eBPF mode) take over its job, but in a standard cluster it is required.
• Container runtime — the software responsible for running containers (containerd, CRI-O, etc., via the CRI interface).

Addons

Addons extend cluster functionality: cluster DNS (CoreDNS by default), the Dashboard web UI, container resource monitoring, and cluster-level logging.

Common follow-up: all communication flows through the API server — the scheduler, controllers, and kubelets simply watch it and react — which makes the API server the critical hub of the cluster.