· javascript
One pod, one node: The architecture behind serverless Kubernetes on AWS
The experience of a single pod utilizing a dedicated compute environment forms the core of serverless Kubernetes on AWS. Amazon Elastic Kubernetes Service (EKS) Fargate redefines infrastructure management by making the pod the fundamental unit, rather than the worker node.
When a pod is selected for Fargate, EKS orchestrates the provisioning of a dedicated compute environment. This includes booting necessary Kubernetes components, assigning the pod an Elastic Network Interface (ENI) within the customer's virtual private cloud (VPC), and subsequently decommissioning the environment once the pod ceases operation. As stated, "Serverless Kubernetes changes who manages the node, not what Kubernetes expects from it."
This streamlined customer experience relies on several coordinated architectural decisions. Admission-time routing prevents the standard scheduler from claiming a Fargate pod; instead, a Fargate-specific scheduler provisions the required capacity. Furthermore, a focused runtime image supplies the necessary Kubernetes node components, while distinct network namespaces separate the platform's operational path from the workload's path.
EKS clusters can simultaneously utilize Amazon Elastic Compute Cloud (Amazon EC2) nodes and Fargate. To manage this placement, EKS employs a Fargate profile, an AWS resource that signals which pods should run on Fargate by specifying a namespace and optional pod labels. This profile also dictates the private subnet and security group for the pod's ENI, thus binding placement and network access together.
When Fargate is enabled, AWS operates an admission webhook within the control plane. If a pod matches a profile, this mutating webhook appends the profile's name to the pod's label and sets the scheduler name to the Fargate scheduler, directing the pod down the Fargate path before it is saved to etcd.
The Fargate scheduler, residing on the control plane, requests new capacity based on the pod's resource needs and its matching profile, bypassing the search across existing node pools. Once capacity is requested, the scheduler tentatively links the pod to a nominated node to prevent duplicate environment provisioning.
Fargate connects each pod to the customer’s VPC via its ENI, with the profile defining the associated subnet and security group. This means security-group rules apply to the pod’s ENI rather than a shared, customer-managed worker node.
To manage traffic, Fargate provisions three logical Linux network namespaces. The platform namespace handles Fargate services like telemetry, while the node namespace hosts Kubernetes core data-plane components and the customer ENI. The workload namespace runs the actual customer workload.
The runtime image functions as a miniature Kubernetes node, maintaining compatibility with the control-plane version. A custom PodAdmitHandler in EKS validates pods before they start, ensuring they are destined for the Fargate scheduling path, which protects the one-pod-per-node model.
EKS manages patching by periodically replacing Fargate pods, ensuring the latest security patches are applied without customer intervention. When this occurs, EKS notifies the customer and uses the Kubernetes Eviction API to gracefully remove the pod, respecting the PodDisruptionBudget.
