Serverless Kubernetes changes the responsibility for node management: instead of a fleet of EC2 workers, each pod runs in its own dedicated Fargate environment. Practitioners care because the change touches scheduling, network topology, IAM usage, and operational tooling.
Admission Routing and Scheduler Changes
EKS uses a Fargate profile to declare which pods should run on the serverless backend. The profile selects a namespace and optional pod labels, and also defines the private subnet and security group for the pod’s ENI. When a pod matches a profile, an admission webhook mutates the pod object: it adds the profile name as a label and overwrites the schedulerName with the Fargate scheduler. This occurs before the pod is written to etcd, preventing the default scheduler from claiming the pod.
Dedicated Compute per Pod and Network Isolation
The Fargate scheduler runs on the control plane and requests fresh capacity based on the pod’s resource request and profile. It creates a provisional node association, then the Fargate runtime launches a lightweight Linux environment that registers a full Node object once ready. When the pod terminates, the runtime tears down the node and releases the capacity.
Each pod receives its own Elastic Network Interface, placed in the subnet and security group defined by the profile. This gives the pod a first‑class presence in the VPC, allowing VPC flow logs and security‑group rules to target the workload directly rather than a shared worker node.
Internally, Fargate creates three Linux network namespaces: a platform namespace for telemetry and credential services, a node namespace that hosts the Kubernetes data‑plane components and the customer ENI, and a workload namespace for the application container. The ENI lives in the node namespace, providing both control‑plane connectivity and pod traffic paths while keeping platform traffic separate.
Operational and Security Implications
Because the environment is serverless, EC2 instance metadata is unavailable. Applications that need AWS credentials must rely on IAM roles for service accounts, using the pod execution role defined in the profile. This role is distinct from any identity the application containers assume.
Lifecycle events—provision, bind, and teardown—are managed by the Fargate runtime. Failures trigger reconciliation that clears the provisional node assignment and reclaims capacity before retrying. Monitoring should therefore include both Kubernetes events (pod status, node registration) and VPC‑level visibility (flow logs on the pod’s ENI).
Security‑group rules applied to the pod’s ENI become the primary network boundary. Since each pod has its own interface, rule granularity can be finer than with shared worker nodes, but it also requires careful profile configuration to avoid unintentionally broad exposure.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
- Define
Fargate profilesthat accurately match the namespaces and labels of workloads you intend to run serverlessly. - Ensure the pod execution
IAM rolegrants only the permissions needed for the Fargate runtime and image pulls; use IAM roles for service accounts for any AWS calls from the application. - Review security‑group and subnet selections in each profile to enforce the desired network isolation per pod.
- Update monitoring pipelines to capture both Kubernetes events (node creation, pod binding) and VPC flow logs for the per‑pod
ENI. - Validate that CI/CD pipelines label pods correctly so the admission webhook routes them to the Fargate scheduler.
