Kubernetes Architecture Diagram: Control Plane vs Data Plane Explained

Kubernetes separates cluster responsibilities into two distinct planes: a control plane that makes decisions and a data plane that runs workloads. Understanding this split is the foundation of every meaningful kubernetes architecture diagram, and it directly shapes how you design, debug, and scale clusters — whether you're running self-managed k8s or a managed service like Amazon EKS.

This article walks through each component in both planes, explains how they communicate, and maps the entire picture onto EKS architecture so you can see exactly what AWS manages for you versus what remains your responsibility. By the end, you'll have a mental model precise enough to draw the diagram yourself — or generate it automatically with a tool like draft1.ai.

What Is the Kubernetes Control Plane?

The control plane is the brain of a Kubernetes cluster: it stores desired state, makes scheduling decisions, and continuously reconciles reality toward that desired state. It never runs your application containers directly.

The control plane consists of four core components:

API Server (kube-apiserver)

The API server is the single entry point for all cluster operations. Every kubectl command, every controller loop, and every kubelet heartbeat flows through it over HTTPS (port 6443 by default). It validates and persists objects to etcd, then serves them back to watchers. Because it is stateless and horizontally scalable, high-availability setups run multiple replicas behind a load balancer.

Key characteristics: - Authenticates requests via certificates, OIDC tokens, or webhook authenticators - Enforces admission controllers (e.g., PodSecurity, MutatingWebhookConfiguration) before writes reach etcd - Exposes a versioned REST API (/api/v1, /apis/apps/v1, etc.)

etcd

etcd is a distributed key-value store that holds the entire cluster state — every Pod spec, ConfigMap, Secret, and node registration. It uses the Raft consensus algorithm to guarantee consistency across replicas. A three-node etcd cluster tolerates one node failure; a five-node cluster tolerates two.

Critical operational facts: - Default data directory: /var/lib/etcd - Recommended storage: low-latency SSD (< 10 ms fsync) - Maximum recommended database size: 8 GiB (etcd v3.5+) - Backup is non-negotiable — losing etcd without a backup means losing the cluster

Scheduler (kube-scheduler)

The scheduler watches for Pods with no assigned node and selects the best node based on resource requests, affinity/anti-affinity rules, taints, tolerations, and topology spread constraints. It does not start the Pod — it only writes the node name into the Pod spec. The kubelet on that node then picks up the assignment and starts the container.

Controller Manager (kube-controller-manager)

The controller manager bundles dozens of control loops into a single binary. The ReplicaSet controller ensures the right number of Pod replicas exist. The Node controller marks nodes NotReady after a configurable timeout (default: 40 seconds). The Job controller tracks completions. Each controller watches the API server and drives actual state toward desired state.

What Is the Kubernetes Data Plane?

The data plane is where your workloads actually run. It consists of worker nodes, each running three mandatory components: kubelet, kube-proxy, and a container runtime.

kubelet

The kubelet is an agent that runs on every worker node. It watches the API server for Pods assigned to its node, instructs the container runtime (via CRI — the Container Runtime Interface) to pull images and start containers, and reports node and Pod status back to the API server. If a container crashes, the kubelet restarts it according to the Pod's restartPolicy.

kube-proxy

kube-proxy maintains network rules on each node so that Service virtual IPs route to the correct Pod endpoints. In modern clusters it uses iptables or IPVS mode. Many teams replace kube-proxy with eBPF-based solutions like Cilium for better performance at scale (tens of thousands of services).

Container Runtime

The container runtime implements the CRI and actually manages container lifecycle. containerd is the dominant runtime in 2026, having fully replaced Docker as the default in most distributions since 2022. CRI-O is common in OpenShift environments.

Pods

A Pod is the smallest deployable unit in Kubernetes. It wraps one or more containers that share a network namespace (same IP, same localhost) and optionally shared volumes. Pods are ephemeral — they are created and destroyed by higher-level controllers like Deployments, StatefulSets, and DaemonSets.

Control Plane vs Data Plane: Side-by-Side Comparison

How This Maps to EKS Architecture

Amazon EKS is the clearest real-world illustration of the control/data split because AWS literally owns one plane and you own the other.

What AWS Manages (EKS Control Plane)

In EKS architecture, AWS runs the control plane in a dedicated VPC managed by AWS — you never SSH into the API server or etcd nodes. AWS guarantees: - Multi-AZ etcd with automated backups - API server endpoint behind an AWS-managed NLB - Automatic control plane version upgrades (with your approval) - CloudWatch logging for API server, audit, authenticator, scheduler, and controller manager logs

The k8s control plane components are invisible to you at the infrastructure level. You interact with them only through the Kubernetes API and AWS Console/CLI.

What You Manage (EKS Data Plane)

Your worker nodes run in your VPC, in subnets you define. You choose between three data plane models:

1. Managed Node Groups — AWS provisions and lifecycle-manages EC2 instances, but they live in your account and VPC. You still patch the AMI.
2. Self-Managed Nodes — Full control; full responsibility. You manage the Auto Scaling Group, AMI, and kubelet configuration.
3. AWS Fargate — Serverless Pods. AWS manages the underlying node entirely; you define only the Pod spec. No node-level access.

Networking the Two Planes Together

EKS uses AWS VPC CNI by default, which assigns each Pod a real VPC IP address from your subnet CIDR. The kubelet on each worker node reaches the API server endpoint over the internet (public endpoint) or through an AWS PrivateLink interface endpoint in your VPC (private endpoint — recommended for production). Port 443 is used for all API traffic.

The EKS auth model maps IAM roles to Kubernetes RBAC via the aws-auth ConfigMap (legacy) or the newer EKS Access Entries API (GA since 2024), which lets you manage IAM-to-RBAC mappings without editing a ConfigMap directly.

Drawing the Architecture Diagram

A complete kubernetes architecture diagram should show:

1. Control plane box (often labeled "AWS-managed" in EKS diagrams): API server → etcd cluster, scheduler, controller manager
2. Data plane box (your VPC): worker nodes, each containing kubelet + kube-proxy + containerd + running Pods
3. Communication arrows: kubelet → API server (port 443), kubectl client → API server, Pods → kube-proxy → Service VIP → target Pods
4. External integrations: IAM, ECR (image pull), ALB Ingress Controller, CloudWatch

Tools like draft1.ai let you describe this in plain English ("show me an EKS cluster with three worker nodes, an RDS backend, and an ALB") and generate the diagram automatically — useful for documentation, architecture reviews, and onboarding.

Key Takeaways

• The control plane (API server, etcd, scheduler, controller manager) makes all decisions; the data plane (kubelet, kube-proxy, Pods) executes them.
• etcd is the single source of truth for cluster state — back it up, use low-latency storage, and monitor its size against the 8 GiB limit.
• The API server is the only component other components communicate with directly; it is stateless and horizontally scalable.
• In EKS architecture, AWS fully manages the control plane; you manage worker nodes (unless using Fargate, where AWS manages the underlying compute too).
• A control plane failure makes the cluster unmanageable but does not immediately kill running Pods — they keep running until the node or container fails.
• EKS Access Entries (introduced 2024) replace the fragile aws-auth ConfigMap pattern for IAM-to-RBAC mapping.
• When drawing a kubernetes architecture diagram, always show the communication direction between kubelet and the API server — it is kubelet that initiates, not the API server pushing to nodes.

Frequently Asked Questions

What is the difference between the control plane and the data plane in Kubernetes?

The control plane stores desired state and makes scheduling and reconciliation decisions; the data plane runs the actual application workloads on worker nodes. Neither plane can fulfill its purpose without the other, but they fail independently — a control plane outage does not immediately stop running Pods.

What does the kube-apiserver actually do?

The API server is the central hub that validates, authenticates, and persists every change to cluster state in etcd, then serves that state to all other components. All cluster communication — from kubectl, controllers, and kubelets — goes through it on port 6443 (or 443 in managed services like EKS).

Why is etcd so critical in a Kubernetes cluster?

etcd holds the complete desired and observed state of the cluster; if it is lost without a backup, the cluster cannot be recovered. It uses the Raft consensus algorithm, so you should always run an odd number of replicas (3 or 5) and store data on low-latency SSDs.

In EKS architecture, who is responsible for the control plane?

AWS fully manages the EKS control plane, including the API server, etcd, scheduler, and controller manager, running them in a dedicated AWS-managed VPC with multi-AZ redundancy. You are responsible for worker nodes (EC2 managed node groups or self-managed) and all workloads running on them.

What is the kubelet and why does it matter?

The kubelet is the agent on every worker node that translates Pod specs from the API server into running containers via the container runtime interface. If the kubelet stops, the node stops reporting status and eventually gets marked NotReady, triggering Pod eviction by the node controller.

Can Kubernetes run without kube-proxy?

Yes — kube-proxy can be replaced by eBPF-based CNI plugins like Cilium, which handle service routing more efficiently at scale using kernel-level packet processing. Many large EKS deployments in 2026 run Cilium in kube-proxy replacement mode to reduce iptables rule explosion at high service counts.

How do I generate a Kubernetes architecture diagram quickly?

Tools like draft1.ai let you describe your architecture in plain English and generate accurate AWS and Kubernetes diagrams automatically, including EKS topology with control plane, worker nodes, VPC subnets, and external services. This is faster than drawing manually in Lucidchart or draw.io and keeps diagrams consistent with your written documentation.

Draw this in seconds with draft1. Describe your architecture in plain English and draft1 generates an editable AWS/cloud diagram plus documentation — no dragging boxes around. Try it free.