Kubernetes'te GPU'lu AI İş Yükleri: Zamanlama, İzolasyon ve Maliyet

Kubernetes’te GPU zamanlama, bir Pod’un istediği hızlandırıcı kaynağını uygun GPU’ya sahip ve erişim koşullarını karşılayan node ile eşleştirme sürecidir. Kubernetes bunu vendor device plugin’lerinin yayımladığı nvidia.com/gpu gibi extended resource’lar veya Dynamic Resource Allocation (DRA) üzerinden yapar; izolasyon, paylaşım ve maliyet politikaları ise ayrıca tasarlanmalıdır.

Bir Pod spec’ine nvidia.com/gpu: 1 yazmak GPU platformu kurmak değildir. Driver, container runtime, device plugin, node etiketi, taint/toleration, topology, GPU memory davranışı, paylaşım modu, telemetry ve bütçe aynı kontrol düzleminde ele alınmadığında pahalı GPU’lar ya boş bekler ya da kuyruk, OOM ve noisy-neighbor sorunları üretir.

Kubernetes GPU’yu nasıl görür? Driver, runtime ve device plugin zinciri

Kubernetes çekirdeğinde NVIDIA GPU keşfi yapmaz. Node’da uyumlu kernel driver ve container runtime entegrasyonu bulunur; vendor device plugin genellikle DaemonSet olarak kubelet’e cihazları kaydeder. Kubelet node capacity ve allocatable alanında nvidia.com/gpu kaynağını yayımlar. Scheduler sayısal kaynağı yerleştirir; container runtime seçilen cihazı workload’a görünür kılar.

kubectl get nodes -o custom-columns=NAME:.metadata.name,GPU:.status.capacity.nvidia\.com/gpu,GPU_ALLOC:.status.allocatable.nvidia\.com/gpu
kubectl describe node gpu-node-01 | sed -n '/Capacity:/,/System Info:/p'
kubectl -n kube-system get ds,pods | grep -E 'nvidia|gpu'
# Node on host:
nvidia-smi
# Inside a scheduled pod:
kubectl exec inference-worker -- nvidia-smi -L

Capacity 0 veya alanın tamamen yok olması scheduler sorunu değildir; zincirin daha erken halkası bozulmuştur. Driver yüklenmiş mi, container toolkit runtime’a bağlanmış mı, device plugin Ready mi ve kubelet plugin registration socket’ini görüyor mu kontrol edilir. GPU Operator kullanılıyorsa driver, toolkit, device plugin, DCGM ve node-feature-discovery bileşenlerinin her biri ayrı status taşır.

Temel GPU Pod manifesti

Kubernetes extended GPU resource yalnız limits altında verilebilir; requests hiç yazılmazsa limit request olarak kabul edilir. Requests ve limits birlikte yazılırsa eşit olmalıdır. Yalnız request yazmak geçerli değildir. GPU kesirli sayı olarak nvidia.com/gpu: 0.5 istenmez; kesirleme MIG, time-slicing, vGPU veya DRA driver politikasından gelir.

apiVersion: v1
kind: Pod
metadata:
  name: inference-worker
  labels:
    app: inference
    model: llama-70b
    cost-center: ai-platform
spec:
  restartPolicy: Never
  tolerations:
    - key: nvidia.com/gpu
      operator: Exists
      effect: NoSchedule
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: accelerator
                operator: In
                values: ["nvidia-h100"]
  containers:
    - name: server
      image: registry.example.com/inference@sha256:REPLACE
      resources:
        requests:
          cpu: "8"
          memory: 64Gi
        limits:
          cpu: "16"
          memory: 96Gi
          nvidia.com/gpu: 1

Node affinity doğru GPU sınıfını seçer; toleration yalnız taint’i tolere eder, node’u seçmez. Bu ikisini karıştırmak GPU’suz node’a toleration vermek veya yanlış accelerator nesline workload göndermekle sonuçlanır. accelerator etiketi cluster yöneticisinin yönettiği güvenilir label olmalı; keyfi workload’un değiştirebildiği etiket scheduling güvenlik sınırı değildir.

0/1 nodes are available: 1 Insufficient nvidia.com/gpu hatası nasıl çözülür?

Bu hata scheduler’ın Pod isteğini karşılayacak boş allocatable nvidia.com/gpu bulamadığını söyler. GPU fiziksel olarak mevcut olsa bile device plugin kaynağı yayımlamıyorsa, GPU başka Pod’a allocate edilmişse, node cordon/taint/affinity nedeniyle elenmişse veya Pod yanlış resource adı istiyorsa aynı mesaj görülebilir. Çözüm yeni node eklemekten önce scheduler’ın eleme nedenini doğrulamaktır.

kubectl describe pod <pod> | sed -n '/Events:/,$p'
kubectl get pod -A -o custom-columns=NS:.metadata.namespace,POD:.metadata.name,NODE:.spec.nodeName,GPU:.spec.containers[*].resources.limits.nvidia\.com/gpu
kubectl get node <node> -o jsonpath='{.status.allocatable.nvidia\.com/gpu}{"\n"}'
kubectl get node <node> --show-labels
kubectl describe node <node> | sed -n '/Allocated resources:/,/Events:/p'
kubectl get events -A --sort-by=.lastTimestamp | tail -50

Hangi Pod hangi GPU’yu kullanıyor sorusuna yalnız Pod spec cevap vermez; spec sayıyı gösterir, fiziksel UUID eşleşmesi kubelet pod-resources API, runtime ve DCGM exporter etiketleriyle kurulur. DCGM exporter Kubernetes mapping açıkken pod, namespace ve container label’ları ekleyebilir. MIG ve DRA için ayrıca instance/claim etiketleri gerekir.

Node affinity, taint ve topology birlikte nasıl kullanılmalı?

GPU node’larını nvidia.com/gpu=present gibi otomatik keşif etiketi ve accelerator sınıfı, GPU memory, interconnect/topology gibi yönetilen etiketlerle sınıflandırın. GPU node’larına NoSchedule taint koyarak yanlışlıkla genel workload doldurmasını engelleyin. Workload toleration ile kapıyı açar, affinity ile doğru sınıfı seçer.

Dağıtık training veya tensor-parallel inference yalnız GPU sayısına değil NVLink/NVSwitch, PCIe ve network topology’sine duyarlıdır. Sekiz GPU’nun sekiz farklı node’a dağılması ile tek NVSwitch domain’inde bulunması aynı performansı vermez. Scheduler’a topology sinyali, gang admission ve tüm replica’lar hazır olmadan başlatmama politikası eklenmelidir; aksi hâlde pahalı GPU’lar eksik peer beklerken allocate kalır.

GPU paylaşımı: MIG mi, time-slicing mi?

MIG, desteklenen NVIDIA GPU’larda compute ve memory kaynaklarını ayrı GPU instance’larına böler; izolasyon ve öngörülebilirlik time-slicing’den daha güçlüdür. Time-slicing daha yüksek doluluk sağlayabilir fakat bir replica isteği nvidia.com/gpu: 1 diye tam GPU performansı garanti etmez. Scheduler time slice’ın gerçek duty cycle veya framebuffer ihtiyacını kendiliğinden bilmez.

Seçim yalnız utilization’a göre yapılmaz. Latency SLO, model VRAM’i, kernel burst’ü, tenant güven sınırı ve profile fragmentation birlikte ölçülür. Aynı GPU’da iki latency-critical model time-slicing ile p99’u bozabilir. MIG profile çok küçükse model yüklenmez; çok büyükse kapasite stranded kalır. Profile değişimi çoğu ortamda draining ve yeniden yapılandırma gerektirir.

DRA ile GPU zamanlama

Dynamic Resource Allocation, workload’un yalnız sayısal extended resource değil DeviceClass ve ResourceClaim üzerinden özellikleri tanımlanmış cihaz istemesini sağlar. DRA ilk kez Kubernetes 1.30’da sunuldu; önemli API’ler 1.34’te GA yoluna girdi ve core özellik Kubernetes 1.35’ten beri stable olarak belgeleniyor. Kullanılan driver ve ek device özelliklerinin feature state’i ayrıca kontrol edilmelidir.

apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: inference-gpu
spec:
  spec:
    devices:
      requests:
        - name: gpu
          exactly:
            deviceClassName: gpu.nvidia.com
            count: 1
---
apiVersion: v1
kind: Pod
metadata:
  name: dra-inference
spec:
  resourceClaims:
    - name: gpu
      resourceClaimTemplateName: inference-gpu
  containers:
    - name: model
      image: registry.example.com/model@sha256:REPLACE
      resources:
        claims:
          - name: gpu

Örnekteki gpu.nvidia.com DeviceClass adı kurulu DRA driver’a bağlı bir placeholder’dır; cluster’daki gerçek DeviceClass ve driver belgeleri doğrulanmadan kopyalanmamalıdır. DRA özellikle cihaz özelliği seçimi, claim yaşam döngüsü, paylaşım ve ileri scheduling politikaları için genişletilebilir bir model sunar. Eski nvidia.com/gpu extended resource kullanımı bir gecede geçersiz olmaz; migration driver olgunluğu ve operasyon ihtiyacına göre yapılır.

Training, batch ve online inference aynı queue’da olmamalı

Online inference düşük p99 ve hazır kapasite ister; batch inference maliyet odaklıdır; training saatlerce GPU tutar ve gang scheduling gerektirebilir. Ayrı PriorityClass, queue, quota ve node pool kullanın. Yüksek öncelikli inference’ın training’i sürekli preempt etmesi checkpoint kaybı üretir; training’in tüm GPU’ları kaplaması da online SLO’yu bozar.

GPU izolasyonu yalnız device görünürlüğü değildir

Device plugin seçilen GPU’yu container’a verir; bu tek başına tenant izolasyonu değildir. Pod Security, seccomp/AppArmor, read-only filesystem, hostPath ve privileged yasağı, service-account least privilege, network policy, secret sınırı ve image provenance ayrıca gerekir. GPU node driver’ı ve device plugin yüksek ayrıcalıklı bileşenlerdir; sürüm ve image digest kontrolü kritik supply-chain sınırıdır.

GPU reset, XID error veya ECC olayı yalnız ilgili Pod’un hatası olmayabilir. Node health policy unhealthy cihazı allocatable’dan düşürmeli, workload’u güvenli biçimde drain etmeli ve aynı bozuk node’a sonsuz restart loop’u önlemelidir. Checkpoint’i olmayan training job’unu otomatik reschedule etmek saatlerce hesap kaybettirebilir.

GPU maliyeti nasıl hesaplanır?

GPU maliyeti Pod çalışma süresi ile node fiyatını çarpmaktan ibaret değildir. Allocated fakat düşük kullanılan süre, image/model download, model warm-up, queue beklerken tutulmuş peer GPU, failed training checkpoint’i, CPU/RAM/network ve boş node headroom’u toplam maliyete girer. FinOps hesabı allocation, utilization ve business output’u aynı run/job kimliğinde birleştirmelidir.

allocated_gpu_hours = sum(pod_gpu_count * allocation_seconds / 3600)
useful_gpu_hours = allocated_gpu_hours * average_SM_active_ratio
idle_cost = allocated_gpu_hours * hourly_gpu_rate * (1 - useful_ratio)

cost_per_1k_requests = total_inference_cost / successful_requests * 1000
cost_per_training_run = node + storage + network + failed_attempt + checkpoint costs

Temsili örnek: 4 GPU 24 saat allocate, saatlik GPU eşdeğeri 2,50 USD ve ortalama yararlı oran yüzde 35 ise brüt maliyet 240 USD, yaklaşık idle/underutilized pay 156 USD’dir. Bu sağlayıcı fiyatı iddiası değildir. Gerçek node fiyatı, taahhüt/spot, CPU/RAM payı ve ölçülen utilization ile yeniden hesaplanmalıdır.

Prometheus ve DCGM exporter ile GPU gözlemlenebilirliği

NVIDIA DCGM exporter DCGM alanlarını Prometheus /metrics endpoint’inde yayımlar ve Kubernetes mapping ile GPU örneklerini pod, namespace ve container’a bağlayabilir. Varsayılan metric set’i donanım ve exporter sürümüne bağlıdır; ConfigMap’e isim yazmak unsupported alanın yayınlanacağını garanti etmez. /metrics çıktısı ve DCGM field desteği birlikte doğrulanmalıdır.

# Namespace bazında allocate edilmiş GPU görünümü label setine göre uyarlanır
sum by (namespace) (DCGM_FI_DEV_GPU_UTIL)

# Düşük utilization: 30 dakikalık ortalama
avg_over_time(DCGM_FI_DEV_GPU_UTIL[30m]) < 0.20

# GPU framebuffer doluluk oranı
DCGM_FI_DEV_FB_USED / (DCGM_FI_DEV_FB_USED + DCGM_FI_DEV_FB_FREE) > 0.90

# XID görülmesi
DCGM_FI_DEV_XID_ERRORS > 0

DCGM oran metriklerinin birimi exporter/DCGM sürümünde doğrulanmalıdır; bazı eski dashboard’lar yüzde, güncel canonical alanlar ratio semantiği kullanabilir. Alert yalnız GPU_UTIL düşük diye Pod’u öldürmemelidir: model server beklerken düşük utilization normal olabilir. Queue depth, request rate, latency ve allocation ile korelasyon gerekir.

Autoscaling neden yalnız GPU utilization ile yapılmamalı?

Online inference’ta model load dakikalar sürebilir; GPU utilization yükseldikten sonra replica açmak geç kalır. HPA/KEDA benzeri kontrol döngüsü queue depth, in-flight request, tokens/s, p95 latency ve model-ready sinyalini kullanmalıdır. Scale-down warm cache’i yok eder ve oscillation üretir; stabilization window ve minimum warm replica gerekir.

Node autoscaler Pending Pod görmeden GPU node açmayabilir; node boot, driver readiness, image pull ve model load toplam cold-start bütçesidir. Cluster autoscaler’ın node template’inde nvidia.com/gpu kapasitesi ve gerekli labels/taints doğru değilse Pod scale-up tetikleyemez. Overprovisioning maliyet ile SLO arasındaki bilinçli karardır.

Dağıtık inference ve training için topology

Tensor parallel workload replica sayısı kadar GPU bulunca tamamlanmış sayılmaz. GPU peer-to-peer erişimi, NVLink/NVSwitch domain, NUMA, NIC locality ve RDMA ağı throughput’u belirler. Rank’leri rastgele node’lara dağıtmak iletişimi PCIe veya düşük hızlı ağ üzerinden geçirip pahalı GPU’ları bekletebilir. Topology-aware placement ve mümkünse aynı failure domain içinde gang admission gerekir.

Tüm Pod’lar hazır olmadan ilk Pod’ların GPU allocate edip beklemesi deadlock benzeri kapasite kaybıdır. Kueue veya uygun batch scheduler ile quota reservation, admission ve gang semantics uygulanabilir. Ancak framework adı garanti değildir; scheduler’ın kullandığınız Kubernetes ve GPU driver sürümüyle topology sinyalini nasıl yorumladığı test edilmelidir.

Üretim kontrol listesi

1. Driver, container toolkit, device plugin ve Kubernetes sürüm matrisi sabit.
2. GPU capacity/allocatable ve health otomatik doğrulanıyor.
3. Node labels yönetilen kaynaktan; GPU taint ve workload toleration doğru.
4. Online, batch, training ve notebook ayrı queue/quota politikalarında.
5. MIG/time-slicing seçimi VRAM, p99 ve tenant izolasyon testine dayanıyor.
6. DRA kullanılıyorsa DeviceClass, claim ve driver feature state doğrulanmış.
7. DCGM exporter Pod/MIG/DRA eşlemesi ve metric birimleri testli.
8. GPU, CPU, RAM, ephemeral storage ve network birlikte limitli.
9. Image digest, Pod Security, RBAC, network policy ve secret sınırı açık.
10. Cost allocation job/model/tenant/cost-center etiketleriyle uzlaştırılıyor.
11. XID, ECC, thermal ve unhealthy device runbook’u var.
12. Cold start, checkpoint, preemption ve rollback yük testinde sınanmış.

Sonuç

Kubernetes’te GPU yönetimi bir YAML’a nvidia.com/gpu eklemekten ibaret değildir. Güvenilir platform; device discovery, doğru placement, paylaşım/izolasyon, topology, queue admission, telemetry ve maliyet muhasebesini tek bir sözleşmede birleştirir.

Event-driven LLM worker mimarisi, multi-agent hata izolasyonu ve MCP sunucusu yazma rehberi GPU üstünde çalışan AI servislerinin uygulama ve entegrasyon katmanlarını tamamlar.