---
title: "NVIDIA DSX OS ile Kubernetes GPU cluster'larını sertifikalamak"
description: "NVIDIA DSX OS, GPU cluster'larını AICR, NVCRE ve NVSentinel ile doğruluyor. NVCRE'de varsayılan threshold yok, NVSentinel önce yalnızca izliyor."
image: "https://sezer.in/wp-content/uploads/2026/11/dsx-os-cluster-readiness-featured-768x432-1.png"
url: "https://sezer.in/haberler/nvidia-dsx-os-kubernetes-gpu-cluster/"
date: "2026-11-07T16:41:40+03:00"
updated: "2026-11-07T16:41:40+03:00"
author: "Sezer Şanlıkan"
lang: "tr"
source: "https://sezer.in/haberler/nvidia-dsx-os-kubernetes-gpu-cluster/"
---

# NVIDIA DSX OS ile Kubernetes GPU cluster'larını sertifikalamak

NVIDIA, açık kaynak NVIDIA DSX OS katmanında Kubernetes GPU cluster'ları için AICR, NVCRE ve NVSentinel araçlarını anlattı. AICR sürümleri sabitlenmiş recipe'ler üretiyor, NVCRE cluster'ı NCCL (NVIDIA Collective Communication Library) testleri ve eğitim işleriyle sınıyor, NVSentinel ise node sağlığını izleyip arızalı node'ları karantinaya alabiliyor. Üç proje de Apache 2.0 lisanslı.

## NVIDIA DSX OS nedir ve nerede kullanılır?

NVIDIA DSX OS, NVIDIA DSX AI Factory Platform'un açık kaynak yazılım katmanıdır. GPU hızlandırmalı Kubernetes altyapısını yapılandırmak, iş yüküne hazır olduğunu doğrulamak ve işletme sırasında node sağlığını izlemek için araçlar içerir. Bileşenleri AICR, NVCRE ve NVSentinel'dir. Argo CD, Flux veya Helm gibi deployment araçlarının yerine geçmez, onlar için artifact üretir.

## NVIDIA DSX OS üç aşamayı ayırıyor

Dağıtık eğitimde iş, en yavaş rank'in hızında ilerliyor. Health check'ten geçen ve utilization'ı normal görünen tek bir node, 64 node'luk bir all-reduce işini yavaşlatabiliyor. NVIDIA DSX OS bu boşluğu üç araçla kapatmaya çalışıyor ve her biri farklı bir anda devreye giriyor:

- AICR kurulumdan önce çalışıyor ve sürümleri sabit bir yazılım baseline'ı üretiyor.
- NVCRE devir teslimden önce ve onarımdan sonra gerçek iş yüküyle ölçüm yapıyor.
- NVSentinel işletme sırasında sürekli çalışıyor, cluster'ın zaten ürettiği sinyalleri izliyor ve GPU zamanı harcamıyor.

NVIDIA ölçüt olarak utilization yerine goodput'u, yani başarıyla tamamlanan iş miktarını öneriyor. Arızalı node'da yanan compute da, temkinden boşta bekletilen sağlam node da utilization grafiğinde kayıp olarak görünmüyor.

## Threshold yoksa sertifika degradasyonu yakalamıyor

NVCRE'de varsayılan olarak hiçbir threshold tanımlı değil. Threshold bloğu olmadan koşu yalnızca ölçüm raporluyor ve ancak testler başlayamazsa başarısız oluyor. Hedefin altında çalışan bir node bu durumda sertifikayı alıyor.

Örnekteki `busBandwidthGBps: "value >= 300"` değerini kendi donanımınıza kopyalamayın. Önce threshold'suz bir koşu yapın, raporda ölçülen bandwidth değerlerini not edin, alt sınırı sonra yazın:

```
nvcrectl certification run --cert-file certification.yaml --wait
```

NVCRE'nin ikinci işi bisect. Kötü sonuç veren grubu bölüp testi yeniden koşuyor, minimum grup boyutuna inince şüpheli node'ları gerekçesiyle listeliyor. Katalogda DCGM (Data Center GPU Manager) level 4 diagnostic paketi ve NeMo Framework ile 8 milyar ve 56 milyar parametreli pretraining işleri var. Kendi test container'ınızı da WorkloadRun kaynağıyla sertifika adımına çevirebilirsiniz.

## NVSentinel'i önce monitoring modunda açın

NVSentinel varsayılan kurulumda yalnızca izliyor. Arızaları node condition olarak yazıyor, node'u cordon etmiyor, evict etmiyor. Canlı cluster'a bu modda kurup bir süre raporları kendi alarmlarınızla karşılaştırabilirsiniz. Condition'ları standart kubectl ile okursunuz:

```
kubectl describe node <node-adi>
```

Karantinayı açarken önce circuit breaker'ı ayarlayın. Bu sınır, kayan bir zaman penceresinde kaç GPU node'unun karantinaya girebileceğini belirliyor. Hatalı yazılmış bir CEL (Common Expression Language) kuralı tüm cluster'ı cordon etmeye kalkarsa sizi bu sınır durduruyor.

Örnek ruleset `nvidia.com/gpu-error=fatal:NoSchedule` taint'ini kullanıyor. Scheduler'ınız ve alerting kurallarınız bu taint'i NVSentinel'e entegre olmadan okuyabiliyor; alarmı taint anahtarına bağlamak en kısa yol. CONTACT_SUPPORT önerisiyle gelen olaylar otomatik çözülmüyor, nöbet sürecinde bunlara ayrı bir kuyruk açın.

## Recipe ve drift kontrolü pipeline'a giriyor

AICR deployment yapmıyor; artifact üretip doğruluyor. Uygulama işi Argo CD, Flux, Helmfile veya düz Helm'de kalıyor, GitOps akışınız değişmiyor. `--fail-on-drift` flag'i drift bulunca sıfırdan farklı çıkış koduyla dönüyor, bu yüzden komut CI'da gate olarak çalışıyor:

```
aicr bundle --recipe recipe.yaml --deployer argocd --output ./bundles
aicr diff --baseline ./golden.yaml --target cm://default/aicr-snapshot --fail-on-drift
```

Health assertion'lar pod phase yerine container waiting reason'a bakıyor. Kaynağa göre CrashLoopBackOff'ta takılan bir pod Running olarak raporlanabiliyor. Kendi readiness script'leriniz yalnızca phase kontrol ediyorsa aynı açığı taşıyor.

## Alpha API'ler ve başlama sırası

Recipe şeması `aicr.run/v1alpha2`, Certification kaynağı `nvcre.nvidia.com/v1alpha1` sürümünde. Kubernetes geleneğinde alpha API'ler sürümler arasında değişebiliyor; manifest'leri repo'da tutun ve her yükseltmede şema notlarını okuyun. NVIDIA DSX OS bileşenlerinin üçü de dış katkıya açık.

Sırayla:

1. NVSentinel'i monitoring modunda kurun.
2. Çalışan cluster için recipe üretip `aicr validate --recipe recipe.yaml` ile farkları görün.
3. Threshold'suz bir NVCRE koşusuyla bandwidth referansınızı çıkarın.
4. Karantinayı ve otomatik revalidation'ı en son açın.

Onarılan node'un havuza dönmeden NVCRE'den geçmesi yapılandırmaya bağlı. Bu tetikleyicileri kurmadan önce NVSentinel kurulum rehberindeki lifecycle olaylarını okuyun.