GPU Operator 파드 구성요소와 역할, 호스트에 드라이버가 없어도 되는가

상태: 초안 (2026-10-07). 파드 이름, 종류, 초기화 컨테이너 순서, 노드 라벨, 설치 옵션 조합은 실제로 동작 중인 환경에서 읽기만 해서 확인한 값입니다. 드라이버를 오퍼레이터가 컨테이너로 올리는 방식은 이 환경이 쓰지 않아 직접 시험하지 못했고(미실측), 공식 문서의 서술로 확인했습니다. 작성 규칙: 실측 데이터가 기본이고, 못 잰 것은 「미실측」으로 표시합니다.

목차

• 1. 설치하면 뜨는 파드
• 2. 파드들은 서로를 기다린다: 검증 체인
• 3. 호스트에 NVIDIA 드라이버가 없어도 되는가
• 4. 파드가 GPU 를 받기까지
• 5. 직접 확인하는 읽기 전용 명령
• 6. 흔한 오해
• 확인한 버전과 날짜, 확인하지 못한 것
• 참고 자료

GPU Operator 를 처음 쓰면 gpu-operator 네임스페이스에 파드가 열 개 넘게 뜨는데, 이름만 봐서는 무엇이 무엇인지 알기 어렵습니다. 이 글은 두 질문에 답합니다.

1. 각 파드는 무슨 일을 하고, 어느 노드에 뜨며, 없으면 어떤 증상이 나는가.
2. 호스트에 NVIDIA 드라이버를 설치하지 않아도 GPU Operator 만으로 GPU 를 쓸 수 있는가.

짧은 답. 파드는 크게 컨트롤러(Deployment), 노드 라벨러(NFD), 그리고 GPU 노드마다 하나씩 뜨는 데몬셋 묶음(드라이버, 툴킷, 디바이스 플러그인, GFD, DCGM Exporter, 검증기)으로 나뉩니다. 호스트에 드라이버가 없어도 됩니다. 오퍼레이터가 기본값으로 드라이버를 컨테이너로 올리기 때문입니다. 반대로 호스트에 드라이버를 이미 설치했다면 오퍼레이터의 드라이버를 끄는 구성(driver.enabled=false)이 가능하고 실제로 흔합니다. 두 방식은 「드라이버의 수명주기를 누가 관리하는가」가 다릅니다.

1. 설치하면 뜨는 파드

실제로 GPU Operator(v26.3.3)가 동작 중인 환경에서 gpu-operator 네임스페이스를 읽은 결과입니다. 숫자(노드 수)는 환경마다 다르므로 종류와 역할만 정리합니다.

NVSwitch 시스템(HGX 등)에서는 GPU 사이 패브릭을 구성하는 Fabric Manager 가 별도로 필요합니다. 오퍼레이터의 드라이버 컨테이너는 NVSwitch 를 감지하면 이를 같이 설치하고, 호스트 드라이버를 쓰면 직접 설치해야 합니다(공식 문서 서술이며 이 환경에는 NVSwitch 가 없어 시험하지 못했습니다, 미실측).

2. 파드들은 서로를 기다린다: 검증 체인

GPU 노드에서 데몬셋들이 한꺼번에 뜨지만 의존 순서가 있습니다. 실제 파드의 초기화 컨테이너 이름으로 확인한 순서입니다.

따라서 한 단계가 막히면 뒤 단계의 파드가 Init:0/1 로 머물고, 문제의 뿌리는 가장 앞에서 막힌 단계에 있습니다. 진단은 드라이버 → 툴킷 → 플러그인 순서로 앞에서부터 합니다.

오퍼레이터는 어느 데몬셋을 어느 노드에 띄울지를 노드 라벨로 정합니다. 확인해 보면 GPU 노드마다 nvidia.com/gpu.deploy.driver, .container-toolkit, .device-plugin, .gpu-feature-discovery, .dcgm, .dcgm-exporter, .operator-validator, .node-status-exporter 라벨이 "true" 로 붙어 있고, 각 데몬셋이 이 라벨을 nodeSelector 로 읽습니다. 특정 노드에서 한 구성요소만 끄고 싶으면 그 노드의 해당 라벨을 false 로 바꾸면 됩니다.

3. 호스트에 NVIDIA 드라이버가 없어도 되는가

됩니다. 공식 문서는 driver.enabled 의 기본값이 true, toolkit.enabled 의 기본값이 true 라고 하고, 오퍼레이터가 드라이버를 컨테이너(nvidia-driver-daemonset)로 설치합니다. 그래서 GPU 가 꽂힌 노드에 OS 와 컨테이너 런타임만 있으면 오퍼레이터가 나머지를 올립니다.

세 가지 구성이 있습니다.

확인한 환경의 ClusterPolicy 는 driver.enabled=false, toolkit.enabled=true, 디바이스 플러그인과 GFD 와 DCGM Exporter 는 켜짐, MIG Manager 는 꺼짐이고, 그 결과 nvidia-driver-daemonset 은 아예 만들어지지 않았습니다. 그래도 검증기는 모두 통과했고 GPU 노드마다 플러그인이 nvidia.com/gpu 를 광고했습니다. 즉 「호스트 드라이버 + 오퍼레이터의 툴킷, 플러그인, 지표」 조합이 실제로 동작합니다. 이때 툴킷 파드는 호스트 루트(/)와 드라이버 설치 경로(/run/nvidia/driver)를 마운트하고, 시작 전에 driver-validation 으로 호스트 드라이버가 쓸 만한지 확인합니다(2절).

호스트 드라이버가 이미 있는데 driver.enabled 를 끄지 않았을 때는 공식 문서에 자동 감지 서술이 있습니다. 드라이버 파드의 초기화 컨테이너가 사전 설치된 드라이버를 감지하면 노드에 라벨을 붙여 드라이버 파드를 종료시키고 다시 스케줄하지 않는다고 합니다(문서 서술을 읽은 것이며 이 환경에서 시험하지 못했습니다, 미실측). 그래도 의도를 분명히 하려면 구성을 명시하는 쪽이 낫습니다.

드라이버 컨테이너 방식의 비용.

• 노드마다 OS 판과 커널에 맞는 드라이버 이미지가 필요합니다. 커널이 올라가면 드라이버를 다시 맞춰야 하고, 사전 컴파일 이미지는 태그가 <브랜치>-<커널>-<OS> 형식이라 그 조합이 있어야 합니다.
• 드라이버는 커널 모듈이라 교체 전에 GPU 를 쓰는 파드를 모두 멈춰야 합니다. 오퍼레이터는 cordon, 대기, GPU 파드 삭제, 선택적 drain 으로 이를 상태 기계로 관리하므로 업그레이드 동안 그 노드의 GPU 를 쓸 수 없습니다.
• 자동 커널 업그레이드(unattended-upgrades)가 켜져 있으면 커널이 바뀐 뒤 드라이버가 맞지 않을 수 있어, 공식 문서는 이를 끄라고 권합니다.

호스트 드라이버 방식의 비용. 오퍼레이터는 호스트 드라이버의 수명주기(업그레이드, 교체)를 관리하지 않습니다. 대신 노드 OS 가 섞여 있어도 되고, 드라이버 교체 절차를 팀의 기존 방식(이미지, 패키지 관리)으로 통제할 수 있습니다.

4. 파드가 GPU 를 받기까지

설치가 끝난 뒤의 흐름입니다.

1. 디바이스 플러그인이 kubelet 에 등록하고 장치 목록을 전달합니다.
2. kubelet 이 노드 status 의 capacity 와 allocatable 을 갱신합니다(nvidia.com/gpu: N).
3. 스케줄러는 장치가 아니라 이 숫자만 봅니다(NodeResourcesFit). GPU 는 limits 에만 쓰고(requests 를 쓰면 같은 값이어야 함) 정수입니다.
4. kubelet 이 Allocate 를 호출하고, 응답으로 장치 노드, 환경 변수, 마운트, CDI 이름을 받습니다.
5. 컨테이너 런타임이 장치를 주입합니다. 오퍼레이터 25.10.0 부터는 CDI(Container Device Interface)가 기본이며, 일반 워크로드는 runtimeClassName 이 필요 없습니다.

플러그인과의 연결이 끊기면 kubelet 은 장치를 unhealthy 로 돌려 allocatable 을 0 으로 내리고, 5분의 유예가 지나면 자원 이름을 지웁니다(kubelet 소스 서술). 그래서 「Insufficient nvidia.com/gpu」 이벤트가 같아도 원인은 플러그인, 툴킷, 드라이버, 스케줄 제약 중 어디든 될 수 있습니다.

5. 직접 확인하는 읽기 전용 명령

# 오퍼레이터가 올린 파드와 노드별 분포
kubectl -n gpu-operator get deploy,ds
kubectl -n gpu-operator get po -o wide

# 오퍼레이터가 어떤 구성요소를 켰는가(ClusterPolicy)
kubectl get clusterpolicy -o jsonpath='{.items[0].spec.driver.enabled} {.items[0].spec.toolkit.enabled}{"\n"}'

# 노드별 GPU 광고량과 GPU 라벨
kubectl get nodes -o custom-columns=N:.metadata.name,CAP:.status.capacity.nvidia\.com/gpu,ALLOC:.status.allocatable.nvidia\.com/gpu
kubectl get nodes -L nvidia.com/gpu.present,nvidia.com/gpu.product

# 어떤 노드에 어떤 구성요소를 띄우도록 라벨이 붙었는가
kubectl get node <노드> -o json | grep -o 'nvidia.com/gpu.deploy[^,]*'

# 검증기가 막힌 곳(초기화 컨테이너 이름이 막힌 단계)
kubectl -n gpu-operator describe po -l app=nvidia-operator-validator | grep -A2 -i "init containers"

6. 흔한 오해

• 「GPU Operator 는 드라이버 설치기다.」 드라이버는 구성요소 하나일 뿐입니다. 호스트 드라이버를 쓰는 환경에서도 툴킷 설치, 플러그인 등록, 라벨 관리, 지표, 검증 때문에 오퍼레이터는 계속 쓸모가 있습니다.
• 「호스트 드라이버가 있으면 오퍼레이터는 필요 없다.」 드라이버만으로는 쿠버네티스가 GPU 를 자원으로 보지 못합니다. 디바이스 플러그인과 컨테이너 런타임 설정이 있어야 nvidia.com/gpu 가 생깁니다. 오퍼레이터가 이 둘을 자동으로 맞춥니다.
• 「오퍼레이터를 올리면 containerd 설정이 안전하다.」 툴킷은 호스트의 containerd 설정 파일(/etc/containerd)을 직접 씁니다. 다른 설정 파일과 겹치면 CRI 설정이 통째로 교체될 수 있습니다(containerd 1.7 의 설정 병합이 플러그인 섹션을 통째로 교체함, 소스 확인). 03편의 5절을 보십시오.
• 「툴킷이 containerd 에 SIGHUP 을 보내면 설정만 다시 읽는다.」 일회용 VM 의 containerd 2.2.1 에서 SIGHUP 을 보내 보니 프로세스가 종료되고 systemd 가 5초 뒤 다시 띄웠습니다(Restart=always). 노드를 한꺼번에 바꾸지 말고 한 노드씩 적용하는 이유입니다(03편 참고).
• 「nvidia.com/gpu.present 만 보면 설치가 끝난 것이다.」 이 라벨은 NFD 와 오퍼레이터가 GPU 하드웨어를 감지했다는 뜻이지 드라이버와 플러그인이 동작한다는 뜻이 아닙니다. 노드의 allocatable 과 검증기 상태를 봐야 합니다.

확인한 버전과 날짜, 확인하지 못한 것

2026-10-07 에 읽은 환경은 GPU Operator v26.3.3, Container Toolkit v1.19.1, 디바이스 플러그인 v0.19.3, NFD v0.18.3, DCGM Exporter 4.5.3-4.8.2(distroless 이미지)입니다. 공식 문서는 설치 안내와 개요 페이지를 열어 확인했습니다.

• 오퍼레이터의 드라이버 컨테이너 방식은 직접 시험하지 못했습니다(미실측). 확인한 환경이 호스트 드라이버를 쓰기 때문입니다. 이 방식의 동작과 비용은 공식 문서의 서술입니다.
• 호스트 드라이버가 있을 때의 자동 감지(드라이버 파드 종료)는 문서를 읽은 것이고 시험하지 못했습니다.
• NVSwitch 시스템의 Fabric Manager 동작, MIG Manager 의 실제 적용, MPS 는 이 환경에서 쓰지 않아 확인하지 못했습니다.
• 파드 목록은 한 시점의 스냅샷이고, 설정에 따라 구성요소가 늘거나 줄어듭니다(샌드박스 워크로드용 KubeVirt 장치 플러그인, vGPU 관리자 등은 이 환경에 없었습니다).

참고 자료

• NVIDIA GPU Operator 개요: https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/overview.html
• NVIDIA GPU Operator 시작하기(사전 설치된 드라이버와 Helm 옵션): https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/getting-started.html
• 이 시리즈의 3편(GPU Operator 스택 해부와 트러블슈팅), 17편(DCGM Exporter 지표), 22편(지식 지도)