Abdelrahman.work

← Blog

EKS & Kubernetes InternalsArchitecture · Part 1 of 2

Understanding the Amazon EKS Architecture: Control Plane and Worker Node Components

4 min read
kubernetes aws eks architecture

Amazon Elastic Kubernetes Service (EKS) runs upstream Kubernetes while removing the operational burden of managing the control plane. To reason about EKS clusters effectively, it helps to understand exactly which components run where, and which are standard Kubernetes components versus EKS-specific additions.

At a high level, every EKS cluster is split into two parts:

  • A control plane that AWS provisions and manages inside an AWS-owned, EKS-managed VPC.
  • A data plane (your worker nodes) that runs in a VPC you control.

Let's walk through each side.

The Control Plane

The control plane makes global decisions about the cluster (such as scheduling) and detects and responds to cluster events (such as starting a new pod when a Deployment's replicas field is not satisfied). In EKS, the control plane is fully managed by AWS, runs across multiple Availability Zones for high availability, and is not directly accessible to you at the host level.

Standard Kubernetes control plane components

  • kube-apiserver — The front end of the Kubernetes control plane and the component every other part of the system talks to. EKS runs the API server as a highly available, fully managed service across multiple Availability Zones.
  • kube-controller-manager — Runs controller loops that continuously reconcile the actual state of objects toward their desired state (spec vs. status). Examples include the Deployment controller and the Node controller.
  • kube-scheduler — Watches for newly created pods that have no assigned node and selects a node for them using a two-step process: filtering (which nodes are feasible) and scoring (which feasible node is best).
  • Node controller — Part of the controller manager; manages node lifecycle concerns. If it stops receiving heartbeats from a node, it eventually marks the node's Ready condition as Unknown.
  • etcd — The consistent, highly available key-value store that holds all cluster data. It is based on the Raft consensus algorithm (one leader, multiple followers). In EKS, etcd is fully managed by AWS as part of the control plane.

For deeper reading on these components, see the Kubernetes components overview and the EKS Best Practices Guide for the control plane.

EKS-specific control plane elements

Beyond the standard Kubernetes components, EKS adds managed pieces that make the service work seamlessly on AWS:

  • Managed API server endpoint — When you create a cluster, EKS provisions a single, highly available endpoint that you use to reach the Kubernetes API server (for example, with kubectl). AWS manages the load balancing and scaling behind this endpoint for you.
  • AWS IAM Authenticator (server side) — Enables authentication to the cluster using AWS IAM identities. Covered in detail in the next post in this series.
  • CloudWatch logging — EKS can export control plane logs (API server, audit, authenticator, controller manager, and scheduler logs) to Amazon CloudWatch when you enable control plane logging.
  • Admission webhooks — EKS uses validating and mutating admission webhooks to support features such as IAM Roles for Service Accounts (IRSA) and Fargate pod admission.
  • Certificate signing components — EKS approves and signs kubelet certificate signing requests (CSRs) as nodes join the cluster.
  • Fargate scheduler — Schedules pods onto AWS Fargate when you use Fargate profiles.

The Worker Nodes (Data Plane)

Worker nodes run in a VPC you manage and are where your application pods actually run. Each node runs a standard set of Kubernetes components plus AWS integrations.

Standard Kubernetes node components

  • kubelet — The agent on each node that ensures containers described in a pod are running and healthy. It reports container and pod status back to the API server. The kubelet is the primary node component that communicates with the API server.
  • kube-proxy — Maintains network rules on each node so traffic can reach the correct pods. It implements Kubernetes Service networking (for example, translating a Service's virtual ClusterIP to the actual pod IPs) using iptables or IPVS mode.
  • Container runtime — The software that runs containers. Current EKS-optimized AMIs use containerd.

AWS integrations installed by default

By default, EKS installs several add-ons on every cluster:

  • Amazon VPC CNI (aws-node) — The container network interface plugin that gives each pod a real VPC IP address. It manages ENIs on the instance, allocates secondary IP addresses, and maintains a warm pool of IPs for fast pod startup. See the amazon-vpc-cni-k8s project for details.
  • CoreDNS — Provides in-cluster DNS resolution for Services and pods.
  • kube-proxy — Shipped and managed as an EKS add-on.
  • AWS IAM Authenticator (client side) — Used by the kubelet to authenticate the node to the cluster.

Bringing It Together

When a node boots, a bootstrap process configures it to join the cluster. In broad strokes, the node:

  1. Discovers the cluster and writes a kubeconfig the kubelet will use.
  2. Configures DNS and the kubelet's runtime configuration.
  3. Starts the kubelet as a systemd service so it can register with the control plane.

The EKS-optimized AMI build scripts are open source and available in the amazon-eks-ami repository, and node bootstrapping relies on the standard Kubernetes TLS bootstrapping mechanism.

The key mental model: AWS runs and scales the control plane for you across multiple AZs in an AWS-managed VPC, while you run the worker nodes in your own VPC. The two halves are joined by a secure, authenticated communication path — which is exactly what the next post covers.