블로그 이미지
Cloud Engineer

클라우드 & 쿠버네티스 엔지니어의 기술 기록

쿠버네티스 기반 프라이빗 클라우드 구축·운영과 레거시 → 클라우드 전환 경험을 정리합니다. 직접 부딪힌 문제와 트러블슈팅 과정을 위주로 기록해요.

Kubernetes Private Cloud Legacy to Cloud
전체 방문자
오늘
어제

GitHub Activity

GitHub Stats Top Languages
GitHub Streak

Tech Stack

Container & Orchestration

OpenShift OpenShift Virtualization RKE2 Rancher Kubernetes Docker Helm

Middleware / WAS

JBoss Apache HTTPD Tomcat

Cloud

AWS Google Cloud

Auth / Identity

Keycloak Google OIDC OAuth2 Proxy

Automation / IaC

Ansible

카테고리 둘러보기

DevOps/Openshift Cloud Platform 2026. 9. 23. 11:18

LeaderWorkerSet(LWS) 정리 - OpenShift 4.20 멀티노드 LLM 추론 오케스트레이션

728x90

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대에 걸쳐 있다는 뜻입니다.

참고사항

728x90