Kubernetes Cluster Architecture Diagram

What this diagram shows

A Kubernetes cluster architecture diagram displays the layered structure of a production Kubernetes deployment, splitting responsibilities between the control plane (master node) and one or more worker nodes. The diagram shows how the API server receives requests, the scheduler places workloads, the kubelet daemon runs containers, and persistent storage connects across nodes. Data flows from client requests through the control plane's decision-making components down to worker nodes where actual application pods execute, with etcd persisting cluster state throughout.

Key components

• API Server — Exposes the Kubernetes API and processes all requests from kubectl, controllers, and external clients.
• Scheduler — Evaluates resource requests and constraints to assign pods to suitable worker nodes.
• etcd — Distributed key-value store that persists all cluster configuration and state data.
• Kubelet — Agent running on each worker node that pulls pod specifications from the API server and manages container lifecycle.
• Container Runtime — Executes container images (typically Docker or containerd) as instructed by the kubelet.
• kube-proxy — Maintains network rules on each node to enable service discovery and load balancing across pods.
• Worker Node — Physical or virtual machine that hosts the kubelet and container runtime to run application workloads.

When to use it

Use this diagram when explaining how Kubernetes operates internally, documenting cluster setup procedures, or designing multi-node deployments. It is essential for architecture reviews, onboarding engineers to Kubernetes concepts, planning resource allocation across nodes, and troubleshooting where a pod is scheduled or why API requests fail. Include it in runbooks, infrastructure-as-code documentation, and system design proposals.

Common mistakes

• Omitting the control plane entirely and showing only worker nodes, which loses the critical orchestration and decision-making layer that distinguishes Kubernetes.
• Placing etcd on worker nodes instead of the control plane, which misrepresents state persistence and causes confusion about cluster resilience.
• Failing to show kube-proxy or networking components, which makes the diagram incomplete and suggests pods communicate directly without the service abstraction.

Adapting it to your system

Replace the single worker node with multiple nodes to reflect your actual cluster size. Add node labels or taints if you use them for scheduling constraints. Extend the control plane to show replicas of API server, scheduler, and controller-manager if you run a highly available cluster. Include persistent volume components if your workloads need stateful storage. Label network policies, ingress controllers, or CNI plugins if they are central to your architecture. Adjust the diagram to show namespace separation if multi-tenancy is relevant to your setup.