데브옵스
Spark Connect on Kubernetes #2: Operator로 만드는 Control Plane
두줄요약
Spark Operator와 Tenant Operator를 분리해 Spark Connect 서버의 복구·교체를 제어했습니다. Blue-Green 전환, readiness 개선, glibc arena 제한으로 세션과 메모리 문제를 다뤘습니다.
구조와 흐름
- Apache Spark Operator의 개별 SparkApplication 기동·상태 관측·재시도와 Spark Tenant Operator의 테넌트별 replica·설정·교체 관리 분리
- Gateway의 generation 기반 라우팅으로 신규 세션은 새 서버군, 기존 세션은 원래 Driver로 유지
- 새 generation 준비, 안정성 확인, 신규 세션 전환, 기존 서버 drain·삭제 순서의 Blue-Green 교체
선택 이유
- Driver 요청·컨테이너·Pod 준비 상태와 기동 타임아웃, 재시도 attempt, 실패 이력의 세분화된 관리 기준
- Apache Spark Operator의 단계별 상태·복구 정책 활용과 Tenant Operator의 서비스 단위 제어 결합
주의할 점
- DriverReady만으로 Connect 요청 수용 가능 여부를 판단하지 않도록 gRPC 연결 기반 exec readiness probe 구성
- Static Allocation에서 Driver Ready와 Executor의 Service DNS 탐색이 서로 대기하는 순환 의존성
- drain 기본 90분 이후 남은 세션 강제 종료 가능성
성능/운영 포인트
spark.kubernetes.executor.useDriverPodIP=true로 Executor의 Driver Pod IP 직접 연결spark.kubernetes.driver.service.publishNotReadyAddresses로 Driver 발견과 Connect 요청 수용 조건 분리- glibc arena 단편화 대응을 위한
MALLOC_ARENA_MAX=max(4, cores)적용과 72시간 메모리 증가 억제 관측
