Küçük bir detay: Kubernetes tarafında yıllardır aynı hikâye dönüp duruyor. Gözlemleme, güvenlik, trafik yönetimi… derken pod başına bir sidecar daha. Bir bakıyorsunuz Envoy gelmiş, ardından Prometheus scrape ediyor, üstüne de trace ajanı eklenmiş — cluster şişiyor da şişiyor. Açık konuşayım: bu işin faturası çoğu zaman ilk anda görünmüyor (şaşırtıcı ama gerçek). Ta ki node sayısı artıp RAM hesabı kabusa dönüşene kadar. Sonra herkes birbirine bakıyor.
Ben bu konuyu ilk kez 2024 yazında, İstanbul’daki küçük bir fintech ekibiyle konuşurken ciddiye aldım. Ellerinde 180 civarı pod vardı ve “neden sürekli daha büyük node alıyoruz?” sorusu masanın üstünde öylece duruyordu. Asıl mesele uygulama değilmiş meğer; uygulamanın etrafına ördükleri sidecar çemberiymiş. İşte eBPF tam da burada sahneye çıkıyor. Bayağı sert bir soru soruyor: Bu yükü gerçekten hâlâ pod’un içine mi koyacağız?
Sidecar vergisi neden can yakıyor?
Sidecar modeli ilk çıktığında mantıklıydı (şaşırtıcı ama gerçek). Uygulamanın yanına küçük bir yardımcı servis koyuyorsun; log topluyor, trafiği yönlendiriyor, güvenlik katmanı sağlıyor. Güzel fikir. Fena değil hatta. Siz ne dersiniz? Ama pratikte her şeyin bedeli var — ve o bedel çoğu zaman RAM olarak geri geliyor, hem de faizli.
İşte tam da bu noktada devreye giriyor.
Araya gireyim: Mesela Istio kullanan yapılarda Envoy proxy’nin bellek tüketimi kullanım şekline göre ciddi değişiyor; küçük bir test ortamında sorun gibi görünmeyen bu durum, 300-500 pod bandına gelince resmen bütçe kalemi oluyor ve o noktada “biz izlenebilirlik için kurmuştuk bunu” açıklaması pek teselli etmiyor. Ben bunu 2023’te Ankara’da — kendi adıma konuşayım — bir SaaS firmasında bizzat gördüm. Ekip geç fark etmişti.
İşin can sıkıcı yani şu: sidecar arttıkça sadece RAM değil, operasyonel karmaşa da büyüyor. Daha fazla container demek daha fazla config demek. Daha fazla config de daha çok hata noktası demek. Hani bazı günler sistemi yönetmekten çok sistemi sakinleştirmeye çalışırsınız ya — tam öyle.
| Yaklaşım | Artısı | Eksiği |
|---|---|---|
| Sidecar tabanlı mimari | Ayrık sorumluluklar, olgun araç desteği | Yüksek RAM kullanımı, karmaşık bakım |
| eBPF tabanlı yaklaşım | Daha az kaynak tüketimi, kernel seviyesinde görünürlük | Sürücü/kernel uyumu hassas olabilir |
Cilium, Hubble ve Tetragon üçlüsü ne veriyor?
Lafı gevelemeden söyleyeyim. eBPF dünyasında en çok öne çıkan paketlerden biri Cilium oluyor — ve bunu sadece CNI olarak düşünmek eksik kalır, çünkü ağ politikalarıyla birlikte görünürlük de veriyor, ikisi bir arada. Hubble ise bunun izleme tarafını tamamlıyor. Servislerin birbirine nasıl bağlandığını görmek için adeta canlı harita gibi davranıyor; bazen dashboard’a bakınca “aa, bu servis buna mı bağlanıyormuş?” dediğiniz oluyor.
Tetragon kısmı biraz daha can alıcı tarafta duruyor (kendi tecrübem). Çünkü burada iş sadece gözlemlemek değil — runtime güvenliği devreye giriyor. Kernel seviyesinde olayları görüp gerekirse müdahale edebilmesi önemli bir fark yaratıyor, özellikle kurumsal ortamlarda (ben de ilk duyduğumda şaşırmıştım). Falco ile kıyaslayanlar çok olur ama açıkçası Tetragon’un kernel’e yakınlığı bende hep ayrı bir etki bırakmıştır (evet, doğru duydunuz). Hani ne farkı var diyorsunuz, değil mi? Neden tam olarak bilmiyorum, sezgisel bir şey belki.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Beyla’yı da unutmamak lazım. Grafana ekosisteminin bu aracı özellikle OpenTelemetry akışına güzel oturuyor, çünkü manuel SDK enjeksiyonu olmadan span üretebiliyor. Ben bunu geçen ay İzmir’de çalışan iki kişilik bir platform ekibinde denedim; adamların yüzündeki rahatlamayı görmeniz lazımdı, çünkü uygulama koduna dokunmadan trace almak onlar için tam nefes oldu. İki kişiyle platform yönetiyorsanız her dakika değerli. Anthropic’in Yeni Ajan Mimarisi: Beyin ve Eller Ayrılıyor yazımızda bu konuya da değinmiştik. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
eBPF’nin asıl cazibesi “her şeyi yeniden paketleyelim” dememesi. Kod değiştirmeden görünürlük vermesi güzel… ama sihir değil; kernel sürümü uyumu ve doğru dağıtım stratejisi hâlâ işin yarısı.
Nerede iyi çalışır?
Küçük startup’larda eBPF’nin en büyük faydası hız oluyor. Bir ekip düşünün: üç geliştirici var, SRE yok denecek kadar az ve her saat başı yeni özellik çıkarmaya uğraşıyorlar. Böyle bir yerde sidecar’la uğraşmak gerçekten lüks kaçabiliyor — hem teknik hem de zaman açısından.
Hani, Büyük kurumlarda ise mevzu başka yere kayıyor. Standartlaşma. Maliyet kontrolü ön plana çıkıyor; enterprise tarafta birkaç bin pod üzerinde yüzde onluk kaynak tasarrufu bile ciddi para ederken eBPF yaklaşımı oldukça cazip hale geliyor. Hesabı yapınca “aa, bu kadar mı?” diyorsunuz.
Migrasyon yaparken nereden başlanır?
Garip gelecek ama, Bence en yanlış hareket doğrudan prod’u çevirmek olurdu. Ben olsam önce staging’de denerdim — ve gerçekten denerdim, yani “kurduk oldu” kafasıyla değil, beklerdim, izlerdim, karşılaştırırdım. Geçen sene Kasım ayında İstanbul Maslak’taki bir perakende projesinde buna benzer geçiş planını inceledim; ekip önce yalnızca network visibility katmanını açtı. Haftalar içinde metrikler toparlandı. Yavaş ama sağlam. Bu konuyla ilgili Flux-2-Pro Neden Dikkat Çekiyor? Görsel Üretimde Dengeli Güç yazımıza da göz atmanızı tavsiye ederim.
Aşağıdaki sıra fena değil: Bu konuyla ilgili Nava’nın 22 Milyon Dolarlık Sıçraması: AI Bulutu Nereye Gidiyor? yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
- Cilium’u staging’e kurup mevcut CNI ile karşılaştırma yapmak
- Hubble UI üzerinden servis grafiğini okumak
- Tetragon ile kritik dosya erişimleri ve yetki yükseltme denetimleri tanımlamak
- Beyla’yı paralel çalıştırıp trace tutarlılığını kontrol etmek
- Tam geçişten önce dashboard’ları oturtmak
# Örnek kontrol komutları
uname -r
kubectl get pods -A
cilium status
hubble observe
tetragon status
beyla --help
}Şu ufak detaya bakın: yerler
Eh, Kernel sürümü meselesini hafife almayın. Linux çekirdeği eskiyse bazı eBPF özellikleri istediğiniz gibi çalışmayabiliyor — ve bu da sizi gece yarısı debug seansına itiyor. Kimsenin sevmediği türden işte. Sabah toplantısına yorgun girmek zorunda kalmadan önce bunu test edin.
İlginç olan şu ki, Bir de veri tutarlılığı konusu var. Eski tracing altyapısıyla yeni OTel akışını aynı anda yürütürken çift kayıt ya da eksik span görebilirsiniz. O yüzden cutover işlemini tek hamlede yapmak yerine kademeli ilerlemek çoğu zaman daha sağlıklı oluyor — aceleye gerek yok.
Maliyet düşüşü kağıt üstünde mi kalır?
Kâğıt üstünde herkes tasarruf anlatır zaten. Asıl mesele bunun gerçek hayatta karşılık bulup bulmadığı. Sidecar yükünü azaltınca node ölçeğinde nefes alan boşluk oluşuyor — bu kısım gerçek, yaşanan bir şey. Benzer tabloyu kendi test laboratuvarımda da gördüm; Ekim 2024’te Berlin’deki bir demo cluster’da yalnızca izleme bileşenlerini sadeleştirerek toplam bellek tüketimini hissedilir biçimde aşağı çekmiştik. Peki bunu neden söylüyorum? Rakam vermek istemiyorum ama etkileyiciydi.
Peki hiç mi dezfayda yok? Var tabi. Kernel bağımlılığı bazen can sıkabiliyor, özellikle heterojen node havuzlarında — bir node’da çalışıyor, diğerinde çalışmıyor, sonra saatlerce neden diye bakıyorsunuz. Ayrıca ekip alışkanlıkları değişmeden teknoloji tek başına mucize yaratmıyor; insanlar hâlâ “bu log nereye gitti?” diye sorarsa süreç yine tıkanır.
Kimin için uygun?
- Küçük startup: Az personelle hızlı görünürlük isteyen ekipler için birebir olabilir.
- Büyüyen SaaS şirketi: Node maliyetini baskılamak isteyen takımlar için ciddi avantaj sağlar.
- Kurum içi platform ekibi: Standardizasyon ve policy enforcement ihtiyacı varsa oldukça mantıklıdır.
Sahada beni ikna eden şey neydi?
Editör masasında bu haberi okuduğumda ilk refleksim şuydu: “Tamam da gerçekten işe yarıyor mu?” Sonra kendime haksızlık ettiğimi düşündüm — çünkü soru artık teknik yeterlilikten çok operasyonel değere dönmüş durumda. İkinci kez düşününce evet dedim. Esas mesele kodu değiştirmeden kazanım almakta yatıyor. Bu küçük bir şey değil aslında.
Evet, sidecar büyük ölçüde bitecek demek fazla iddialı olurdu. Bazı mimarilerde hâlâ anlamlılar. Ama dürüst olmak gerekirse birçok gözlemleme senaryosunda artık o ağır topa ihtiyaç duymadığınız açık. Bazen en iyi çözüm daha fazla parça eklemek değil — tam tersine, gereksiz parçayı sökmek oluyor.
Sıkça Sorulan Sorular
EＢPＦ Kubernetes’te sidecar ihtiyacını tamamen bitirir mi?
Tamamen bitirmez ama birçok observability ve security senaryosunda sidecar sayısını ciddi biçimde azaltır. Bilhassa network visibility,trace toplama ve runtime security tarafında güçlüdür.
Cilium kullanmak için hangi kernel sürümü gerekir?
LTS seviyesinde en az 5.10 önerilir,6.1 ve üzeri ise genelde daha rahat sonuç verir. Üretime geçmeden önce tüm node’larda ? Hayır—önce düzgünce doğrulama yapın diyelim.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
