Cilium Nedir? eBPF Tabanlı Kubernetes Networking

Kubernetes’te bir Pod ayağa kalktığında ona IP adresi vermek işin yalnızca başlangıcıdır. Pod başka bir node’daki servise nasıl ulaşacak? Trafiğe hangi network policy uygulanacak? Bir istek neden drop oldu? Service trafiğini kim load balance edecek? Cluster büyüdükçe bütün bu kararlar nasıl yönetilecek?

Cilium, tam olarak bu ağ katmanında çalışan; Kubernetes için networking, security ve observability yeteneklerini eBPF üzerine kuran açık kaynaklı bir projedir. CNI olarak Pod bağlantısını sağlayabilir, network policy uygulayabilir, Kubernetes Service trafiğini eBPF ile yönetebilir ve Hubble üzerinden ağ akışlarını görünür hale getirebilir.

Ancak Cilium’u yalnızca “bir Kubernetes CNI eklentisi” olarak tanımlamak bugün için eksik kalır. Proje; network policy, kube-proxy replacement, BGP, Gateway API, transparent encryption, multi-cluster networking ve service mesh gibi daha geniş bir alanı kapsar. Cilium aynı zamanda CNCF’nin Graduated projeleri arasındadır. Projenin güncel kapsamı ve dokümantasyonu Cilium resmi web sitesi ve Cilium resmi dokümantasyonu üzerinden takip edilebilir.

Son güncelleme: Ağustos 2026 · Referans sürüm: Cilium 1.20.0 (29 Temmuz 2026)

Cilium nedir?

Cilium, Kubernetes ve diğer container ortamlarında ağ bağlantısını sağlamak, güvenlik politikaları uygulamak ve trafiği gözlemlemek için eBPF kullanan açık kaynaklı bir networking platformudur.

Kubernetes tarafında Cilium genellikle bir CNI (Container Network Interface) olarak konumlanır. Pod’ların ağa bağlanması, Pod-to-Pod iletişimi, Service load balancing ve network policy gibi işlemleri yönetebilir. Bunun üzerine Hubble observability, BGP, transparent encryption, Gateway API, Cluster Mesh ve L7 policy gibi yetenekler eklenebilir.

Buradaki önemli nokta, Cilium’un uygulama trafiğine yalnızca IP adresi ve port üzerinden bakmak zorunda olmamasıdır. Kubernetes label ve workload identity bilgisini networking katmanına taşıyarak politika kararlarını daha dinamik hale getirebilir. HTTP ve gRPC gibi Layer 7 senaryolarında node seviyesindeki Envoy proxy devreye girebilir; DNS ve FQDN tabanlı policy ise Cilium’un ayrı DNS proxy mekanizması üzerinden uygulanır.

Kubernetes’te Cilium hangi problemi çözer?

Basit bir Kubernetes cluster’ında ilk bakışta ağ tarafı kolay görünür: Pod’lar IP alır, Service oluşturulur ve uygulamalar birbirine bağlanır. Ancak sistem büyüdükçe birkaç soru aynı anda ortaya çıkar:

• Pod’lar farklı node’lar arasında hangi yoldan haberleşecek?
• Frontend yalnızca belirli backend servislerine erişebilsin denildiğinde policy nerede uygulanacak?
• Bir bağlantı başarısız olduğunda paketin nerede drop olduğu nasıl görülecek?
• Binlerce Service ve endpoint olduğunda load balancing nasıl ölçeklenecek?
• Cluster dışındaki router’lara Pod veya Service ağları nasıl duyurulacak?
• Birden fazla Kubernetes cluster’ı arasında servis keşfi ve policy nasıl korunacak?

Cilium bu soruların tamamını tek bir özellik ile çözmez. Bunun yerine eBPF tabanlı bir datapath etrafında farklı networking, security ve observability bileşenlerini bir araya getirir. Bu nedenle Cilium’u anlamanın en iyi yolu özellik listesini ezberlemek değil, paketin cluster içinde hangi kararlardan geçtiğini anlamaktır.

CNI nedir ve Cilium burada ne yapar?

CNI, container runtime ile ağ eklentileri arasındaki standart arayüzdür. Kubernetes yeni bir Pod oluşturduğunda ağ tarafında Pod’un interface’inin hazırlanması, IP adresinin atanması ve gerekli routing yapılandırmasının yapılması gerekir. Cilium CNI bu aşamada Pod’u Cilium datapath’ine dahil eder.

Cilium farklı ağ modellerinde çalışabilir. Yaygın seçenekler arasında encapsulation tabanlı overlay networking ve native routing bulunur. Overlay modelinde node’lar arasında VXLAN veya Geneve gibi encapsulation yöntemleri kullanılabilir. Native routing modelinde ise Linux host routing tablosu ve mevcut ağ altyapısı daha doğrudan devreye girer.

Hangi modelin doğru olduğu cluster’ın bulunduğu ortama bağlıdır. Bare-metal, on-prem, cloud VPC yapısı, Pod CIDR tasarımı, BGP kullanımı ve mevcut network operasyon modeli seçimde birlikte değerlendirilmelidir.

Cilium 1.20’de netkit ne işe yarar?

Cilium 1.20’de bpf.datapathMode için klasik veth yanında netkit seçeneği de bulunur. Netkit, Linux kernel 6.8 ve üzerindeki uygun sistemlerde Pod datapath overhead’ini azaltmayı hedefler ve BIG TCP gibi optimizasyonlarla birlikte kullanılabilir. bpf.datapathMode=auto destek varsa netkit’i seçip diğer node’larda veth’e dönebilir; varsayılan datapath modu yine veth‘tir.

Netkit mevcut Pod’ların veth interface’lerini yerinde dönüştüren bir “tek ayarla hızlandırma” özelliği değildir. Mevcut cluster’da geçiş planlanacaksa yeni node’lar veya kontrollü cordon/drain süreci üzerinden ilerlemek gerekir. Ayrıntılar Cilium Tuning Guide içinde yer alır.

eBPF nedir ve Cilium neden kullanır?

eBPF, Linux kernel içinde kontrollü programların belirli hook noktalarında çalıştırılmasına imkan veren bir teknolojidir. Networking açısından bu, bir paketin kernel networking stack içerisinde ilerlerken belirli noktalarda programlanabilir kararlar uygulanabilmesi anlamına gelir.

Cilium eBPF programlarını XDP, traffic control, socket ve cgroup gibi uygun kernel hook’larına yükleyerek routing, policy enforcement, Service load balancing ve observability işlemlerinin önemli bölümünü kernel seviyesinde gerçekleştirebilir.

Bunun pratik karşılığı şudur: uygulamanın kodunu değiştirmeden veya her Pod içine ayrı bir networking ajanı koymadan, node üzerindeki trafik davranışı merkezi politikalarla yönetilebilir.

Cilium 1.20 stable dokümantasyonunda ayrıca Alpha durumunda Standalone DNS Proxy seçeneği bulunur. Bu bileşen ayrı bir DaemonSet olarak çalışabilir ve agent geçici olarak kullanılamadığında önceden bilinen DNS kayıtlarında policy enforcement’ı sürdürebilir; ancak policy kurallarını almak ve yeni domain identity’leri oluşturmak için cilium-agent ile koordinasyon hâlâ gereklidir. Ayrıntılar için Standalone DNS Proxy dokümantasyonu incelenebilir.

eBPF’nin Cilium tarafından nasıl kullanıldığına daha teknik seviyede bakmak isteyenler Cilium eBPF datapath giriş dokümantasyonunu inceleyebilir.

Cilium Network Policy nasıl çalışır?

Kubernetes NetworkPolicy, workload’lar arasında hangi trafiğe izin verileceğini tanımlamak için kullanılan temel mekanizmadır. Cilium standart Kubernetes NetworkPolicy kaynaklarını destekler; bunun yanında daha gelişmiş kurallar için CiliumNetworkPolicy ve cluster genelinde uygulanabilen CiliumClusterwideNetworkPolicy kaynaklarını sunar.

Cilium 1.20 ile upstream Kubernetes ClusterNetworkPolicy (KCNP) desteği de eklendi. Bu destek varsayılan olarak kapalıdır ve Helm tarafında k8sClusterNetworkPolicy.enabled=true ile etkinleştirilebilir. KCNP’nin v1alpha2 modeli, önceki AdminNetworkPolicy ve BaselineAdminNetworkPolicy yaklaşımını ayrı kaynaklar yerine Admin ve Baseline tier’ları altında birleştirir. KCNP kullanılacaksa ilgili upstream ClusterNetworkPolicy CRD’sinin cluster’a ayrıca kurulmuş olması gerekir.

Bu sayede politika yalnızca “bu IP şu porta erişebilir” şeklinde düşünülmek zorunda değildir. Kubernetes label’ları ve Cilium security identity yaklaşımı kullanılarak uygulama rolleri üzerinden kurallar tanımlanabilir.

Örneğin mimari şu şekilde tasarlanabilir:

frontend  →  api:443        ALLOW
frontend  →  database:5432  DENY
api       →  database:5432  ALLOW

Buradaki güvenlik modeli Pod IP’sinin kalıcı olmasına bağlı değildir. Pod yeniden oluşturulup farklı IP aldığında label ve identity tabanlı politika mantığı korunabilir.

Layer 7 policy ne sağlar?

Cilium bazı senaryolarda Layer 7 seviyesinde HTTP, gRPC ve DNS/FQDN kuralları uygulayabilir. HTTP ve gRPC trafiğinde L7 enforcement Envoy üzerinden yapılabilirken DNS/FQDN politikaları Cilium’un DNS proxy mekanizmasını kullanır. Örneğin belirli bir workload’un backend servisine TCP 80 üzerinden erişmesine izin vermek yerine yalnızca belirli HTTP method ve path kombinasyonlarına izin verilebilir.

Cilium 1.20 notu: Kafka-aware L7 network policy ve Envoy Go Extensions (proxylib) desteği 1.20’de kaldırılmıştır. Güncel policy tasarımında bu eski örneklere dayanılmamalıdır.

GET /public       ALLOW
POST /admin       DENY

Bu özellik uygulama firewall’ı ile birebir aynı şey değildir ve her workload için otomatik olarak gerekli değildir. Ancak mikroservis ortamlarında yalnızca port bazlı segmentasyonun yetersiz kaldığı durumlarda ek kontrol sağlar. Güncel policy yapısı için Cilium Network Policy dokümantasyonu kullanılabilir.

Cilium kube-proxy’nin yerini alabilir mi?

Evet. Cilium uygun yapılandırmada Kubernetes Service load balancing işlevlerini eBPF üzerinden gerçekleştirerek kube-proxy’yi tamamen değiştirebilir. Cilium dokümantasyonunda bu model “Kubernetes Without kube-proxy” olarak ayrı bir deployment senaryosu şeklinde ele alınır.

Kube-proxy’nin görevi Kubernetes Service ve EndpointSlice durumlarını izleyerek Service IP’lerine gelen trafiği uygun backend endpoint’lere yönlendirmektir. Linux üzerinde kube-proxy iptables, nftables veya farklı desteklenen proxy modlarıyla çalışabilir.

iptables ve eBPF farkı neden konuşuluyor?

Klasik kube-proxy iptables modunda Service ve endpoint sayısı arttıkça node üzerinde oluşan kural sayısı da büyür. Kubernetes’in kendi teknik açıklamasında iptables Service eşleşmesinin Service sayısına göre O(N) arama davranışı gösterebildiği belirtilir. Büyük cluster’larda bu özellikle ilk paket latency’si ve ruleset güncellemeleri açısından önem kazanabilir.

Cilium ise Service lookup ve load balancing kararlarında eBPF map’lerinden yararlanır ve uzun lineer iptables rule chain’lerine bağlı değildir.

Kube-proxy replacement; Service load balancing, NodePort, LoadBalancer ve ilgili trafik yollarını Cilium datapath’ine taşıdığı için mimari bir karardır. Mevcut cluster’da yalnızca “daha hızlı olsun” düşüncesiyle etkinleştirmek yerine kernel sürümü, Cilium sürümü, cloud entegrasyonu ve mevcut network davranışı test edilmelidir. Ayrıntılar Cilium kube-proxy replacement ve Kubernetes’in nftables kube-proxy açıklamalarında incelenebilir.

Hubble nedir?

Networking katmanında en zor problemlerden biri bağlantının çalışıp çalışmadığını değil, neden çalışmadığını görebilmektir. Hubble, Cilium’un network ve security observability katmanıdır.

Hubble üzerinden workload’lar arasındaki flow’lar, allow/drop kararları, DNS istekleri ve desteklenen Layer 7 bilgilerinin bir bölümü izlenebilir. Hubble Relay kullanıldığında görünürlük tek node’dan cluster geneline genişletilebilir; Hubble UI ise servis ilişkilerini görsel service map üzerinden incelemeye yardımcı olur.

Örneğin uygulama ekibi “API database’e erişemiyor” dediğinde yalnızca Pod loglarına bakmak yerine flow’un hangi node’dan çıktığı, hangi destination’a gittiği ve policy tarafından drop edilip edilmediği araştırılabilir.

Hubble’ın node, cluster ve Cluster Mesh seviyesindeki observability modeli Cilium Hubble dokümantasyonunda açıklanmaktadır.

Cilium BGP destekliyor mu?

Evet. Cilium BGP Control Plane, Pod networkleri ve Kubernetes Service’leri dış router’lara BGP üzerinden advertise etmek için kullanılabilir. Bu özellik özellikle on-prem ve bare-metal cluster’larda mevcut network altyapısıyla entegrasyon açısından önemlidir.

Ancak BGP Control Plane ile cluster içi datapath aynı şey değildir. Cilium’un kendi dokümantasyonu da BGP Control Plane’in datapath’i programlamadığını ve cluster içi reachability oluşturmak için kullanılmaması gerektiğini özellikle belirtir.

BGP tasarımında ASN, peer yapısı, route advertisement, ECMP davranışı, failure senaryoları ve ToR/router mimarisi birlikte planlanmalıdır. Güncel CRD ve konfigürasyon modeli için Cilium BGP Control Plane dokümantasyonu referans alınabilir.

Cilium trafiği şifreleyebilir mi?

Cilium, Cilium tarafından yönetilen endpoint’ler arasındaki trafiği transparent encryption ile korumak için IPsec, WireGuard ve ztunnel seçenekleri sunar. Şifreleme varsayılan olarak kapalıdır; etkinleştirildiğinde encryption.type için varsayılan yöntem IPsec’tir. ztunnel yaklaşımı halen Beta durumundadır. Şifreleme uygulama koduna TLS eklemekle aynı şey değildir; node ve workload network katmanında transparan biçimde uygulanabilir.

WireGuard kullanıldığında node’lar arasında güvenli tüneller oluşturulur ve aynı node üzerindeki Pod-to-Pod paketleri şifrelenmez. ztunnel ise enroll edilen workload’lar arasındaki L4 mTLS trafiğini aynı node üzerindeki Pod’lar dahil şifreleyebilir. Ancak ztunnel 1.20’de yalnızca TCP trafiğini destekler; iletişimin desteklenmesi için kaynak ve hedef workload’un ikisinin de ztunnel’a enroll edilmiş olması gerekir. Ayrıca ztunnel etkinleştirildiğinde Cluster Mesh şu anda desteklenmez ve standart L4 policy davranışında önemli kısıtlar vardır.

Şifreleme açmak da tek başına network security tasarımını tamamlamaz. Network policy, workload identity, key yönetimi, CPU maliyeti, MTU ve overlay kullanılıyorsa ek encapsulation etkisi birlikte değerlendirilmelidir. Güncel seçenekler için Cilium Transparent Encryption ve ztunnel Transparent Encryption dokümantasyonları kullanılabilir.

Cilium Service Mesh midir?

Cilium bir service mesh’ten daha aşağı katmanda başlar; temelinde Kubernetes networking ve security datapath’i bulunur. Bununla birlikte Cilium; L7 trafik yönetimi, Gateway API, ingress ve service mesh senaryoları için de özellikler sunar.

Cilium’un “sidecarless” yaklaşımı sık konuşulur. Burada doğru ayrım şudur: klasik service mesh modellerinde her Pod’un yanında ayrı bir Envoy sidecar bulunabilir. Cilium’da L3/L4 trafiğin önemli bölümü eBPF datapath üzerinden işlenirken L7 özellikleri için Envoy node seviyesinde Cilium agent ile birlikte veya ayrı cilium-envoy DaemonSet olarak çalıştırılabilir. Böylece her Pod’a ayrı proxy sidecar eklemek zorunlu değildir.

Bu nedenle “Cilium eBPF ile HTTP’yi tamamen kernel içinde parse eder” veya “Cilium kullanınca Envoy artık yoktur” gibi ifadeler doğru değildir. Cilium’un güncel service mesh yaklaşımı Cilium Service Mesh dokümantasyonunda açıklanmaktadır.

mTLS tarafında durum nedir?

Cilium’un SPIRE tabanlı legacy Mutual Authentication özelliği güncel stable dokümantasyonda Beta durumundadır ve Cilium 1.20 upgrade notlarında deprecated olarak işaretlenmiştir. Alternatif olarak geliştirilen ztunnel tabanlı transparent L4 mTLS yaklaşımı da halen Beta durumundadır. Cilium 1.20 bu ztunnel yolunda identity yönetimi ve aynı-node trafik şifreleme gibi alanlarda ilerlemeler getirir; ancak ztunnel ilk kez 1.20’de ortaya çıkmış bir özellik değildir. Bu nedenle production service mesh seçimi yapılırken “Cilium bütün mTLS ihtiyaçlarını hazır ve kararlı biçimde karşılıyor” varsayımıyla hareket edilmemelidir.

Cilium Gateway API destekliyor mu?

Evet. Cilium 1.20, Gateway API v1.6.1 ile çalışır ve resmi dokümantasyonda Core conformance testlerinin geçtiği belirtilir. Destek; GatewayClass, Gateway, HTTPRoute, GRPCRoute, TLSRoute, BackendTLSPolicy ve ReferenceGrant kaynaklarını kapsar. Ayrıca ilgili CRD’ler kurulduğunda ListenerSet, TCPRoute ve UDPRoute desteği de kullanılabilir. Cilium ayrıca CiliumGatewayClassConfig ile GatewayClass davranışını özelleştirebilir.

Gateway API kullanımı için Cilium’un kubeProxyReplacement=true ve l7Proxy=true ile yapılandırılması gerekir; l7Proxy varsayılan olarak açıktır. Güncel destek matrisi, TLSRoute geçiş notları ve kurulum gereksinimleri için Cilium Gateway API sayfası kontrol edilmelidir.

Cluster Mesh ne işe yarar?

Tek cluster içinde çözülen networking problemleri, multi-cluster mimaride yeniden ortaya çıkar: farklı cluster’lardaki Pod’lar nasıl konuşacak, servisler nasıl keşfedilecek, policy nasıl korunacak ve failover nasıl yapılacak?

Cilium Cluster Mesh birden fazla Kubernetes cluster’ının ağlarını birbirine bağlayarak cross-cluster Pod connectivity, service discovery/load balancing ve policy enforcement sağlayabilir.

Bu özellik hybrid cloud veya farklı bölgelerde çalışan cluster’lar için faydalı olabilir; ancak Pod CIDR çakışmaları, cluster’lar arası node connectivity, firewall ve failure domain tasarımı önceden çözülmelidir. Cluster Mesh mevcut WAN/VPC bağlantısı problemlerini sihirli biçimde ortadan kaldırmaz.

Cilium 1.20 ile Kubernetes Multi-Cluster Services API (MCS-API) implementasyonu stable seviyeye yükseldi. ServiceExport ve ServiceImport kaynakları üzerinden daha taşınabilir bir cross-cluster service discovery modeli isteyen ortamlarda MCS-API kullanılabilir.

Güncel gereksinimler için Cilium Cluster Mesh ve Cilium MCS-API dokümantasyonları incelenebilir.

AWS EKS, GKE ve AKS üzerinde Cilium nasıl kullanılır?

Cilium yalnızca bare-metal Kubernetes cluster’ları için değildir. Büyük cloud sağlayıcılarının Kubernetes servislerinde de Cilium veya Cilium tabanlı datapath modelleri kullanılmaktadır.

AWS EKS

AWS tarafında iki farklı yaklaşım görülebilir. Cilium kendi AWS ENI IPAM moduyla EC2 Elastic Network Interface IP’lerini yönetebilir. Bunun yanında mevcut AWS VPC CNI’nin IPAM ve interface oluşturma işini sürdürdüğü, Cilium’un ise bu interface’lere eBPF programları eklediği CNI chaining modeli de kullanılabilir.

Chaining modunda bazı gelişmiş Cilium özelliklerinde kısıtlar bulunabileceği için “AWS VPC CNI + Cilium” ile “tam Cilium CNI” aynı deployment olarak değerlendirilmemelidir. Ayrıntılar AWS VPC CNI chaining ve Cilium AWS ENI IPAM dokümanlarında yer alır.

Google Kubernetes Engine

Google Cloud, GKE Dataplane V2’yi eBPF ve Cilium üzerine inşa etmiştir. Bu durum Cilium’un yalnızca self-managed Kubernetes ortamlarında kullanılan niş bir CNI olmadığını göstermesi açısından önemlidir. GKE kullanıcıları için özelliklerin yönetilen servis sınırları ve Google’ın sunduğu Dataplane V2 davranışı ayrıca değerlendirilmelidir.

Azure Kubernetes Service

AKS tarafında Azure CNI Powered by Cilium, Azure CNI control plane ile Cilium datapath’ini birleştirir. Microsoft güncel dokümantasyonunda bu modeli service routing, network policy, observability ve büyük cluster ölçeklenebilirliği için desteklenen bir seçenek olarak sunmaktadır. AKS Automatic cluster’larında Cilium tabanlı Azure CNI Overlay varsayılan networking modelinin parçasıdır.

Cilium ve Calico arasındaki fark nedir?

Cilium ve Calico Kubernetes networking tarafında en sık karşılaştırılan projelerden ikisidir. Ancak bu karşılaştırmayı “Cilium eBPF kullanır, Calico kullanmaz” şeklinde yapmak artık doğru değildir; Calico’nun da eBPF datapath modu bulunmaktadır.

Dolayısıyla doğru soru “hangisi daha iyi?” değil, hangi datapath ve operasyon modeli mevcut cluster’a daha uygun? sorusudur. Mevcut network mimarisi, cloud sağlayıcısı, BGP gereksinimi, policy kapsamı, observability beklentisi ve ekibin operasyon tecrübesi seçimde birlikte değerlendirilmelidir.

Cilium hangi durumlarda tercih edilir?

Cilium özellikle aşağıdaki gereksinimlerin birkaçının aynı ortamda bulunduğu Kubernetes cluster’larında güçlü bir adaydır:

• Pod ve Service networking katmanında eBPF kullanmak isteniyorsa,
• Network policy yalnızca basit IP/port filtrelemenin ötesine taşınacaksa,
• Hubble ile workload bazlı network observability isteniyorsa,
• kube-proxy replacement değerlendiriliyorsa,
• on-prem veya bare-metal ortamda BGP entegrasyonu gerekiyorsa,
• WireGuard veya IPsec ile transparent encryption ihtiyacı varsa,
• Gateway API veya Cilium service mesh yetenekleri kullanılacaksa,
• birden fazla Kubernetes cluster’ı Cluster Mesh ile bağlanacaksa,
• network troubleshooting’in yalnızca tcpdump ve Pod loglarıyla yürütülmesi yeterli gelmiyorsa.

Cilium her Kubernetes cluster’ında gerekli mi?

Hayır. Küçük ve basit bir cluster’da temel Pod connectivity dışında gelişmiş network policy, observability, BGP, multi-cluster veya service mesh gereksinimi yoksa Cilium’un bütün özelliklerini kullanmak operasyonel olarak anlamlı olmayabilir.

Yeni bir networking katmanı eklemek yalnızca feature kazanımı değildir. Kernel uyumluluğu, CNI lifecycle, upgrade planı, BPF map kapasitesi, MTU, routing modeli, cloud provider entegrasyonları, network policy davranışı ve troubleshooting yetkinliği de operasyon kapsamına girer.

Özellikle mevcut çalışan bir cluster’ın CNI’ını değiştirmek, “Helm upgrade” seviyesinde basit bir uygulama değişikliği gibi ele alınmamalıdır. IPAM ve datapath geçişleri workload connectivity üzerinde doğrudan etki yaratabilir.

Cilium sistem gereksinimleri nelerdir?

Güncel Cilium 1.20 dokümantasyonu container image ile çalışan host’lar için AMD64 veya AArch64 mimarisini ve genel olarak Linux kernel 5.10 veya üzeri ya da eşdeğer özellikleri taşıyan bir distribution kernel’i ister. Resmi doküman buna örnek olarak RHEL 8.10 üzerindeki 4.18 kernel’i verir. Daha yeni Cilium özelliklerinin bir bölümü ise daha güncel kernel sürümleri gerektirebilir.

Bu nedenle yalnızca uname -r çıktısına bakmak yeterli değildir. Distribution kernel’inin ilgili BPF özelliklerini backport edip etmediği ve gerekli kernel configuration seçeneklerinin açık olup olmadığı da kontrol edilmelidir.

Güncel gereksinimler her kurulumdan önce Cilium System Requirements sayfasından doğrulanmalıdır.

Cilium kullanırken hangi komutlar işinize yarar?

Bu yazı kurulum rehberi değildir; ancak çalışan bir ortamda ilk kontrol için birkaç Cilium CLI komutu oldukça yararlıdır:

cilium status
cilium connectivity test
cilium config view
cilium hubble enable
hubble status
hubble observe

cilium status Cilium bileşenlerinin genel durumunu, cilium connectivity test networking ve policy davranışını test senaryolarıyla kontrol etmeyi sağlar. Hubble etkinse hubble observe üzerinden gerçek flow’lar incelenebilir.

Production ortamında connectivity test veya konfigürasyon değişiklikleri yapılmadan önce kullanılan Cilium sürümü, cluster topolojisi ve testin oluşturacağı trafik dikkate alınmalıdır.

Cilium hakkında sık sorulan sorular

Cilium bir CNI mıdır?

Evet. Cilium Kubernetes için CNI olarak kullanılabilir. Ancak güncel Cilium yalnızca Pod networking sağlayan bir CNI’dan daha geniş kapsamlıdır; network policy, load balancing, observability, BGP, encryption, Gateway API ve multi-cluster gibi yetenekler de sunar.

Cilium eBPF olmadan çalışır mı?

Cilium’un temel datapath mimarisi eBPF üzerine kuruludur. Bu nedenle Cilium kullanımı için host kernel’inde gerekli eBPF desteğinin bulunması gerekir.

Cilium kube-proxy’yi kaldırabilir mi?

Evet. Kube-proxy replacement modu etkinleştirildiğinde Kubernetes Service load balancing işlevleri Cilium eBPF datapath tarafından üstlenilebilir. Ancak bunun mevcut bir cluster’a geçişi ayrı bir mimari değişiklik olarak planlanmalıdır.

Cilium ile Hubble aynı şey mi?

Hayır. Cilium networking ve security datapath’ini sağlar; Hubble ise Cilium ve eBPF üzerinde çalışan observability katmanıdır. Hubble flow, drop ve servis iletişimi gibi verilerin görünür hale gelmesini sağlar.

Cilium NetworkPolicy destekliyor mu?

Evet. Standart Kubernetes NetworkPolicy desteklenir. Daha gelişmiş kullanım için CiliumNetworkPolicy ve CiliumClusterwideNetworkPolicy kaynakları kullanılabilir. Cilium 1.20 ayrıca opt-in olarak upstream Kubernetes ClusterNetworkPolicy (v1alpha2) desteği sunar.

Cilium Layer 7 policy destekliyor mu?

Evet. HTTP, gRPC ve DNS/FQDN gibi bazı uygulama katmanı senaryolarında policy uygulanabilir. HTTP ve gRPC tarafında Envoy kullanılabilirken DNS/FQDN policy Cilium’un DNS proxy mekanizması üzerinden uygulanır.

Cilium WireGuard kullanabilir mi?

Evet. Cilium transparent encryption tarafında WireGuard ve IPsec seçeneklerinin yanında Beta durumundaki ztunnel yaklaşımını da sunar. WireGuard aynı node üzerindeki Pod-to-Pod trafiği şifrelemez; ztunnel ise enroll edilen workload’larda aynı-node L4 mTLS trafiğini de kapsayabilir.

Cilium BGP destekliyor mu?

Evet. Cilium BGP Control Plane Pod networkleri ve Service prefix’lerini dış BGP peer’lerine advertise etmek için kullanılabilir.

Cilium Istio yerine geçer mi?

Bu sorunun tek bir cevabı yoktur. Cilium service mesh ve Gateway API yetenekleri sunar; ancak Istio’nun tüm özellikleriyle birebir aynı ürün değildir. L7 routing, mTLS, policy, telemetry, multi-cluster ve mevcut operasyon modeli üzerinden ayrı değerlendirme yapılmalıdır.

Cilium multi-cluster çalışır mı?

Evet. Cluster Mesh ile birden fazla Cilium cluster’ı arasında Pod connectivity, service discovery/load balancing ve policy uygulanabilir. Ağ adreslerinin çakışmaması ve cluster’lar arası node connectivity gibi ön koşullar vardır.

Cilium ile Calico arasında hangisi daha iyi?

Genel bir “daha iyi” cevabı yoktur. Cilium eBPF merkezli datapath ve Hubble entegrasyonuyla öne çıkar; Calico ise güçlü policy/routing özelliklerine ve kendi eBPF datapath seçeneğine sahiptir. Doğru seçim mevcut altyapı ve operasyon gereksinimlerine göre yapılmalıdır.

Cilium’a geçmeden önce hangi sorular cevaplanmalı?

Production cluster için teknoloji seçimini yalnızca feature listesine göre yapmak yerine önce şu soruları cevaplamak daha sağlıklıdır:

• Mevcut CNI hangi problemi çözmekte yetersiz kalıyor?
• Network policy L3/L4 seviyesinde mi kalacak, L7 ihtiyacı var mı?
• Hubble observability gerçekten operasyon sürecine dahil edilecek mi?
• Kube-proxy replacement gerekli mi, yoksa mevcut kube-proxy modeli yeterli mi?
• Cluster bare-metal, on-prem, EKS, GKE veya AKS üzerinde mi?
• Overlay mi native routing mi kullanılacak?
• BGP ile fiziksel network entegrasyonu gerekiyor mu?
• Pod CIDR, Service CIDR ve IPAM modeli nasıl tasarlanmış?
• WireGuard/IPsec encryption için performans ve MTU etkisi test edildi mi?
• Mevcut cluster’dan migration için rollback planı var mı?

Bu sorular cevaplanmadan yapılan CNI değişikliği, networking katmanında yeni yetenekler kazanırken yeni ve daha zor operasyon problemleri oluşturabilir.

Sonuç

Cilium’u değerli yapan tek bir özellik yoktur. Asıl fark; Kubernetes networking, network policy, Service load balancing ve observability işlevlerini eBPF merkezli bir datapath üzerinde bir araya getirmesidir. Hubble, kube-proxy replacement, BGP, encryption, Gateway API ve Cluster Mesh gibi özellikler bu temelin üzerine eklenir.

Ancak Cilium’un güçlü olması her cluster için otomatik olarak doğru seçim olduğu anlamına gelmez. Doğru karar; cluster büyüklüğü, mevcut CNI, cloud sağlayıcısı, routing tasarımı, security gereksinimleri ve ekibin operasyon yetkinliği üzerinden verilmelidir.

Kubernetes mimarisini Pod, Service, networking, security ve operasyon boyutlarıyla daha geniş ele almak isteyen ekipler Absonet Kurumsal Kubernetes Eğitimleri içeriğini inceleyebilir.

Mevcut Kubernetes altyapınızda CNI seçimi, network mimarisi, ölçeklenebilirlik veya açık kaynak altyapı tasarımı değerlendiriliyorsa Absonet danışmanlık hizmetleri sayfasını inceleyebilir; ihtiyaç ve mevcut mimarinizi iletişim formu üzerinden paylaşabilirsiniz.

Diğer Linux, Kubernetes, Ceph, veri altyapısı ve açık kaynak içerikleri için Absonet Teknik Rehberler bölümünü inceleyebilirsiniz.