쿠버네티스 1.32 DRA로 GPU 나눠 쓰기: 멀티테넌트 AI 워크로드 스케줄링 설계

2026년 현재 엔터프라이즈 AI 인프라의 중심축은 Kubernetes로 급속히 이동하고 있다. GPU 자원의 효율적 할당과 멀티테넌트 ML 워크로드 격리가 핵심 과제로 떠오른 가운데, Kubernetes 1.32는 DRA(Dynamic Resource Allocation) API를 v1beta1으로 승격하며 이 문제에 정면으로 답한다. DRA, Kueue, NVIDIA KAI Scheduler 등 최신 Kubernetes AI 스케줄링 생태계를 살펴보고, 프로덕션 환경에서의 멀티테넌트 GPU 운영 전략을 정리한다.

GPU를 수량이 아니라 속성으로 요청한다 (DRA v1beta1)

Kubernetes 1.32에서 DRA가 v1beta1 API로 승격되면서, GPU 자원 관리의 패러다임이 근본적으로 바뀌었다. 기존 Device Plugin 방식은 nvidia.com/gpu: 1처럼 단순 수량만 요청할 수 있었으나, DRA는 GPU 메모리 용량, MIG(Multi-Instance GPU) 프로파일, NVLink 토폴로지, RDMA 대역폭 등 세밀한 속성을 선언적으로 요청할 수 있게 한다.

apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaim
metadata:
  name: gpu-claim-training
spec:
  devices:
    requests:
    - name: gpu
      deviceClassName: gpu.nvidia.com
      selectors:
      - cel:
          expression: >
            device.attributes["memory"].isGreaterThan(quantity("40Gi")) &&
            device.attributes["migProfile"] == "3g.20gb"
  controller: ""

이 선언을 통해 스케줄러는 40GiB 이상 메모리와 3g.20gb MIG 프로파일을 갖춘 GPU를 정확히 매핑한다.

⤢✕

DRA의 핵심은 ResourceSlice를 통한 노드별 GPU 인벤토리 공개와 DeviceClass를 통한 기업 정책 중앙화다. 클러스터 관리자는 DeviceClass에 MIG 프로파일 제약이나 NVLink 토폴로지 요구사항을 정의하고, 개발자는 ResourceClaim에서 DeviceClass를 참조하기만 하면 된다.

네임스페이스 하나로는 부족하다: 멀티테넌트 격리

멀티테넌트 GPU 클러스터에서는 팀 간 자원 경쟁과 보안 격리가 동시에 해결되어야 한다. Kubernetes는 네임스페이스, ResourceQuota, LimitRange, NetworkPolicy의 조합으로 이를 구현한다.

# 팀별 ResourceQuota
apiVersion: v1
kind: ResourceQuota
metadata:
  name: ml-team-a-quota
  namespace: team-a-ml
spec:
  hard:
    requests.nvidia.com/gpu: "8"
    limits.nvidia.com/gpu: "8"
    requests.memory: "512Gi"
    limits.memory: "512Gi"
    requests.cpu: "64"

# PodSecurityStandard로 컨테이너 권한 제한
apiVersion: v1
kind: Namespace
metadata:
  name: team-a-ml
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: v1.32

멀티테넌트 환경에서는 Kueue와 연계해 팀 간 공정한 GPU 분배를 구현하는 것이 표준 패턴이다. Kueue는 ClusterQueue와 LocalQueue를 통해 글로벌 GPU 풀을 논리적으로 분할하고, borrowing 정책으로 유휴 자원의 임시 대출을 가능하게 한다.

# Kueue ClusterQueue: 전사 GPU 풀 정의
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
  name: cluster-gpu-pool
spec:
  namespaceSelector: {}
  resourceGroups:
  - coveredResources: ["nvidia.com/gpu", "cpu", "memory"]
    flavors:
    - name: "a100-80gb"
      resources:
      - name: "nvidia.com/gpu"
        nominalQuota: 32
        borrowingLimit: 16
    - name: "h100-sxm"
      resources:
      - name: "nvidia.com/gpu"
        nominalQuota: 16

이 설계로 Kueue 도입 전 GPU 활용률 25~~35%였던 클러스터가 도입 후 60~~85%까지 향상되는 사례가 보고되고 있다.

KubeFlow Pipelines가 학습 파이프라인을 규격화한다

KubeFlow Pipelines v2는 Kubernetes 기반 ML 실험 관리와 재현 가능 파이프라인의 사실상 표준으로 자리 잡았다. DAG 형태의 파이프라인을 Python SDK로 정의하고, ArgoWorkflows 또는 Tekton 백엔드에서 실행된다.

⤢✕

PyTorchJob과 TFJob은 Kubernetes Operator 패턴으로 분산 학습을 관리하며, Kueue와 통합하면 배치 학습 잡의 공정 스케줄링이 보장된다. 2026년 기준 llm-d, vLLM, Ray Serve를 결합한 스택이 LLM 서빙의 표준 아키텍처로 자리 잡고 있다.

# PyTorchJob + Kueue 통합
apiVersion: kubeflow.org/v1
kind: PyTorchJob
metadata:
  name: llm-finetune-job
  labels:
    kueue.x-k8s.io/queue-name: team-a-local-queue
spec:
  pytorchReplicaSpecs:
    Master:
      replicas: 1
      template:
        spec:
          containers:
          - name: trainer
            image: nvcr.io/nvidia/pytorch:24.10-py3
            resources:
              limits:
                nvidia.com/gpu: "1"
    Worker:
      replicas: 7
      template:
        spec:
          containers:
          - name: trainer
            image: nvcr.io/nvidia/pytorch:24.10-py3
            resources:
              limits:
                nvidia.com/gpu: "1"

추론 서비스는 큐 깊이로 스케일링한다 (KEDA)

KEDA(Kubernetes Event-Driven Autoscaling)는 GPU 추론 서비스의 동적 스케일링에 필수 컴포넌트다. 기존 HPA의 CPU/메모리 메트릭 한계를 넘어, 큐 깊이, 추론 레이턴시, GPU 활용률 등 커스텀 메트릭 기반 스케일링이 가능하다.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: vllm-inference-scaler
  namespace: inference-prod
spec:
  scaleTargetRef:
    name: vllm-llama3-deployment
  minReplicaCount: 1
  maxReplicaCount: 16
  cooldownPeriod: 120
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus.monitoring.svc:9090
      metricName: vllm_request_queue_depth
      query: avg(vllm_num_requests_waiting{namespace="inference-prod"})
      threshold: "5"
  - type: prometheus
    metadata:
      serverAddress: http://prometheus.monitoring.svc:9090
      metricName: gpu_utilization
      query: avg(DCGM_FI_DEV_GPU_UTIL{namespace="inference-prod"})
      threshold: "80"

추론 서비스 Pod는 GPU 1개를 점유하므로, KEDA 스케일링은 GPU 노드 오토프로비저너(Karpenter 또는 Cluster Autoscaler)와 연동되어야 한다.

GPU를 쪼개 쓰는 방법: MIG와 Time-slicing

A100, H100 GPU에서 GPU 공유 전략은 크게 두 가지로 갈린다.

MIG(Multi-Instance GPU)는 NVIDIA A100/H100에서 GPU를 최대 7개의 독립된 인스턴스로 분할한다. 각 인스턴스는 전용 SM, L2 캐시, 메모리 대역폭을 가져 완전한 격리를 보장한다.

A100 80GB MIG 프로파일 예시:
- 1g.10gb  × 7  (소형 추론, 배치 작업)
- 2g.20gb  × 3  (중형 파인튜닝)
- 3g.40gb  × 2  (대형 학습)
- 7g.80gb  × 1  (풀 GPU 학습)

Time-slicing은 MIG를 지원하지 않는 V100, T4 등에서 활용한다. 단일 GPU를 시간 분할로 여러 프로세스가 공유하며, 격리 수준은 낮지만 활용률을 높인다.

# NVIDIA Device Plugin ConfigMap for Time-slicing
apiVersion: v1
kind: ConfigMap
metadata:
  name: nvidia-device-plugin-config
  namespace: kube-system
data:
  config.json: |
    {
      "version": "v1",
      "sharing": {
        "timeSlicing": {
          "resources": [
            {
              "name": "nvidia.com/gpu",
              "replicas": 4
            }
          ]
        }
      }
    }

⤢✕

보고 있지 않으면 모른다: GPU 메트릭 수집

GPU 클러스터 운영의 가시성은 DCGM(Data Center GPU Manager) Exporter와 Prometheus의 조합으로 확보한다.

# DCGM Exporter DaemonSet 핵심 설정
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: dcgm-exporter
  namespace: gpu-monitoring
spec:
  selector:
    matchLabels:
      app: dcgm-exporter
  template:
    spec:
      tolerations:
      - key: nvidia.com/gpu
        operator: Exists
        effect: NoSchedule
      hostNetwork: true
      containers:
      - name: dcgm-exporter
        image: nvcr.io/nvidia/k8s/dcgm-exporter:3.3.7-3.5.0-ubuntu22.04
        env:
        - name: DCGM_EXPORTER_KUBERNETES_GPU_ID_TYPE
          value: uid
        ports:
        - containerPort: 9400
          name: metrics
        securityContext:
          capabilities:
            add: ["SYS_ADMIN"]

수집 핵심 메트릭은 다음과 같다.

메트릭	설명	임계값 기준
`DCGM_FI_DEV_GPU_UTIL`	GPU 코어 활용률 (%)	80% 초과 시 스케일아웃
`DCGM_FI_DEV_MEM_COPY_UTIL`	메모리 대역폭 활용률	90% 초과 시 병목 경고
`DCGM_FI_DEV_FB_USED`	사용 중인 GPU 메모리 (MiB)	OOM 예방
`DCGM_FI_DEV_POWER_USAGE`	GPU 전력 소비 (W)	열 스로틀링 예방
`DCGM_FI_DEV_SM_CLOCK`	SM 클럭 주파수	성능 저하 감지
`DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL`	NVLink 대역폭	분산 학습 병목 탐지

Grafana 대시보드에는 팀별, 네임스페이스별 GPU 활용률과 Kueue 잡 큐 깊이를 함께 시각화해 자원 회계(Resource Accounting) 기능을 갖추는 것이 권장된다.

고가 자원이니 보안도 다층으로

GPU 클러스터는 고가 자원과 민감 학습 데이터를 함께 다루기 때문에 다층적 보안 설계가 필수다.

공급망 보안 측면에서는 GPU 워크로드 이미지를 Cosign으로 서명하고, Kyverno 정책으로 서명 검증을 강제한다.

# Kyverno: 서명되지 않은 GPU 컨테이너 이미지 차단
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-gpu-image-signature
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-image-signature
    match:
      resources:
        kinds: ["Pod"]
        namespaceSelector:
          matchLabels:
            workload-type: gpu-ml
    verifyImages:
    - imageReferences:
      - "nvcr.io/nvidia/*"
      - "registry.internal.corp/*"
      attestors:
      - count: 1
        entries:
        - keyless:
            issuer: "https://token.actions.githubusercontent.com"
            subject: "https://github.com/corp/ml-images/.github/workflows/*"

네트워크 격리는 팀 간 NetworkPolicy로 추론 서비스와 학습 워크로드의 네트워크 경계를 분리한다. GPU 노드는 Taints와 NodeAffinity로 ML 전용 노드풀을 별도 유지해 일반 워크로드의 침입을 차단한다. 시크릿 관리 측면에서는 모델 가중치 접근 자격증명과 Hugging Face 토큰을 External Secrets Operator로 AWS Secrets Manager 또는 Vault에서 동적 주입한다.

Helm으로 스택 전체를 버전 고정한다

ML 플랫폼 구성 요소는 Helm 차트와 Helmfile로 선언적 관리하는 것이 표준 패턴이다.

# helmfile.yaml - ML 플랫폼 전체 스택 관리
repositories:
  - name: nvidia
    url: https://helm.ngc.nvidia.com/nvidia
  - name: kueue
    url: https://charts.kueue.x-k8s.io
  - name: keda
    url: https://kedacore.github.io/charts
  - name: kubeflow
    url: https://kubeflow.github.io/helm-charts

releases:
  - name: gpu-operator
    namespace: gpu-operator
    chart: nvidia/gpu-operator
    version: "~24.9"
    values:
      - mig.strategy: mixed
        dcgmExporter.enabled: true
        devicePlugin.config.name: time-slicing-config

  - name: kueue
    namespace: kueue-system
    chart: kueue/kueue
    version: "~0.9"
    values:
      - manageJobsWithoutQueueName: false
        integrations:
          frameworks:
          - "batch/job"
          - "kubeflow.org/pytorchjob"
          - "kubeflow.org/tfjob"

  - name: keda
    namespace: keda
    chart: keda/keda
    version: "~2.15"

  - name: training-operator
    namespace: kubeflow
    chart: kubeflow/training-operator
    version: "~1.8"

이 Helmfile 한 파일로 GPU Operator, Kueue, KEDA, KubeFlow Training Operator의 전체 ML 플랫폼 스택을 버전 고정 배포할 수 있다.

관리형 서비스와 비교하면

항목	Kubernetes (자체 구축)	AWS SageMaker	GCP Vertex AI	Azure ML
비용 모델	GPU 인스턴스 직접 비용	EC2 대비 15~40% 마크업	TPU 전용 가격	Azure VM 기반 + ML 서비스 요금
GPU 지원	A100, H100, DRA 세밀 할당	P3, P4d, P5(H100), Trn1	TPU v5p, A100, H100	ND A100, NDv5(H100)
확장성	Karpenter, Cluster Autoscaler	HyperPod 1.5만 노드	TPU Pod 2.8X 빠른 학습	Arc 하이브리드
MLOps 통합	KubeFlow, MLflow, Argo	SageMaker Pipelines 네이티브	Vertex Pipelines, BigQuery 직통	Azure ML Studio
멀티테넌트	Kueue, 네임스페이스 완전 통제	IAM + VPC 격리	VPC SC, IAM	Azure AD + RBAC
프로덕션 추론	KServe, vLLM, llm-d	SageMaker Endpoints	Vertex Endpoints, Model Garden	Azure ML Online Endpoints
온프레미스 연동	완전 지원	Outposts(제한적)	Anthos	Arc (완전 하이브리드)
벤더 종속성	없음(CNCF 표준)	높음	중간	중간
운영 복잡도	높음(전담 팀 필요)	낮음	낮음	중간
최적 사용 사례	대규모 프로덕션, 커스텀 요구	빠른 실험, AWS 생태계	BigQuery ML, TPU 학습	하이브리드, Azure 엔터프라이즈

2026년 현재 실제 프로덕션 패턴은 이분화되어 있다. 개발·실험 단계는 관리형 서비스(SageMaker, Vertex AI)를 활용하고, 대규모 프로덕션 추론과 반복 학습은 Kubernetes 기반으로 이동하는 추세가 뚜렷하다.

설계할 때 놓치기 쉬운 지점

멀티테넌트 GPU 클러스터를 설계할 때 반복적으로 걸리는 지점은 대체로 다섯 가지로 좁혀진다. 네임스페이스·ResourceQuota·RBAC로 자원을 격리하는 설계, 빈 패킹(Bin Packing)·갱 스케줄링(Gang Scheduling)·Fair-share 알고리즘 중 워크로드 성격에 맞는 스케줄링 방식 선택, HPA·VPA·KEDA 중 GPU 추론 서비스에 맞는 오토스케일링 메커니즘, PodDisruptionBudget과 TopologySpreadConstraints로 GPU 노드 장애 시에도 서비스 연속성을 지키는 가용성 설계, 그리고 공급망 보안·시크릿 관리·네트워크 격리를 아우르는 Zero Trust 기반 보안 아키텍처다. DRA v1beta1은 이 중에서도 특히 동적 자원 할당 패턴의 실전 사례로, 선언적 인프라 설계와 정책 기반 운영이라는 클라우드 네이티브 원칙을 구체적으로 구현한다.

마무리

Kubernetes 1.32는 DRA v1beta1 승격을 통해 GPU 자원 관리의 복잡성을 선언적 API로 추상화하며, AI 워크로드의 효율적 멀티테넌트 운영을 위한 기반을 마련했다. Kueue와 NVIDIA KAI Scheduler의 조합은 GPU 활용률을 60~85%까지 끌어올리며, KubeFlow Pipelines와 KEDA의 통합으로 엔드투엔드 ML 파이프라인 자동화가 완성된다. 관리형 서비스(SageMaker, Vertex AI)는 실험 속도를 높이지만, 대규모 프로덕션 추론과 비용 최적화 측면에서 Kubernetes 자체 구축의 우위는 더욱 명확해지는 방향으로 시장이 재편되고 있다.