Cilium ve eBPF 2026: Kubernetes Network ve Security Rehberi

Cilium ve eBPF 2026, Kubernetes networking, observability ve security katmanlarını tek bir kernel düzeyinde programlanabilir veri yoluna indirgeyen en kritik altyapı dönüşümünü temsil ediyor. cilium ebpf kombinasyonu, kube-proxy iptables zincirini bypass ederek tek pakette mikrosaniye seviyesinde latency düşüşü sağlar; CNCF Graduated projesi statüsünde 21.000+ GitHub yıldızı ile production-ready kabul edilir. Google GKE Dataplane V2, AWS EKS Anywhere ve Azure AKS Advanced Container Networking varsayılan olarak Cilium tabanlı çalışıyor. Bu yazıda 2026 itibarıyla Cilium 1.16 / 1.17 sürüm ailesinin getirdiği WireGuard mesh, Gateway API v1.2, Tetragon runtime security, ve Service Mesh sidecarsız mimarisinin teknik gerçeklerini; kurulum, performance benchmark, maliyet etkisi ve migration karar çerçevesini somut rakamlarla işliyoruz.

eBPF’in Kernel Mimarisi ve Cilium Konumlandırması

eBPF (extended Berkeley Packet Filter), Linux kernel’in 3.18 sürümünden bu yana var olan; ancak 5.x serisinde olgunlaşan bir sandboxed yürütme ortamıdır. Kullanıcı uzayında derlenen BPF bytecode’u kernel verifier’ı tarafından statik analiz edilir, JIT compiler ile native makine koduna çevrilir ve XDP, TC, kprobe, tracepoint, LSM gibi kernel hook noktalarına bağlanır. Bu sayede ağ paketleri, system call’lar veya güvenlik olayları, kernel modülü yazmadan ve sistem yeniden başlatılmadan dinamik olarak izlenip yönlendirilebilir. Cilium, eBPF’i CNI (Container Network Interface) bağlamında kullanan ilk olgun projedir ve 2025 sonu itibarıyla CNCF Graduated statüsünde sertifikalıdır.

Klasik Kubernetes ağı kube-proxy üzerinden iptables veya IPVS rule setleri ile çalışır. Bir Service ClusterIP’sine giden paket için node başına ortalama 10.000+ iptables kuralı taranır; cluster büyüdükçe rule lookup O(n) karakteri ile latency artar. Cilium eBPF mode bu zinciri tamamen ortadan kaldırır: XDP veya TC katmanında hash-tabanlı socket lookup ile O(1) yönlendirme yapar. Isovalent benchmark’larına göre 5.000 service / 50.000 endpoint ortamında p99 latency 1.2 ms’den 0.18 ms’ye düşer, syscall overhead ise %42 azalır.

Özellik	kube-proxy iptables	kube-proxy IPVS	Cilium eBPF
Service lookup karmaşıklığı	O(n)	O(1) hash	O(1) BPF map
5K service p99 latency	~1.2 ms	~0.4 ms	~0.18 ms
Connection tracking	conntrack	conntrack	BPF CT map
NetworkPolicy backend	iptables	iptables	BPF (L3-L7)
L7 policy desteği	Yok	Yok	HTTP/gRPC/Kafka
Encryption	Yok	Yok	WireGuard/IPsec
Observability	iptables -L	ipvsadm	Hubble (gRPC)

Cilium 1.16 ve 1.17: 2026 Sürüm Yol Haritası

Cilium 1.16, Temmuz 2024’te GA olan ve 2025 boyunca production’da en yaygın çalışan sürümdür. BGP Control Plane v2, Gateway API v1.1 desteği, ve Mutual Authentication (mTLS) SPIRE entegrasyonu bu sürümün öne çıkan özellikleridir. 1.17 ailesi (2025 Q2 itibarıyla stable), Gateway API v1.2, Multi-Network desteği (CNI chaining yerine native multi-NIC), ve Tetragon 1.2 entegrasyonu getirir. 2026’da beklenen 1.18 sürümü ise WASM tabanlı eBPF filtreler ve IPv6 SRv6 (Segment Routing) destekli L3VPN servis modeli üzerinde çalışıyor.

Sürüm	GA Tarihi	Öne Çıkan Özellik	Önerilen Kullanım
Cilium 1.14	Ağu 2023	Service Mesh GA, Gateway API v0.7	Legacy upgrade hedefi
Cilium 1.15	Şub 2024	Cluster Mesh v2, BGP graceful restart	EOL’a yaklaştı
Cilium 1.16	Tem 2024	BGPv2, Gateway API v1.1, mTLS	Mevcut production stabil
Cilium 1.17	Şub 2025	Gateway API v1.2, Multi-Network	Yeni cluster default
Cilium 1.18 (beta)	2026 H1	SRv6, WASM eBPF filter	Test/PoC

Sürüm seçiminde Kubernetes uyumluluk matrisini dikkate almak gerekir: Cilium 1.17 minimum Kubernetes 1.27 ister, 1.16 ise 1.24-1.31 aralığını destekler. Managed cloud sağlayıcılarda sürüm seçimi sağlayıcıya bağlıdır; GKE Dataplane V2 şu anda Cilium 1.16 fork’u, AKS Advanced Container Networking 1.14 tabanlı çalışır.

Kubernetes Networking: kube-proxy Replacement Mimarisi

Cilium’un en güçlü özelliği kubeProxyReplacement=true modudur. Bu mod aktive edildiğinde kube-proxy DaemonSet tamamen kaldırılır ve tüm Service ClusterIP, NodePort, LoadBalancer, ExternalIPs trafiği doğrudan eBPF tarafından yönetilir. Veri yolunda iptables conntrack tablosu yerine BPF connection tracking map kullanılır; bu map node başına 524.288 entry’ye kadar ölçeklenir ve bellek tüketimi ortalama 64 MB civarındadır.

Replacement mimarisinin pratik faydaları somut rakamlarla şöyledir:

• Latency: 10.000 service ölçeğinde p99 service-to-service latency 1.8 ms → 0.22 ms (Isovalent benchmark, 2024).
• CPU: Node başına kube-proxy + iptables sync CPU tüketimi ortadan kalkar; ortalama 50-150 mCPU tasarruf.
• Memory: Conntrack tablo bellek kullanımı %35-40 azalır (BPF map daha kompakt).
• Pod startup süresi: Yeni pod için service erişimi Avantaj: 200 ms → 40 ms (DNS+service propagation).
• Connection drop: Rolling restart sırasında bağlantı kopması %92 düşer (graceful termination eBPF map’inde işaretlenir).

Geçiş için cilium install --set kubeProxyReplacement=true komutu yeterlidir; ancak öncesinde kernel sürümünün 5.10+ olduğunu, BPF JIT’in aktif olduğunu (sysctl net.core.bpf_jit_enable=1) ve nf_conntrack modülünün limitlerinin yeniden değerlendirildiğini doğrulamak şarttır. Docker Kubernetes Yönetimi rehberinde cluster temel kurulum adımlarını detaylı işledik.

NetworkPolicy ve L7 Identity-Based Güvenlik

Kubernetes’in yerel NetworkPolicy kaynağı L3/L4 düzeyinde IP ve port bazlı kural tanımlar; ancak modern mikroservis mimarisinde IP’ler kısa ömürlüdür ve identity tabanlı güvenlik gereklidir. Cilium, CiliumNetworkPolicy (CNP) ve CiliumClusterwideNetworkPolicy (CCNP) CRD’leri ile L7 görünürlüğü ve identity bazlı policy yazımını mümkün kılar. Pod label’ları SHA-256 hash’lenerek bir security identity‘ye dönüştürülür; her paket başlığına bu kimlik yerleştirilir ve hedef node’da policy değerlendirmesi O(1) lookup ile yapılır.

L7 protocol parser’ları HTTP, gRPC, Kafka, DNS ve TLS SNI’yi destekler. Örneğin bir frontend pod’unun backend API’sine sadece GET /api/v1/users endpoint’ine erişmesine izin verilirken DELETE metodu engellenebilir. Bu kural kernel’de eBPF parser ile değerlendirildiği için sidecar proxy overhead’i yoktur; Kubernetes Network Policy yazısında CNP örneklerini örnek YAML’larla işledik.

Policy Türü	Standart NetworkPolicy	CiliumNetworkPolicy	Service Mesh (Istio)
Identity model	IP/CIDR	Pod label (SHA-256)	SPIFFE ID (X.509)
L3/L4	Evet	Evet	Evet (Envoy)
L7 HTTP	Hayır	Evet (eBPF)	Evet (Envoy)
L7 gRPC method	Hayır	Evet	Evet
Kafka topic ACL	Hayır	Evet	Kısmen
DNS hostname allow	Hayır	Evet (toFQDNs)	Evet (ServiceEntry)
Per-request latency overhead	~50 µs	~80 µs	~1.5-3 ms
Encryption	Yok	WireGuard/IPsec	mTLS (Envoy)

L7 policy yazarken dikkat edilecek pratik kurallar:

• Avantaj: Sidecar proxy bellek/CPU yükü olmadan L7 görünürlük.
• Dezavantaj: Envoy kadar zengin filter chain yoktur; karmaşık AuthZ kuralları için service mesh hâlâ gerekli.
• Ne zaman seç: 200+ servisli cluster’da basit L7 kuralları için Cilium; complex JWT/OIDC için Istio + Cilium kombinasyonu.
• Anti-pattern: Tüm pod’lara allow all egress CNP yazıp güvenlik illüzyonu yaratmak — DevSecOps Shift-Left prensipleriyle çelişir.

Hubble Observability ve Akış Verisi

Hubble, Cilium’un native observability katmanıdır ve eBPF’in kernel düzeyinde topladığı her paket olayını gRPC stream olarak dışa açar. Klasik network monitoring araçları sFlow/NetFlow sampling yaparken Hubble %100 paket görünürlüğü sunar; üstelik bu görünürlük L7 protokol parsing’i de içerir. Hubble UI, Grafana entegrasyonu ve hubble observe CLI’ı ile servis grafikleri, drop reason analizi ve policy verdict trace’leri gerçek zamanlı çıkarılır.

Production ölçeğinde Hubble Relay komponenti tüm node Hubble agent’larından gelen stream’leri merkezi olarak toplar. 100 node’luk bir cluster’da Hubble Relay ortalama 300 MB RAM, 200 mCPU tüketir ve saniyede 80.000-120.000 flow event işler. Verinin uzun süreli saklanması için Hubble Timescape (Isovalent enterprise) veya OpenTelemetry export ile Loki/Tempo/Prometheus pipeline’ına bağlanabilir.

Metric	kube-proxy + Prometheus	Service Mesh (Envoy)	Cilium Hubble
L3/L4 flow visibility	Kısmi (kube-state-metrics)	Evet	Evet (%100 sampling)
L7 HTTP request tracing	Hayır	Evet	Evet
Drop reason detail	Hayır	Sınırlı	Evet (BPF code)
Policy verdict log	Hayır	Kısmi	Evet (allowed/denied)
Resource overhead (per node)	~50 MB RAM	~200-400 MB RAM	~80 MB RAM
Service map UI	Yok (manuel)	Kiali	Hubble UI native

Hubble verilerini etkin kullanmanın somut yolları: troubleshooting sırasında hubble observe --verdict DROPPED komutu ile reddedilen paketleri kaynak/hedef pod kimliğiyle listelemek; Grafana dashboard’larında p95 latency’yi servis bazlı izlemek; ve GitOps Kubernetes akışında policy değişikliklerinden sonra verdict trend’ini PR yorumuna eklemek.

Cilium Service Mesh: Sidecarsız Mimari

Geleneksel service mesh (Istio, Linkerd) her pod’a Envoy veya Linkerd-proxy sidecar enjekte eder. Sidecar başına 50-150 MB RAM, 100-300 mCPU overhead’i 1000+ pod’lu cluster’larda toplam 50-150 GB RAM tüketimine ulaşır. Cilium Service Mesh, eBPF tabanlı L7 routing ile sidecar olmadan mTLS, retry, timeout, traffic split ve canary deployment özelliklerinin önemli bir kısmını sunar. mTLS için SPIRE entegrasyonu üzerinden SPIFFE identity dağıtımı yapar; sertifika rotasyonu otomatiktir.

Sidecarsız modelin trade-off’ları net olarak şöyledir:

• Avantaj: Pod başına 80-100 MB RAM tasarruf, deploy süresinde sidecar inject adımı yok, daha basit upgrade.
• Avantaj: Latency overhead Envoy’da 1.5-3 ms iken Cilium L7 parser’da 80-150 µs.
• Dezavantaj: Envoy’un WASM filter, Lua filter, OAuth2/JWT validation, complex retry budget gibi gelişmiş özellikleri eksiktir.
• Dezavantaj: Multi-cluster federation Istio kadar olgun değil; Cluster Mesh limited mesh topolojisi sunar.
• Ne zaman seç: Latency-sensitive servisler, finansal işlem hattı, edge cluster. Service Mesh karşılaştırma yazısında karar matrisini detaylı işledik.

Hibrit yaklaşımlar da yaygındır: Cilium L3/L4 + temel L7 routing + WireGuard encryption tabanı; üzerinde sadece AuthN/AuthZ-yoğun servisler için seçici Istio ambient mode (Istio’nun sidecarsız sürümü) çalıştırmak. Bu mimari 2025’te Cloud-Native Mimari trend raporlarında %38 büyüme gösteren bir desen olarak öne çıkıyor.

Tetragon ve Runtime Security

Tetragon, Cilium ekosisteminin runtime security komponentidir ve eBPF’i kernel security hook’larına (LSM, kprobe, tracepoint) bağlayarak süreç yürütme, dosya erişimi, network bağlantısı ve capability kullanımı düzeyinde gözlem ve politika uygulama yapar. Falco gibi alternatiflerin aksine Tetragon kullanıcı uzayında syscall’ları toplamak yerine kernel düzeyinde inline policy enforcement yapar; bu sayede tespit ve önleme arasındaki gecikme 50 ms’den 200 µs’ye düşer.

Tetragon’un tipik kullanım senaryoları:

1. Container escape detection: unshare, setns, nsenter syscall’larının container içinden çağrılması — sıfır false positive ile yakalanır.
2. Crypto-miner tespit: Anormal execve path’leri (örn. /tmp/xmrig) ve yüksek CPU + dış bağlantı kombinasyonu.
3. Privilege escalation: CAP_SYS_ADMIN elde etme girişimleri runtime’da loglanır.
4. File integrity monitoring: /etc/passwd, /etc/shadow, kubelet kubeconfig dosyalarına yazma girişimleri.
5. Reverse shell detection: Stdin/stdout’un socket’e bind edildiği process’ler eBPF tracepoint ile yakalanır.

NIST SP 800-190 ve CIS Kubernetes Benchmark gerekliliklerine uyum için Tetragon TracingPolicy CRD’leri standart pattern’leri kapsayan örneklerle gelir. Container Güvenliği yazısında runtime security stack’in tüm katmanlarını birlikte değerlendirdik.

Performance Benchmarks ve Ölçeklenme

Cilium’un performans iddialarını doğrulayan üç bağımsız benchmark vardır: Isovalent’in resmi 2024 raporu, Google Cloud’un GKE Dataplane V2 PR’ı, ve Talos Linux’un community benchmark serisi. Aşağıdaki tablo 100 node, 5.000 pod, 10.000 service ölçeğinde TCP_RR (request-response) testlerinin agregatlanmış sonuçlarını gösterir:

Senaryo	kube-proxy iptables	kube-proxy IPVS	Cilium eBPF	Cilium eBPF + WG
Pod-to-pod p50 latency	0.32 ms	0.28 ms	0.18 ms	0.24 ms
Pod-to-pod p99 latency	1.45 ms	0.62 ms	0.31 ms	0.48 ms
Service ClusterIP p99	1.82 ms	0.88 ms	0.22 ms	0.42 ms
Throughput (RPS, single conn)	32.000	38.000	52.000	44.000
NetworkPolicy eval latency	~120 µs (iptables)	~120 µs	~8 µs (BPF)	~8 µs
10K service config propagation	~9 sn	~6 sn	~1.8 sn	~1.8 sn
Node CPU @ 80K RPS	3.2 cores	2.4 cores	1.1 cores	1.8 cores

Bu rakamlar üç kritik karar verisini doğrular: (1) İptables tabanlı kube-proxy 5.000+ servisli cluster için artık sürdürülebilir değil; (2) WireGuard encryption Cilium üzerinde TLS sidecar’a kıyasla ~6 kat daha düşük overhead getirir; (3) NetworkPolicy değerlendirme latency’sindeki 15x iyileşme L7 policy yoğun mimarilerin pratik olmasını sağlar. Kubernetes Cost VPA HPA bağlamında CPU tasarrufu yıllık 20-40 vCPU karşılığına çıkabilir; cloud sağlayıcıda 100 node ölçeğinde 8.000-15.000 USD/yıl arasında doğrudan maliyet azaltır.

Managed Kubernetes ve Cloud Entegrasyonları

2026 itibarıyla üç büyük hyperscaler de yerel Cilium entegrasyonu sunuyor. Google Cloud GKE Dataplane V2, yeni cluster oluşturmada varsayılan seçenektir ve Cilium 1.16 fork’unu yönetilen modda çalıştırır; kullanıcı kubectl ile CiliumNetworkPolicy yazabilir ama agent yapılandırmasına müdahale edemez. AWS EKS, AWS VPC CNI yanında Cilium’u “chained” veya “Cilium-only” modda destekler; Cilium-only modda VPC CNI tamamen devre dışı kalır. Azure AKS Advanced Container Networking Services (ACNS) 2025’te GA olarak Cilium tabanlı Hubble görünürlüğü ve L7 policy sunar.

Platform	Cilium Sürümü	Yönetim Modeli	Ek Maliyet	Sınırlama
GKE Dataplane V2	1.16 (fork)	Tam yönetilen	Yok (standart fiyat)	Agent config kapalı
AWS EKS (Cilium-only)	1.16/1.17 (kendi yöneten)	Kullanıcı yönetir	EC2 + EBS	VPC CNI conflict riski
AKS ACNS	1.14 tabanlı	Tam yönetilen	~0.10 USD/node/saat	Bölgesel kullanılabilirlik
OpenShift OVN+IC	Yok (OVN-K varsayılan)	Cilium 3rd-party	Operator lisans	Sınırlı destek
Self-managed (kubeadm)	Son stable	Tam kontrol	Compute + ops	Operasyon yükü

Multi-cloud veya hybrid senaryoda Cilium Cluster Mesh, birden fazla cluster’ı tek bir L3 mesh halinde birleştirir; service discovery cluster sınırlarını aşar ve global service’ler tanımlanabilir. Bu desen Multi-Cloud Stratejisi ve Cloud Migration Stratejisi kapsamında lift-and-shift sonrası refactor adımında değer üretir. Ömer Önal danışmanlık projelerinde sıklıkla GKE + on-prem RKE2 hibrit mesh’i Cilium ile birleştiriyor; sertifika dağıtımı, IPAM çakışma çözümü ve BGP peering konfigürasyonu için 4-6 haftalık bir geçiş planı tipiktir.

Migration Karar Çerçevesi ve Riskler

Mevcut bir Calico, Flannel veya Weave Net cluster’ından Cilium’a geçiş tek tıkla yapılabilecek bir işlem değildir. CNI değişimi, pod CIDR uyumu, NetworkPolicy semantiği ve mevcut workload kesintisi planlanması gereken dört ana boyuttur. Önerilen yaklaşım yeni node pool oluşturup workload’ları aşamalı taşımak (blue-green), production cluster üzerinde in-place CNI değişiminden kaçınmaktır.

Migration kontrol listesi:

1. Kernel sürüm doğrulaması: 5.10+ önerilir, 5.4 minimum. eBPF JIT ve cgroup v2 aktif olmalı.
2. PodCIDR planı: Cilium IPAM modu seçimi (cluster-scope, kubernetes, AWS ENI, GKE alias IP).
3. NetworkPolicy denkleştirme: Mevcut Calico GlobalNetworkPolicy → CiliumClusterwideNetworkPolicy dönüşümü manuel yapılır.
4. Audit mode: İlk 2 hafta policy-audit-mode=true ile çalıştır, drop’ları log’la ama engelleme.
5. Gözlem: Hubble Relay + Grafana panel’lerini önce kur, baseline metrik topla.
6. Rollback planı: CNI binary backup’ı, eski iptables snapshot’ı, mainline ve hotfix branch ayrı.
7. Performans baseline: Migration öncesi ve sonrası p50/p99 latency, RPS, CPU kıyaslaması.

Tipik riskler ve azaltma yöntemleri:

• Risk: Eski Calico annotation’ları workload’larda kalır → CNP’ye eşleşmez. Azaltma: Migration öncesi annotation audit script’i çalıştır.
• Risk: Kube-proxy kaldırıldığında host network’tan ClusterIP erişimi bozulur. Azaltma: Cilium hostServices=true ile etkinleştir.
• Risk: Cloud LB controller (AWS Load Balancer Controller) Cilium ile çakışabilir. Azaltma: Annotation bazlı LB tip ayrımı (NLB instance mode tercih).
• Risk: WireGuard etkinleştirildiğinde MTU sorunları. Azaltma: Underlay MTU – 80 byte hesabı yap, jumbo frame varsa ayrı.

Edge ve serverless senaryolarda Cilium’un rolü değişiyor: Edge Computing CF Workers tabanlı mimarilerde küçük cluster’lar için Cilium overhead’i ölçü dışıdır; bu noktada Cloudflare’in kendi V8 isolate mimarisi tercih edilir.

Sıkça Sorulan Sorular (SSS)

Sonuç

Cilium ve eBPF birlikteliği, Kubernetes networking’in 2026’daki yeni varsayılanıdır. Kube-proxy iptables zincirinin O(n) ölçeklenme limiti, sidecar tabanlı service mesh’in 50-150 MB/pod overhead’i ve klasik observability araçlarının %5-10 sampling sınırı; eBPF veri yolunun O(1) lookup, 80-100 MB/pod tasarruf ve %100 flow visibility avantajlarıyla doğrudan değiştirilebiliyor. Performance benchmark’lar p99 latency’de 5-8x, NetworkPolicy değerlendirmede 15x ve hyperscale cluster CPU kullanımında %35-40 azalmayı tutarlı şekilde gösteriyor.

Karar çerçevesi pratikte üç eksende oluşturulur: (1) Cluster ölçeği — 500+ servis ve 5.000+ pod üzerinde Cilium ekonomik olarak kendini öder; (2) Güvenlik modeli — identity-based L7 policy ve Tetragon runtime security ihtiyacı varsa Cilium en olgun açık kaynak yığınıdır; (3) Operasyon olgunluğu — kendi eBPF agent’larınızı yönetebileceğiniz ekibiniz yoksa GKE Dataplane V2 veya AKS ACNS gibi yönetilen modlar tercih edilmelidir. FinOps Bulut Maliyet perspektifinden bakınca 100 node ölçeğinde yıllık 8.000-15.000 USD doğrudan compute tasarrufu, observability ve security yığınında ekstra aracın elenmesi ile birlikte toplam 40.000-60.000 USD seviyesine çıkar.

Migration yolculuğu blue-green CNI değişimi, audit mode öncülüğü ve baseline ölçümlerle riski yönetilebilir tutar. Kendi cluster’ınız için Cilium PoC’u, performans benchmark’ı veya Tetragon TracingPolicy şablonu kurulumu konusunda destek almak isterseniz iletişim sayfamızdan ulaşabilirsiniz.

Referanslar ve daha derin kaynaklar: Cilium resmi dokümantasyonu, eBPF.io topluluk hub’ı, Google Cloud GKE Dataplane V2 docs, Azure AKS Advanced Container Networking, CNCF Cilium project page, Tetragon GitHub repository, NIST SP 800-190 Container Security Guide.