Job 워크로드를 위한 EKS 노드 그룹 자동 확장 여정

Karrot의 Cluster 팀은 Job 워크로드가 한 번 시작되면 중단하기 어렵다는 점 때문에, 서버 워크로드와 분리된 전용 EKS Node Group을 운영해 왔다. 하지만 고정 노드 수만으로는 작업이 몰릴 때 지연이 생기고, 한가할 때는 비용이 낭비돼 운영 부담이 컸다.

자동 확장을 적용하려면 두 가지가 필요했다. 첫째는 Pod를 가능한 한 적은 노드에 몰아 넣는 bin-packing이고, 둘째는 스케일-in 과정에서 실행 중인 Job이 강제 종료되지 않게 막는 장치였다.

bin-packing은 별도 스케줄러 대신 PodAffinity로 구현했다. group: job 라벨을 가진 Pod끼리 같은 노드에 배치되도록 유도했고, 이를 Kyverno로 Argo Workflow Pod에 일괄 적용했다. 테스트에서는 Pod가 여러 노드에 고르게 퍼지던 상태에서, PodAffinity 적용 후 일부 노드에 집중 배치되는 것을 확인했다.

강제 종료 방지는 Cluster Autoscaler의 cluster-autoscaler.kubernetes.io/safe-to-evict: "false"와 Karpenter의 karpenter.sh/do-not-disrupt: "true"를 활용했다. 또한 Cluster Autoscaler를 Multi-AZ ASG와 함께 쓸 때는 AZ rebalancing이 Job Pod를 끊을 수 있어 이를 꺼야 한다고 정리했다.

Alpha 환경에서는 정상 동작했지만, Production에서는 정각마다 대량의 Job Pod가 몰리면서 새로운 문제가 드러났다. Pod가 적은 노드에 집중되자 한 노드당 부하가 급격히 올라갔고, 특히 다음 문제가 발생했다.

• kubelet overload: kubelet_pleg_relist_duration_seconds_bucket 지표가 급등했고, Pod의 CPU request가 실제 사용량보다 낮아 더 많은 Pod가 한 노드에 몰렸다.
• Image Pull failures
• EBS Volume throttling
• CNI Plugin IP assignment 지연

저자는 kube-reserved를 늘리는 방법도 시도했지만, Pod right-sizing 없이서는 충분하지 않았다고 설명한다. 결국 bin-packing만으로는 부족하고, 노드 집중으로 생기는 운영 부하까지 함께 제어해야 한다는 점이 핵심 결론이다.