Chapter 15 of 24

Fargate and Mixed Scheduling

Add serverless pod capacity without pretending every Kubernetes workload fits it.

01Learning objectives

02The selector is the placement boundary

A profile is not a general serverless switch. Both namespace and label must match when the pod is scheduled.

03What fits Fargate

Workload needFargate?Course placement
Stateless queue worker with normal pod networkingYesworkers namespace plus compute=fargate.
Envoy Gateway, Argo CD, monitoring agentsNo for this designDedicated EC2 system group.
DaemonSetsNoEC2; Fargate does not support DaemonSets.
Privileged containers, host networking, or HostPortNoReviewed EC2 group if the security design permits them.
GPUsNoGPU-capable EC2 node group.
EBS-backed pods, including CassandraNoDedicated EC2 group; EBS volumes cannot mount to Fargate pods.

04Lab: inspect the selector

# The same mocked test runs with either CLI.
terraform -chdir=learn-terraform/capstone/infra/modules/eks test -filter=tests/eks.tftest.hcl
tofu -chdir=learn-terraform/capstone/infra/modules/eks test -filter=tests/eks.tftest.hcl

# Review the two selector dimensions.
rg 'fargate_namespace|fargate_labels|selector' learn-terraform/capstone/infra/modules/eks learn-terraform/capstone/infra/environments

The test rejects a namespace-only profile. A broad selector can silently move future pods to Fargate, so the label is part of the contract.

05Plan and runtime behavior

  1. The Fargate pod execution role lets EKS launch the pod and pull images. It is not the application workload role.
  2. EKS Pod Identity does not support Fargate. A Fargate application that calls SQS or another AWS API uses IAM roles for service accounts (IRSA); its containers cannot assume the pod execution role.
  3. This EKS Terraform state owns the IAM OIDC provider lifecycle and exports its ARN. Task 10's data Terraform state owns the Fargate worker IAM role because it knows the exact SQS permissions. Task 10's GitOps Helm chart owns the service-account annotation because it knows the exact Kubernetes service account.
  4. Fargate profiles use private subnets only. Those subnets need NAT or reviewed VPC endpoints.
  5. Changing selectors or subnets replaces the profile. Existing pods do not automatically move; rescheduling evaluates profiles again.
  6. Fargate services behind load balancers use IP targets. The later Envoy Gateway stays on EC2 system nodes.
  7. Mixed compute keeps one control plane while choosing the smallest suitable runtime per pod class.

!Failure drill

A worker pod stays Pending after the profile is added. Check the exact namespace and labels. Pods are evaluated when scheduled; delete only the disposable failed pod so its controller recreates it. Do not broaden the profile to default or remove the label merely to make scheduling succeed.

06Verify boundaries

07Cleanup

The mocked test leaves no AWS resources. After a future apply, remove or relabel the owning Deployment before deleting its profile; otherwise replacement pods can remain Pending.

08Quick check

Does Fargate create EC2 instances in your account?

No. EKS schedules matching pods onto AWS-managed Fargate compute; you do not manage an EC2 group for those pods.

Can the EBS CSI controller run on Fargate?

The controller can, but the EBS CSI node DaemonSet must run on EC2, and EBS volumes cannot mount to Fargate pods.

09Recap and next

Fargate is a narrow pod runtime for labeled stateless workers. EC2 remains the home for Envoy, platform agents, DaemonSets, GPUs, privileged networking, and EBS-backed state.

Next in Phase 4: add autoscaling ownership, EBS CSI and snapshots, then Envoy Gateway behind a private NLB.

10Source notes