Kubernetes'e gerçekten ihtiyacımız var mı? Tek sunucu, yönetilen konteyner ve sunucusuz arasında karar

Kubernetes bir olgunluk seviyesi değil, belirli bir problemin çözümü: bağımsız dağıtılabilir çok sayıda iş yükünü ortak bir makine havuzuna sıkıştırıp tek bir bildirimsel arayüzden yönetmek. Tek bir uygulaması ya da üç dört servisi olan ekiplerin çoğunda bu problem yok, dolayısıyla doğru cevap genelde sıkıcı bir sunucu ya da yönetilen bir konteyner platformu oluyor. Kararı üç soru belirliyor: kaç tane bağımsız dağıtılabilir parçanız var, hizmetiniz ayda kaç saat sıcak durmak zorunda, ve gece üçte kimin telefonu çalıyor. Fiyat listeleri bu üç cevabın sonucudur, başlangıç noktası değil.

Dört seçenek, dört farklı sahiplik sınırı

Seçim aslında bir teknoloji değil, sınır seçimi. Nereye kadarı sizin sorumluluğunuzda?

• Tek sanal sunucu. Makine sizin. İşletim sistemi yaması, ters vekil, sertifika yenileme, yedek ve geri yükleme tatbikatı sizde kalır.
• Yönetilen konteyner platformu. Sınır konteyner imajı. İmajı ve birkaç ayarı verirsiniz; kademeli geçiş, sağlık kontrolü, otomatik ölçekleme ve TLS platformun işidir. Cloud Run, Azure Container Apps, App Runner, Fly, Render bu kümede.
• Kubernetes. Sınır kümenin kendisi. Artık yalnızca uygulamanızı değil, uygulamanızı yöneten API'yi de işletirsiniz: sürüm yükseltmeleri, ingress denetleyicisi, depolama ve ağ eklentileri, kaynak istekleri.
• Sunucusuz fonksiyon. Sınır tek bir istek işleyicisi. Ölçekleme ve dayanıklılık sağlayıcıda, karşılığında uygulamanın biçimi kısıtlanır.

Bu bir merdiven değil. Alttan başlayıp yukarı çıkmak zorunda değilsiniz ve üstte olmak daha iyi mühendislik anlamına gelmiyor.

Kubernetes tam olarak hangi problemi çözer

Üç şeyi gerçekten iyi yapar: çok sayıda iş yükünü ortak bir makine havuzuna yerleştirmek, ölen şeyi bildirilen duruma geri getirmek, ve ekipler arasına kaynak, ağ ve yetki sınırı çizmek. Üçü de "çok sayıda" ile başlıyor. Bir web uygulaması, bir arka plan işçisi ve bir veritabanınız varsa yerleştirme problemi yoktur; yerleştirilecek tek bir şey vardır ve onu bir makineye kurmanın adı zamanlayıcı değil, kurulumdur.

Yoğun paketleme kazancının kendiliğinden gelmediğini de eklemek lazım. Cast AI'ın 2026 kaynak optimizasyonu raporu on binlerce üretim kümesinde ortalama CPU kullanımını %8, bellek kullanımını %20 buluyor; CPU aşırı tahsisi bir yılda %40'tan %69'a çıkmış, bellekte %79. Yani istenen kapasitenin büyük kısmı hiç kullanılmıyor. Kubernetes yoğun paketleme yapabilir, ama kaynak isteklerini kimse ölçüp daraltmadığı sürece yapmaz. Bu ölçümü yapmayacak bir ekip, mimari kazancı değil yalnızca faturayı satın alır.

Kontrol düzlemi ücreti, tek bir pod çalışmadan başlar

Amazon EKS'te küme başına saatte 0,10 dolar kontrol düzlemi ücreti var, ayda kabaca 73 dolar. Geliştirme, hazırlık ve üretim için üç ayrı küme açtıysanız tek bir iş yükü çalışmadan aylık 219 dolar. Google GKE aynı ücreti alıyor, ama faturalandırma hesabı başına ayda bir zonal ya da Autopilot kümenin ücretini karşılayan bir kredi tanıyor. Azure AKS'te ücretsiz kademede küme yönetimi bedava; karşılığında finansal taahhütlü çalışma süresi garantisi yok ve Microsoft bu kademeyi geliştirme ile test için, 10 düğümün altındaki kümeler için öneriyor. Üretim SLA'sı istiyorsanız ücretli kademeye geçmeniz gerekiyor.

Asıl kalemler bundan sonra geliyor: düğümler, yük dengeleyici, NAT geçidi, kalıcı diskler ve çıkış trafiği. Küçük bir işletme uygulamasının tamamı tek haneli euro seviyesinde bir sanal sunucuda dururken, aynı uygulama için açılan küme daha ilk gün üç haneli bir taban maliyet yaratır. Bu taban kötü bir şey değil, sadece bir karşılığı olması gerekiyor. Karşılık genelde şudur: birden fazla ekip, birden fazla bağımsız dağıtım hattı.

Yükseltme bir proje değil, abonelik

Kubernetes yılda üç minör sürüm çıkarıyor ve yalnızca en yeni üç minör dalı bakımda tutuyor. Bugün destekli sürümler 1.34, 1.35 ve 1.36; 1.34'ün ömrü 27 Ekim 2026'da, 1.35'in 28 Şubat 2027'de, 1.36'nın 28 Haziran 2027'de doluyor. Her minör sürüm kabaca bir yıl yama alıyor, yükseltme penceresiyle birlikte 14 ay. Pratik sonuç: kümeyi kuran ekip, yılda en az bir kez sürüm yükseltmesi yapmayı üstlenmiş olur.

Ertelemenin fiyatı da yazılı. EKS'te bir sürümün standart desteği 14 ay sürüyor, sonrasında küme otomatik olarak genişletilmiş desteğe geçiyor ve saat ücreti 0,10 dolardan 0,60 dolara çıkıyor. Altı katı, ayda kabaca 438 dolar, en fazla 12 ay için. Azure tarafında Premium kademe 24 aya kadar uzun dönem destek satıyor. İkisi de aynı şeyi söylüyor: "sonra yükseltiriz" bir teknik borç kalemidir ve bu kalemin faizi bu kez tahmin değil, liste fiyatı (teknik borcu ölçme ve önceliklendirme).

Sunucusuzda gerçek sınır fiyat değil, biçim

AWS Lambda'nın sabitleri kararı tek başına verecek kadar net:

• Fonksiyon zaman aşımı en fazla 900 saniye, yani 15 dakika.
• Bellek 128 MB ile 10.240 MB arası; 1.769 MB'de bir vCPU'ya denk güç alıyorsunuz.
• Senkron istek ve yanıt yükü 6 MB (akış yanıtlarında 200 MB), asenkron çağrıda 1 MB.
• Zip paketi açılmış halde 250 MB, konteyner imajı olarak 10 GB.
• Eşzamanlılık varsayılanı bölge başına 1.000 ve her yürütme ortamı saniyede 10 isteğe kadar hizmet veriyor. Yeni hesaplar daha düşük kotayla başlıyor.

Liste uzunluğuyla değil karakteriyle önemli: kısa ömürlü, durumsuz, tek istekle biten iş. AWS bu zarfı zaman içinde genişletti, artık sekiz saate kadar çalışabilen MicroVM'ler ve durumlu iş akışları için durable fonksiyonlar da var. Ama klasik fonksiyon biçimi aynı kaldı. 45 dakikalık bir toplu iş, 60 MB'lık bir rapor çıktısı ya da açık kalması gereken bir WebSocket bağlantısı varsa tartışma fiyatta değil, biçimde biter.

Soğuk başlangıç tartışması genelde yanlış yerde dönüyor

AWS'nin kendi dokümanı şunu yazıyor: soğuk başlangıçlar tipik olarak çağrıların %1'inden azında görülüyor, süresi 100 ms'nin altından 1 saniyenin üstüne kadar değişiyor ve geliştirme ile test fonksiyonlarında üretimden daha sık yaşanıyor, çünkü o fonksiyonlar daha seyrek çağrılıyor. Ortalama gecikme çoğu iş yükünde konu bile değil.

Konu iki başka yerde. Birincisi kullanıcının beklediği yolda kuyruk gecikmesi: ödeme adımında bir saniyelik p99, ortalamaya bakarak savunulamaz. Hazır tutulan eşzamanlılık bunu çözer, ama parayla ve sıfıra inme avantajını silerek. İkincisi veritabanı bağlantıları: her yürütme ortamı kendi bağlantı havuzunu açar, yüz eşzamanlı ortam yüz bağlantı ister ve sınıra ilk çarpan taraf veritabanı olur. Havuz yönetimi ve bağlantı sınırı tarafını veritabanı darboğazları yazısında ayrıntılandırdık.

Aylık saat hesabı kararın yarısını verir

Kural basit: iş yükünüz ayın büyük bölümünde sıcak durmak zorundaysa saniye başına ücretlendirme pahalıya gelir, trafik ani ve seyrekse ucuza gelir. Cloud Run vCPU-saniye ve GiB-saniye üzerinden faturalıyor ve istek yoksa sıfıra inebiliyor. İstek zaman aşımı varsayılan olarak 5 dakika, en fazla 60 dakikaya çıkıyor ve Google 15 dakikanın üstündeki değerler için isteklerin idempotent olmasını ya da kaldığı yerden devam edebilmesini öneriyor. Bu öneri tek başına bir mimari uyarıdır: uzun işler istek içinde değil, kuyrukta yapılır.

Pratik test şu. Hizmetin ayda kaç saat gerçekten iş yaptığını yazın. Ayın 730 saatinin tamamı ise kiraladığınız şey bir sunucudur, adı ne olursa olsun, ve ayrılmış kapasite fiyatı neredeyse her zaman daha ucuzdur. Ayın %5'i ise sürekli ayakta duran bir düğüm için ödediğiniz paranın büyük kısmı boşa gidiyor. Faturanın hangi kalemlerde biriktiğini bulut maliyetini kalıcı düşürme yazısında kalem kalem anlattık.

Çoğu ekip için doğru cevap yönetilen konteyner

Buradan çıkan varsayılan öneri sade: bir Dockerfile, bir imaj, bir adres. Kademeli geçiş, sağlık kontrolü, otomatik ölçekleme, TLS ve log toplama hazır gelir; yükseltmeniz gereken bir API sunucusu olmaz. Bir servisten beşe çıkmak yeni bir platform öğrenmek anlamına gelmez, çünkü beşinci servis de sadece başka bir imajdır.

Sınırları da net. Servisler arası ağ ilkelleri sınırlıdır, yardımcı süreç (sidecar) desteği her platformda yoktur, ölçekleme ve kimlik ayarları sağlayıcıya özgüdür. Tek kural bunu yönetilebilir tutuyor: imaj taşınabilir kalsın, yapılandırma ortam değişkeninde dursun, yerelde docker run ile çalışan bir yol her zaman bulunsun. Sondalar, kapanış sırasında biten istekler ve şema değişikliklerinin sırası yine sizde kalır; o tarafı sıfır kesintili yayına alma yazısında topladık.

Tek sunucu utanılacak bir şey değil, ama beş maddesi yazılı olmalı

systemd, bir ters vekil ve bir dağıtım betiğiyle yıllarca ayakta kalan üretim sistemleri var. Bu seçeneği savunulabilir yapan şey basitliği değil, şu beş maddenin var olması: makineyi sıfırdan aynı şekilde kuran bir imaj veya betik, otomatik işletim sistemi yaması, gerçekten geri yükleme denemesi yapılmış yedek, gerektiğinde terfi ettirebileceğiniz ikinci bir makine, ve bir alarm üreten temel izleme. Beşinden biri eksikse tek sunucu ucuz değil, sadece maliyeti ertelenmiş olur.

İki uyarı. Birincisi güvenlik: yönetilen platformda çalışma zamanının yamasını sağlayıcı yapar, tek sunucuda çekirdek ve kütüphane yaması sizde kalır. Paylaşılan sorumluluk çizgisinin tam olarak nerede durduğunu bulut yapılandırma hataları yazısında ele aldık. İkincisi fiyat: ucuz sunucu listeleri sabit değil, Hetzner 15 Haziran 2026'da yeni siparişler ve yeniden boyutlandırmalar için fiyat listesini güncelledi. Bir sağlayıcının bugünkü fiyatı üzerine iş modeli kurmayın.

Kendi donanımına dönmek: 37signals örneği neyi kanıtlıyor

En çok konuşulan örnek 37signals. 2022'de yıllık bulut faturası 3,2 milyon dolardı. 2023'te yaklaşık 700 bin dolarlık Dell donanımı aldılar ve altı ayda yedi uygulamayı buluttan çıkardılar. 2024'te fatura 1,3 milyon dolara indi, yani yaklaşık 2 milyon dolar tasarruf. Kurucusu beş yıllık tasarrufun 10 milyon doları geçeceğini yazdı ve 2025'te kalan S3 yükünü de 18 petabaytlık kendi flash depolamalarına taşıdılar.

Bu örnek şunu kanıtlıyor: yük öngörülebilir ve büyükse, sahip olmak kiralamayı yenebilir. Şunu kanıtlamıyor: bu işi yapan ekipte donanım yaşam döngüsünü sahiplenen insanlar, kendi dağıtım araçları ve iki ayrı veri merkezi var. Aylık faturası dört haneli olan bir ekip aynı hesabı çıkaramaz, çünkü oradaki en pahalı kalem donanım değil, dikkat. Bulut faturası aylık on binlerce dolara ulaşmış ve trafiği düz bir çizgiyse hesabı yapmaya değer; bunun altında değmez.

Kilit hangi katmanda oluşuyor

Taşınabilirlik sırası kabaca şöyle: konteyner imajı her yere gider, Kubernetes manifestleri gider ama yönetilen eklentiler (ingress denetleyicisi, kimlik entegrasyonu, depolama sürücüleri) gitmez, sunucusuz işleyiciler ile olay bağlamaları ise en az taşınabilir olanıdır. Bu bir yasak listesi değil, bir bütçe kalemi: seçtiğiniz katman, üç yıl sonra taşınmak isterseniz ödeyeceğiniz bedeli belirliyor.

Maliyeti düşük tutmanın yolu sınırı kodda çizmek. İş mantığını sağlayıcı SDK'sının içine değil, bir arayüzün arkasına yazın; kuyruk, depolama ve zamanlayıcı çağrılarını tek bir yerde toplayın. Böyle yazılmış bir uygulamada platform değişikliği bir taşıma projesi olur, yeniden yazma olmaz.

Bu haftaya sığan ilk adım

Beş satır yazın. Bir: kaç tane bağımsız dağıtılabilir parçanız var, gerçekten ayrı ayrı yayına çıkıyorlar mı? İki: hizmet ayda kaç saat sıcak durmak zorunda, tepe trafik ortalamanın kaç katı? Üç: gece üçte kimin telefonu çalıyor ve o kişi neyi düzeltmeye yetkili? Dört: sürüm yükseltmelerinin sahibi kim, takvimi ne? Beş: bu platformdan çıkmanız gerekirse taşınacak şeylerin listesi ne kadar uzun?

İkinci ve üçüncü sorunun cevabı yoksa platform seçimi zaten erken; önce ölçüm ve nöbet düzeni gelir (izlenebilirlik, SLO ve hata bütçesi). Birinci sorunun cevabı "bir" ise mimari tartışmasını mikroservis tarafına taşımadan önce monolit mi mikroservis mi yazısına bakın, çünkü Kubernetes ihtiyacı genelde oradan doğar. Hangi platformu seçerseniz seçin, tek makineli bir kurulumda bile yayına almayı otomatikleştirmek en yüksek getirili adım olarak kalıyor (küçük ekipler için CI/CD).