Cilium'un eBPF ağ yapısı GKE, AKS ve EKS'te varsayılan yol haline geliyor

Üç büyük sağlayıcı tek bir CNI'da buluşuyor

eBPF tabanlı Container Network Interface olan Cilium, niş bir tercihten büyük yönetilen Kubernetes platformlarının ağ omurgasına dönüştü. Ekim ayında yayımlanan bir dev.to analizine göre Google Cloud artık GKE Autopilot'ta Cilium'u standart CNI olarak sunuyor, Microsoft Azure onu AKS için tercih edilen gelişmiş ağ seçeneği olarak konumlandırıyor ve Amazon da zorlu EKS senaryolarında öneriyor. Yığının, Calico, Flannel, Weave ve Cilium'un uzun süre beraber ve zevk meselesi olarak var olduğu bir katmanında, üç hiperscaler'ın bu düzeyde hemfikir olması alışılmadık bir durum.

eBPF kaputun altında neyi değiştiriyor

Cilium'un temel fikri, iptables tabanlı paket işlemeyi doğrudan Linux çekirdeğine yüklenen küçük programlarla değiştirmek. dev.to yazısı mekaniği şöyle açıklıyor: klasik CNI'lar, servis ve kural eklendikçe doğrusal biçimde büyüyen iptables zincirlerine dayanır; küstör binlerce kurala ulaştığında ölçülebilir gecikme artışları ortaya çıkar. Cilium ise sabit zamanda arama sunan eBPF map'leri kullanır; böylece ağ performansı küstör büyüdükçe kötüleşmez.

Analiz, pod-to-service trafiğinde 28,5 Gbit/s'ye varan verim, 0,8 ms P99 gecikme ve iptables tabanlı alternatiflerin yaklaşık yarısı kadar CPU tüketimi bildiren 2026 kıyaslama rakamlarına atıfta bulunuyor. Ancak bir kısıt var: yaklaşım Linux 5.4 veya daha yeni bir sürüm gerektiriyor, üretim için 5.15+ öneriliyor. Eski node imajlarını çalıştıran küstörler bunu benimseyemez ve Calico ya da Flannel'a bağımlı kalmaya devam eder.

Service mesh sidecar'ı olmadan Layer 7 politikası

Ham performansın ötesinde analiz, politika uygulamasını Cilium'un Calico ve Flannel'a karşı gerçek farklılaştırıcısı olarak gösteriyor. Standart Kubernetes NetworkPolicy'leri bağlantı düzeyinde çalışır — örneğin 8080 portunda TCP'ye izin verir — while CiliumNetworkPolicy kaynakları ise HTTP metodu ve yol düzeyinde kurallar ifade edebilir: frontend'den bir products uç noktasına GET isteklerine izin ver, bir admin yoluna DELETE çağrılarını engelle. İnceleme çekirdeğe yakın gerçekleştiği için her pod'un yanında bir Envoy sidecar çalışması gerekmez.

Yazı ayrıca bir uyumluluk argümanı da ortaya koyuyor: SOC 2 veya ISO 27001 gibi rejimler için yol düzeyindeki kurallar, geriye dönük olarak yamalanmış güvenlik duvarı yapılandırması yerine CI/CD hattında doğrudan doğrulanabilen, test edilebilir artefaktlar haline gelir.

Hubble ağ akışlarını birinci sınıf veriye dönüştürüyor

Cilium'un entegre gözlemlenebilirlik katmanı Hubble, politika uygulamasında kullanılan aynı eBPF hook'larına bağlanır. dev.to analizine göre sonuç; agent, sidecar veya örnekleme olmadan ağ akışlarının tam görünürlüğü: her bağlantı kaynak ve hedef pod, protokol, politika kararı ve sayaçlarıyla birlikte kaydedilir. Operasyonel olarak bu, hubble observe --verdict DROPPED gibi bir komutun reddedilen bağlantıları doğrudan ortaya çıkardığı, bir mühendisin yirmi mikro hizmetteki tutarsız uygulama loglarını ilişkilendirmek zorunda kalmadığı anlamına gelir. Hubble ayrıca yerleşik bir OpenMetrics uç noktası sunduğundan mevcut Prometheus ve Grafana yığınları veriyi yeni araçlar olmadan tüketebilir.

Calico ve Istio hâlâ nerede yer buluyor

Yazarın 2026 karar matrisi açık: yeni küstörler varsayılan olarak Cilium kullanmalı, eski çekirdekler veya fiziksel sunucu ortamlarında BGP gereksinimleri geçerli olduğunda Calico doğru tercih olmaya devam ediyor ve Istio ise yalnızca gerçekten karmaşık trafik yönetimi — kanarya dağıtımları, dinamik trafik mirroring — gerektiğinde yerini hak ediyor. Betimlenen yaygın bir desen, Cilium'un temel ağ katmanını sağlaması ve Istio'nun yalnızca ek yükün haklı çıktığı yerlerde üstüne katlanması.

Hâlâ Calico veya Flannel üzerinde olan ekipler için yazı, Cilium'a geçişin resmi Helm chart ile belgelendiğini ve üretim kesintisi olmadan node node ilerleyebildiğini, ancak öğrenme eğrisinin gerçek olduğunu belirtiyor. Cilium CNCF'den mezun olmuş bir projedir.

Neden önemli

İki değişime dikkat çekmek gerek. Birincisi, Kubernetes ağ yapısı üç büyük bulut sağlayıcısının da onayladığı tek bir eBPF tabanlı uygulama çevresinde yoğunlaşıyor — bu, iptables tabanlı CNI'lar etrafında kurulmuş araçların, becerilerin ve sorun giderme pratiklerinin kademeli olarak önemini yitireceği anlamına geliyor. İkincisi, daha önce service mesh gerektiren yetenekler — L7 politikası ve akış düzeyinde gözlemlenebilirlik gibi — artık çekirdekte yaşıyor ve birçok kuruluşun mesh dağıtımını küçültmesine ya da tamamen atlamasına olanak tanıyor.

Uyarılar şunlar: bu tek bir topluluk analizi, satıcı dokümantasyonu değil ve kıyaslama rakamları bağımsız olarak doğrulanmış sonuçlar değil, yazarın aktardığı değerler. Çekirdek sürümü gereksinimleri ayrıca benimsemeyi kısmen bir node yükseltme meselesi haline getiriyor. Yine de Google, Microsoft ve Amazon aynı yönü işaret ederken, eski CNI'lar çalıştıran platform ekipleri için göç yolu planlamaya başlamak için net bir sinyal var.