Two Misconfigurations That Caused Spark OOM Failures on Kubernetes

KẾT LUẬN

Hai lỗi cấu hình hạ tầng tưởng chừng vô hại — tmpfs RAM-backed scratch directories và podAffinity cứng ép executor cùng node — đã tương tác theo kiểu compound và gây OOM failures hàng loạt cho Spark pipeline trên AKS sau migration từ on-prem. Vấn đề chỉ lộ diện ở tải production shuffle-heavy. Fix bằng cách tắt tmpfs (dùng disk-backed volumes), tăng volume size 1Gi → 10Gi, và dùng podAntiAffinity preferred để phân tán executor. Kết quả: zero OOM trong 6 tháng, job hoàn thành ổn định với 4 executor, không cần nâng cấp infrastructure.

LUẬN ĐIỂM CHÍNH

• spark.kubernetes.local.dirs.tmpfs=true khiến shuffle spill ghi vào RAM node thay vì disk — mỗi executor ghi shuffle data vào tmpfs volumes, cạn kiệt node RAM chỉ trong vài giây
• podAffinity requiredDuringScheduling buộc toàn bộ 4 executor chạy trên cùng một node 64GB, tập trung toàn bộ áp lực bộ nhớ shuffle-time vào một máy duy nhất
• Volume size 1Gi cho tmp-volume và workdir là quá nhỏ với job multi-layout fixed-width đọc file 3GB nhiều lần — shuffle spill vượt quá capacity và gây OOM killer
• Compound infrastructure misconfigurations chỉ lộ diện dưới tải production-scale; pre-migration test với dataset nhỏ không phát hiện được, dễ chẩn đoán nhầm thành vấn đề Spark tuning như heap undersize hay data skew

LUẬN ĐIỂM PHỤ

• Cloud migration làm thay đổi ‘hợp đồng hạ tầng’ — storage semantics (emptyDir/tmpfs vs disk) và scheduling behavior (podAffinity vs podAntiAffinity) cần được validate rõ ràng trước khi lên production
• Tăng executor memory (8g → 10g) và tăng số lượng executor không giải quyết được vấn đề gốc vì bottleneck nằm ở node-level memory exhaustion, không phải heap sizing
• Pre-migration testing với dữ liệu nhỏ hoặc ít shuffle-intensive không thể phát hiện compound failures — cần mô phỏng đúng production workload volume trong staging

LUẬN CỨ & VÍ DỤ

• Datadog Kubernetes Node Overview cho thấy node memory spike từ ~42GB lên >58GB chỉ trong vài giây khi shuffle stage bắt đầu, kèm OOMKilled (exit code 137); job phải spin tới executor-50 trước khi fail hoàn toàn — chứng tỏ vấn đề là node-level memory exhaustion, không phải heap
• Sau fix: job hoàn thành trong ~1 giờ với đúng 4 executor, zero OOM incidents trong 6 tháng, không cần nâng cấp node pool hay tăng chi phí infrastructure
• kubectl describe node (Standard_D16a_v4) cho thấy 64GB RAM → ~60.6GB allocatable, 4 executor x 10GB = 40GB, headroom ~20GB — đủ an toàn khi executor phân tán qua các node, nhưng fatal khi dồn cả 4 executor cùng node + tmpfs-backend

Nguồn: InfoQ | Phân tích bởi AI