Kubernetes'te GPU ve 2 GB'lık sunucu: küçük işletmeye Docker Compose neden yetiyor

Bu hafta CNCF ve Netflix, Kubernetes hakkında dört teknik inceleme yayınladı: GPU'yu kiracılar arasında nasıl bölüştürmeli, autoscaler ile zamanlayıcı düğümün biçimi konusunda neden anlaşamıyor, Netflix konteynerleri otomatik olarak nasıl küçültüyor ve Kyverno Linux çekirdeğine nasıl taşınıyor. Bunların hepsi yüzlerce ekibi olan şirketlerin sorunlarını çözüyor. Küçük işletme sahibine buradan başka bir şey yarar: bu sorunlardan hangilerinin kendisinde gerçekten olduğunu anlamak ve geri kalanının çözümüne para ödememek.

Ne çıktı

CNCF 23 Ekim'de iki açık projeden oluşan bir laboratuvar gösterdi. Kamaji, her kiracının Kubernetes kontrol katmanını tek bir ortak kümenin içinde pod olarak çalıştırıyor; HAMi ise pod'un GPU'nun bir parçasını istemesine izin veriyor: belleği megabayt, hesaplama payını yüzde olarak. Yazar sorunu ilk paragrafta anlatıyor: Kubernetes GPU'yu bütün olarak veriyor ve 80 GB'lık karttan 4 GB'a ihtiyacı olan pod kartın tamamını kaplıyor. Yazar her şeyi fiziksel GPU olmadan, HAMi'nin mock eklentisiyle, 4 çekirdek ve 8 GB bellekli tek bir makinede kurdu.

CNCF 19 Ekim'de bölgede kapasite varken GPU'lu bir pod'un neden beklemede kalabildiğini açıkladı. Zamanlayıcı pod'u mevcut düğüme yerleştiriyor, autoscaler düğüm ekliyor ve on yıl boyunca bu iki döngünün birbiriyle anlaşmasına gerek olmadı. Hızlandırıcılarla birlikte autoscaler yanlış biçimde düğüm ekliyor, zamanlayıcı da pod'u oraya koymuyor. Topluluğun yanıtı Dynamic Resource Allocation: “2 GPU lazım” sayısı yerine pod yapılandırılmış bir talep tanımlıyor.

Netflix 14 Ekim'de Stratum Resource Tuner'ı anlattı. Video işleme platformu günde yüz binlerce konteyner başlatıyor, her fonksiyonun limitlerini ise sahipleri YAML'da belirliyor: 8 CPU, 18.000 MB bellek, 50.000 MB disk. Bu sayılar genellikle komşu fonksiyondan kopyalanıyor ve ne olur ne olmaz diye yüksek tutuluyor. Tuner gerçek tüketimi topluyor, öneri veriyor, öneriyi deneyle doğruluyor, uyguluyor ya da reddediyor ve sonra fonksiyonu izlemeye devam ediyor. Gecikmeden korkmayan yüklerle başlamışlar: tüketimin %70-80'i onlardan geliyor.

CNCF 15 Ekim'de Kyverno için Nirmata Runtime'ı anlattı. Sıradan Kyverno manifest'i girişte kontrol ediyor: pod doğru tanımlanmış mı. Yeni parça çekirdekte eBPF ve LSM üzerinden çalışıyor ve başka bir soruya yanıt veriyor: pod söz verdiğini mi yapıyor. Her politika önce gözlem modunda çalışıyor ve neyi yasaklayacağını gösteriyor. Yazıdaki örnek tam da ajanlarla ilgili: pod'a yalnızca modele giden iç ağ geçidine izin var, kimlik bilgisi dosyalarını okumak yasak, ve ajanın içindeki prompt injection bu yasağı aşamıyor, çünkü yasak ajanın sürecinde yaşamıyor.

Bu sorunlardan hangileri küçük işletmede var

Bir araç kiralama şirketi düşünelim. Rezervasyonlu bir sitesi, CRM entegrasyonlu bir backend'i ve yöneticiler için bir uygulaması var: üç dört konteyner ve bir iki geliştiriciden oluşan tek bir ekip. Kontrol katmanı izole edilmesi gereken kiracı yok. GPU yok. Autoscaler gerekmiyor, çünkü yük belli: günde onlarca rezervasyon.

Dört yazıdan böyle bir şirketi ilgilendiren iki düşünce var. İlki Netflix'ten: konteyner limitleri “payla” konuluyor ve bir daha dokunulmuyor, sonra bellek en uygunsuz anda bitiyor. İkincisi Nirmata'dan: konteyner yalnızca ona ait olanı görmeli ve bu kural boyuta bağlı değil. Geri kalanı üç konteynerin sahip olmadığı sorunları çözüyor, Kubernetes ise üstüne birinin güncelleyip onarması gereken bir kontrol katmanı ekliyor.

Bende nasıl kurulu

Eylül ve Ekim 2026'da tasarlayıp yaptığım “Birlikte Kahve” adlı iç servis ile sitem kononov.dev, 2 GB bellekli ortak bir sunucuda, Nginx arkasında Docker'da yaşıyor. Sunucu küçük, bu yüzden konteynerlerin sıkı bellek limitleri var ve güncellemede eski kopya yenisi başlamadan önce durduruluyor. Derlemeye bellek yetmezse imaj sunucu dışında derlenip hazır olarak yükleniyor. Servis çalışanlara ve yöneticilere ayda 100 saatten fazla kazandırıyor ve bunun için orkestratör gerekmedi.

ABD'deki PDR şirketinde görev daha büyük: 2022'den beri Google Cloud'daki kendi Debian sunucusunda MariaDB, API, site ve kendi PBX'leri üzerinde telefon sistemi çalışıyor, şirkette 30'dan fazla kişi var. Bu yığında Kubernetes yok ve 2022'den beri kurtarma gerektiren ciddi bir arıza olmadı. Bu ölçekte kaynakları elle paylaştırmak daha kolay, otomatik tuner'a gerek yok.

Ben ne yapardım

Konteynerleri ve ekipleri saymak. Tek ekip ve ondan az servis: tek sunucu, Nginx arkasında Docker Compose ya da benzeri basit bir çalıştırma. Kubernetes'e geçişi, farklı yetkilere sahip birkaç ekip, GPU ya da gün içinde kat kat değişen yük ortaya çıkınca konuşmak.

Her konteynere bellek limiti koymak ve yük altında kontrol etmek. Altı ay sonra gözden geçirmek: bu, Netflix tuner'ının elle yapılan versiyonu.

Güncellemede ne olacağına karar vermek. Küçük sunucuya iki kopya sığmaz, demek ki eski kopya yenisi başlamadan önce duruyor ve bunu önceden bilmek gerekiyor.

Sunucuda bellek azsa imajı başka bir makinede derlemek.

Nirmata yazısındaki ilkeyle konteynerin ağını ve secret'larını kısıtlamak: yalnızca iş için gereken adresler ve dosyalar. Bunun için eBPF gerekmez, Docker ağı ve ortam değişkenleri yeter.

İlgili içerikler

Sistemin merkezi olarak sunucuyu Sunucu: veri, erişim ve sürecin yürütülmesi yazısında anlattım. Alan: yayınlanabilen ve kurtarılabilen altyapı. Vakalar: 2 GB'lık sunucuda ortak kahve siparişi servisi ve 2021'den beri PDR şirketinin teknik ortağı. Diğer incelemelerden: 20 dolarlık kendi sunucunuz platformdan ne zaman daha kârlı, 30 kişilik şirket için zero trust ve tek sunuculu sisteme ne kadar gözlemlenebilirlik gerekir. Daha önce ortak GPU havuzu ve ona kuyruk hakkında yazmıştım. Size üç konteyner için Kubernetes öneriliyorsa, şu anda neyin çalıştığını ve kaç kişinin onu sürdürdüğünü anlatın. Görevi konuşalım.