We Recommend Managed Node Groups over Fargate for EKS Add-Ons
6 days ago
- #Karpenter
- #Fargate
- #EKS
- Fargate initially seemed ideal for running Karpenter on EKS due to no node management and automatic scaling.
- In practice, Fargate caused issues with EKS add-ons, leading to a recommendation for small managed node groups (MNGs).
- Fargate's appeal includes simpler setup and showcasing Karpenter's capabilities, but MNGs offer operational benefits with Infrastructure-as-Code.
- Terraform's dependency model creates a bootstrap deadlock with Fargate, as add-ons can't start without nodes, and nodes can't start without add-ons.
- High availability challenges arise with Fargate, as critical services may end up co-located on a single node, creating a single point of failure.
- A minimal MNG solution ensures add-ons are distributed across AZs, provides stability for Karpenter, and eliminates bootstrap deadlock.
- Fargate has architectural constraints like isolated compute resources, no EBS-backed PVCs, and fixed CPU/memory configurations.
- Cost-wise, Fargate is more expensive than EC2 instances, and the hybrid approach (MNG + Karpenter) offers better cost optimization.
- Karpenter's documentation now defaults to MNGs, indicating a shift towards reliability over Fargate's simplicity.
- EKS Auto Mode offers a managed solution but comes with trade-offs like higher costs and less configuration control.