eBPF ve Cilium ile Kubernetes Ağı 2026: Network Observability ve Performans Mimarisi

2026 itibarıyla Kubernetes ekosisteminin en hızlı büyüyen alt katmanı eBPF (extended Berkeley Packet Filter) ve onun network/security uygulamalarıdır. CNCF 2026 Annual Survey’e göre Kubernetes kullanan organizasyonların %48’i en az bir eBPF tabanlı araç (Cilium, Falco, Pixie, Tetragon) üretimde çalıştırıyor. eBPF, Linux kernel’i içine güvenli kod enjekte etme yeteneğiyle, klasik iptables/sidecar yaklaşımına göre 3-7x daha hızlı ağ trafiği, %84 daha az bellek ve kernel seviye observability sağlar. Türkiye’de büyük ölçekli Kubernetes işleten şirketlerin %37’si 2025-2026 döneminde Calico → Cilium veya kube-proxy → Cilium replacement geçişi yaptı.

Bu rehberde eBPF’in Cilium ile Kubernetes ağında nasıl kullanıldığını, security observability senaryolarını, üretim performans rakamlarını ve Türkiye özelinde geçiş notlarını somut sayılarla aktaracağız.

eBPF Nedir? Neden Önemli?

eBPF, Linux kernel’in içine kullanıcı kodu çalıştırmasını mümkün kılan bir teknolojidir. Kernel modülü yazmadan, kernel restart etmeden ağ paketleri, system call’lar, dosya işlemleri ve bellek erişimi gibi olayları yakalayıp programlanabilir tepki üretir. “JavaScript-for-kernel” benzetmesi yaygındır. Avantajları:

• Kernel hızında çalışır (user-space switch yok).
• Sandbox + verifier ile güvenli (yanlış kod kernel’i çökertmez).
• Klasik iptables kuralından 3-7x daha hızlı.
• Daha az bellek (sidecar’sız mimari).
• L3-L7 visibility (HTTP, gRPC, Kafka, DNS).
• Dinamik yükleme — node restart gerekmeden policy güncellenir.

eBPF, sadece network için değil; observability (Pixie), security (Falco/Tetragon), profiling (Parca) ve hatta workload acceleration (XDP) için kullanılıyor. Türkiye’deki ekiplerde gözlemlediğim ortak şaşkınlık: eBPF “yeni bir teknoloji” sanılır ama 2014’ten beri Linux kernel’de mevcut; sadece son 3 yılda araç ekosistemi olgunlaştı.

Cilium: eBPF Tabanlı CNI

Cilium, Kubernetes Container Network Interface (CNI) projesi olarak başladı, 2025’te CNCF’in graduated projesi oldu. 2026 itibarıyla AWS EKS, Google GKE, Azure AKS managed varsayılan CNI seçeneklerinden biri. Türkiye’de büyük ölçek Kubernetes işleten ekiplerin önemli bir kısmı (e-ticaret, fintech, telco) Cilium’a geçmiş durumda.

Yetenekler

• Cilium Network Policy: L3-L7 (HTTP path, Kafka topic, gRPC method) bazlı erişim kontrolü.
• Cilium Service Mesh: Sidecar’sız mesh (Envoy + eBPF). Bellek %84 daha az.
• Hubble: Network observability — her servis arası trafik gerçek zamanlı görünür.
• Cluster Mesh: Multi-cluster service discovery.
• Cilium Cluster Pool IPAM: Geniş IP havuzu yönetimi.
• BGP integration: On-prem network entegrasyonu.
• Gateway API: Kubernetes Gateway API’nın eBPF-tabanlı implementasyonu.

Cilium ile derinleşmek için Cilium ve eBPF Kubernetes network rehberini okumanızı öneririm — kurulum komutları ve YAML örnekleri ile birlikte. Multi-cluster setup için ise Kubernetes multi-cluster karşılaştırmamıza bakabilirsiniz.

Performans Karşılaştırması

CNI	Throughput	Latency p99	CPU/Gbps
Cilium (eBPF)	96 Gbps	0,3 ms	%2,1
Calico (iptables)	72 Gbps	0,8 ms	%4,8
Flannel (VXLAN)	48 Gbps	1,2 ms	%6,4
kube-proxy (default)	52 Gbps	1,1 ms	%5,9

Hubble: Network Observability

Hubble, Cilium’un observability katmanı. Klasik observability araçları sadece uygulamanın gönderdiği bilgiyi gösterir; Hubble doğrudan kernel’den ağ trafiği yakalar. Avantaj:

• Hiçbir uygulama kod değişikliği gerekmez.
• Service map otomatik üretilir.
• DNS sorguları, HTTP istekleri, mTLS handshake’leri görünür.
• Drop edilmiş paketlerin sebebi (policy ihlali, çakışma, vs).
• Grafana entegrasyonu.
• Flow logs cardinality kontrolü ile maliyet düşük.

Network Policy: L7 Erişim Kontrolü

Klasik Kubernetes Network Policy sadece L3-L4 (IP+port) seviyesinde. Cilium L7 seviyede çalışır:

• HTTP path bazlı: “frontend sadece api/orders/* erişebilir, api/admin/* yasak”.
• HTTP method: “service-A sadece GET yapabilir, POST yapamaz”.
• gRPC method: “Order.Create izinli, Order.Delete reddedildi”.
• Kafka topic: “service-B sadece orders-topic’e produce yapabilir”.
• DNS: “Pod sadece github.com’a outbound bağlanabilir”.
• FQDN allowlist: Egress trafiği için DNS-based whitelist.

L7 policy’ler özellikle zero-trust mimariye geçişte kritik. Tamamlayıcı policy katmanı için Open Policy Agent (OPA) + Rego kullanımı incelenebilir.

eBPF Tabanlı Güvenlik (Tetragon)

Cilium ekosistemi içinden Tetragon, runtime security gözlem aracı:

• Her container’ın çalıştırdığı her komutu (execve syscall) gözlemler.
• Dosya erişimi (open, read, write) izlenir.
• Network bağlantısı (connect, accept) loglanır.
• Privilege escalation (setuid, capability change) yakalanır.
• Şüpheli pattern’lar real-time alert.
• Audit + enforce mode — sadece logla veya doğrudan engelle.

Avantaj: Falco’ya göre %70 daha az CPU, %50 daha düşük overhead. KVKK/PCI-DSS uyum süreçlerinde “her admin komutu kayıtta” garantisi pratik bir delil sağlar.

Üretim Kurulum Notları

Kernel Gereksinimleri

• Linux kernel ≥ 5.10 (5.15+ tercih).
• BPF helper functions enabled.
• CONFIG_BPF_SYSCALL=y, CONFIG_NET_CLS_BPF=y.
• Ubuntu 22.04 LTS / Debian 12 / RHEL 9 doğrudan uyumlu.
• AKS/EKS/GKE node image versiyonları kontrol edilmeli (eski LTS’lerde feature eksik).

Cilium Kurulum Modları

• Standard mode: Tradicional CNI, kube-proxy ile birlikte.
• kube-proxy replacement: kube-proxy yerine eBPF — daha hızlı.
• Native routing: Encapsulation yok (VXLAN/Geneve gerekmez).
• Cluster mesh: Multi-cluster, multi-region.
• Tunnel mode (VXLAN): Network izole yer ve VLAN sınırlamalı ortamlarda.
• Gateway API mode: Modern Ingress yerine Gateway API.

Türkiye Özelinde Geçiş Notları

• On-prem network ekipleri: Cilium BGP entegrasyonu kullanırken network ekibinin BGP peering izni vermesi gerekir; bu çoğu kurumda 2-4 hafta süren bir koordinasyon.
• Calico → Cilium geçişi: Big-bang yerine new node pool + workload migration ile sıfır kesinti yapılabilir.
• Bank/finans uyum: BDDK ve KVKK uyumu için Tetragon “her admin komutu audit trail” özelliği güçlü argüman.
• RHEL 7 / CentOS 7: Hâlâ üretimde olan eski node’larda kernel yetersiz — node refresh zorunlu.
• Vendor desteği: Isovalent Türkiye’de partner yok; doğrudan EU desteği veya self-managed gerekiyor.

Bilinen Sorunlar ve Çözümleri

• Kernel debug zorluğu: bpftool ve bpftrace ile.
• Eski kernel: Bazı features (TPROXY) kernel 5.7+ gerektirir.
• Multi-CNI çakışması: Cilium + Calico birlikte yaşatma zor — biri tercih edilmeli.
• Sertifika rotasyonu: Hubble’da TLS sertifikası otomatik yenilenmiyor (manuel).
• Resource taşma: Çok sayıda L7 policy, agent memory artırabilir.
• Conntrack table fill: Yüksek bağlantı sayısında kernel conntrack tablosu doldurma riski — tuning gerekli.

Maliyet Etkisi

• Cilium open source — lisans 0 TL.
• Isovalent Enterprise (commercial support) — node başına 800-2.000 USD/yıl.
• iptables → eBPF geçişi: %30-40 ağ trafiği CPU tasarrufu = orta ölçek cluster’da yıllık 200-400K TL kazanç.
• Sidecar service mesh → eBPF mesh: bellek %84 düşüş = 100 servisli cluster’da 20-50 GB RAM tasarrufu.
• Falco → Tetragon geçişi: monitoring overhead %50 düşer.

Sık Sorulan Sorular

Ömer Önal’dan pratik not: Türkiye’de Cilium geçişi yaptığım ekiplerde gördüğüm en sık hata, “öğleden sonra kuralım, çalışır” iyimserliği. Cilium kurulumun teknik kısmı 1 saatlik iş; ama doğru kurulum projesi 4-6 hafta sürer. Çünkü: network ekibi BGP onayı (2 hafta), staging’de load test (1 hafta), workload-by-workload network policy yazımı (2-3 hafta), production canary rollout (1 hafta). Bu fazları atlayan ekiplerde “neden bazı pod’lar başkalarıyla konuşamıyor” tipi 3 günlük outage’lar oluyor. Cilium gücünü Network Policy + Hubble + Tetragon ile zero-trust mimariye dönüşünce gösterir; sadece CNI olarak kurmak eski iptables’la benzer kalır. Sizin cluster’ınızda Cilium hangi seviyede kullanılıyor — sadece CNI mi, yoksa Hubble + L7 policy + Tetragon kombinasyonu mu aktif?

Sonuç

eBPF + Cilium, Kubernetes ağ ve gözlemlenebilirlik katmanını yeniden tasarlıyor. Doğru kurulumda ağ throughput’u %33 artırır, CPU kullanımını %56 azaltır, observability’i uygulama kod değişikliği olmadan sağlar. 2026’da bulut-yerlisi Kubernetes kullanıcıları için varsayılan tercih. Tamamlayıcı içerikler: event-driven mimari, gRPC vs REST vs GraphQL, polyglot persistence ve database sharding. İletişim formundan projeniz için Kubernetes mimari değerlendirme talep edebilirsiniz.

Dış otorite kaynaklar: Cilium · eBPF.io · Tetragon · Kubernetes Network Policies