2024년 12월 20일(금) 주간 개발트렌드

![image](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/2a3741f8-626e-4237-b985-d52de10bb444_thumbnail_1.png)

## Cloud / DevOps — Kubernetes 1.32 출시

Kubernetes가 **24년 12월 11일 Kubernetes 1.32 Penelope**를 정식 출시했습니다.

이번 버전에는 총 **44개의 Enhancement**가 포함됐으며 단계별로는 다음과 같이 구성됐습니다.

- Stable: 13개
- Beta: 12개
- Alpha: 19개

여러 기능이 개선됐지만 Infrastructure 관점에서 특히 주목할 부분 중 하나는 **Dynamic Resource Allocation(DRA)**이 계속 발전하고 있다는 점이었습니다.

DRA는 CPU와 Memory처럼 단순한 Resource뿐 아니라 **GPU, FPGA, Network Device 같은 특수 Hardware Resource를 Kubernetes에서 보다 유연하게 할당하기 위한 구조**입니다.

[Kubernetes - Kubernetes v1.32: Penelope](https://kubernetes.io/blog/2024/12/11/kubernetes-v1-32-release/)

---

### 기존 Kubernetes Resource 관리

Kubernetes에서 가장 기본적인 Resource는 CPU와 Memory입니다.

Pod에서는 다음과 같이 필요한 Resource를 선언할 수 있습니다.

```yaml
resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "1"
    memory: "1Gi"
```

Scheduler는 Cluster의 각 Node가 가지고 있는 Resource를 확인한 뒤 적절한 Node에 Pod를 배치합니다.

```text
Pod

CPU: 1
Memory: 1Gi

      ↓

Kubernetes Scheduler

      ↓

적절한 Node 선택
```

일반적인 Web Application에서는 이 방식으로 대부분의 Workload를 처리할 수 있었습니다.

---

### 특수 Hardware의 등장

하지만 AI와 Machine Learning Workload가 Kubernetes에 올라오기 시작하면서 상황이 복잡해졌습니다.

AI Model을 실행하려면 일반 CPU뿐 아니라 GPU 같은 Accelerator가 필요할 수 있습니다.

```text
AI Workload

CPU
+
Memory
+
GPU
```

GPU 외에도 다양한 특수 Hardware가 존재합니다.

```text
Specialized Resource

├─ GPU
├─ FPGA
├─ NIC
├─ Accelerator
└─ 기타 Device
```

이런 Resource는 CPU와 Memory처럼 단순히 숫자 하나로만 표현하기 어렵습니다.

---

### GPU는 모두 같은 GPU가 아니다

예를 들어 Cluster에 여러 종류의 GPU가 있다고 가정해보겠습니다.

```text
Node A
└─ NVIDIA A100

Node B
└─ NVIDIA L4

Node C
└─ NVIDIA H100
```

Application마다 필요한 GPU 특성도 다를 수 있습니다.

```text
AI Training
     ↓
H100 / A100


AI Inference
     ↓
L4


Small Model
     ↓
상대적으로 작은 GPU
```

단순히

```text
GPU = 1개
```

라고 요청하는 것만으로는 충분하지 않을 수 있습니다.

어떤 종류의 GPU인지, 어떤 특성을 가지고 있는지, 어떻게 공유하거나 할당할 것인지까지 고려해야 합니다.

---

### 기존 Device Plugin 방식

Kubernetes에서는 기존에도 Device Plugin을 통해 GPU 같은 특수 Hardware를 사용할 수 있었습니다.

개념적으로는 다음과 같은 구조입니다.

```text
Hardware
   ↓
Device Plugin
   ↓
Kubernetes
   ↓
Pod
```

예를 들어 NVIDIA GPU를 사용하는 Pod에서 다음과 같은 Resource를 요청할 수 있습니다.

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

Scheduler는 GPU를 사용할 수 있는 Node에 해당 Pod를 배치합니다.

---

### 기존 방식의 한계

하지만 Accelerator 종류와 사용 방식이 다양해지면서 단순한 Extended Resource 모델만으로는 표현하기 어려운 요구사항이 생기기 시작했습니다.

```text
GPU 요청

단순히

GPU 1개

        ↓

실제로 필요한 조건

GPU 종류
GPU Memory
Driver
Device 특성
공유 여부
Topology
Allocation 정책
```

AI Infrastructure가 복잡해질수록 Scheduler가 Device의 특성을 더 세밀하게 이해해야 할 필요가 커집니다.

---

### Dynamic Resource Allocation

Dynamic Resource Allocation은 이런 Resource를 Kubernetes에서 보다 유연하게 다루기 위한 Architecture입니다.

기존 구조를 단순화하면 다음과 같습니다.

```text
Pod
 ↓
GPU 1개 요청
 ↓
Scheduler
 ↓
GPU Node
```

DRA에서는 Resource의 특성과 요구사항을 더 명시적으로 표현할 수 있는 방향으로 발전하고 있습니다.

```text
Workload
    ↓
Resource Requirement
    ↓
Dynamic Resource Allocation
    ↓
Scheduler
    ↓
적절한 Device 선택
    ↓
Node
```

즉 Kubernetes가 단순히 Device 개수를 확인하는 수준에서 벗어나 **Workload에 맞는 Resource를 선택하고 할당하는 구조**로 확장되는 것입니다.

---

### 왜 Dynamic인가

기존 Resource Scheduling은 상대적으로 정적인 구조에 가깝습니다.

```text
Pod
 ↓
CPU 2
Memory 4Gi
 ↓
Node 선택
```

하지만 Hardware Accelerator는 더 복잡할 수 있습니다.

```text
AI Workload
    ↓
특정 Accelerator 필요
    ↓
사용 가능한 Device 검색
    ↓
조건 확인
    ↓
Resource Allocation
    ↓
Pod 실행
```

Workload의 요구사항과 Cluster의 실제 Device 상태를 바탕으로 Resource를 동적으로 선택할 필요가 있습니다.

---

### AI Workload와 Kubernetes

생성형 AI가 확산되면서 Kubernetes에서 실행되는 Workload 종류도 달라지고 있습니다.

기존에는 주로 다음과 같은 Application이 중심이었습니다.

```text
Kubernetes

├─ Web Server
├─ Backend API
├─ Worker
├─ Batch Job
└─ Database Operator
```

이제는 AI 관련 Workload도 증가하고 있습니다.

```text
Kubernetes

├─ AI Inference
├─ Model Serving
├─ Model Training
├─ Embedding
├─ GPU Batch Job
└─ Distributed Training
```

Cluster Scheduler가 다뤄야 하는 Resource 종류 자체가 늘어나고 있는 것입니다.

---

### 일반 Web Server Scheduling

전통적인 Web Application에서는 주로 다음 두 Resource가 중요했습니다.

```text
CPU
+
Memory
```

예를 들어 Backend Pod를 여러 개 실행한다고 하면,

```text
Backend Pod A
Backend Pod B
Backend Pod C
        ↓
Scheduler
        ↓
CPU / Memory 기준 배치
```

상대적으로 단순한 Scheduling 문제입니다.

---

### AI Infrastructure Scheduling

AI Workload에서는 상황이 달라집니다.

```text
Model
  ↓
GPU 필요
  ↓
GPU Type 확인
  ↓
GPU Memory 확인
  ↓
Node 확인
  ↓
Resource 할당
```

Distributed Training 같은 환경에서는 더 복잡해질 수 있습니다.

```text
Training Job

GPU × 8
+
Network
+
Storage
+
Node Topology
```

단순한 Container Scheduling을 넘어 **High Performance Compute Resource Scheduling**에 가까워집니다.

---

### Kubernetes 역할의 변화

Kubernetes 초기의 대표적인 역할을 단순화하면 다음과 같습니다.

```text
Container
   ↓
Web Application
   ↓
CPU / Memory Scheduling
```

하지만 Kubernetes가 다양한 Infrastructure Workload를 수용하면서 역할이 확장되고 있습니다.

```text
Kubernetes

CPU
+
Memory
+
GPU
+
Accelerator
+
Network
+
Storage
```

즉 Container Orchestrator를 넘어 **범용 Compute Resource Orchestrator**에 가까운 역할을 담당하기 시작한 것입니다.

---

### AI Inference

AI Inference Service도 Kubernetes에서 운영할 수 있습니다.

```text
Client
  ↓
Load Balancer
  ↓
Inference Service
  ↓
GPU Pod
  ↓
Model
```

Traffic이 늘어나면 GPU Pod를 Scale Out해야 할 수 있습니다.

```text
Traffic 증가
     ↓
Inference Pod 증가
     ↓
GPU Resource 필요
     ↓
Scheduler
     ↓
GPU Node 배치
```

이 과정에서 GPU Resource Scheduling이 전체 서비스 Scalability에 직접적인 영향을 줍니다.

---

### AI Training

Training Workload에서는 Resource Scheduling 문제가 더 중요합니다.

```text
Training Job
     ↓
GPU × N
     ↓
여러 Node
     ↓
Distributed Training
```

여러 GPU를 동시에 확보해야 하는 Job이라면 Cluster Resource가 충분히 존재해도 원하는 형태로 Resource를 확보하지 못해 대기할 수 있습니다.

```text
Cluster

Node A → GPU 2
Node B → GPU 1
Node C → GPU 3

Training Job
→ GPU 4 필요
```

이런 환경에서는 단순한 Pod Scheduling보다 더 정교한 Resource 관리가 필요합니다.

---

### GPU는 비싼 Resource다

GPU Scheduling이 특히 중요한 이유 중 하나는 **GPU가 매우 비싼 Infrastructure Resource이기 때문**입니다.

CPU Resource가 일부 Idle 상태인 것과 GPU가 Idle 상태인 것은 비용 영향이 크게 다를 수 있습니다.

```text
GPU Cluster

GPU 사용
→ 비용 발생

GPU Idle
→ 여전히 비용 발생
```

따라서 AI Infrastructure에서는 단순히 GPU를 확보하는 것뿐 아니라 **GPU Utilization을 얼마나 높일 수 있는가**도 중요한 문제입니다.

---

### Resource Utilization

AI Infrastructure에서는 다음과 같은 구조가 이상적입니다.

```text
Available GPU
      ↓
Scheduler
      ↓
적절한 Workload
      ↓
높은 GPU Utilization
```

반대로 Scheduling이 제대로 되지 않으면 Resource Fragmentation이 발생할 수 있습니다.

```text
Node A
GPU 일부 사용

Node B
GPU 일부 사용

Node C
GPU 일부 사용

        ↓

새로운 Large Job 배치 불가
```

Resource가 존재하지만 원하는 형태로 사용할 수 없는 상황입니다.

이 때문에 Accelerator Scheduling은 AI Infrastructure의 중요한 최적화 문제가 됩니다.

---

### Cloud-native와 AI Infra의 결합

과거 AI Infrastructure는 일반 Application Infrastructure와 별도의 영역으로 운영되는 경우가 많았습니다.

```text
Web Infrastructure

Kubernetes
CPU
Memory


AI Infrastructure

GPU Server
HPC
Training Cluster
```

하지만 점점 두 영역이 결합되고 있습니다.

```text
Cloud-native Platform
        ↓
Kubernetes
        ↓
 ┌──────┼──────┐
Web   Backend   AI
               ↓
              GPU
```

하나의 Platform에서 일반 Application과 AI Workload를 함께 관리하려는 요구가 커지고 있습니다.

---

### Platform Engineer의 역할 변화

Kubernetes가 GPU와 Accelerator까지 관리하기 시작하면 Platform Engineer가 다뤄야 하는 영역도 확대됩니다.

```text
Platform Engineering

기존

├─ CPU
├─ Memory
├─ Network
├─ Storage
└─ Container


확장

├─ GPU
├─ Accelerator
├─ AI Workload
└─ Model Serving
```

AI Team만 GPU Infrastructure를 이해하면 되는 구조가 아니라 Platform Team에서도 Accelerator Scheduling을 이해해야 하는 환경이 만들어집니다.

---

### Backend 개발자에게도 영향을 준다

GPU Scheduling은 Infrastructure 문제처럼 보이지만 AI 기능을 제공하는 Backend에서는 Application Architecture와 직접 연결될 수 있습니다.

예를 들어 AI API를 제공한다면,

```text
Backend API
     ↓
Inference Service
     ↓
GPU
```

GPU Resource가 부족하면 Backend API의 Latency와 Availability에도 영향을 줍니다.

```text
GPU 부족
   ↓
Inference Queue 증가
   ↓
Latency 증가
   ↓
API Response 지연
```

따라서 AI Backend에서는 GPU도 Database Connection이나 Thread Pool과 비슷하게 **제한된 Resource로 관리해야 하는 대상**이 됩니다.

---

### Scheduler의 역할 확대

기존 Kubernetes Scheduler의 대표적인 판단 기준은 다음과 같았습니다.

```text
CPU

Memory

Node Selector

Affinity

Taint / Toleration
```

AI Workload가 증가하면 여기에 Device와 Accelerator 관련 조건도 중요해집니다.

```text
Scheduler

CPU
+
Memory
+
GPU
+
Accelerator
+
Topology
+
Device Requirement
```

Scheduler가 단순한 Container 배치기가 아니라 **Compute Resource 전체를 조정하는 핵심 Component**로 발전하고 있는 것입니다.

---

### 왜 중요한가

Kubernetes 1.32의 DRA 발전에서 중요한 것은 기능 하나가 추가됐다는 사실만이 아닙니다.

Kubernetes가 처리하려는 Workload 자체가 변하고 있다는 점입니다.

```text
기존

Web Application
      ↓
CPU / Memory


확장

AI / HPC Workload
      ↓
GPU / Accelerator
```

생성형 AI Workload가 Cloud-native Infrastructure 안으로 들어오면서 Kubernetes에서도 Accelerator Scheduling이 핵심 문제로 떠오르기 시작했습니다.

---

### Kubernetes가 범용 Compute Orchestrator로

Kubernetes의 역할 변화는 다음처럼 정리할 수 있습니다.

```text
초기

Container Orchestrator
        ↓
Web Application


이후

Cloud-native Platform
        ↓
Microservices


현재 확장 방향

Compute Orchestrator
        ↓
Web
Backend
Batch
AI
GPU
Accelerator
```

Container를 실행하는 것 자체보다 **다양한 종류의 Compute Resource를 어떻게 효율적으로 배치하고 운영할 것인가**가 중요해지고 있습니다.

---

### 실무 영향

Kubernetes에서 AI Workload를 운영하는 조직에서는 앞으로 다음과 같은 영역이 중요해질 수 있습니다.

```text
AI Infrastructure

├─ GPU Scheduling
├─ Device Allocation
├─ GPU Utilization
├─ Resource Quota
├─ Autoscaling
├─ Model Serving
├─ Distributed Training
└─ Observability
```

특히 GPU는 CPU보다 비싸고 종류도 다양하기 때문에 Resource Scheduling 전략이 Infrastructure Cost와 직접 연결됩니다.

```text
Better Scheduling
       ↓
GPU Utilization 증가
       ↓
Infrastructure 효율 증가
       ↓
AI Serving Cost 최적화
```

결국 Kubernetes 1.32와 DRA의 발전은,

> **Kubernetes가 CPU와 Memory 중심의 Container Scheduler에서 GPU와 Accelerator까지 관리하는 범용 Compute Orchestrator로 확장되고 있음을 보여주는 흐름**

이라고 볼 수 있습니다.

2024년 12월 13일(금) 주간 개발트렌드

독자의 메모