LeaderWorkerSet(LWS) 정리 - OpenShift 4.20 멀티노드 LLM 추론 오케스트레이션
2026년 11월 GA된 OpenShift 4.20에서 LeaderWorkerSet(LWS)이 정식 지원되면서, 최근 다룬 KubeRay·Kueue와 함께 분산 AI 워크로드 오케스트레이션의 한 축을 이루게 된 LWS의 개념, StatefulSet과의 차이, 핵심 스펙, 실제 예시를 정리합니다.
LWS(LeaderWorkerSet)란
LWS는 쿠버네티스 SIG(Special Interest Group)가 관리하는 API로, 여러 파드를 하나의 복제 단위(unit of replication)로 묶어 배포하기 위해 만들어졌습니다. 주 타깃은 멀티호스트 LLM 추론입니다. Llama 3.1 405B처럼 GPU 하나, 심지어 노드 하나에도 다 올라가지 않는 거대 모델을, 텐서 병렬화(tensor parallelism)·파이프라인 병렬화(pipeline parallelism)로 여러 노드에 쪼개 올릴 때 "리더 1개 + 워커 N개"로 구성된 파드 그룹을 관리해주는 것이 LWS의 역할입니다. OpenShift 4.20에서는 이 LWS API가 정식(GA)으로 들어왔고, 함께 JobSet이 테크 프리뷰로, Kubernetes Model Context Protocol(MCP) 서버가 개발자 프리뷰로 추가됐습니다.
StatefulSet과 무엇이 다른가
지금까지는 이런 멀티노드 추론을 StatefulSet + 커스텀 초기화 스크립트로 억지로 흉내 내는 경우가 많았습니다. LWS는 이 패턴을 아예 1급 개념으로 승격시켰습니다.
| 구분 | StatefulSet | LeaderWorkerSet |
|---|---|---|
| 관리 단위 | 파드 1개 | 리더+워커로 구성된 파드 "그룹" |
| 템플릿 | 단일 템플릿(모든 파드 동일) | 리더용·워커용 이중 템플릿 |
| 생성 순서 | 순차 생성(0,1,2...) | 그룹 단위 병렬 생성 |
| 장애 시 동작 | 실패한 파드만 재생성 | 그룹 내 1개 실패 시 그룹 전체 재생성(all-or-nothing) |
| 롤링 업데이트 | 파드 단위 | 그룹 단위 |
| 갱 스케줄링 | 미지원 | 지원(Alpha) - 그룹 전체가 동시에 뜰 자원이 없으면 대기 |
핵심 스펙 필드
| 필드 | 의미 |
|---|---|
replicas |
리더+워커 "그룹"을 몇 세트 만들지 (예: 2면 독립된 추론 그룹 2개) |
leaderWorkerTemplate.size |
그룹 하나당 파드 개수(리더 1 + 워커 size-1). 모델을 몇 개 노드에 쪼갤지에 대응 |
leaderWorkerTemplate.leaderTemplate |
리더 파드 스펙. 보통 OpenAI 호환 API 서버 역할 |
leaderWorkerTemplate.workerTemplate |
워커 파드 스펙. --headless 모드로 리더의 지휘를 받아 연산만 수행 |
leaderWorkerTemplate.restartPolicy |
그룹 내 파드 하나가 죽었을 때 그룹 전체를 재생성할지 여부 |
워커는 LWS_LEADER_ADDRESS, LWS_GROUP_INDEX, LWS_WORKER_INDEX 같은 환경 변수를 통해 자신이 어느 그룹, 몇 번째 노드인지 알 수 있고, 이 값이 vLLM 같은 추론 엔진의 --node-rank, --master-addr 인자로 그대로 흘러 들어갑니다.
Kueue·KubeRay와의 관계
Kueue는 처음부터 LeaderWorkerSet을 네이티브 지원 워크로드 목록에 포함하고 있었습니다. 실제 운영에서는 LWS 하나만 단독으로 쓰기보다, Kueue가 GPU 쿼터와 대기열을 관리하고, LWS가 그 위에서 실제 멀티노드 추론 그룹을 기동하는 조합이 자연스럽습니다. KubeRay가 Ray 기반 분산 학습/추론을 담당한다면, LWS는 그보다 더 가볍고 vLLM 등 특정 추론 엔진에 최적화된 "멀티노드 서빙 전용" 계층에 가깝습니다.
예시 매니페스트 - vLLM 멀티노드 추론
8-GPU 노드 2대에 텐서 병렬 8, 파이프라인 병렬 2로 거대 모델을 쪼개 서빙하는 축약 예시입니다.
apiVersion: leaderworkerset.x-k8s.io/v1
kind: LeaderWorkerSet
metadata:
name: vllm-llama3-405b
spec:
replicas: 2
leaderWorkerTemplate:
size: 2
restartPolicy: RecreateGroupOnPodRestart
leaderTemplate:
spec:
containers:
- name: vllm-leader
image: vllm/vllm-openai:latest
args:
- "vllm serve meta-llama/Llama-3.1-405B-Instruct"
- "--tensor-parallel-size=8"
- "--pipeline-parallel-size=2"
resources:
limits:
nvidia.com/gpu: 8
workerTemplate:
spec:
containers:
- name: vllm-worker
image: vllm/vllm-openai:latest
args:
- "vllm serve --headless"
resources:
limits:
nvidia.com/gpu: 8
replicas: 2는 이런 405B 모델 서빙 그룹이 통째로 2세트 떠서 트래픽을 나눠 받는다는 뜻이고, size: 2는 그룹 하나(리더 1 + 워커 1)가 노드 2대에 걸쳐 있다는 뜻입니다.
참고사항
'DevOps > Openshift Cloud Platform' 카테고리의 다른 글
| OpenShift에서 GPU 나눠쓰기 - NVIDIA MIG(Multi-Instance GPU) 정리 (0) | 2026.09.17 |
|---|---|
| CVE-2026-33814 정리 - OpenShift/Kubernetes를 강타한 HTTP/2 DoS 치명적 취약점 (0) | 2026.09.16 |
| 인프라/라우트등 노드 웹콘솔 디버그 노드(pod) 불가 (0) | 2025.04.02 |
| openshift container platform에 dify 설치 (0) | 2025.04.02 |
| [DataGrid] publishNotReadyAddress=JGRP000032 (0) | 2024.11.27 |
