Spark on Kubernetes 배포 모델 — 드라이버/익스큐터 파드와 디커미셔닝
Apache Spark Whole-Stage Code Generation 및 Kubernetes 배포 공식 문서·기술 자료 종합 (웹 리서치, 2026) — Apache Spark 공식 문서(running-on-kubernetes.html) + japila.pl Mastering Spark SQL(WholeStageCodegenExec) Apache Spark 공식 문서 Running Spark on Kubernetes
이 모듈을 다 읽으면
- K8s에서 Spark 애플리케이션 하나가 실행될 때 어떤 파드들이 만들어지는지 설명할 수 있다
- YARN과 달리 K8s에는 상시 떠 있는 별도 리소스 매니저 프로세스가 없다는 것의 의미를 판단할 수 있다
- 셔플 블록 디커미셔닝이 spark-learn-39의 shuffleTracking과 어떻게 다른 대안인지 구분할 수 있다
spark-learn-39에서 이미 다룬 K8s Dynamic Allocation의 shuffleTracking 대안을 전제로, K8s 배포 자체의 파드 모델과 client/cluster 모드, 그리고 shuffleTracking과는 또 다른 세 번째 대안인 디커미셔닝을 정리한다.
드라이버 파드가 스스로 익스큐터 파드를 만든다
spark-submit --master k8s://<API서버주소>로 제출하면, Spark는 먼저 드라이버를 담을 파드 하나를 K8s에 띄운다. 그 드라이버 프로세스가 직접 K8s API 서버에 요청을 보내 자신이 필요로 하는 만큼의 익스큐터 파드를 만든다 — YARN처럼 별도로 항상 떠 있는 ResourceManager 데몬이 스케줄링을 도맡는 게 아니라, 애플리케이션(드라이버) 자신이 그때그때 자신의 익스큐터를 K8s에 직접 요청하는 방식이다. 애플리케이션이 끝나면 익스큐터 파드들은 정리되지만, 드라이버 파드는 로그를 보존한 채 'Completed' 상태로 K8s API에 남아있다가 나중에 가비지 컬렉션되거나 수동으로 정리된다.
핵심 포인트
- 드라이버 파드가 뜬 뒤 그 드라이버 프로세스가 직접 K8s API에 익스큐터 파드 생성을 요청한다 — YARN의 상시 ResourceManager와 다른 모델
- 애플리케이션 종료 후 익스큐터 파드는 정리되지만, 드라이버 파드는 로그 보존을 위해 'Completed' 상태로 남는다
client 모드와 cluster 모드의 차이
cluster 모드는 드라이버 자체도 K8s 파드 안에서 실행된다(spark-submit을 실행한 머신과 무관하게 클러스터 안에서 완결). client 모드는 spark-submit을 실행한 바로 그 프로세스(예: 로컬 머신이나 노트북 서버)가 드라이버 역할을 하고, 그 드라이버가 K8s 클러스터에 익스큐터 파드만 만들어 연결한다 — 이 경우 드라이버를 실행하는 머신이 K8s 클러스터 안의 익스큐터 파드들과 네트워크로 직접 통신 가능해야 한다는 제약이 따른다. cluster 모드에서는 spark-submit 시 --kubernetes-namespace 같은 옵션으로 드라이버/익스큐터 파드가 배치될 네임스페이스를 지정할 수 있다.
핵심 포인트
- cluster 모드: 드라이버도 K8s 파드 안에서 실행(완전히 클러스터 안에서 완결)
- client 모드: spark-submit을 실행한 머신이 드라이버 역할 — 그 머신이 익스큐터 파드들과 직접 통신 가능해야 하는 제약
셔플 블록 디커미셔닝 — shuffleTracking과는 또 다른 세 번째 대안
spark-learn-39에서 다룬 shuffleTracking은 '아직 필요한 셔플 데이터가 있으면 executor 회수를 늦춘다'는 방식이었다. 이와 별개로 spark.decommission.enabled + spark.storage.decommission.shuffleBlocks.enabled를 켜면, 노드가 회수(decommission)되기 전에 그 노드가 들고 있던 셔플 블록을 다른 살아있는 노드로 미리 옮겨두는 방식으로 대응할 수 있다 — shuffleTracking이 '회수를 늦추는' 수동적 대응이라면, 디커미셔닝은 '데이터를 미리 옮겨서' 회수를 그대로 진행할 수 있게 하는 능동적 대응이라는 차이가 있다. 클라우드 스팟 인스턴스처럼 노드가 예고 후 강제로 회수되는 환경(Kubernetes의 노드 축소 등)에서 특히 유용하다.
핵심 포인트
- shuffleTracking(module 39): 셔플 데이터가 필요한 동안 executor 회수를 늦추는 수동적 대응
- 디커미셔닝(spark.decommission.enabled+shuffleBlocks.enabled): 노드 회수 전 셔플 블록을 다른 노드로 미리 옮기는 능동적 대응 — 스팟 인스턴스나 K8s 노드 축소 환경에 유용