SysPad › Lessons › compute lessons › EKS Cluster

How EKS Cluster works

Managed Kubernetes control plane with an EC2 worker node group. The workload autoscales (HPA) between min and max replicas to hold pods near a target utilisation - running pod count, node pressure, and cost follow the load. Billed as a flat $0.10/hr control plane plus the EC2 node group.

Kubernetes is the industry-standard container platform, but its control plane is notoriously fiddly to run. EKS takes that part off your hands: AWS operates a managed control plane, and you bring the workers, either EC2 nodes you manage or serverless Fargate. You get real Kubernetes and its whole ecosystem, minus the worst of the operational pain.

What you will learn

What does "managed Kubernetes" actually manage, and what’s still yours?
EC2 node groups vs Fargate for the data plane, what’s the trade?
How do pods, Deployments, and the scheduler fit together?
When is EKS worth its complexity over ECS?

Control plane vs data plane

A Kubernetes cluster has a control plane (the API server, scheduler, and etcd datastore that make decisions) and a data plane (the workers that actually run containers). EKS runs the control plane for you, highly available across AZs, patched and scaled by AWS.

EC2 nodes vs Fargate workers

For the data plane you choose how pods get capacity. EC2 node groups are pools of EC2 instances you manage (and can pack many pods onto). Fargate runs each pod on serverless capacity, no nodes to manage at all.

Pods, Deployments, and the scheduler

The unit you run is a pod (one or more containers). You usually declare a Deployment ("keep 3 replicas of this pod"), and the Kubernetes scheduler places each pod onto a worker with room. A Service gives a stable address to reach them.

You describe the desired state (3 replicas); Kubernetes continuously reconciles reality to match it, rescheduling pods if a node dies.

⚓ Teams with existing Kubernetes manifests/skills, multi-cloud goals, or a need for the k8s ecosystem (operators, Helm, service meshes).

EKS vs ECS

EKS gives you real Kubernetes: portability across clouds/on-prem, the huge k8s ecosystem, and standard tooling. ECS is simpler and AWS-native with less to learn and operate.

Flashcards

In EKS, what does AWS manage and what stays your responsibility?: AWS manages the control plane (API/scheduler/etcd). You provide the data plane workers (EC2 nodes or Fargate) and your workloads.
EC2 node groups vs Fargate for EKS workers?: EC2 nodes: control, any instance type, denser/cheaper at scale, but you manage them. Fargate: per-pod serverless, no node ops, at a premium and with some feature limits.
You declare a Deployment of 3 replicas; a node fails. What happens?: Kubernetes reconciles to desired state: the scheduler reschedules the lost pods onto healthy capacity to keep 3 running.
What is the basic deployable unit in Kubernetes/EKS?: A pod (one or more containers sharing context). Deployments manage replica sets of pods; Services give them a stable address.
Why pick EKS over ECS despite the extra complexity?: You want real Kubernetes: portability, existing k8s skills/manifests, and the ecosystem (Helm, operators, meshes). Otherwise ECS is lighter.

Sources

Open the SysPad canvas · Official EKS Cluster documentation