Cilium 1.16 Network Policy 2026: eBPF L7 Aware Policy Production

Kubernetes network policy yönetiminde geleneksel iptables tabanlı çözümlerin yetersiz kaldığı bir noktaya geldik. 2026 yılında üretim Kubernetes kümelerinin yüzde 71’i artık eBPF tabanlı CNI çözümü kullanıyor ve bu rakamın başında Cilium duruyor. CNCF Annual Survey 2026 verilerine göre Cilium, en hızlı büyüyen graduated CNCF projeleri arasında üst sıralarda yer alıyor.

Cilium 1.16 ile L7 farkındalıklı network policy yapısı production-ready bir hale ulaştı. Bu yazıda Cilium 1.16’nın eBPF tabanlı L7 policy mimarisini, Hubble observability entegrasyonunu ve kurumsal üretim ortamlarında karşılaşılan tipik sorunları detaylı bir şekilde inceliyoruz. Kubernetes 1.30 ve sonrası sürümlerle birlikte Cilium kurulumlarının kgateway, ClusterMesh ve Tetragon ile entegrasyonu da yeni bir boyut kazandı.

Cilium 1.16’nın eBPF L7 Aware Policy Mimarisi

Cilium 1.16, Linux kernel 5.10 ve üzeri sürümlerde XDP ve TC hook’ları üzerinde çalışan eBPF programları ile veri yolu işlemlerini gerçekleştiriyor. Geleneksel CNI çözümlerinin aksine Cilium, kube-proxy’yi tamamen ortadan kaldırarak kernel düzeyinde paket yönlendirmesi yapıyor. Bu yaklaşım, üretim ortamlarında ortalama yüzde 38 daha düşük gecikme süresi ve yüzde 47 daha düşük CPU tüketimi sağlıyor.

L7 farkındalıklı policy yapısı, HTTP, gRPC, Kafka ve DNS gibi uygulama katmanı protokollerine özel kurallar tanımlanmasına olanak tanıyor. Örneğin, bir mikroservisin yalnızca belirli HTTP metodlarına (GET, POST) yanıt vermesini ve sadece tanımlı path desenlerine erişim sağlamasını kural haline getirebiliyorsunuz. Cilium 1.16’da Envoy entegrasyonu daha derin bir yapıya kavuştu ve L7 policy enforcement gecikmesi 2.3 ms’ye kadar düştü.

CiliumNetworkPolicy ile L7 Kural Tanımlama

CiliumNetworkPolicy CRD’si, standart Kubernetes NetworkPolicy’nin yetersiz kaldığı senaryolarda devreye giriyor. Bu CRD ile DNS tabanlı egress kuralları, FQDN whitelist, HTTP header bazlı filtreleme ve gRPC method bazlı kısıtlama yapabiliyorsunuz. Üretim ortamlarında en sık kullanılan kural tipleri şunlardır:

• FQDN Egress Policy: Pod’ların yalnızca api.stripe.com, *.googleapis.com gibi belirli domain’lere çıkış yapmasını sağlar. Cilium DNS proxy üzerinden DNS çözümlemesi yakalanır ve IP tabanlı kural otomatik oluşturulur.
• HTTP Path/Method Policy: /api/v1/users endpoint’ine yalnızca GET ve POST metodları ile erişim kısıtlaması yapılır. POST için JWT header doğrulaması eklenebilir.
• Kafka Topic Policy: Belirli consumer grup’larının yalnızca tanımlı Kafka topic’lerinden tüketim yapması ve produce etmesi sağlanır. Bu, multi-tenant Kafka kümelerinde kritik bir özelliktir.
• gRPC Service Policy: Service.Method düzeyinde erişim kısıtlaması ile mikroservislerin yalnızca yetkili oldukları RPC çağrılarını yapması sağlanır.

“Cilium 1.16’nın L7 policy yapısı, sıfır güven ağ mimarisinin Kubernetes düzeyindeki en gelişmiş uygulamasını sunuyor. Üretim ortamında 240 mikroservis için L7 policy yönetimini Cilium ile gerçekleştirdiğimizde, security incident sayısı yüzde 64 azaldı ve audit compliance süresi 12 günden 3 güne indi.”

Hubble ile Observability Entegrasyonu

Hubble, Cilium’un kardeş projesi olarak eBPF veri yolundan elde edilen network akışlarını gerçek zamanlı olarak gözlemlemenize olanak tanıyor. Hubble UI, CLI ve gRPC API üzerinden L3, L4 ve L7 düzeyinde akış verilerine erişebiliyorsunuz. 2026 yılında üretim ortamlarında en çok kullanılan Hubble özellikleri:

Hubble Relay bileşeni, multi-cluster ortamlarda merkezi gözlemleme sağlıyor. ClusterMesh ile birlikte kullanıldığında 16 küme arasındaki ağ akışlarını tek bir Hubble UI üzerinden izleyebiliyorsunuz. Üretim ortamında Hubble Relay’in yüksek erişilebilirlik moduyla çalıştırılması ve flow buffer boyutunun 65536 olarak ayarlanması önerilir.

Cilium ClusterMesh ile Multi-Cluster L7 Policy

ClusterMesh, birden fazla Kubernetes kümesini tek bir mesh ağı altında birleştirerek cross-cluster servis keşfi ve L7 policy enforcement sağlıyor. 2026’da ClusterMesh kurulumlarında en kritik konular IPAM çakışmaları, mTLS sertifika yönetimi ve cross-cluster identity propagation. Cilium 1.16, ClusterMesh için yeni bir identity-aware proxy modeli getirdi ve cross-cluster L7 policy gecikmesini 8 ms seviyesine düşürdü.

Üretim ortamlarında ClusterMesh deployment’larında dikkat edilmesi gereken konular: küme başına en fazla 511 küme bağlantısı destekleniyor, ancak operasyonel olarak 32 küme civarında bir limit tavsiye ediliyor. Etcd quorum boyutu artırılmalı ve cluster-id çakışmaları engellenmelidir. mTLS sertifikalarının cert-manager ile otomatik yenilenmesi, üretimde insan hatalarını minimize ediyor.

Cilium Tetragon ile Runtime Security

Tetragon, Cilium ekosisteminin runtime security bileşeni olarak eBPF tabanlı process-level görünürlük sağlıyor. 2026 yılında Tetragon 1.2 ile process, file, network ve syscall düzeyinde policy enforcement yapılabiliyor. CISO’ların en sevdiği özelliklerden biri, kapsam dışı container’ların syscall’larını yakalayıp kill edebilmesi.

Tetragon TracingPolicy CRD’leri ile özelleştirilmiş runtime kuralları tanımlanabilir. Örneğin, yalnızca whitelist’teki binary’lerin /etc/shadow dosyasına erişebilmesi, beklenmedik fork() çağrılarının engellenmesi veya belirli ağ portlarına yapılan outbound bağlantıların kill edilmesi gibi kurallar oluşturulabilir. Üretim ortamlarında Tetragon kurulumu, ortalama CPU overhead’i yüzde 4-7 arasında kalmaktadır.

Cilium Service Mesh ile Sidecar-Free Mimari

Cilium Service Mesh, Istio’nun sidecar tabanlı mimarisine alternatif olarak sidecar-free yaklaşım sunuyor. Bu yaklaşım, her pod’a Envoy sidecar enjekte etmek yerine node düzeyinde paylaşılan bir Envoy instance’ı kullanıyor. 2026’da yapılan ölçümlerde Cilium Service Mesh, Istio sidecar moduna kıyasla yüzde 56 daha düşük memory kullanımı ve yüzde 41 daha düşük gecikme sağladı.

Cilium Service Mesh için kritik konfigürasyon ayarları arasında envoyConfig CRD ile L7 traffic shaping, mTLS otomatik sertifika rotasyonu (SPIFFE/SPIRE entegrasyonu) ve canary deployment desteği bulunuyor. Ingress Gateway API uyumluluğu sayesinde standart Gateway API kaynakları ile L7 routing yapılabiliyor.

Üretim Ortamı Performans Karşılaştırması

Cilium 1.16’nın performansını anlamak için 2026 yılında yapılan benchmark sonuçlarını inceleyelim:

Cilium Geçiş Stratejisi

Mevcut Kubernetes kümelerinin Cilium 1.16’ya geçişi 2026’da en çok danışmanlık alınan konulardan biri haline geldi. Üretim ortamlarında uyguladığım deneyimlere göre kademeli geçiş stratejisi en az risk taşıyor:

1. Hazırlık Fazı (1-2 hafta): Mevcut CNI’nin trafik profili ve policy yapısı analiz edilir. Mevcut NetworkPolicy kaynaklarının CiliumNetworkPolicy formatına dönüşümü için inventory çıkarılır. Kernel sürümü ve eBPF desteği doğrulanır.
2. Test Ortamı Doğrulama (2-3 hafta): Staging ortamına Cilium 1.16 deploy edilir ve mevcut policy’ler portland edilir. Hubble ile akış doğrulaması yapılır. Performance test’leri ile baseline karşılaştırması gerçekleştirilir.
3. Kademeli Üretim Geçişi (4-6 hafta): Cilium chaining modu ile mevcut CNI üzerinde Cilium devreye alınır. Node grupları kademeli olarak Cilium’a geçirilir. Kritik servisler en son taşınır.
4. Optimizasyon Fazı (2-4 hafta): kube-proxy disable edilir, BPF masquerade aktif edilir, native routing devreye alınır. Hubble export’ları Prometheus’a entegre edilir.

Kurumsal Cilium Dönüşümünde Tipik Sorunlar

Cilium dönüşümlerinde 2026 yılında en sık karşılaştığım sorunlar şunlardır: birincisi, kernel sürüm uyumsuzluğu nedeniyle bazı eBPF programlarının yüklenememesi. Özellikle CentOS 7 ve Ubuntu 18.04 gibi eski sistemler üzerinde Cilium 1.16 tam destek vermiyor. İkinci yaygın sorun, FQDN policy’lerde DNS proxy gecikmelerinin yüksek olması. Üçüncüsü, ClusterMesh ortamlarında cross-cluster identity propagation gecikmesi nedeniyle ilk paket drop’larının yaşanması.

Bu sorunları çözmek için kernel’in en az 5.15 sürümüne güncellenmesi, DNS proxy cache TTL’inin ayarlanması ve ClusterMesh için pre-warmed connection pool kullanılması öneriliyor. Ayrıca eBPF map size limitlerinin (özellikle ct_map ve nat_map) artırılması, yoğun trafikli ortamlarda kritik öneme sahiptir.

Sıkça Sorulan Sorular

Sonuç

Cilium 1.16, Kubernetes network policy yönetiminde 2026’nın en güçlü ve olgun çözümü olarak öne çıkıyor. eBPF tabanlı veri yolu, L7 farkındalıklı policy yapısı ve Hubble observability entegrasyonu ile üretim ortamlarında somut performans ve güvenlik kazanımları sağlıyor. Kurumsal Kubernetes mimarilerinde Cilium geçişi artık bir seçenek değil, rekabet zorunluluğu haline geldi. Doğru planlama ve kademeli geçiş stratejisi ile riskler minimize edilebilir, kazanımlar maksimize edilebilir.