Skip to content

Gpu-operator

  • Published on
    쿠버네티스는 GPU를 모릅니다. 노드가 GPU를 자원으로 광고하게 만드는 것은 kubelet에 등록된 디바이스 플러그인이고, 그 결과로 생기는 이름이 확장 리소스 nvidia.com/gpu입니다. 이 글은 디바이스 플러그인이 구현해야 하는 gRPC 인터페이스와 등록 소켓 경로, 확장 리소스에서 requests와 limits가 반드시 같아야 하는 이유, GPU를 CPU처럼 밀리코어로 쪼갤 수 없는 근본적인 이유, 그리고 GPU Feature Discovery가 붙이는 노드 라벨로 카드 종류를 지정해 스케줄링하는 방법을 공식 문서 기준으로 정리합니다. 쿠버네티스 GPU 운영·관측 시리즈의 두 번째 글입니다.
  • Published on
    쿠버네티스에서 GPU를 쓰려면 드라이버, NVIDIA Container Toolkit, 디바이스 플러그인, DCGM, GPU Feature Discovery, Node Feature Discovery를 노드마다 손으로 맞춰야 했습니다. NVIDIA GPU Operator는 이 조각들을 하나의 오퍼레이터로 묶고 ClusterPolicy 하나로 상태를 관리합니다. 각 컴포넌트가 정확히 무엇을 하는지, Helm 차트의 어떤 값이 무엇을 켜고 끄는지, 설치 전에 확인해야 할 것이 무엇인지를 공식 문서와 저장소의 values.yaml을 직접 읽어 정리했습니다. 쿠버네티스 GPU 운영·관측 시리즈의 첫 번째 글입니다.
  • Published on
    GPU 한 장에 여러 워크로드를 올리는 방법은 크게 두 가지입니다. 시간을 나누는 time-slicing과 하드웨어를 나누는 MIG인데, 이름이 비슷해 보이는 것과 달리 격리 수준이 전혀 다릅니다. 이 글은 NVIDIA GPU Operator 공식 문서를 기준으로 두 방식의 설정 파일 구조와 노드 라벨, 광고되는 리소스 이름, 지원 하드웨어 조건을 정리하고, time-slicing 복제본 사이에 메모리와 장애 격리가 없다는 사실이 실무에서 무엇을 뜻하는지, 어떤 워크로드에 무엇을 골라야 하는지를 판단 기준으로 정리합니다. 쿠버네티스 GPU 운영·관측 시리즈의 세 번째 글입니다.
  • Published on
    쿠버네티스에서 GPU 문제를 진단할 때 가장 큰 낭비는 순서 없이 아무 데나 찔러 보는 것입니다. 파드가 스케줄되지 않는 것, 파드는 떴는데 GPU가 안 보이는 것, 드라이버와 툴킷 버전이 어긋난 것, 메모리가 부족한 것, 노드에서 GPU가 사라지는 것은 서로 다른 계층의 문제라 확인 순서가 다릅니다. 이 글은 NVIDIA GPU Operator 공식 트러블슈팅 문서와 dcgm-exporter 저장소를 근거로 다섯 계층의 확인 순서와 각 계층에서 실제로 실행할 명령, 그리고 어떤 메트릭이 그 계층의 증거인지를 정리합니다. 쿠버네티스 GPU 운영·관측 시리즈의 마지막 글입니다.
  • Published on
    NVIDIA GPU Operator의 아키텍처와 7대 핵심 구성요소(Driver, Container Toolkit, Device Plugin, DCGM, MIG Manager, Node Feature Discovery, GFD)의 역할을 상세히 분석하고, Helm 기반 설치, KubeVirt와의 GPU/vGPU 패스스루 통합, MIG 파티셔닝, 모니터링, 트러블슈팅까지 실전 가이드를 총정리한다.