Cilium ve eBPF: Ağ Politikasında ve Gözlemlenebilirlikte Ne Değişiyor

Problem: IP tabanlı ağ politikaları podların doğasına uymuyor

Kubernetes'te bir pod silinip yeniden oluşturulduğunda IP adresi değişir. Bu iptables tabanlı bir CNI (Container Network Interface) için ciddi bir sorun yaratır: her pod eklendiğinde veya silindiğinde iptables kuralları yeniden yazılır, kural sayısı pod sayısıyla kabaca doğru orantılı büyür ve netfilter kuralları sırayla taranır. Birkaç yüz podluk bir kümede bu fark edilmez ama binlerce poda çıkınca paket başına kural taraması gözle görülür gecikme yaratır, kural senkronizasyonu saniyeler sürebilir.

Standart Kubernetes NetworkPolicy kaynağı da sınırlıdır: yalnızca L3 (IP/CIDR) ve L4 (port/protokol) seviyesinde izin/red tanımlar. "Backend servisine yalnızca GET isteği gelsin, POST gelmesin" ya da "bu pod yalnızca api.example.com alan adına çıksın" gibi kurallar NetworkPolicy'nin kapsamı dışındadır, çünkü bunlar L7 (uygulama katmanı) bilgisi gerektirir.

eBPF (extended Berkeley Packet Filter) bu iki soruna birden çözüm sunar. Kernel içine, doğrulanmış küçük programlar yükleyerek paketleri kernel-user space geçişi olmadan işler; kural arama iptables'ın sıralı taramasının aksine hash map'lerle çok daha hızlı yapılır. Cilium, bu eBPF programlarını ağ arayüzlerine bağlayarak hem servis yönlendirmesini hem ağ politikasını hem gözlemlenebilirliği tek bir veri düzleminde topluyor.

Kimlik tabanlı güvenlik: IP değil, etiket

Cilium'un temel farkı, IP adresini değil pod etiketlerinden türettiği bir güvenlik kimliğini politika biriminin merkezine koymasıdır. Aynı etiket setine sahip podlar aynı kimliği paylaşır; bir pod yeniden oluşup IP'si değiştiğinde kimliği değişmez, dolayısıyla politika yeniden hesaplanmaz. Bu, büyük ve sık deploy yapılan kümelerde iptables'ın kural patlamasına düştüğü noktada Cilium'u ölçeklenebilir kılan asıl mekanizmadır.

CiliumNetworkPolicy CRD'si bu kimlik modeli üstüne kurulur ve standart NetworkPolicy'nin üstüne L7 kuralları ekler: HTTP metod ve path, gRPC servis/metod, Kafka topic seviyesinde izin verme; ayrıca DNS'e dayalı egress kuralları (toFQDNs) ile "bu pod sadece şu alan adına çıkabilir" gibi tanımlar mümkün olur. L7 filtreleme, eBPF'in hızlı yolunun yanında gömülü bir Envoy proxy üzerinden yapılır; L3/L4 trafiği tamamen kernel içinde kalırken, L7 denetimi gereken trafik user space'teki proxy'ye yönlendirilir.

Örnek: sadece belirli HTTP metoduna izin vermek

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: backend-http-read-only
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api/v1/.*"

Bu politika frontend etiketli podlardan backend'e yalnızca GET isteklerine izin verir; aynı bağlantı üzerinden POST veya DELETE denemesi eBPF+Envoy katmanında reddedilir. Standart NetworkPolicy ile bunu ifade etmek mümkün değildir, çünkü o yalnızca 8080 portuna erişimi bütün olarak açıp kapatabilir.

Egress tarafında FQDN tabanlı bir kural:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: worker-egress-payment-api
spec:
  endpointSelector:
    matchLabels:
      app: worker
  egress:
    - toFQDNs:
        - matchName: "api.payment-provider.example"
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP

Bu, "worker podları dışarıya yalnızca bu tek alan adına 443 üzerinden çıkabilir" kuralını IP aralığı bilmeden tanımlamanın yoludur; Cilium DNS yanıtlarını izleyip çözülen IP'leri politika arka planında günceller.

Hubble: eBPF'in ürettiği veri, sidecar olmadan

Servis mesh'lerinin çoğu gözlemlenebilirlik için her poda bir sidecar proxy enjekte eder; bu ekstra kaynak tüketimi ve gecikme demektir. Cilium'un Hubble bileşeni aynı veriyi zaten trafiği işleyen eBPF programlarından toplar, ayrı bir proxy'ye ihtiyaç duymaz. hubble observe komutu akan trafiği kaynak/hedef kimlik, HTTP metod/path, DNS sorgusu ve verdict (FORWARDED/DROPPED) seviyesinde canlı gösterir; Hubble Relay küme genelinde bu akışı toplar, Hubble UI ise servisler arası trafiği bir harita olarak çizer.

Pratikte bu, "bu pod neden 403 alıyor" sorusuna log tarama yerine akış filtreleme ile cevap vermek anlamına gelir: hubble observe --namespace backend --verdict DROPPED reddedilen tüm bağlantıları, hangi politika tarafından reddedildiğiyle birlikte döner.

Tuzaklar

Kernel sürümü sürpriz kısıtlar getirir. eBPF programlarının kullanabildiği özellik kümesi kernel sürümüne bağlıdır; kube-proxy replacement ve socket tabanlı yük dengeleme gibi ileri özellikler eski kernel'lerde ya çalışmaz ya da kısıtlı çalışır. Yönetilen bir Kubernetes servisinde node image'ının kernel sürümünü kontrol etmeden Cilium'un tüm özelliklerini varsaymak, kurulum sonrası "bu özellik neden yok" sorusuyla sonuçlanır.

kube-proxy'yi değiştirme kararı geri dönüşü zor bir adımdır. Cilium'u kube-proxy'nin yerine geçecek şekilde kurmak servis yönlendirmesini eBPF'e taşır; bu geçişi küme zaten trafik alırken yapmak, iki yönlendirme mekanizmasının aynı anda çakışmasına yol açabilir. Yeni kurulan kümelerde baştan bu modla başlamak, çalışan bir kümede sonradan geçmekten çok daha güvenlidir.

Politikayı doğrudan uygulamaya almak riskli. Cilium politikaları audit/log modunda çalıştırıp gerçek trafiği gözlemleyip sonra enforce moduna geçirme imkânı sunar; bu adımı atlayıp yeni bir CiliumNetworkPolicy'yi doğrudan enforce modunda uygulamak, beklenmedik bir bağımlılığı (örneğin bir health check ya da metrics scrape yolu) susturabilir. Üretimde önce audit, sonra gözlem, sonra enforce sırası ihmal edilmemeli.

eBPF map boyutları sabit ve sonludur. Connection tracking, servis, kimlik gibi bilgiler sabit boyutlu eBPF map'lerinde tutulur; büyük kümelerde varsayılan map boyutları yetersiz kalabilir, dolan bir map yeni bağlantıların sessizce reddedilmesine yol açar. Bu tür bir sorun iptables'takinden farklı bir hata izi bırakır, map doluluğu ayrı araçlarla ayrıca kontrol edilmelidir.

Debug modeli iptables'tan tamamen farklıdır. iptables -L ile kural okumaya alışkın bir ekip, eBPF programlarının kernel içinde ne yaptığını görmek için farklı araçlara (cilium CLI, hubble, bpftool) alışmak zorundadır; bu öğrenme eğrisi küçük bir ekip için hafife alınmamalı.

Ne zaman seçmemeli

Cilium'un asıl değeri L7 politika ve sidecar'sız gözlemlenebilirlik ihtiyacı olduğunda ortaya çıkar. Birkaç düzine podluk, L3/L4 seviyesinde basit izin kurallarının yettiği bir kümede eBPF'in getirdiği operasyonel karmaşıklık (kernel uyumluluğu, farklı debug araçları, map boyutu ayarı) kazanılan faydayı aşabilir; böyle bir kümede standart bir CNI'nin varsayılan NetworkPolicy desteği yeterlidir. Benzer şekilde CNI seçimi yönetilen bir platform tarafından kilitlenmişse, çünkü bazı yönetilen Kubernetes sunucuları belirli CNI'ler dışında kısıtlı destek verir, önce o platformun Cilium'u hangi modda desteklediğini doğrulamadan mimariyi buna göre kurmamak gerekir.