EKS Pods can run on Fargate, but it’s not a direct replacement for EC2 nodes; it’s a parallel execution plane managed by Fargate itself, triggered by specific Kubernetes configurations.
Let’s see this in action. Imagine you have a standard Kubernetes Deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-fargate-app
labels:
app: my-fargate-app
spec:
replicas: 2
selector:
matchLabels:
app: my-fargate-app
template:
metadata:
labels:
app: my-fargate-app
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
By default, this Pod would land on an EC2 node in your EKS cluster. To make it run on Fargate, you need to associate it with a Fargate Profile.
A Fargate Profile is a Kubernetes Custom Resource (CR) that tells EKS how to route Pods to Fargate. It’s defined within your EKS cluster’s networking configuration.
Here’s what a Fargate Profile looks like:
apiVersion: eksctl.io/v1alpha5
kind: FargateProfile
metadata:
name: my-fargate-profile
namespace: default # Or any namespace you want to target
cluster: my-eks-cluster
spec:
selectors:
- namespace: default # This profile applies to Pods in the 'default' namespace
labels:
runOn: fargate # And specifically to Pods with this label
subnets:
- subnet-0123456789abcdef0
- subnet-0fedcba9876543210
podExecutionRoleArn: arn:aws:iam::123456789012:role/eksctl-my-eks-cluster-FargateExecutionRole-ABCDEFG
When you create this profile, EKS watches for Pods that match the selectors. In this example, any Pod created in the default namespace that also has the label runOn: fargate will be scheduled onto Fargate.
The subnets are crucial. These are the VPC subnets where your Fargate Pods will get their IP addresses. They need to have routes to the internet (via NAT Gateway or similar) if your Pods need to access external services.
The podExecutionRoleArn is an IAM role that Fargate assumes to perform actions on your behalf, like pulling container images from ECR and logging to CloudWatch. This role needs permissions like AmazonEKS_CNI_ExecuteRole and AmazonEC2ContainerRegistryReadOnly.
So, to run our my-fargate-app on Fargate, we’d modify its Deployment to include the label specified in the Fargate Profile:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-fargate-app
labels:
app: my-fargate-app
spec:
replicas: 2
selector:
matchLabels:
app: my-fargate-app
template:
metadata:
labels:
app: my-fargate-app
runOn: fargate # This label matches our Fargate Profile selector
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
Once this Deployment is applied, EKS detects the runOn: fargate label in the default namespace. Instead of trying to find an available EC2 node, EKS signals AWS Fargate to provision the Pod. Fargate then handles the underlying infrastructure provisioning, container execution, and networking for that Pod.
The key takeaway is that Fargate isn’t a node type you attach to your EKS cluster in the traditional sense. It’s a separate, serverless compute engine that EKS integrates with via Fargate Profiles. You define which Pods go to Fargate, and Fargate handles the rest. This is excellent for ephemeral workloads, batch jobs, or applications that benefit from automatic scaling without managing EC2 instances.
When you define a Fargate Profile, EKS doesn’t provision EC2 nodes for those selected Pods. Instead, it creates a Kubernetes Node object in your cluster that represents the Fargate capacity. This Node object is a virtual representation, and the actual compute resources are managed by Fargate. This abstraction allows your existing Kubernetes tooling (like kubectl) to interact with Fargate-scheduled Pods seamlessly. The Pods appear as if they are running on a node, but that "node" is managed by AWS.