A pod-level walkthrough of admission routing, dedicated scheduling, and network isolation, no worker nodes required

Serverless Kubernetes changes who manages the node, not what Kubernetes expects from it. Kubernetes expects a node to register with the control plane, report capacity, run a Kubelet, provide networking, and host workloads. AWS Fargate provides those behaviors without asking customers to create, patch, scale, or replace a fleet of worker nodes.

Amazon Elastic Kubernetes Service (EKS) Fargate solves that problem by making the pod the unit of infrastructure. When a pod is selected for Fargate, EKS provisions a dedicated compute environment, boots the Kubernetes components it needs, gives the pod an Elastic Network Interface (ENI) in the customer’s virtual private cloud (VPC), and tears the environment down when the pod is gone.

“Serverless Kubernetes changes who manages the node, not what Kubernetes expects from it.”

That customer experience depends on several coordinated design choices. Admission-time routing prevents the default scheduler from claiming a Fargate pod. A Fargate-specific scheduler provisions capacity instead of selecting from a pre-existing node pool. A focused runtime image supplies the Kubernetes node components, while separate network namespaces keep the platform path distinct from the workload path. An admission handler on the node limits workloads to patterns that fit a one-pod, one-environment model.

This article follows the components that make pod provisioning possible, from admission and scheduling through the node runtime and networking.

An EKS cluster can use nodes from Amazon Elastic Compute Cloud (Amazon EC2) and Fargate at the same time.

Source link