Dagster jobs causing ephemeral-storage evictions on eks-prod-legacy
Status Fixed / completed
Maintainer reply None cached
Activity 5 comments · opened Jan 9, 2026 · closed Jan 9, 2026
Summary
Dagster jobs on eks-prod-legacy are being evicted due to ephemeral-storage exhaustion on Karpenter-managed nodes.
Evidence
Active evictions observed:
4m41s Warning Evicted pod/claims-prod-97cc97-58b459896f-4nfnr
The node was low on resource: ephemeral-storage.
Threshold quantity: 3210844697, available: 2997940Ki.
Affected pods (Error state):
- ai-cw-virtual-agent-dagster-prod-* (multiple)
- claims-prod-97cc97-* (multiple)
- eld-management-prod-* (multiple)
Problem node: ip-10-0-77-203.ec2.internal (dagster nodepool, r5a.2xlarge)
Root Cause
- Insufficient disk provisioning - EC2NodeClass
defaulthas noblockDeviceMappings, resulting in ~17GB allocatable ephemeral storage per node (Bottlerocket default)
- Under-requested storage - All Dagster jobs request only 1Gi ephemeral-storage but appear to use significantly more
- High pod density - Some dagster nodes have 19+ pods; concurrent job execution exhausts available disk
Impact
- Intermittent Dagster job failures
- Pods evicted mid-execution
- Jobs need manual re-triggering
Recommended Fixes
Infrastructure (DevOps)
- Add
blockDeviceMappingsto EC2NodeClass with larger root volume (e.g., 100Gi) - Consider creating a dedicated EC2NodeClass for dagster with appropriate disk sizing
Application (Data Team)
- Profile actual disk usage of jobs
- Update ephemeral-storage requests to match actual usage
- Ensure jobs clean up temp files after processing
- Consider PVCs for large data processing workloads
Related Context
This aligns with observations about "intermittent failures happening to some dagster jobs" related to ephemeral disk availability when running multiple jobs concurrently.
---
🤖 Generated with Claude Code
5 Comments
Additional Finding: Stale Code Server Deployments
Investigation revealed that multiple old code server versions are still running but essentially idle, contributing to pod density and disk pressure.
Activity Analysis (Last 2 Hours)
| Code Server | Age | Log Lines | Status |
|-------------|-----|-----------|--------|
| claims-prod-97cc97 | 8 months (May 2025) | 2 | ❌ Idle (startup only) |
| claims-prod-92a9c3 | ~1 hour | 86 | ✅ Active |
| eld-management-5c2518 | 8 months (May 2025) | 23 | ⚠️ Low activity |
| eld-management-91b53a | 10 days | 63 | ✅ Active |
Evidence
The OLD claims-prod-97cc97 has only 2 log lines (just startup messages) - it's not processing any work.
Root Cause
Dagster Cloud deployments create new code server versions on each deploy, but old versions are retained for rollback capability. There's no automatic cleanup of very old versions, resulting in:
Recommended Cleanup
Safe to delete (Data Team confirmation recommended):
claims-prod-97cc97- Clearly idle, 8 months oldeld-management-prod-5c2518- Much less active than newer versionsImpact of cleanup:
Action Items
---
🤖 Generated with Claude Code
Summary: Root Cause Analysis
| Factor | Finding |
|--------|---------|
| Trigger | Multiple jobs running concurrently exhaust disk |
| Root Cause 1 | Nodes only have 17Gi disk (default Bottlerocket, no blockDeviceMappings configured) |
| Root Cause 2 | 10 code servers running when 4 would suffice |
| Root Cause 3 | Stale 8-month-old deployments never cleaned up |
| Root Cause 4 | 1Gi ephemeral requests underestimate actual usage |
Recommended Actions
Quick Wins
blockDeviceMappings(DevOps) - e.g., 100Gi root volumeLonger Term
---
🤖 Generated with Claude Code
Resolution
Fix has been applied to
devops-app-of-apps-k8srepo. All EC2NodeClasses now have proper blockDeviceMappings for Bottlerocket:| NodeClass | Boot (/dev/xvda) | Data (/dev/xvdb) | Status |
|-----------|------------------|------------------|--------|
| ai | 10Gi | 100Gi | ✅ |
| dagster | 10Gi | 100Gi | ✅ |
| default | 10Gi | 100Gi | ✅ |
| devops | 10Gi | 100Gi | ✅ |
Impact
Verification
New nodes confirmed provisioning with larger disk:
Remaining Items (Data Team)
---
🤖 Generated with Claude Code
Closing - infrastructure fix applied. Remaining items (stale code server cleanup) are Data Team responsibility.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.