26Z29d
네. 꽤 중요한 변경점이 있습니다. 다만 결론부터 말하면, 현재 우리가 잡아둔 RHEL 10.2 + K8s 1.33 + B300 + Intel E810 + RoCEv2 + AIStor라는 구조에서 Benchmark의 큰 방향은 그대로이고, 오히려 몇 가지를 더 명확하게 분리해야 합니다.
특히 Network Operator 26.4.1은 RHEL 10.2/K8s 1.33을 공식 지원 범위에 넣었고, GPU Operator 26.7은 구성요소가 상당히 업데이트되었습니다. (NVIDIA Docs)
1. 가장 중요한 변경점 요약
| 항목 | 기존 계획 | 최신 기준 | 영향 |
|---|---|---|---|
| GPU Operator | 26.3.x | 26.7.x | 업데이트 필요 |
| Network Operator | 26.4.0 | 26.4.1 | 업데이트 필요 |
| RHEL | 10.2 | 10.2 | 그대로 |
| K8s | 1.33 | 1.33 | 그대로 |
| B300 | 지원 | 지원 | 그대로 |
| Intel E810 | 공식 GPUDirect 지원 불명확 | 여전히 NVIDIA 공식 GPUDirect 지원 NIC 아님 | 가장 중요 |
| RDMA Shared Device Plugin | 사용 | 사용 가능 | 그대로 |
| NFD | GPU Operator 제공 | GPU Operator 26.7의 NFD 0.19.0 사용 | 별도 설치하지 않는 방향 유지 |
| Multus | 필요할 경우 | Network Operator에 포함 | 선택 |
| RDMA CNI | 필요할 경우 | Network Operator에 포함 | 선택 |
| GPU Driver | GPU Operator | GPU Operator 26.7 | driver lifecycle 변경사항 확인 필요 |
| Container Toolkit | 기존 | 1.20.0 | 변경 |
| DCGM Exporter | 기존 | 4.6.0-4.8.3 | 변경 |
| Device Plugin | 기존 | 0.20.0 | 변경 |
| GPUDirect | 테스트 | 테스트 | E810에서는 여전히 별도 검증 |
2. Network Operator 26.4.1에서 가장 좋은 변화
이건 사용자 환경에서 의미가 있습니다.
NVIDIA Network Operator 26.4.1에서:
- Kubernetes 1.36 지원
- RHEL 10.2 지원
- RHEL 9.8 지원
- OpenShift 4.22 지원
- CVE fixes
가 추가됐습니다. (NVIDIA Docs)
즉 현재 환경:
RHEL 10.2
Kubernetes 1.33은 Network Operator 26.4.1 지원 범위 안에 명확히 들어갑니다. Network Operator 26.4.x의 지원표도 RHEL 10.0 계열 + Kubernetes 1.31–1.35를 명시하고 있습니다. (NVIDIA Docs)
따라서 제가 앞서 작성한 benchmark에서:
"RHEL 10.2에서 Network Operator가 공식 지원되는지 확인 필요"
라는 부분은 이제 확인 필요 → 지원됨으로 바꿔도 됩니다.
3. 그런데 아주 중요한 문제가 하나 그대로 남습니다
Intel E810입니다.
Network Operator 26.4.1의 공식 지원 NIC 목록을 보면:
- ConnectX-6
- ConnectX-6 Dx
- ConnectX-7
- ConnectX-8
- ConnectX-9
- BlueField-3
등 NVIDIA NIC가 대상입니다. Intel E810은 목록에 없습니다. (NVIDIA Docs)
그리고 GPUDirect RDMA 지원 조건도:
NVIDIA GPU + NVIDIA ConnectX/BlueField
로 명시되어 있습니다. (NVIDIA Docs)
따라서 이번 환경에서 아주 중요한 구분은:
Intel E810
│
├── RoCEv2
│ ↓
│ RDMA
│ ↓
│ PASS 가능
│
└── GPUDirect RDMA
↓
공식 지원?
↓
NO입니다.
즉,
E810의 RoCE/RDMA 자체는 충분히 POC할 가치가 있지만, NVIDIA 공식 GPUDirect RDMA 지원 플랫폼이라고 보면 안 됩니다.
이 부분은 최신 26.4.1에서도 바뀌지 않았습니다.
4. 그래서 Network Operator를 꼭 설치해야 하느냐?
여기서 이전 답변보다 더 명확하게 정리할 필요가 있습니다.
현재 환경이:
RHEL 10.2
K8s 1.33
Intel E810
ice
irdma
bond1
Cilium
RoCEv2라면 Network Operator를 무조건 설치해야 하는 것은 아닙니다.
Network Operator 26.4.x는 기본적으로 NVIDIA NIC ecosystem을 관리하기 위한 Operator입니다. 공식 지원 NIC도 NVIDIA NIC입니다. (NVIDIA Docs)
따라서 Intel E810을 사용한다면:
방법 A — Host 기반
RHEL
├─ ice
├─ irdma
├─ RDMA subsystem
└─ bond1
↓
Kubernetes
↓
RDMA Device Plugin이 방식이 현재 사용자 환경에는 더 자연스럽습니다.
즉:
GPU Operator
+
RDMA Shared Device Plugin중심으로 구성하고,
NVIDIA Network Operator는 굳이 넣지 않는 것을 우선 검토하는 것이 좋습니다.
5. 그러면 Multus도 필요 없나?
현재 architecture라면 필수는 아닙니다.
현재:
bond0 → external
bond1 → internal이고 GPU node에서:
bond1
│
├── Cilium traffic
│
└── RDMA/RoCE를 사용하려는 것이니까요.
RDMA application이 host의 RDMA device를 직접 사용한다면:
Pod
│
└── RDMA device
│
↓
bond1/E810구조로 갈 수 있습니다.
Multus가 필요한 것은 주로:
Pod
├── eth0 → Cilium
│
└── net1 → dedicated RDMA network처럼 Pod에 별도의 network interface를 추가해야 하는 경우입니다.
현재 계획에서는 이게 반드시 필요한 것은 아닙니다.
6. NFD는 어떻게 달라졌나?
이 부분도 좋은 변화가 있습니다.
Network Operator 26.4.x 자체에도 NFD dependency가 있지만, NVIDIA는 GPU Operator와 Network Operator를 같은 cluster에 설치할 경우:
NFD instance를 하나만 설치하고 GPU Operator에 포함된 NFD를 사용하는 것을 권장
하고 있습니다. (NVIDIA Docs)
GPU Operator 26.7에는:
Node Feature Discovery 0.19.0이 포함됩니다. (NVIDIA Docs)
따라서 현재 계획:
GPU Operator
↓
NFD
↓
GPU Feature Discovery를 유지하고,
Network Operator 때문에 NFD를 별도로 하나 더 설치하면 안 됩니다.
7. GPU Operator 26.7의 변화
GPU Operator 26.7은 단순 patch 수준의 변화가 아닙니다.
주요 component가 다음처럼 올라갔습니다. (NVIDIA Docs)
GPU Driver
595.91.07
Driver Manager
0.12.0
Container Toolkit
1.20.0
Device Plugin
0.20.0
DCGM Exporter
4.6.0-4.8.3
DCGM
4.6.0-1
MIG Manager
0.15.0
NFD
0.19.0
GPU Feature Discovery
0.20.0따라서 우리가 앞서 만들었던 benchmark의 Prometheus/Grafana metric 수집 부분은 반드시 실제 26.7 DCGM Exporter metric을 기준으로 다시 mapping하는 게 좋습니다.
8. 그리고 GPU Operator 26.7에서 중요한 변화 하나
이건 이번 프로젝트에서 상당히 중요합니다.
NVIDIA Driver CRD가 본격적으로 중요해졌습니다.
NVIDIA 문서에서는 GPU Operator가 26.7 이전이고 NVIDIADriver resource를 사용하지 않는 경우, 26.7로 upgrade하면서 CRD를 migration할 수 있는 절차까지 별도로 제공합니다. (NVIDIA Docs)
즉 신규 GPU node라면 처음부터:
GPU Operator 26.7
+
NVIDIADriver CRD방향을 검토할 가치가 있습니다.
특히 사용자의 환경처럼:
기존 K8s cluster
+
향후 GPU node 여러 대
+
RHEL 10.2
+
air-gapped
+
Kubespray라면 driver lifecycle을 Kubernetes resource로 관리할 수 있다는 것이 장점입니다.
9. 또 하나 중요한 변화 — containerd
GPU Operator 26.7 release note에는 최소 containerd 버전이 2.0으로 변경되었다고 명시되어 있습니다. (NVIDIA Docs)
이건 사용자 환경에서 반드시 확인해야 합니다.
이전에 사용자가 이야기했던 환경에서는 containerd 1.7 계열을 사용했었기 때문에, 현재 실제 GPU cluster node가:
containerd --version에서:
containerd 1.x인지 확인해야 합니다.
만약 1.7이라면 GPU Operator 26.7 도입 전에 이 부분부터 해결해야 합니다.
이건 이번 버전 변경에서 가장 중요한 실무 체크포인트 중 하나입니다.
10. 따라서 설치 구조도 조금 바뀝니다
제가 현재 환경이라면 우선 다음 구조를 선택하겠습니다.
GPU Node
RHEL 10.2 / K8s 1.33
│
┌──────────┴──────────┐
│ │
GPU Operator Intel E810
26.7 ice + irdma
│ │
├─ NVIDIA Driver │
├─ Container Toolkit │
├─ Device Plugin │
├─ DCGM │
├─ DCGM Exporter │
├─ NFD │
└─ GFD │
│
RDMA subsystem
│
RDMA Device Plugin
│
bond1
│
RoCEv2 network
│
AIStor그리고 Network Operator 26.4.1은 일단 설치하지 않는 방향을 우선 검토합니다.
11. 그러면 Network Operator 26.4.1은 언제 설치하는가?
다음과 같은 요구가 생기면 설치합니다.
① ConnectX로 변경
E810
↓
ConnectX-7/8/9이때는 Network Operator의 가치가 크게 올라갑니다.
② SR-IOV
PF
├── VF1 → Pod1
├── VF2 → Pod2
└── VF3 → Pod3③ Pod에 별도 RDMA network
eth0 → Cilium
net1 → RDMA④ RDMA CNI
Network Operator가 제공하는 RDMA CNI를 사용해야 하는 architecture.
⑤ NVIDIA NIC Configuration Operator
NIC-level configuration을 Kubernetes에서 관리하고 싶은 경우.
Network Operator 26.4.x에는 RDMA Shared Device Plugin, RDMA CNI, Multus, SR-IOV 관련 component 등이 함께 제공됩니다. (NVIDIA Docs)
12. 이번 POC에서 Network Operator를 넣었을 때의 문제
현재:
Intel E810인데:
NVIDIA Network Operator를 설치하면 관리 architecture가 복잡해집니다.
특히 Network Operator의 핵심 driver component는 DOCA-OFED driver 중심입니다. 26.4.x component matrix에서도 DOCA-OFED Driver Container가 포함되어 있습니다. (NVIDIA Docs)
그런데 E810은:
Intel ice
Intel irdma입니다.
따라서:
Network Operator
↓
DOCA-OFED
↓
E810같은 구조를 만들어서는 안 됩니다.
13. 그래서 현재 환경에서 추천하는 software stack
Host OS
RHEL 10.2Kernel
RHEL 10.2 supported kernelNIC
Intel E810
↓
ice
↓
irdmaKubernetes
K8s 1.33CNI
CiliumGPU
GPU Operator 26.7GPU driver
GPU Operator managedRDMA
Host irdma
+
RDMA Device PluginNetwork Operator
현재는 설치하지 않음Multus
현재는 설치하지 않음PFC/ECN
Switch + E810
별도 QoS configurationAIStor
별도 K8s cluster14. 그런데 여기서 한 가지 더 중요한 문제
"RDMA Device Plugin"을 NVIDIA Network Operator의 RDMA Shared Device Plugin으로 설치할 것인지는 별도로 결정해야 합니다.
Network Operator의 RDMA Shared Device Plugin은 기본적으로 NVIDIA networking ecosystem에서 사용하는 component입니다. 26.4.x component matrix에도 포함되어 있습니다. (NVIDIA Docs)
Intel E810에서는 Intel/Kubernetes community의 RDMA device plugin 또는 적합한 generic RDMA device plugin을 사용하는 방향을 검토해야 합니다.
즉 제가 앞서 "Network Operator → RDMA Shared Device Plugin"이라고 단순화했던 부분은 Intel E810이라는 조건에서는 수정하는 것이 맞습니다.
15. Benchmark 계획도 이렇게 수정하는 게 좋습니다
기존:
T00 Hardware
T01 TCP
T02 RDMA
T03 latency
T04 QP
T05 PFC
T06 Cilium
T07 Bond
T08 GPU RDMA
T09 DMA-BUF
T10 AIStor
T11 AIStor RDMA
T12 GPU-direct
T13 vLLM에서 앞단에 Software Compatibility Gate를 추가하겠습니다.
T00 OS/K8s/containerd
T01 GPU Operator 26.7
T02 Intel E810 ice/irdma
T03 RDMA device plugin
T04 RDMA functional test
T05 TCP baseline
T06 RDMA bandwidth
T07 QP scaling
T08 PFC/ECN
T09 Cilium coexistence
T10 LACP
T11 GPU-memory RDMA
T12 DMA-BUF GPUDirect
T13 AIStor TCP
T14 AIStor RDMA/direct path
T15 vLLM
T16 Soak
T17 Reboot/upgrade이게 훨씬 깔끔합니다.
16. 특히 이번에는 T12가 "Supported / Experimental"로 나뉩니다
T11
B300
↓
GPU memory
↓
E810
↓
RoCE기술적 동작 여부
T12
B300
↓
DMA-BUF
↓
E810
↓
RoCEGPUDirect RDMA 여부
그리고 각각:
| 결과 | 판단 |
|---|---|
| T11 FAIL | E810 GPU RDMA 자체 문제 |
| T11 PASS / T12 FAIL | GPU RDMA는 가능하지만 DMA-BUF path 문제 |
| T12 PASS | 기술적으로 GPUDirect RDMA 가능 |
| T12 PASS + NVIDIA unsupported | Experimental / vendor support risk |
| T12 PASS + vendor supported NIC | Production candidate |
현재 E810은 마지막 경우가 아니라 "기술적으로 동작하는지 검증해야 하는 experimental path"로 보는 게 맞습니다. NVIDIA 공식 GPUDirect RDMA 지원표가 지원 NIC를 ConnectX/BlueField로 한정하고 있기 때문입니다. (NVIDIA Docs)
17. 오히려 좋은 점도 있습니다
현재 사용자가 처음에는:
GPU node에 ConnectX를 못 쓰고 E810을 써야 한다.
고 했는데, 이번 POC에서는 이것이 오히려 architecture decision을 명확하게 해줍니다.
두 가지를 분리해서 증명할 수 있습니다.
Architecture A
B300
│
E810
│
RoCEv2
│
AIStorArchitecture B — 향후
B300
│
ConnectX
│
RoCEv2
│
AIStor그리고 동일 benchmark:
Host RDMA
GPU RDMA
GPUDirect
AIStor
vLLM를 돌리면 E810을 계속 사용할지 ConnectX로 갈지 정량적으로 결정할 수 있습니다.
결론
현재 버전 기준으로는 제가 이전 계획을 다음처럼 수정하겠습니다.
유지
- RHEL 10.2
- K8s 1.33
- B300
- Intel E810
ice + irdma- bond1
- RoCEv2
- PFC/ECN
- Cilium coexistence test
- AIStor 별도 cluster
- TCP → RDMA → GPU RDMA → AIStor → vLLM 단계별 benchmark
업데이트
- GPU Operator → 26.7
- Network Operator → 26.4.1 기준 문서/호환성 검토
- DCGM Exporter 등 metric baseline을 26.7 component 기준으로 재작성
- containerd 2.0 이상 여부 확인
- NFD는 GPU Operator 26.7에 포함된 0.19.0 하나만 사용
- GPU Driver CRD/NVIDIADriver 도입 검토
중요한 수정
Intel E810을 사용하는 현재 구조에서는 Network Operator 26.4.1을 무조건 설치하지 않는 것이 좋습니다.
Network Operator 26.4.1은 RHEL 10.2/K8s 1.33 자체는 지원하지만, 공식 RDMA/GPUDirect NIC 지원은 NVIDIA ConnectX/BlueField 중심입니다. (NVIDIA Docs)
따라서 현재 POC는:
GPU Operator 26.7
+
Intel ice/irdma
+
Generic RDMA device plugin
+
Cilium
+
bond1
+
RoCEv2를 기본으로 하고,
Network Operator 26.4.1은 향후 ConnectX를 사용할 때의 target architecture로 보는 것이 가장 깔끔합니다.
그리고 GPU Operator 26.7의 최소 containerd 2.0 변경은 반드시 먼저 확인해야 할 사항입니다. (NVIDIA Docs)
원래 만들어드린 Excel benchmark도 이 변경사항을 반영해서 GPU Operator 26.7 / Network Operator 26.4.1 / Intel E810 기준으로 T00~T17까지 다시 구성하는 게 맞습니다.
