Kubernetes GPU Yönetimi: NVIDIA Operator, MIG ve FinOps Rehberi

🎯 Giriş: Kubernetes'te GPU Neden "Her Şeyi Kendin Getir" Modeline Dönüşür?

Merhaba! ☕ Hazırsan başlayalım.

Kubernetes üzerinde GPU iş yükleri çalıştırmak, sadece bir container başlatıp "çalışıyor, hadi geçelim" demekten ibaret değil. Aslında arka planda tüm sorumluluk sizde — bir nevi "Bring-your-own-everything" (her şeyi kendin getir) modeline dönüşüyor.

Ne demek istiyorum? Şöyle düşünün:

🏠 Hazır ev almak → Managed GPU servisi (ör. GKE Autopilot, EKS managed node groups). Altyapı, sürücü, güncelleme, izleme… hepsi sağlayıcıda.
🧱 Kendiniz inşaat yapmak → Self-managed Kubernetes cluster + GPU node'ları. Siz her şeyi kurarsınız, yamarsınız, izlersiniz, ödersiniz.

Kubernetes'te GPU kullanmaya karar verdiğiniz an, şu tüm bu parçaları ekibinizin omuzuna yüklersiniz:

✅ GPU sürücüleri (NVIDIA driver, container toolkit, vb.) — her node'da doğru sürümde olmalı
✅ Donanım bölme / paylaşma (MIG, time-slicing, vGPU) — pods arası izolasyon sizin tasarımınız
✅ İzleme & metrikler (DCGM exporter, Prometheus, Grafana dashboards) — "GPU % kaç dolu?" sorusuna cevap siz vereceksiniz
✅ Maliyet takibi — hangi namespace/team ne kadar GPU harcıyor? Showback/chargeback mekanizması sizde
✅ Yaşam döngüsü yönetimi — sürücü güncellemesi, node upgrade, firmware yaması… rolling upgrade stratejisi sizin çizeniz
✅ Scheduling & topology — nvidia.com/gpu resource, node selector, taint/toleration, pod topology spread… hepsi sizin manifestlarınızda

Kısaca: Kubernetes size orkestrasyon verir, ama GPU'yu tüketilebilir kaynak haline getirme işi tamamen sizin elinizde.

Bu yazının geri kalanında şunları öğreneceksiniz:

🛠 GPU node'larını nasıl hazırlarsınız? (Driver installation, NVIDIA Container Toolkit, Operator)
🔁 MIG / Time-slicing / vGPU — hangi paylaşma modeli işinize uygun?
📊 İzleme ve maliyet görünürlüğü nasıl kurulur? (DCGM, Prometheus, kubecost vb.)
⚙️ Scheduling stratejileri — ResourceQuota, LimitRange, PriorityClass, topology spread
🚀 Güncelleme ve dayanıklılık — sürücü升级, node drain, pod disruption budget

Hadi pratik bir örnek üzerinden anlayalım 👇

🔁 GPU Sürücü Yönetimi: NVIDIA GPU Operator ile Otomatik Kurulum

NVIDIA GPU Operator aslında Kubernetes klasterında GPU donanımını tamamen otomatik yöneten bir operatördür.
Manuel olarak her node’a sürücü kurmak, kernel modülü derlemek, device‑plugin dağıtmak ve sürüm uyumluluğunu takip etmek… Hepsi operatörün arkasında kalıyor 🎯.

Neden GPU Operator?

Manuel Yöntem	GPU Operator ile
Her node’a SSH → sürücü indir → kur → reboot	Tek Helm chart → tüm bileşenler otomatik rollout
Kernel güncellemesinde sürücü bozulur	Operator kernel‑değişikliklerini izler ve yeniden kurar
Device‑plugin, DCGM, validator ayrı ayrı yönetilir	Hepsi tek bir CRD altında birleşik

Helm ile Kurulum – 3 Adımda

Repo ekle & güncelle

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update

Namespace oluştur (genelde gpu-operator)
```
kubectl create namespace gpu-operator
```

Values dosyasıyla install

helm install gpu-operator nvidia/gpu-operator \
    -n gpu-operator \
    -f values.yaml

Otomatik Dağıtılan Bileşenler 🛠

driver – NVIDIA kernel modülü + userspace sürücüleri
device‑plugin – Kubelet’e GPU’ları tanıtır (nvidia.com/gpu)
dcgm – DCGM Exporter ile metrik toplama (Prometheus uyumlu)
validator – Kurulum sonrası nvidia-smi testi, sağlık kontrolü

Bu sayede node eklendiği anda GPU hazır hale gelir, ek bir komut girmezsiniz ✅.

Sürüm Uyumluluğu & Node Taint/Toleration ⚙️

driver.version: Klasterınızdaki Kubernetes ve kernel sürümüne uygun driver tag’ini seçin (ör. 550.127.08).
toolkit.enabled: true olduğunda container toolkit (nvidia‑container‑runtime) da kurulur.
Taint/Toleration: GPU node’larını nvidia.com/gpu=present:NoSchedule taint’iyle işaretleyin; operator pod’ları tolerations ile bu node’lara yerleşir.
```
tolerations:
  - key: "nvidia.com/gpu"
    operator: "Exists"
    effect: "NoSchedule"
```

Kendi Klasterınızda Deneyeceğiniz `values.yaml` Örneği 📄

Aşağıdaki dosyayı values.yaml olarak kaydedin ve helm install … -f values.yaml ile uygulayın. İhtiyacınıza göre driver.version ve toolkit.enabled alanlarını güncelleyin.

# values.yaml – NVIDIA GPU Operator temel konfigürasyon
driver:
  version: "550.127.08"          # Klaster kernel/OS sürümüne göre ayarlayın
  licensingConfig:
    nlsEnabled: false            # Lisans sunucusu yoksa false

toolkit:
  enabled: true                  # nvidia-container-toolkit kurulsun mu?
  version: "1.14.6"

devicePlugin:
  enabled: true                  # Kubelet’e GPU tanıtımı
  config:
    name: "nvidia-device-plugin"

dcgm:
  enabled: true                  # Metrik exporter
  serviceMonitor:
    enabled: true                # Prometheus ServiceMonitor oluştur

validator:
  enabled: true                  # Kurulum sonrası nvidia-smi testi

# Node taint/toleration stratejisi (örnek)
nodeSelector:
  nvidia.com/gpu.present: "true"

tolerations:
  - key: "nvidia.com/gpu"
    operator: "Exists"
    effect: "NoSchedule"

Ne olacak?

Operator pods gpu-operator namespace’inde ayağa kalkar.
Her GPU node’unda driver, device‑plugin, DCGM ve validator otomatik çalışır.
Siz sadece kubectl get pods -n gpu-operator diyip Running olduğunu görürsünüz 🚀.

Hazırsanız bu values.yaml ile kendi klasterınızda bir deneme yapın, sonraki bölümde GPU paylaşımı (Time‑Slicing / MIG) stratejilerine geçeceğiz 🎉.

❗️ Paylaşım Stratejileri: MPS ve MIG Arasında Seçim

GPU'yu birden fazla işlemcide paylaştırmak için iki ana yolumuz var: MPS (Multi-Process Service) ve MIG (Multi-Instance GPU). Kısaca: biri zaman paylaşır, diğeri donanımdan kesin ayırır. Hadi kısaca karşılaştıralım 👇

🎯 Temel Fark: Nasıl İzole Ediyorlar?

Özellik	MPS ⏱	MIG 🧱
İzolasyon Türü	Zaman paylaşımlı (time-sliced)	Donanımsal (hardware-level)
Kaynak Bölme	SM'ler, bellek, cache dinamik paylaşılır	GPU fiziksel parçalara (instance) bölünür
Performans Garantisi	❌ Yok — bir süreç diğerini yavaşlatabilir	✅ Var — her instance kendi kaynağını garanti altına alır
Esneklik	✅ Yüksek — işlemler gelip gidebilir	⚠️ Düşük — instance'lar statik tanımlanır
Desteklenen GPU'lar	Çoğu modern NVIDIA GPU (Volta+)	Sadece Ampere (A100, A30) ve Hopper (H100) mimarisi
Kullanım Kolaylığı	Basit — `nvidia-cuda-mps-control` ile başlatırsın	`nvidia-smi mig` ile konfigürasyon gerekir

🛠 Ne Zaman Hangisini Seçmeli? — Küçük Bir Kılavuz

Senaryo	Tercih	Neden?
Geliştirme / Test ortamı 👨‍💻	MPS	Hızlıca birden fazla modeli/deneyi aynı GPU'da koşturursun, izolasyon kritik değil.
Inference serving (çoğu küçük model) 🚀	MPS	Düşük gecikme, yüksek throughput isteyen çoklu model servisleri için ideal.
Production inference (SLA / garanti gerekli) 📜	MIG	Her müşteri/model için kesin performans garantisi lazımsa — örn. 7/24 servis.
Training (büyük modeller) 🏋️	Neither / Full GPU	Training genelde tüm GPU'yu ister. Paylaşım performansı düşürür.
Çok kiracılı (multi-tenant) bulut ortamı ☁️	MIG	Kiracılar birbirini etkilemesin, kaynakları faturalandırılabilir birimlere bölelim.
Küme kaynak verimliliği (bin packing) 📦	MIG	GPU'yu 1/7, 2/7, 3/7 gibi standart dilimlere böldüğünde planlama kolaylaşır.

⚡️ Pratik İpucu: MPS'i Hızlıca Açmak

# MPS daemon'ını başlat (root/sudo gerektirir)
nvidia-cuda-mps-control -d

# Client'lar artık aynı GPU'yu paylaşabilir
# Durdurmak için:
echo quit | nvidia-cuda-mps-control

Not: MPS varsayılanda tüm GPU'yu tek bir context havuzunda tutar. Per-process limit koymak istersen CUDA_MPS_ACTIVE_THREAD_PERCENTAGE ortam değişkeniyle oynayabilirsin.

🎯 Özetle

MPS = "Hızlı, esnek, ama garanti yok" — geliştirme, inference serving, düşük gecikmeli çoklu iş yükü.
MIG = "Kesin, öngörülebilir, ama sert" — production SLA, multi-tenant, kaynak kotalama.

Benim tavsiyem? Geliştirme aşamasında MPS ile başla 🛠. Production'a çıkarken SLA varsa MIG'e geç 🚀. Her ikisi de araç kutunda dursun — doğru yerde doğru kullanmak sana kalmış.

🛠 Pratik: MIG Yapılandırması için Örnek Pod YAML

Hazırsan MIG etkin bir GPU üzerinde Pod nasıl çalıştırılır, adım adım görelim 🎯

Önce node’da MIG profillerinin oluşturulduğunu hatırlayalım. Genelde şu komutla profil YAML’i uygulanır:

kubectl create -f mig-profile.yaml

Bu işlem GPU’yu istediğimiz boyutlarda (örneğin 1g.5gb) MIG instance’larına böler. Profil oluştuktan sonra Pod tanımında ilgili kaynağı request/limit olarak belirtmemiz yeterli.

📋 Pod YAML’i – kopyala, yapıştır, çalıştır

Aşağıdaki manifest nvidia.com/mig-1g.5gb kaynağını ister, doğru node’u seçmek için nodeSelector ve tolerations ekler. Kendi cluster’ına göre nvidia.com/gpu.product değerini (ör. NVIDIA-A100-SXM4-40GB) güncellemeyi unutma.

apiVersion: v1
kind: Pod
metadata:
  name: mig-demo-pod
  labels:
    app: mig-demo
spec:
  restartPolicy: Never
  nodeSelector:
    # MIG profili oluşturulan node’u işaretle
    nvidia.com/gpu.product: NVIDIA-A100-SXM4-40GB
    # opsiyonel: özel bir etiket de kullanabilirsin
    mig-profile: "1g.5gb"
  tolerations:
    # GPU node’larda genellikle olan taint’leri tolere et
    - key: "nvidia.com/gpu"
      operator: "Exists"
      effect: "NoSchedule"
  containers:
    - name: cuda-workload
      image: nvidia/cuda:12.4.0-base-ubuntu22.04
      command: ["sleep", "3600"]  # test için container ayakta kalsın
      resources:
        limits:
          nvidia.com/mig-1g.5gb: 1
        requests:
          nvidia.com/mig-1g.5gb: 1

🔍 Ne oluyor burada?

nodeSelector → Pod’u MIG profili hazırlanmış GPU node’una yönlendirir.
tolerations → GPU node’lardaki nvidia.com/gpu:NoSchedule taint’ini geçmemizi sağlar.
resources.limits/requests → nvidia.com/mig-1g.5gb: 1 diyerek tam bir 1g.5gb MIG instance rezerve ederiz.
Container basit bir sleep ile ayakta kalıyor; gerçek iş yükünü buraya eklemen yeterli ✅

⚡ Hızlı test

kubectl apply -f mig-demo-pod.yaml
kubectl get pod mig-demo-pod -o wide
kubectl logs mig-demo-pod   # beklediğin çıktıyı görmeli (boşsa da sorun yok, sleep çalışıyor)

Pod Running durumuna geçtiyse MIG yapılandırman hazır demektir 🎉

İpucu: Farklı MIG boyutları (örn. 2g.10gb, 3g.20gb) için mig-profile.yaml’i ve Pod’da nvidia.com/mig-<boyut> alanını değiştirmen yeterli. Cluster’ındaki mevcut MIG profillerini şu komutla görebilirsin:

kubectl get nodes -o json | jq '.items[].status.capacity | with_entries(select(.key | startswith("nvidia.com/mig")))'

Keyifli MIG denemeleri! 🚀

🔁 İş Yükü İzleme: DCGM Exporter ve Prometheus Entegrasyonu

DCGM Exporter, NVIDIA GPU'larınızın kalp atışlarını Prometheus'e besleyen köprü. Hazırsan ne sunduğuna bir göz atalım 👇

📊 DCGM Exporter Hangi Metrikleri Veriyor?

Exporter, /metrics endpoint'inde şu ana kategorileri yayınlar:

GPU Utilization — DCGM_FI_DEV_GPU_UTIL (GPU core kullanım %)
Memory Usage — DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_FREE (VRAM kullanım/boş)
Temperature — DCGM_FI_DEV_GPU_TEMP (GPU sıcaklığı °C)
Power Draw — DCGM_FI_DEV_POWER_USAGE (Anlık güç tüketimi Watt)
Clock Frequencies — SM, Memory, Video clock'ları
ECC Errors — DCGM_FI_DEV_ECC_SBE_VOL_TOTAL / DBE (Single/Double bit hataları)
NVLink Throughput — Çoklu GPU sistemlerde bağlantı bant genişliği
XID Errors — Driver seviyesindeki kritik hata sayaçları

💡 İpucu: Metrik isimleri DCGM_FI_DEV_ prefix'iyle başlar. PromQL yazarken bu prefix'i göreceksiniz.

⚙️ Prometheus `scrape_configs` Bloğu

DCGM Exporter genellikle DaemonSet olarak her node'da 9400 portunda çalışır. Prometheus'in onu bulması için şu konfigürasyonu ekleyin:

scrape_configs:
  - job_name: 'dcgm-exporter'
    static_configs:
      - targets: ['localhost:9400']
        labels:
          cluster: 'prod-gpu-cluster'
    relabel_configs:
      - source_labels: [__address__]
        regex: '(.+):9400'
        target_label: __address__
        replacement: '${1}:9400'
      - source_labels: [__meta_kubernetes_pod_node_name]
        target_label: node
      - action: labeldrop
        regex: '__meta_kubernetes_pod_label_.*'

Ne oluyor burada?

static_configs ile basitçe localhost:9400 hedefliyoruz (DaemonSet host network modunda çalışıyorsa)
relabel_configs bloğunda:
- Node adını node label'ına taşıyoruz → Grafana'da node bazlı filtreleme kolaylaşır
- Gereksiz Kubernetes label'larını drop ediyoruz → Storage tasarrufu

🛠 Not: Eğer kube-prometheus-stack kullanıyorsanız, ServiceMonitor ile de yapabilirsiniz. Aşağıya bakın.

🔗 kube-prometheus-stack Entegrasyonu (ServiceMonitor Yolu)

Helm values dosyanıza (values.yaml) şu bloğu ekleyip helm upgrade çekin:

prometheus:
  prometheusSpec:
    serviceMonitorSelectorNilUsesHelmValues: false
    serviceMonitorSelector:
      matchLabels:
        release: kube-prometheus-stack

Sonra DCGM Exporter için ServiceMonitor CR uygulayın:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: dcgm-exporter
  labels:
    release: kube-prometheus-stack
spec:
  selector:
    matchLabels:
      app: dcgm-exporter
  endpoints:
    - port: metrics
      interval: 15s
  namespaceSelector:
    matchNames:
      - gpu-monitoring

Avantajı? Prometheus Operator otomatik keşfeder, IP değişikliklerinde manuel müdahale yok. ✅

📈 Grafana Dashboard Önerisi

Sıfırdan dashboard yazmayın. NVIDIA resmi dashboard hazır:

Dashboard	ID	Açıklama
NVIDIA DCGM Exporter Dashboard	12239	GPU utilization, memory, temp, power, NVLink, XID errors — hepsi tek panelde

Nasıl eklersiniz?

Grafana → Dashboards → New → Import
ID: 12239 yazın → Load
Prometheus data source seçin → Import

🎯 Bu dashboard multi-GPU node'ları da düzgün gösterir. node ve gpu label'larına göre variable filtreleme var.

🚨 Hangi Metrikleri Alarmla? (Pratik İpuçları)

Alarm kurarken sadece eşik değil, trend de izleyin. Şu 5 kuralı mutlaka ekleyin:

Alarm	PromQL Örneği	Eşik (Örnek)	Neden?
GPU Sıcaklığı Yüksek	`DCGM_FI_DEV_GPU_TEMP > 85`	85°C	Throttling başlar, performans düşer 🔥
GPU Utilization Sustained Low	`avg_over_time(DCGM_FI_DEV_GPU_UTIL[10m]) < 10`	%10	Kaynak israfı, maliyet kontrolü 💸
VRAM Kullanımı Kritik	`DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_TOTAL * 100 > 95`	%95	OOM kill riski ❌
Power Draw Anomali	`abs(DCGM_FI_DEV_POWER_USAGE - avg_over_time(DCGM_FI_DEV_POWER_USAGE[1h])) > 50`	50W sapma	Donanım arızası / runaway process ⚡
XID Error Artışı	`increase(DCGM_FI_DEV_XID_ERRORS_COUNT[5m]) > 0`	0	Driver/GPU donanım hatası — acil müdahale 🚑

Bonus: DCGM_FI_DEV_ECC_SBE_VOL_TOTAL artışı görürseniz, RAM modülü değişim zamanı gelmiş olabilir. 🔧

🎯 Özetle

DCGM Exporter → GPU metriklerinin tek kaynağı
Prometheus scrape_configs veya ServiceMonitor → Veriyi çeker
Grafana Dashboard 12239 → Görselleştirir
5 kritik alarm → Uyurken de GPU'larınız güvende 😴✨

Hadi şimdi kubectl apply -f çekip dashboard'u import edin. Sorun yaşarsanız yanınızdayım! 🤝

❗️ Maliyet Görünürlüğü: FinOps İçin GPU Kullanım Verisi Toplama

GPU’lar kümenin en pahalı kaynaklarından biri ama fatura gelince nerede harcandığı çoğu zaman bir gizem kalıyor 🤔.
Sebebi basit:

Paylaşımlı kullanım – birden fazla pod aynı GPU’yu bölüşebiliyor (MIG, time‑slicing vb.)
Saniyelik faturalandırma yok – cloud sağlayıcıları genelde saat/dakika bazında faturalandırıyor, kullanım anlık izlenmiyor

Bu yüzden FinOps prensiplerini Kubernetes’in metadata yapısıyla birleştirmek kurtarıcı oluyor.

🎯 Neyi Etiketleyeceğiz?

Metadata Türü	Ne İşe Yarar?	Örnek
Label	Pod/namespace bazlı maliyet grubu	`team=ml`, `project=recommendation`
Annotation	Ekstra maliyet bilgisi (ör. GPU modeli, saatlik fiyat)	`gpu-cost-per-hour="0.90"`
Namespace	Çok kiracılı ortamlarda maliyet ayrımı	`ns-finance`, `ns-research`

Bu etiketleri CI/CD pipeline’ında veya admission controller ile otomatik basarsanız, sonradan manuel müdahale gerekmez ✅.

🛠 Araçlar: Kubecost & OpenCost

Kubecost – UI’si hazır, GPU maliyetini node‑level fiyatlandırma ile eşleştirir.
OpenCost – Açık kaynak, Prometheus exporter’ı vardır, kendi dashboard’unuza entegre edersiniz.

İkisi de label/annotation/namespace bazlı raporlama sunar; hangisini seçerseniz seçin, veri kaynağı Prometheus olur.

📊 Basit Bir PromQL: GPU‑Saat Başına Tahmini Maliyet

Aşağıdaki sorgu, her namespace + pod çifti için GPU kullanım oranını alır, node bazındaki saatlik maliyetle çarpar ve GPU‑saat maliyetini verir.

sum(rate(dcgm_gpu_utilization[5m])) by (namespace, pod)
  * on(node) group_left(node_cost) node_cost_per_hour

Ne oluyor burada?

dcgm_gpu_utilization – NVIDIA DCGM exporter’ından gelen GPU kullanım % metrikleri.
rate(...[5m]) – Son 5 dakikadaki saniyelik değişim hızı (kullanım oranı).
sum(...) by (namespace, pod) – Pod bazında toplam kullanım.
* on(node) group_left(node_cost) node_cost_per_hour – İlgili node’un saatlik maliyetini (ör. node_cost_per_hour metriği) getirip çarpar.

Sonuç: namespace/pod granülarında GPU‑saat × $ → FinOps raporlarınızın kaynağı 🎉.

✅ Küçük Bir Kontrol Listesi

Tüm GPU pod’larına team, project label’ları eklendi mi?
Node’larda node_cost_per_hour (veya cloud‑provider fiyatı) metriği expose ediliyor mu?
Kubecost/OpenCost GPU modülü etkinleştirildi mi?
PromQL sorgusunu bir Grafana paneline ekleyip günlük/haftalık trendleri takip ediyor musunuz?

Bu adımları yerleştirdiğinizde, fatura geldiğinde “Bu GPU saati kim harcadı?” sorusuna anlık, ölçülebilir cevap verebilirsiniz 🚀.

🛠 Platform Mühendisliği: Şablonlar, Helm Chart'lar ve GitOps ile Tekrarlanabilir Dağıtım

Hazırsan başlayalım. Platform mühendisi olarak en büyük hedefimiz: takımların "GPU nasıl isteyeceğim?" derdine düşmeden, self-service bir şekilde workload'larını dağıtmasını sağlamak 🎯.

Bunu üç parça ile çözüyoruz:

Ortak Helm chart (gpu-workload) → Şablon, varsayılanlar, parametreler
Kustomize overlay'leri → Ortam/ takım farklarını yönetmek
ArgoCD / Flux → GitOps ile sürekli senkronizasyon

🎯 Sorun: Herkes Kendi YAML'ını Yazıyor

Eski dünyada her takım kendi Deployment manifest'ını kopyalayıp, nodeSelector unutuyor, tolerations yanlış giriyordu. Sonuç? Pod Pending, GPU boşa çıkıyor, MIG profili uyuşmuyor ❗️.

Çözüm: Tek bir chart, parametrik values.yaml, sıfır tekrar.

🛠 gpu-workload Chart Yapısı

gpu-workload/
├── Chart.yaml
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── _helpers.tpl
└── values.yaml          # <-- Bu bizim "sözleşmemiz"

values.yaml içindeki alanları takımın sadece doldurması gereken parametreler olarak düşün. Gerisi chart hallediyor.

📋 Örnek values.yaml Parçası

# gpu-workload/values.yaml
gpu:
  enabled: true
  mig:
    profile: "mig-1g.5gb"   # MIG profil adı (GPU operator CRD ile eşleşmeli)
  nodeSelector:
    nvidia.com/gpu.product: "NVIDIA-A100-SXM4-40GB"
    workload-type: "ml-training"
  tolerations:
    - key: "nvidia.com/gpu"
      operator: "Exists"
      effect: "NoSchedule"
    - key: "dedicated-gpu"
      operator: "Equal"
      value: "true"
      effect: "NoSchedule"
  resources:
    limits:
      nvidia.com/mig-1g.5gb: 1
    requests:
      nvidia.com/mig-1g.5gb: 1

Ne oluyor burada?

gpu.enabled: false → GPU'suz çalıştırma (CPU-only fallback) ✅
mig.profile → Takım sadece profil adını yazar, chart resourceName eşleştirmesini yapar
nodeSelector + tolerations → Zorunlu alanlar, unutulmaz
resources.limits.nvidia.com/mig-1g.5gb → MIG slice isteği, typo riski sıfır

🔁 Kustomize Overlay ile Ortam Farkları

Takım base chart'ı kullanır, ortamına özel overlay ekler:

apps/
├── base/
│   └── gpu-workload/           # upstream chart (HelmRelease veya chart ref)
├── overlays/
│   ├── dev/
│   │   └── kustomization.yaml  # replicas: 1, gpu.mig.profile: mig-1g.5gb
│   ├── staging/
│   │   └── kustomization.yaml  # replicas: 2, nodeSelector: gpu-type: a100-80gb
│   └── prod/
│       └── kustomization.yaml  # replicas: 4, tolerations: dedicated-gpu=true

Örnek overlays/dev/kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base/gpu-workload
patches:
  - patch: |-
      - op: replace
        path: /spec/values/gpu/mig/profile
        value: "mig-1g.5gb"
      - op: replace
        path: /spec/values/replicaCount
        value: 1
    target:
      kind: HelmRelease

💡 İpucu: ArgoCD ApplicationSet ile her takım için Application otomatik üret. Takım sadece values-dev.yaml commitler, gerisi GitOps.

✅ Self-Serve Stratejisi: Takımın Yapması Gerekenler

Adım	Takım Sorumluluğu	Platform Sağladığı
1️⃣ Repo oluştur	`git clone platform/gpu-workload-template`	Template repo (cookiecutter / helm create)
2️⃣ values.yaml doldur	`gpu.mig.profile`, `nodeSelector`	Şema doğrulama (JSON Schema / `helm schema`)
3️⃣ Overlay seç	`overlays/dev` veya `overlays/prod`	Kustomize base + CI lint
4️⃣ Push & merge	PR aç, review al	ArgoCD sync → canary → prod

Sonuç: Takım 5 dakikada GPU'lu workload dağıtır, platform ekibi şablon güncellemesi ile tüm ekiplere best-practice yayar 🚀.

🛠 Sonuç: Şablon = Sözleşme

Chart = API sözleşmesi (values.yaml şeması)
Kustomize = Ortam varyasyonları (DRY)
GitOps = Tek kaynak gerçeği, audit trail, rollback

Bu trio ile GPU workload dağıtımı tekrarlanabilir, denetlenebilir ve self-service hale geliyor. Bir sonraki bölümde bu chart'ı ArgoCD ApplicationSet ile nasıl çoklu klüştere scale edeceğimize bakalım 👉.

🎯 Yol Haritası: Operasyonel Olgunluk Aşamaları ve Kontrol Listesi

Hazırsan bu yol haritasını beraber inceleyelim. Amacımız, ekibin "sadece çalıştır" modundan "sürdürülebilir çalıştır" moduna nasıl geçeceğini netleştirmek 🎯.

1️⃣ Aşama – Ad‑hoc (El Koyup Çalıştır)

✅ Kontrol Listesi	Açıklama
Sürücü Güncelleme Politikası	Elle güncelleme, takvim yok, "gerekirse yaparız" mantığı
MIG Profil Yönetimi	Profil hand‑crafted, versiyonlama yok, kopyala‑yapıştır
Alarm Kuralları	Sadece kritik hata logları için manuel e‑mail/Slack
Maliyet Raporlama	Ay sonu fatura kontrolü, detaylı breakdown yok

Ne oluyor?

Hızlı başlangıç ama tekrar edilemez, hata payı yüksek ❗️

Takım üyesi değişince bilgi kaybolur 📉

2️⃣ Aşama – Standartlaştırılmış (Tekrar Edilebilir)

✅ Kontrol Listesi	Açıklama
Sürücü Güncelleme Politikası	Haftalık/aylık planlı pencere, changelog şablonu
MIG Profil Yönetimi	Merkezi repo (Git), semantic versioning, code‑review zorunlu
Alarm Kuralları	Temel metrikler (CPU, RAM, Disk) için otomatik uyarı, runbook bağlantılı
Maliyet Raporlama	Haftalık otomatik rapor (CSV/JSON), servis bazlı gruplandırma

Nasıl çalışıyor?

Süreçler dokümante, yeni üye onboarding'i kolaylaşır 🚀

Hala manuel müdahale gereken noktalar var, ama görünürlük artar 🔍

3️⃣ Aşama – İzlenebilir & Maliyetli (Gözlem + Optimizasyon)

✅ Kontrol Listesi	Açıklama
Sürücü Güncelleme Politikası	Canary/rolling deploy, otomatik rollback kriterleri
MIG Profil Yönetimi	Profil test pipeline (unit + integration), performans benchmark
Alarm Kuralları	Çok boyutlu alarm (latency, error rate, cost anomaly), SLA‑bağlı escalation
Maliyet Raporlama	Günlük/ saatlik maliyet dashboards, tag‑based allocation, anomaly detection

Bu sayede ne oluyor?

Proaktif müdahale, fire drill sayısı düşer 📊

Maliyet şeffaflığı sayesinde right‑sizing kararları veri tabanlı olur 💰

4️⃣ Aşama – Otomatik & Self‑Healing (Tam Otomasyon)

✅ Kontrol Listesi	Açıklama
Sürücü Güncelleme Politikası	Policy‑as‑code, otomatik canary + health‑check, sıfır dokunma
MIG Profil Yönetimi	GitOps ile declarative profil, auto‑promote on green tests
Alarm Kuralları	Self‑healing runbook (auto‑scale, restart, traffic shift), post‑mortem auto‑create
Maliyet Raporlama	Real‑time cost optimizer (spot/instance‑type switch), budget guardrails

Ne kazanırsın?

Sıfır manuel müdahale, sistem kendini korur 🤖

Ekip stratejik işlere odaklanır, operasyonel yük minimumda ✅

📋 Kendi Durumunu Değerlendir – Hızlı Tablo

Aşama	Sürücü Güncelleme	MIG Profil	Alarm & İzleme	Maliyet Raporlama
1 – Ad‑hoc	❌ Manuel, plan yok	❌ Versiyonsuz	❌ Sadece kritik log	❌ Ay sonu fatura
2 – Standartlaştırılmış	✅ Planlı pencere, changelog	✅ Git + semver + review	✅ Temel metrik + runbook	✅ Haftalık CSV/JSON
3 – İzlenebilir & Maliyetli	✅ Canary + rollback	✅ Test pipeline + benchmark	✅ Çok boyutlu + SLA	✅ Günlük dashboard + anomaly
4 – Otomatik & Self‑Healing	✅ Policy‑as‑code, zero‑touch	✅ GitOps + auto‑promote	✅ Self‑healing + auto‑postmortem	✅ Real‑time optimizer + guardrails

Nasıl kullanılır?

Satırları oku, ekibin mevcut durumu hangi sütuna en yakın geliyorsa o hücreyi işaretle.
Her sütun için 1‑4 arası puan ver (1 = hiç yok, 4 = tam otomatik).
Toplam puan / 16 → Olgunluk Yüzdesi çıkar.
Eksik kalan maddeler öncelikli backlog'a girer 🎯.

🛠 Sonuç Olarak

Bu 4 aşamalı model, "neredeydik, nereye gidiyoruz?" sorusuna net bir cevap verir.
Kontrol listelerini sprint planlamanıza ekleyin, her iki haftada bir tabloyu güncelleyin ve görüşme notlarınızı bu tabloya bağlayın. Böylece hem şeffaflık hem de sürekli iyileştirme culture'ı oluşur 🌱.

Hadi, bir sonraki sprintte en az bir sütunu bir üst aşamaya taşıyalım! 🚀

🎁 Bonus Tavsiye: Sürekli İyileştirme ve Topluluk Kaynakları

Hazırsan kısaca özetleyelim ve bir sonraki adıma geçelim 🚀

Özet: Bu yazıda GPU Operator kurulumundan MIG yapılandırmasına, FinOps stratejilerine ve topluluk kaynaklarına kadar uçtan uca bir GPU‑on‑Kubernetes yol haritası çizdik.

İlk adım olarak bugün GPU Operator'ı bir test klasterına kur ve deneyimlemeye başla — küçük bir adım, büyük bir fark yaratır ✅

📚 Faydalı Linkler

NVIDIA GPU Operator Dokümantasyonu – https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/
MIG Best Practices – https://docs.nvidia.com/datacenter/tesla/mig-user-guide/
FinOps Foundation – https://www.finops.org/
CNCF TAG Runtime – https://tag-runtime.cncf.io/

Herhangi bir sorunda yorumlarda buluşalım! 🙌

Bu içerik tamamen yapay zeka destekli otomasyon sistemi ile üretilmiştir.

Kubernetes GPU Yönetimi: NVIDIA Operator, MIG ve FinOps Rehberi

🎯 Giriş: Kubernetes'te GPU Neden "Her Şeyi Kendin Getir" Modeline Dönüşür?

🔁 GPU Sürücü Yönetimi: NVIDIA GPU Operator ile Otomatik Kurulum

Neden GPU Operator?

Helm ile Kurulum – 3 Adımda

Otomatik Dağıtılan Bileşenler 🛠

Sürüm Uyumluluğu & Node Taint/Toleration ⚙️

Kendi Klasterınızda Deneyeceğiniz values.yaml Örneği 📄

❗️ Paylaşım Stratejileri: MPS ve MIG Arasında Seçim

🎯 Temel Fark: Nasıl İzole Ediyorlar?

🛠 Ne Zaman Hangisini Seçmeli? — Küçük Bir Kılavuz

⚡️ Pratik İpucu: MPS'i Hızlıca Açmak

🎯 Özetle

🛠 Pratik: MIG Yapılandırması için Örnek Pod YAML

📋 Pod YAML’i – kopyala, yapıştır, çalıştır

🔍 Ne oluyor burada?

⚡ Hızlı test

🔁 İş Yükü İzleme: DCGM Exporter ve Prometheus Entegrasyonu

📊 DCGM Exporter Hangi Metrikleri Veriyor?

⚙️ Prometheus scrape_configs Bloğu

🔗 kube-prometheus-stack Entegrasyonu (ServiceMonitor Yolu)

📈 Grafana Dashboard Önerisi

🚨 Hangi Metrikleri Alarmla? (Pratik İpuçları)

🎯 Özetle

❗️ Maliyet Görünürlüğü: FinOps İçin GPU Kullanım Verisi Toplama

🎯 Neyi Etiketleyeceğiz?

🛠 Araçlar: Kubecost & OpenCost

📊 Basit Bir PromQL: GPU‑Saat Başına Tahmini Maliyet

✅ Küçük Bir Kontrol Listesi

🛠 Platform Mühendisliği: Şablonlar, Helm Chart'lar ve GitOps ile Tekrarlanabilir Dağıtım

🎯 Sorun: Herkes Kendi YAML'ını Yazıyor

🛠 gpu-workload Chart Yapısı

📋 Örnek values.yaml Parçası

🔁 Kustomize Overlay ile Ortam Farkları

✅ Self-Serve Stratejisi: Takımın Yapması Gerekenler

🛠 Sonuç: Şablon = Sözleşme

🎯 Yol Haritası: Operasyonel Olgunluk Aşamaları ve Kontrol Listesi

1️⃣ Aşama – Ad‑hoc (El Koyup Çalıştır)

2️⃣ Aşama – Standartlaştırılmış (Tekrar Edilebilir)

3️⃣ Aşama – İzlenebilir & Maliyetli (Gözlem + Optimizasyon)

4️⃣ Aşama – Otomatik & Self‑Healing (Tam Otomasyon)

📋 Kendi Durumunu Değerlendir – Hızlı Tablo

🛠 Sonuç Olarak

🎁 Bonus Tavsiye: Sürekli İyileştirme ve Topluluk Kaynakları

📚 Faydalı Linkler

Kubernetes

GPU

NVIDIA GPU Operator

MIG

MPS

DCGM

FinOps

GitOps

Burak Sağlık

Burak Saglik

©2024 Desing and Developed by @Burak Sağlık

Kendi Klasterınızda Deneyeceğiniz `values.yaml` Örneği 📄

⚙️ Prometheus `scrape_configs` Bloğu