Serverless Kubernetes on AWS introduces a model where infrastructure management shifts from the worker node to the pod itself.
Amazon Elastic Kubernetes Service (EKS) Fargate addresses the complexity of maintaining worker nodes by making the pod the fundamental unit of infrastructure. When Fargate selects a pod, EKS provisions a dedicated compute environment, initiates necessary Kubernetes components, assigns an Elastic Network Interface (ENI) within the customer's virtual private cloud (VPC), and dismantles the environment upon pod termination. As stated, "Serverless Kubernetes changes who manages the node, not what Kubernetes expects from it."
This operational shift relies on several coordinated design elements. Admission-time routing prevents the default scheduler from claiming a Fargate pod. Instead, a Fargate-specific scheduler allocates capacity, and a focused runtime image supplies the required Kubernetes node components. Furthermore, distinct network namespaces ensure the platform path remains separate from the workload path. An admission handler on the node restricts workloads to patterns suitable for a one-pod, one-environment configuration.
An EKS cluster can concurrently utilize Amazon EC2 and Fargate nodes. Therefore, placement must be explicitly defined before the standard scheduling process commences. EKS utilizes a Fargate profile, an AWS resource specifying which pods run on Fargate by selecting a namespace and optional pod labels. This profile also dictates the private subnet and security group for the pod's ENI, unifying placement and network access decisions.
For clusters with Fargate enabled, AWS manages an admission webhook as part of the Kubernetes control plane. When a pod matches a profile, this mutating webhook adds the profile's name to the pod's label and sets the scheduler name to the Fargate scheduler. This action occurs before the pod object is saved in etcd and before the default scheduler can claim it. The profile also defines an AWS Identity and Access Management (IAM) role for the Fargate infrastructure to register its kubelet and fetch images from Amazon Elastic Container Registry (Amazon ECR), which is separate from the application identity.
The Fargate scheduler, running on the Kubernetes control plane, requests new capacity based on the pod's resource needs and its matching Fargate profile, rather than querying existing node pools. As noted, "The Fargate scheduler is a dedicated scheduler that runs on the Kubernetes control plane. It requests new capacity for a pod rather than searching a pool of existing nodes." Following capacity request, the scheduler tentatively links the pod to a nominated node, preventing duplicate environment provisioning. The runtime registers the Kubernetes Node object when the environment is ready, and the scheduler finalizes the binding after the node reports readiness.
Fargate connects each pod to the customer's VPC via its ENI, with the Fargate profile defining the associated private subnet and security group. Security-group rules and VPC routing thus apply to the pod's ENI, not a shared customer-managed node. This grants the pod a primary position within the VPC, allowing VPC flow logs to identify the interface and security-group rules to define the intended workload boundary.
To manage traffic, Fargate provisions three logical Linux network namespaces. The platform namespace handles Fargate services like telemetry and provisioning. The node namespace manages Kubernetes core data-plane components and the customer ENI. The workload namespace executes the customer workload. This separation maintains distinct paths for managed platform functions versus workload traffic.
The runtime image functions as a miniaturized Kubernetes node, ensuring compatibility with the control-plane version by providing the kubelet and necessary components. EKS employs a custom PodAdmitHandler to validate pods before they start, admitting only those destined for the Fargate scheduling path, which reinforces the one-pod-per-node concept.
This architectural evolution reflects a broader industry trend toward abstracting infrastructure management layers. The ability for market participants to leverage serverless primitives directly at the workload unit level reduces operational overhead associated with managing underlying compute fleets.
