[2025.09.05 주간 개발 트렌드] PostgreSQL 18 RC1 정리 (비동기 I/O, UUIDv7, 업그레이드)

![주간 개발 트렌드](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b28d786c-9ec3-46ec-8055-adcd53a303c5_thumbnail_2.png)

# Kubernetes에서 GPU를 요청하는 방식이 달라지고있다

Pod를 만들때 CPU와 메모리는 어느정도 익숙한데 GPU가 들어가면 확인할게 늘어난다. 장치 모델과 드라이버, 노드 조건까지 같이 봐야한다.

GPU 한개라고해도 모든 작업에서 같은 의미는 아니다. 모델이 올라갈 메모리가 필요할 수도 있고 특정 기능을 지원하는 장치를 골라야할 수도 있다.

이번주 8월 27일에 [Kubernetes 1.34](https://kubernetes.io/blog/2025/08/27/kubernetes-v1-34-release/)가 출시됐다. 총 58개 enhancement 중 23개가 Stable로 올라왔고, 그중 DRA의 핵심 기능이 GA가 된 부분이 눈에 들어왔다.

이번주 개발트렌드로 GPU 같은 장치를 Kubernetes에서 어떻게 다루려는지 정리해보려고 한다.

# 1. 우선 기존 GPU 요청을 생각해보자

장치 플러그인을 사용하는 환경에서는 다음처럼 확장 리소스 이름과 개수를 요청하는 예를 자주 볼 수 있다.

```yaml
resources:
  limits:
    nvidia.com/gpu: 1
```

이 설정도 해당 장치 플러그인과 드라이버가 준비된 환경에서 의미가 있다. YAML에 이름만 적었다고 노드에 GPU가 생기는것은 아니다.

또한 개수 요청만으로 필요한 장치 조건을 전부 표현하기는 어렵다. 실제 운영에서는 노드 라벨이나 장치별 리소스 이름, 벤더가 제공하는 설정을 같이 보게된다.

DRA는 이런 장치의 선택과 할당을 Kubernetes API에서 더 구조적으로 다루려는 기능이다. 기존 장치 플러그인을 어느날 전부 없앤다는 의미는 아니다.

# 2. DRA에는 어떤 객체가 나오나

처음 보면 이름이 여러개라 복잡해보인다. 우선 역할을 나눠보면 이해하기 쉽다.

| 객체 | 하는 일 |
| --- | --- |
| DeviceClass | 어떤 장치 부류와 선택 조건을 사용할지 정의 |
| ResourceClaim | 워크로드가 필요한 장치를 요청하고 할당 결과를 보관 |
| ResourceClaimTemplate | Pod용 Claim을 만들기 위한 틀 |
| ResourceSlice | 드라이버가 관리하는 장치와 속성 정보를 게시 |

Pod는 ResourceClaim을 참조하고, 스케줄러는 요청 조건과 장치 정보를 함께 보고 할당을 결정한다. ResourceSlice는 DRA 드라이버가 제공한다. [DRA 구성과 동작](https://v1-34.docs.kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)

```text
워크로드의 요청
Pod → ResourceClaim → DeviceClass의 선택 조건
             ↓
     스케줄러가 장치·노드 조건 확인
             ↑
DRA Driver → ResourceSlice에 장치 정보 게시
             ↓
     할당 후 노드에서 장치 사용 준비
```

표현하는 API가 표준화되는것과 실제 장치를 연결하는 구현은 구분해야한다. GPU 드라이버나 벤더 지원이 필요없어지는것은 아니다.

클러스터 운영자는 사용할 DRA 드라이버를 준비하고 장치 종류에 맞는 설정을 확인해야한다. 애플리케이션 쪽에서는 어떤 Claim을 요청할지 정하게된다.

# 3. GA라면 모든 GPU 기능이 되는건가

이번에 Stable이 된건 DRA의 핵심 API다. resource.k8s.io/v1이 기본 제공되는 단계로 올라왔다.

그렇다고 GPU 분할, 장치 공유, 메모리 단위 할당 등 관련된 모든 기능이 한꺼번에 GA가 됐다는 의미는 아니다. 세부 기능의 성숙도와 실제 드라이버 지원은 따로 봐야한다.

예를 들어 GPU를 여러 Pod가 나눠쓰고싶다면 해당 기능이 클러스터 버전과 드라이버에서 어떻게 제공되는지 확인해야한다. DRA를 켰다는 이유만으로 어떤 GPU든 원하는 크기로 쪼개지는것은 아니다.

그래서 도입 검토는 기능 이름보다 필요한 조건부터 적는게 좋겠다.

- 어떤 장치 모델과 기능이 필요한가?
- 장치를 독점해서 사용할지 공유할지 정했는가?
- 요청 조건이 실제 드라이버 속성으로 표현되는가?
- 사용할 기능은 Stable인지 별도 feature gate가 필요한가?

GA라는 단어만 보고 전체 요구사항이 해결됐다고 생각하면 실제 구성에서 다시 막힐 수 있다.

# 4. AI 워크로드에서는 뭐가 중요할까

학습이나 추론 작업에서는 GPU가 있다는 사실만으로 충분하지 않다. 모델이 올라가야하고 필요한 라이브러리가 장치를 인식해야하며 실제 성능도 나와야한다.

예를 들어 작은 모델의 추론과 큰 모델의 학습이 같은 장치를 요청한다고 해보자. 단순히 같은 개수로만 보면 자원을 효율적으로 사용하는지 판단하기 어렵다.

DRA를 검토한다면 요청 조건을 명확히 표현하는 부분과 장치를 할당받은 뒤 실제로 잘 사용하는 부분을 나눠서 확인하면 좋겠다.

```text
확인할 단계
요청 조건 → 할당 결과 → Pod 실행 → 장치 인식 → 실제 작업 성능
```

Pod가 Running이 됐다는것과 애플리케이션이 GPU를 사용한다는것도 다르다. 컨테이너 안에서 장치를 인식하는지, CPU로 조용히 돌아가고있지는 않은지 봐야한다.

대기 시간과 활용률도 같이 확인해보자. 장치를 잘 골라도 요청 조건이 너무 좁으면 작업이 오래 대기할 수 있고, 할당된 장치의 대부분을 놀릴 수도 있다.

# 5. 기존 클러스터에서 확인할 순서

운영 클러스터 전체를 바로 바꾸기보다는 테스트 노드와 작은 워크로드에서 시작하면 좋겠다.

1. Kubernetes와 장치 드라이버의 지원 버전을 확인한다.
2. DRA 드라이버가 ResourceSlice를 게시하는지 확인한다.
3. DeviceClass와 Claim의 선택 조건을 확인한다.
4. 할당과 Pod 실행, 실제 장치 사용까지 확인한다.
5. 실패 후 재시도와 리소스 정리가 기대대로 되는지 확인한다.

장치가 부족할때의 대기 상태나 노드가 재시작된 경우도 살펴보면 좋겠다. 정상 실행 한번보다 운영 중에 막혔을때 원인을 찾을 수 있는지가 중요하다.

또한 기존 장치 플러그인과 DRA가 같은 장치를 중복해서 관리하지 않도록 벤더의 전환 구성을 확인해야한다. 실제 운영 절차는 사용중인 하드웨어와 드라이버를 기준으로 정하는게 맞다.

# 마무리

이번 Kubernetes 1.34에서 DRA 핵심 기능이 GA가 된건 가속기 자원을 더 표준적인 API로 다루기 위한 기반이 성숙했다는 의미로 보인다.

개인적으로는 GPU 개수만 적는것에서 어떤 장치가 필요한지 표현하는 방향으로 넓어지고있다는 점이 흥미롭다. 다만 표준 API가 생겨도 장치와 드라이버의 차이가 사라지는것은 아니다.

AI 작업을 올리는 클러스터라면 DRA를 같이 살펴볼 시점인것 같다. YAML이 적용됐다는것보다 요청한 장치를 실제로 잘 쓰고있는지까지 확인해야겠다..


[2025.08.29 주간 개발 트렌드] Kubernetes 1.34 정리 (DRA, GPU 할당, 드라이버)

독자의 메모