Proxmox +
Kubernetes ile
Hibrit AI Altyapısı
Bare-metal GPU node'ları, vGPU lisanslama modelleri ve iş yükü zamanlayıcılarıyla kurumsal ölçekte AI/ML platformu nasıl inşa edilir? Mühendisler için katman katman rehber.
"VM mi, container mı?" sorusu artık yanlış bir çerçevedir. Gerçek kurumsal AI altyapısı her ikisine de ihtiyaç duyar.
Makine öğrenmesi iş yüklerinin hızla çeşitlendiği günümüzde tek tip bir altyapı stratejisi yetersiz kalmaktadır. Bazı iş yükleri izolasyon, güvenlik sertifikasyonu ve tam kontrol gerektirirken; bazıları anlık ölçeklenme, kaynak verimliliği ve DevOps entegrasyonu talep eder. Proxmox VE + Kubernetes kombinasyonu bu iki dünyayı bir arada yönetmenin en olgun ve açık kaynak destekli yoludur.
Bu yazıda GTM Teknoloji'nin Proxmox resmi partner perspektifinden, bare-metal GPU node mimarisinden vGPU lisanslama modellerine, Kubernetes GPU zamanlayıcısından üretim operasyonuna kadar her katmanı ayrıntılı biçimde ele alıyoruz.
Hibrit Katman Mimarisi: Proxmox Üstünde Kubernetes
Klasik yaklaşımda Kubernetes bare-metal üzerine doğrudan kurulur. Hibrit modelde ise Proxmox VE hypervisor katman olarak kalır; Kubernetes worker node'ları Proxmox VM'leri olarak çalışır. GPU node'ları ise duruma göre ya doğrudan pass-through ile VM'lere teslim edilir ya da vGPU ile birden fazla iş yüküne paylaştırılır.
Proxmox yalnızca bir hypervisor değildir; aynı zamanda VM ve LXC container yaşam döngüsünü, Ceph tabanlı dağıtık depolamayı, yazılım tanımlı ağ yapısını (SDN) ve yüksek erişilebilirlik kümelemeyi tek bir API üzerinden yönetir. Kubernetes node'larını Proxmox VM'leri olarak çalıştırmak, snapshot, live migration ve kaynak kotaları gibi hypervisor avantajlarını Kubernetes iş yüklerine taşır.
Bare-Metal GPU Node'ları: Üç Erişim Modeli
GPU'yu sanal ortamlara açmak için üç temel model vardır. Her birinin avantajları, kısıtlamaları ve lisans gereksinimleri farklıdır. Doğru seçim iş yükü profiline bağlıdır.
GPU doğrudan tek bir VM'e bağlanır. Sürücü VM içinde çalışır. Bare-metal performansına eşdeğer. NVLink multi-GPU eğitim için zorunlu.
Tek fiziksel GPU birden fazla VM'e profil bazlı ayrılır. vGPU Manager + GRID lisansı şart. Inference ve geliştirme ortamları için ideal.
GPU motorları ve bellek donanımsal olarak izole dilimlenebilir. Lisans gerektirmez. Her dilim tam izolasyonlu, gerçek donanım garantisi sunar.
| Özellik | PCIe Passthrough | NVIDIA vGPU | MIG (Multi-Instance GPU) |
|---|---|---|---|
| Performans | Bare-Metal | %90–98 arası | Donanım Garantili |
| İzolasyon | Tam (VM bazlı) | Yazılımsal | Donanımsal |
| Eş-zamanlı Kullanıcı | 1 | 2–32 (profile bağlı) | 2–7 (GPU modeline göre) |
| Ek Lisans | Yok | NVIDIA vGPU Zorunlu | Yok |
| Live Migration | Kısıtlı | Destekli | Kısıtlı |
| Desteklenen GPU | Tüm NVIDIA | Data Center serisi | A100, H100, H200 |
| Ideal İş Yükü | Dağıtık eğitim | Inference, geliştirme | Çoklu küçük inference |
Proxmox'ta PCIe Passthrough: Kritik Yapılandırma Adımları
Proxmox üzerinde GPU passthrough için önce BIOS'ta IOMMU ve VT-d / AMD-Vi etkinleştirilmeli, ardından GRUB parametreleri ayarlanmalıdır:
# Intel CPU için: GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt" # AMD CPU için: GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt" # Ardından: update-grub && reboot
vfio vfio_iommu_type1 vfio_pci vfio_virqfd
Aynı IOMMU grubunda birden fazla cihaz varsa (tipik sunucu durumu), standart kernel
passthrough'u reddeder. Proxmox'un özel kernel'i ACS override patch içerir;
bu sayede pcie_acs_override=downstream,multifunction parametresiyle
gruplar ayrıştırılabilir. Üretim ortamında güvenlik etkilerini değerlendirin.
MIG Yapılandırması: H100/H200 için Pratik Notlar
H100 SXM5 üzerinde 7 adet 1g.10gb dilimi veya 1 adet 7g.80gb
dilimi oluşturulabilir. Aynı GPU üzerinde farklı boyutlarda MIG profilleri karıştırılabilir;
bu da heterojen iş yükü kapasitesi açısından büyük esneklik sağlar.
# MIG modunu etkinleştir (reboot gerektirir) nvidia-smi -i 0 -mig 1 # H100 üzerinde 3g.40gb profili ile 2 dilim oluştur nvidia-smi mig -cgi 3g.40gb,3g.40gb -C # Mevcut profilleri listele nvidia-smi mig -lgip # Kubernetes için MIG device'ları görüntüle nvidia-smi -L | grep MIG
NVIDIA vGPU Lisanslama: Modeller ve Tuzaklar
vGPU teknolojisi hem VM içinde sanal GPU sunmak hem de CUDA iş yüklerini çalıştırmak için NVIDIA vGPU Software lisansı gerektirir. Bu lisans sistemi karmaşık olup yanlış planlanması ciddi operasyonel kesintiye yol açabilir.
| Lisans Sınıfı | Kullanım Senaryosu | CUDA | vGPU Profil | Faturalama |
|---|---|---|---|---|
| vPC (Virtual PC) | Sanal masaüstü | Yok | Q serisi | Concurrent / Subscription |
| vApps | Uygulama sanallaştırma | Yok | A serisi | Concurrent |
| vWS (Virtual Workstation) | Grafik iş istasyonu | Sınırlı | Q serisi (yüksek) | Concurrent |
| vCS / CNX | AI/ML, HPC CUDA | Tam CUDA | C serisi | Concurrent / Node-locked |
vGPU driver'ı her 24 saatte bir NVIDIA License Server veya DLS (NVIDIA Delegated License Service) ile iletişime geçmek zorundadır. Lisans sunucusuna erişilemeyen VM'lerde GPU performansı ciddi biçimde kısıtlanır veya tamamen devre dışı kalır. Üretim ortamında yüksek erişilebilirlik mimarisine sahip lisans sunucusu zorunludur. DLS Cloud opsiyonu bu riski azaltır ancak internet bağlantısı gerektirir.
vGPU Profil Seçimi
Her fiziksel GPU belirli bellek ve hesaplama profilleri sunar. A100 80GB üzerinde örnek profiller:
| Profil | FB Bellek | Max VM Sayısı | İdeal Kullanım |
|---|---|---|---|
A100-4C |
4 GB | 20 | Hafif inference, geliştirme |
A100-8C |
8 GB | 10 | Orta boyut model inference |
A100-20C |
20 GB | 4 | 13B model inference |
A100-40C |
40 GB | 2 | Fine-tuning, 33B inference |
A100-80C |
80 GB | 1 | Tek VM tam GPU |
Proxmox, NVIDIA vGPU'yu Linux kernel Mediated Device (MDEV) çerçevesi
üzerinden yönetir. Proxmox 8.x ile birlikte mdevctl ve QEMU entegrasyonu
güçlendirilmiştir; GUI üzerinden vGPU profil seçimi yapılabilmektedir. Ancak
vGPU Manager (host driver) kurulumu ve yapılandırması ayrıca yapılmalıdır.
Kubernetes'te GPU İş Yükü Zamanlama Stratejileri
Kubernetes, GPU'ları varsayılan olarak tam aygıt (whole device) olarak zamanlayabilir. İş yükü verimliliği için bu yeterli değildir; time-slicing, MIG ve vGPU paylaşımı için ek yapılandırma şarttır.
NVIDIA GPU Operator ile Otomatik Kurulum
NVIDIA GPU Operator, Kubernetes cluster'ında GPU driver kurulumu, device plugin, DCGM izleme, MIG yapılandırması ve container runtime entegrasyonunu tek bir Helm chart ile otomatize eder.
# Helm repo ekle helm repo add nvidia https://helm.ngc.nvidia.com/nvidia helm repo update # GPU Operator kur (MIG stratejisi: mixed) helm install gpu-operator nvidia/gpu-operator \ --namespace gpu-operator \ --create-namespace \ --set mig.strategy=mixed \ --set driver.enabled=true \ --set toolkit.enabled=true \ --set dcgmExporter.enabled=true # Node'larda GPU varlığını kontrol et kubectl get nodes -o json | jq '.items[].status.capacity | select(."nvidia.com/gpu")'
GPU Time-Slicing: Tek GPU'yu Birden Fazla Pod'a Paylaştırma
Küçük inference iş yükleri için MIG desteklemeyen GPU'larda time-slicing kullanılabilir. Bu yöntemde bellek izolasyonu yoktur; aynı GPU'nun hesaplama kapasitesi zaman dilimlerinde paylaştırılır.
apiVersion: v1 kind: ConfigMap metadata: name: time-slicing-config namespace: gpu-operator data: any: |- version: v1 sharing: timeSlicing: replicas: 4 # GPU başına 4 sanal slice failRequestsGreaterThanOne: false
GPU Kaynak Talep Örnekleri
apiVersion: v1 kind: Pod metadata: name: llm-inference spec: containers: - name: vllm image: vllm/vllm-openai:latest resources: limits: # Tam GPU talebi: nvidia.com/gpu: "1" # MIG dilimi talebi (alternatif): # nvidia.com/mig-3g.40gb: "1" # vGPU talebi (alternatif): # nvidia.com/vgpu: "1" nodeSelector: nvidia.com/gpu.product: H100-SXM5-80GB tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule
İş Yükü Zamanlama Akışı
talebi
filtresi
& env inject
-runtime
başlatma
Varsayılan kube-scheduler, gang scheduling (bir grup pod'un hepsinin aynı anda
başlatılması) konusunda yetersiz kalır. Dağıtık eğitim için Volcano
(CNCF projesi) veya Kueue (Kubernetes SIG) kullanılmalıdır.
Volcano PodGroup kaynak tipiyle PyTorch ve MPI iş yüklerinde tüm worker'ların
eş zamanlı başlamasını garanti ederek ölü kilit (deadlock) riskini ortadan kaldırır.
KubeVirt: VM İş Yüklerini Kubernetes'te Çalıştırmak
Bazı AI iş yükleri container'a taşınamaz: lisanslı yazılımlar, Windows tabanlı ML toolchain'leri veya kernel seviyesi özelleştirme gerektiren uygulamalar. KubeVirt, Kubernetes üzerinde VM'leri pod gibi yönetmeye olanak tanır; GPU passthrough ile birlikte kullanıldığında güçlü bir hibrit senaryo oluşturur.
Proxmox VE üzerinde çalışan bir Kubernetes cluster'ına KubeVirt kurulduğunda
iç içe sanallaştırma (nested virtualization) devreye girer.
Proxmox'ta CPU tipi host olarak ayarlanmalı ve nested VM özelliği QEMU
argümanıyla etkinleştirilmelidir. GPU passthrough bu yapıda Proxmox VM → KubeVirt VM
zinciriyle çalışabilir; ancak ek gecikme katmanı nedeniyle performans-kritik eğitim
iş yüklerinde önerilmez.
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: ml-workstation spec: template: spec: domain: devices: gpus: - name: gpu1 deviceName: nvidia.com/A100_PCIE_80GB resources: requests: memory: 64Gi cpu: "16"
Gözlemlenebilirlik: Proxmox + Kubernetes + GPU İzleme Yığını
Hibrit bir altyapıda metrikler üç farklı katmandan gelir: Proxmox hypervisor metrikleri, Kubernetes cluster metrikleri ve GPU aygıt metrikleri. Bunları birleştiren tutarlı bir izleme yığını olmadan operasyon kör uçuşa dönüşür.
| Bileşen | Araç | Topladığı Metrikler |
|---|---|---|
| Proxmox Hypervisor | pve-exporter → Prometheus |
VM CPU/RAM, storage I/O, HA durumu |
| Kubernetes Cluster | kube-state-metrics, cAdvisor | Pod durumu, kaynak kullanımı, scheduler kuyruğu |
| GPU (Fiziksel) | DCGM Exporter | SM kullanımı, bellek, sıcaklık, güç, NVLink BW |
| GPU (vGPU) | vGPU Plugin Metrics | vGPU frame buffer kullanımı, lisans durumu |
| Görselleştirme | Grafana | Birleşik dashboard, anomali tespiti |
| Uyarı | Alertmanager | GPU sıcaklık eşiği, OOM, vGPU lisans hatası |
🔍 Kritik Uyarı Kuralları
Üretimde mutlaka izlenmesi gereken üç metrik: (1) vGPU lisans sunucusu erişim başarısızlığı — 5 dakika içinde yanıt alınamaması uyarı tetiklemelidir. (2) GPU sıcaklığı 85°C üzeri — termal throttling başlamadan önce iş yükünü yeniden zamanlayın. (3) Kubernetes GPU aygıt plugin pod crash loop — tüm GPU talepleri başarısız olmaya başlar, sessiz bir kriz olabilir.
Üretim Öncesi Kontrol Listesi
Hibrit AI altyapısını üretim ortamına taşımadan önce aşağıdaki kontrol listesini tamamlayın. Her madde atlanan bir mühendislik kararını değil, bir üretim kesintisini temsil eder.
Proxmox Katmanı
- IOMMU ve ACS Override yapılandırması doğrulandı ve test edildi
- Proxmox cluster için Ceph veya NFS paylaşımlı depolama yapılandırıldı (VM migration için zorunlu)
- GPU node'ları için CPU tipi
hostolarak ayarlandı (AVX-512, CUDA için şart) - Proxmox HA group yapılandırması GPU node'larını kapsıyor
pve-exporterile Prometheus izlemesi aktif
GPU Erişim Katmanı
- vGPU kullanıyorsanız yüksek erişilebilir lisans sunucusu (minimum 2 node) kurulu
- MIG modu etkin node'larda MIG config kalıcılığı (reboot sonrası) sağlandı
nvidia-smivenvidia-smi topoçıktıları belgelenmiş referans olarak saklandı- PCIe Passthrough yapılandırmasında interrupt remapping doğrulandı
Kubernetes Katmanı
- GPU Operator kurulumu doğrulandı; tüm node'larda
nvidia.com/gpukapasitesi görünür - Dağıtık eğitim için Volcano veya Kueue kurulu ve test edildi
- GPU node'larına taint/toleration stratejisi uygulandı (CPU iş yükleri GPU node'larını işgal etmesin)
- ResourceQuota ile namespace bazlı GPU limitleri tanımlandı
- DCGM Exporter → Prometheus → Grafana pipeline aktif ve test edildi
Ağ Katmanı
- Dağıtık eğitim için RDMA/RoCE veya InfiniBand network ayrılmış (storage trafiğiyle karışmasın)
- Kubernetes CNI eklentisi (Calico/Cilium) MTU değeri RDMA ile uyumlu ayarlandı
- Multi-node eğitim için pod-to-pod ağ latency ölçümü yapıldı ve belgelendi
Hibrit AI Altyapınızı Birlikte Tasarlayalım
Proxmox lisanslama, GPU node mimarisi ve Kubernetes entegrasyonu için teknik danışmanlık ve uygulama desteği sunuyoruz.
// Bu yazıdaki komut örnekleri Proxmox VE 8.x, Kubernetes 1.29+ ve NVIDIA GPU Operator 23.x sürümleri baz alınarak hazırlanmıştır. vGPU lisans modelleri ve profilleri NVIDIA'nın ürün politikasına göre değişiklik gösterebilir; güncel bilgi için resmi NVIDIA vGPU documentation'ına başvurunuz.