Kubernetes GPU Paylaşımı: MIG, vGPU ve Time-Slicing 2026

Kubernetes’te GPU paylaşımı, tek bir fiziksel hızlandırıcıyı birden fazla iş yüküne bölerek atıl kalan saniyeleri ve VRAM’i geri kazanmanın yoludur. 2026 itibarıyla üç ana yaklaşım baskın: NVIDIA MIG (Multi-Instance GPU) ile donanım seviyesinde izolasyon, vGPU ile hipervizör tabanlı dilimleme ve Time-Slicing ile zaman ekseninde paylaşım. Doğru seçim; inference latency hedefine, multi-tenant izolasyon zorunluluğuna ve kubernetes gpu sharing stratejisinin maliyet tarafına bağlıdır. NVIDIA’nın resmi raporlarına göre A100 80 GB üzerinde MIG ile 7’ye kadar instance çıkarıldığında inference throughput’u tek-instance moduna kıyasla yaklaşık %3-7x artarken, idle kalan H100 sayısı tipik bir orta ölçekli ML platformda %30-45 arasında seyrediyor. Bu yazı; üç yöntemin teknik mekaniğini, Kubernetes device plugin entegrasyonunu, gerçek benchmark verilerini, maliyet matrisini ve üretim ortamı kararı için somut bir çerçeveyi 2026 yılı verisiyle inceler.

GPU Paylaşımı Neden 2026’nın En Sıkışık Bulut Problemi Oldu?

Stack Overflow Developer Survey 2024’e göre profesyonel geliştiricilerin %76’sı AI/ML iş yükleriyle temas ediyor; ancak GPU’ların ortalama doluluğu Datadog Cloud Report 2024 ölçümlerinde %35-50 bandında kalıyor. NVIDIA H100 PCIe sürümünün 2026 başı itibarıyla AWS p5.48xlarge fiyatlandırmasında saatlik yaklaşık 98 USD seviyesinde olması, atıl her bir GPU saatinin doğrudan bütçe sızıntısı anlamına geldiğini gösteriyor. CNCF 2024 Annual Survey bulgularına göre üretim Kubernetes cluster’larının %63’ünde en az bir tip GPU node havuzu mevcut. Sorun şu: tek bir pod, gerektiğinden çok GPU rezerve edip kullanmıyor.

Klasik Kubernetes scheduler’ı nvidia.com/gpu: 1 isteğini tam-cihaz tahsisi olarak görür. Bu inference için ciddi israftır: BERT-base H100’ün yalnızca %8-12’sini kullanırken cihazın tamamı kilitlenir. MIG, vGPU ve Time-Slicing bu tek-cihaz dogmasını üç farklı katmanda kırar. Asıl soru “hangisi hızlı” değil, “hangisi yeterli izolasyon ile yeterli yoğunluk verir” sorusudur. McKinsey State of AI 2024 raporu AI altyapı maliyetinin 2025-2026’da ortalama %38 büyüdüğünü işaret ediyor — paylaşım stratejisinin birincil itici gücü.

İzolasyon spektrumu da önemli. MIG, donanım seviyesinde SM (Streaming Multiprocessor) ve L2 cache slice’ları ayırır. vGPU, hipervizör katmanı eklediğinden VM sınırına dayanır. Time-Slicing zaman dilimlemesi yapar; iki pod aynı SM havuzunu paylaşır ve belleği izole etmez. Multi-tenant SaaS’ta bu fark compliance, performans ve risk dengesini değiştirir.

MIG (Multi-Instance GPU): Donanım Seviyesinde Bölme

MIG, NVIDIA A100, A30, H100 ve H200 jenerasyonlarında bulunan donanım özelliğidir. Tek fiziksel GPU 7 adede kadar bağımsız “GPU instance”a bölünür. Her instance kendi SM havuzu, L2 cache slice, bellek bant genişliği ve PCIe DMA kanalına sahiptir. Komşu instance’taki yoğun batch işi, sizin inference’in p99 latency’sini etkilemez. NVIDIA MIG User Guide’a göre A100 80GB’da 1g.10gb profili 14 SM + 10 GB VRAM verir; 7g.80gb GPU’nun tamamı. Üretimde sık tercih edilen mix: 3x 2g.20gb + 1x 1g.10gb — orta boy modelleri verimli paketler.

MIG Profili	SM Sayısı	VRAM	Bellek Bant Genişliği	İdeal İş Yükü
1g.10gb	14	10 GB	~150 GB/s	Küçük inference (BERT-base, ResNet-50)
1g.20gb	14	20 GB	~150 GB/s	Embedding servisleri, retrieval
2g.20gb	28	20 GB	~300 GB/s	Mid-tier LLM (7B FP16)
3g.40gb	42	40 GB	~600 GB/s	13B model inference
4g.40gb	56	40 GB	~600 GB/s	Multi-stream batch inference
7g.80gb	98	80 GB	~2000 GB/s	Tam-GPU eğitim (LoRA fine-tune)

Kubernetes tarafında MIG’i etkinleştirmek için iki ana yol var. Birincisi statik partitioning: node provisioning sırasında nvidia-smi mig -cgi ile profiller sabitlenir, nvidia-device-plugin her instance’ı ayrı kaynak olarak (nvidia.com/mig-1g.10gb) yayar. İkincisi dinamik MIG: NVIDIA GPU Operator 24.x ile gelen mig-manager, node label’ına göre profili otomatik değiştirir — workload mix değiştiğinde drain edip yeniden bölmeli olur. Üretimde tercih edilen yaklaşım: node havuzu başına statik profil, çünkü dinamik geçiş drain + reboot maliyetini ağırlaştırır.

MIG’in gerçek üstünlüğü güçlü izolasyontur. SM, L2 cache, bellek kontrolcüsü ve PCIe yolu donanımda ayrılır. NVIDIA Hopper Architecture Whitepaper, MIG instance’ları arasındaki performance interference değerini “ölçülemez seviyede düşük” olarak işaretler — özellikle p99 latency duyarlı SaaS inference servisleri için bu kritiktir. Dezavantaj: instance’a atanan SM/VRAM sabittir, dinamik scaling yok. Bir instance %20 kullansa bile fazla SM’ler komşulara verilemez. Bu da MIG’i tahmin edilebilir ama elastik olmayan bir model yapar.

vGPU: Hipervizör Katmanlı Sanal GPU Dilimleme

NVIDIA vGPU, RTX Virtual Workstation ve AI Enterprise lisanslarıyla gelen, hipervizör seviyesinde GPU sanallaştırma teknolojisidir. VMware vSphere, Red Hat OpenShift Virtualization, Nutanix AHV ve KVM tabanlı yığınlarda çalışır. Tek bir fiziksel GPU (örneğin A40 48GB veya L40S 48GB), A40-2Q, A40-4Q, A40-8Q, A40-12Q, A40-24Q ve A40-48Q gibi profillere bölünebilir; rakam VRAM (GB) miktarını gösterir. SM tahsisi ise zaman dilimlemeli (round-robin veya equal-share scheduler) yapılır.

Kubernetes’te vGPU’yu kullanmanın iki tipik desenı var. Birincisi OpenShift Virtualization (KubeVirt) üzerinden sanal makineleri pod gibi yönetmek: VM içine vGPU profili enjekte edilir, GPU operator bunu standart device plugin gibi şedüller. İkincisi HAMi (Heterogeneous AI Computing Virtualization Middleware) ya da Volcano AI scheduler kullanarak konteyner katmanında soft-vGPU benzeri dilimleme yapmak — ancak buradaki “vGPU”, NVIDIA’nın resmi vGPU lisansı değil, açık kaynak yazılım katmanıdır. CNCF’in Volcano projesi, GPU sharing annotation’ları üzerinden bu pratikte sınırlı bir izolasyon sağlar.

Boyut	MIG	vGPU (Resmi NVIDIA)	Time-Slicing
İzolasyon Seviyesi	Donanım (en güçlü)	Hipervizör (güçlü)	Yok (zayıf)
VRAM İzolasyonu	Tam ayrım	Tam ayrım	Paylaşımlı (OOM riski)
SM Paylaşımı	Sabit slice	Zaman dilimi	Zaman dilimi
Lisans Maliyeti	Donanımla geliyor	Ayrı abonelik (~250 USD/yıl/CCU)	Ücretsiz
Desteklenen GPU	A100, A30, H100, H200	A40, L40, L40S, A16, vb.	Çoğu CUDA GPU
Max Bölme	7	Profile bağlı (24’e kadar)	Replica sayısına bağlı
Multi-Tenant Uygunluk	Mükemmel	Mükemmel	Sadece güvenilir tenants

vGPU’nun en güçlü olduğu nokta, MIG desteklemeyen GPU’larda izolasyonlu paylaşım kabiliyetidir. L40S gibi geniş VRAM’li ama MIG yetenekli olmayan kartlar, vGPU ile 4-8 tenant’a açılabilir. Dezavantajlar: NVIDIA AI Enterprise veya RTX vWS lisansı zorunlu, hipervizör overhead’i %3-7 ekler. Red Hat OpenShift Virtualization 4.x docs verisine göre vGPU instance’ları live migration destekler — finansal hizmetler için belirleyici avantaj.

Time-Slicing: En Hızlı Kurulum, En Zayıf İzolasyon

Time-Slicing, NVIDIA Kubernetes Device Plugin’in config.yaml dosyasındaki sharing.timeSlicing bloğuyla aktive edilen yazılım katmanlı bir paylaşım modudur. Yöntem basittir: tek bir GPU’yu sanki N tane kaynakmış gibi advertise eder. CUDA scheduler (driver içindeki) iş kuyruğunu round-robin işler. Ne MIG gibi donanım slice’ı vardır, ne vGPU gibi hipervizör sınırı — sadece zamanın bölünmesi söz konusudur.

version: v1
sharing:
  timeSlicing:
    resources:
      - name: nvidia.com/gpu
        replicas: 4

Bu örnekte tek bir H100, nvidia.com/gpu: 1 isteyen 4 ayrı pod’a aynı anda atanabilir. Avantaj: 5 dakikada kurulur, lisans gerekmez, donanım kısıtı yoktur. Dezavantaj: VRAM ortak havuzda. İki pod 50’şer GB istediğinde fiziksel 80 GB sınırına çarpıp CUDA out of memory üretebilirler. Üstelik bir pod sustained-load yaparsa diğer podların ortalama throughput’u orantılı olarak düşer; p99 latency öngörülemez hale gelir.

• Avantaj: Sıfır lisans, sıfır donanım kısıdı, dakikalar içinde devreye alma.
• Avantaj: Geliştirme ortamı, CI runner, batch dev-test iş yükleri için ideal.
• Dezavantaj: VRAM izolasyonu yok — bir pod OOM’a girerse diğerini etkileyebilir.
• Dezavantaj: p99 latency öngörülemez — production SaaS inference için riskli.
• Ne zaman seç: İçi güvenilir multi-tenant, ML araştırma cluster’ı, Jupyter notebook havuzu.
• Ne zaman SEÇME: Müşteri-yüzlü inference, finansal hesaplama, SLA’lı API.

NVIDIA’nın k8s-device-plugin GitHub deposu Time-Slicing ile MPS (Multi-Process Service) arasındaki farkı net ifade eder: MPS aynı CUDA context’i paylaşan süreçler arası concurrency sağlar, Time-Slicing ise farklı pod’lar için yalnızca scheduler-level dilimlemedir. MPS, üretimde tipik olarak HPC ve simülasyon iş yüklerinde tercih edilir; Time-Slicing genel-amaçlı paylaşım için.

NVIDIA GPU Operator ve Device Plugin: Kubernetes Entegrasyonu

Üç paylaşım modunun da Kubernetes katmanında çalışması için NVIDIA GPU Operator 24.x veya üzeri kurulu olmalı. Operator; driver yönetimini (precompiled veya dynamic), container toolkit’i, device plugin’i, MIG manager’ı, DCGM exporter’ı (metrik) ve node feature discovery’yi tek paket halinde getirir. Helm chart üzerinden kurulum, ortalama 4-6 dakikada tamamlanır. NVIDIA GPU Operator resmi dokümantasyonu sürüm uyumluluk matrisini Kubernetes 1.27–1.31 aralığında tutuyor (2026 başı itibarıyla).

Operator değerleri arasında en kritik olanlar:

• mig.strategy: single veya mixed — node’da homojen mi heterojen profil mi kullanılacak.
• devicePlugin.config.name — Time-Slicing yapılandırmasını içeren ConfigMap.
• migManager.enabled — dinamik profil değişimi için.
• dcgmExporter.enabled — Prometheus için GPU utilization, memory, power, temp metrikleri.
• toolkit.env — CDI (Container Device Interface) entegrasyonu için.

2026’nın belirleyici teknik kararı: CDI’a (Container Device Interface) geçiş. Kubernetes 1.27+ ile stabilleşen CDI standardı, vendor-spesifik device plugin’lerin yerini almaya başlıyor. NVIDIA GPU Operator 24.6 sürümünden itibaren CDI varsayılan modu. CDI, GPU dışında DPU, FPGA, NIC gibi heterogen hızlandırıcıları aynı abstraction altında toplar. Kubernetes Enhancement Proposal (KEP-4009) Dynamic Resource Allocation, 2025’in ikinci yarısında stabil oldu ve GPU paylaşımının next-gen modelini şekillendiriyor. Kubernetes resmi blog’undaki DRA beta yazısı bu geçişin haritasını veriyor.

GPU node havuzlarını ayrı yönetmek için nodeSelector ve taint/toleration kombinasyonu hâlâ standart. nvidia.com/mig.config: all-1g.10gb label’ı node’a uygulandığında MIG manager ilgili profili otomatik kurar. Pod tarafında resources.limits.nvidia.com/mig-1g.10gb: 1 isteği MIG instance’a, resources.limits.nvidia.com/gpu: 1 ise Time-Slicing replikasına eşlenir. Bu detay, scheduler’ın yanlış node’a pod basmasının önüne geçer. CI/CD pipeline’larında bu mapping’i versiyonlamak için ConfigMap’leri Git’te tutmak ve GitOps Kubernetes akışıyla otomatize etmek 2026 standardı.

Gerçek Dünya Benchmark’ları: Throughput, Latency ve Maliyet

MLPerf Inference v4.1 sonuçları ve NVIDIA’nın resmi performance whitepaper’ları, üç yöntem için aşağıdaki yaklaşık tabloyu çiziyor. Tüm değerler H100 PCIe 80GB referans donanımı üzerinde, BERT-Large FP16 inference test çerçevesinden. Sonuçlar konsept doğrulama amaçlıdır; kendi production yığınınızda yeniden ölçmeniz şart.

Senaryo	Toplam Throughput (samples/sec)	Pod Başına Throughput	p99 Latency (ms)	VRAM Kullanımı
Tek pod, tam GPU (baseline)	~3850	3850	~22	~14 GB / 80 GB
MIG 7x 1g.10gb	~9400	~1343	~28	7x ~9 GB
vGPU 4x H100-20Q	~7600	~1900	~31	4x 20 GB izole
Time-Slicing 4 replica	~5200	~1300	~58 (kararsız)	Ortak 80 GB
Time-Slicing 7 replica	~5600	~800	~92 (yüksek varyans)	Ortak 80 GB

Tablonun anlatımı net: MIG, agregat throughput’u baseline’ın yaklaşık 2.4 katına çıkarırken p99 latency’yi sadece %27 artırıyor. Time-Slicing aynı yoğunlukta agregat throughput’u %45 artırıyor ama p99 latency’yi 4 katına çıkarıyor — bu fark, SLA tabanlı API ürünleri için kabul edilemez. vGPU, MIG ile Time-Slicing arasında konumlanır: izolasyon güçlüdür, ancak hipervizör overhead’i ham throughput’u biraz törpüler.

Maliyet tarafına dönelim. AWS p5.48xlarge (8x H100) saatlik ~98 USD seviyesinde. Bir node’da MIG ile 56 instance (8 x 7) açmak teknik olarak mümkün ama gerçekçi orta-tier mix için 32-40 instance bandı tipik. Şirket içi 7B parametreli LLM inference için pod başına 3000 USD/ay tahsisli H100 maliyeti, MIG sonrasında pod başına ~430-540 USD’ye düşebilir. FinOps Bulut Maliyet disiplinine entegre edildiğinde bu kazanım, idle GPU saatlerini doğrudan budget’a geri kazandırır.

Karar Çerçevesi: Hangi Yöntemi Ne Zaman Seçmeli?

2026’da üretim ortamı için karar verme matrisini üç eksenli düşünmek gerekiyor: iş yükü tipi, izolasyon zorunluluğu, donanım envanteri. Aşağıdaki matris ekiplerin %80’ine doğru cevap verir; geri kalan %20 için POC yapın.

Senaryo	Önerilen Yöntem	Gerekçe
Multi-tenant SaaS inference (B2B API)	MIG	Donanım izolasyonu p99 stabilitesi sağlar
Internal ML platform (eğitim + inference)	MIG + Time-Slicing (node havuzu ayrı)	Eğitim batch’i izolasyonsuz olabilir, inference izole
VDI + AI (Citrix/Omnissa kullanıcıları)	vGPU	Lisans zaten var, hipervizör entegrasyonu doğal
L40S/A40 envanteri, MIG yok	vGPU veya HAMi	MIG donanım desteği yok
Jupyter notebook havuzu, dahili	Time-Slicing	Maliyet sıfır, izolasyon riskini güvenilir kullanıcılar üstlenir
HPC, MPI tabanlı simülasyon	MPS	Aynı CUDA context, en düşük overhead
Finansal hesaplama, regulated	MIG (H100/H200)	Donanım kanıtlı izolasyon, audit-friendly

Hibrit yaklaşımlar son dönemde yaygınlaşıyor. Tipik bir 2026 production deseni şu: Üç node havuzu — birinde MIG (latency-kritik inference), birinde vGPU (regulated VM iş yükleri için), birinde Time-Slicing (dev/test, batch). Kubernetes scheduler bu havuzları taint/toleration ile birbirinden ayırır; pod manifestlerindeki resources blokları doğru havuza yönlenir. Kubernetes Cost VPA HPA mekanizmasıyla node havuzu boyutlandırması otomatize edilebilir; tek başına manuel boyutlandırma 2026 ölçeklerinde sürdürülemez.

Ömer Önal’ın orta ölçekli teknoloji şirketleriyle yürüttüğü danışmanlık projelerinde tipik tek-kazan, ilk hafta içinde idle GPU saatlerinin %25-35 oranında geri kazanılması oluyor — bunun büyük kısmı doğru sharing modunu doğru node havuzuna eşlemekten geliyor, ekstra donanım almaktan değil. CNCF 2024 Annual Survey da bu eğilimi doğruluyor: katılımcıların %58’i GPU sharing’i 2024-2025 arasında devreye almış veya alıyor.

Gözlemlenebilirlik, Quota ve Multi-Tenant Yönetimi

GPU paylaşımı kurmak yarısı; gözlemleyebilmek diğer yarısı. NVIDIA DCGM Exporter, MIG instance bazında utilization, memory, power, temperature, ECC error ve XID error metriklerini Prometheus formatında verir. Grafana’da MIG instance UUID bazında dashboard’ları kurulur. p95/p99 latency’yi inference servisinin kendisinden (vLLM, TGI, Triton Inference Server) toplamak ek bir disiplin gerektirir; bu iki katman birleşmediğinde “GPU %30 ama p99 patladı” gibi gizli korelasyonlar atlanır.

• Quota yönetimi: Namespace başına ResourceQuota ile nvidia.com/mig-1g.10gb ya da nvidia.com/gpu sınırı koyun.
• PriorityClass: Inference pod’ları yüksek öncelik, batch training düşük öncelik. Preemption iş yükü mix’ini stabilize eder.
• Node taint: nvidia.com/sharing=mig:NoSchedule ile sharing havuzlarını izole edin.
• Audit log: Her GPU isteği kim, ne, ne kadar — FinOps raporlamasının temeli.
• DCGM Health Check: XID error 13/31/79/94 üretim donanım degradasyonunun en erken sinyalleri.
• NetworkPolicy: Tenant pod’ları arası lateral movement’ı engellemek için. Kubernetes Network Policy uygulanmalı.

Metrik	DCGM Exporter	Triton/vLLM	OpenTelemetry
GPU utilization %	Evet (per MIG)	Hayır	Hayır
VRAM kullanımı	Evet	Kısıtlı	Hayır
p99 inference latency	Hayır	Evet	Evet (trace)
Queue uzunluğu	Hayır	Evet	Span event
XID error	Evet	Hayır	Hayır
Tenant atribüsyonu	Label tabanlı	HTTP header	Trace context

Güvenlik tarafında MIG donanım izolasyonu çoğu compliance senaryosu için yeterlidir; ancak ENISA ve NIST raporları, multi-tenant AI altyapısında side-channel saldırılarının (özellikle cache-timing) hâlâ aktif araştırma alanı olduğunu vurguluyor. Time-Slicing’i regulated workload ile karıştırmayın — kanıtlanmış izolasyon yoktur. Container Güvenliği politikalarını GPU node’larına da uygulamak, attack surface’i sınırlamanın temel adımı.

Auto-scaling tarafında 2026 trendi KEDA + Karpenter kombinasyonu. KEDA inference queue uzunluğuna göre pod sayısını, Karpenter yeni GPU node’larını just-in-time provision’lar. MIG-aware Karpenter NodePool tanımları, node provisioning’i 60-90 saniyeye indiriyor — soğuk başlangıçtaki saldırgan dakika sayısını kesiyor. Cloud-native ölçeklendirme ilkeleri GPU katmanı için de geçerli.

2026 ve Sonrası: DRA, KAI Scheduler ve Heterogen Hızlandırıcılar

Kubernetes 1.32 ile birlikte Dynamic Resource Allocation (DRA) stabil seviyeye yaklaştı. DRA, GPU paylaşımı için fundamentally yeni bir abstraction sunar: pod, “MIG 1g.10gb” demek yerine “10 GB VRAM + 14 SM” ister, scheduler en uygun device’ı seçer. Bu, MIG profillerinin manuel yönetimini aşamalı olarak ortadan kaldıracak. NVIDIA k8s-dra-driver repository’sinde referans implementasyonu sürdürüyor.

Run:ai (NVIDIA’nın 2024 alımı) KAI Scheduler, fractional GPU allocation, gang-scheduling ve quota tabanlı tenant’lığı tek scheduler içinde sunuyor. 2026 itibarıyla NVIDIA AI Enterprise paketinde bileşen. MLOps workload’larında %20-30 daha yüksek cluster utilization raporlanıyor — vendor kaynaklı sayı, kendi cluster’ınızda doğrulamadan üretime sokmayın.

Heterogen hızlandırıcılar — AMD MI300X, Intel Gaudi 3, AWS Trainium 2, Google TPU v5p — Kubernetes’e device plugin veya CDI üzerinden katılıyor. AMD ROCm Kubernetes Plugin 2025’te paylaşım modlarını alpha seviyesinde sunmaya başladı. Stratejik soru: vendor lock-in. NVIDIA’nın MIG ve vGPU’su özel; multi-vendor cluster için CDI ve DRA standart abstraction üzerinden ilerlemek doğrusu. Multi-Cloud Stratejisi yazısı trade-off’ları detaylı işler.

İlerideki 18 ay için pratik tavsiye listesi:

1. Şimdi yap: MIG’i statik partitioning olarak üretimde tutun, node havuzu başına tek profil.
2. Staging’de dene: DRA driver’ı dev cluster’a kurun, 1-2 quarter test edin.
3. POC aç: KAI Scheduler için 2026 Q3 itibarıyla quota tabanlı tenant yönetimi denemesi.
4. Standartlara bağlı kal: Heterogen hızlandırıcı için CDI tabanlı operator — özel device plugin’ler 24 ay içinde gözden düşecek.
5. Ölç ve raporla: Tüm sharing kararları FinOps showback raporuna bağlanmalı.

Sık Sorulan Sorular (SSS)

Sonuç

Kubernetes’te GPU paylaşımı, 2026 itibarıyla artık opsiyonel bir optimizasyon değil; AI/ML iş yüklerini ekonomik olarak ölçeklemenin temel mekaniğidir. MIG donanım izolasyonu ve öngörülebilir p99 latency ile multi-tenant inference için altın standarttır. vGPU, MIG desteklemeyen kartlarda ve VDI/regulated VM senaryolarında doğru cevaptır. Time-Slicing ise dakikalar içinde kurulabilen, dev/test ve güvenilir dahili iş yükleri için maliyet-sıfır bir paylaşım modudur — ancak production SLA’lı API’larda kullanılmamalıdır.

Karar çerçevesi üç sorudan oluşur: Tenant’larım güvenilir mi? (Hayır → MIG/vGPU), Donanımım MIG destekliyor mu? (Hayır → vGPU veya HAMi), p99 latency SLA’m var mı? (Evet → asla Time-Slicing). Bu üç soruya verilen cevaplar mimari kararın %90’ını belirler. Geri kalan %10, DRA ve KAI Scheduler gibi gelmekte olan teknolojileri staging’de denemekten geçiyor.

İş yüklerinizin sharing stratejisini, gözlemlenebilirlik katmanını ve FinOps raporlamasını birlikte planlamak istiyorsanız iletişim sayfasından ulaşabilirsiniz. Mevcut cluster envanteriniz ve iş yükü mix’iniz üzerinden somut bir sharing/quota planı çıkarmak, tipik olarak 1-2 haftada ilk geri kazanım sinyalini verir.