eBPF Nedir? Linux’ta Performans ve Güvenliği Uçurun
eBPF nedir, ne işe yarar? Linux’ta izleme, ağ görünürlüğü ve güvenlik için eBPF’yi adım adım öğrenin ve örneklerle uygulayın.
eBPF Nedir? Linux’ta Performans ve Güvenliği Uçurun
Meta Description
eBPF nedir? Linux’ta observability, ağ izleme ve güvenlik için eBPF’yi hızlıca öğrenin. Örneklerle bugün deneyin.
Giriş (Introduction)
Prod ortamda “CPU niye zıpladı?”, “bu servis neden timeout veriyor?”, “hangi process bu portu dinliyor?” gibi sorulara cevap ararken çoğu ekip ya fazla genel metriklere takılır ya da sunucuyu yoran debug araçlarına mecbur kalır. Üstelik konteynerler, mikroservisler ve servis mesh’ler derken sorunlar daha da görünmez hale gelir.
İşte burada eBPF devreye girer: Linux çekirdeğinin içinde, çok düşük overhead ile izleme (observability), ağ görünürlüğü, güvenlik ve performans analizi yapmanızı sağlar. Bu yazı, eBPF’nin ne olduğunu, neden “game changer” sayıldığını ve bugün nasıl pratikte kullanabileceğinizi anlatır.
eBPF Nedir? (Temel Tanım)
eBPF (extended Berkeley Packet Filter), Linux kernel içinde güvenli şekilde çalışan küçük programlar yükleyip çalıştırmanıza izin veren bir teknolojidir. Başta ağ paket filtreleme için doğsa da bugün:
- Tracing / profiling (hangi fonksiyon ne kadar çalıştı?)
- Networking (hangi bağlantı nerede gecikiyor?)
- Security (hangi process hangi syscall’ı çağırdı?)
- Observability (log/metric/trace tamamlayıcı görünürlük)
gibi alanlarda yaygın kullanılır.
Kritik nokta: eBPF programları kernel içinde çalışsa bile verifier sayesinde belirli kurallara uymak zorundadır; bu da stabilite ve güvenlik için temel korumadır.
Neden eBPF Kullanmalıyım?
“Bunu neden yapmalıyım?” sorusunun pratik cevapları:
1) Prod’da düşük overhead ile görünürlük
Klasik debug yaklaşımları (ağ trafiğini dump’lamak, ağır profiller) prod’da risklidir. eBPF ile olay anında, hedefli ölçüm yapabilirsiniz.
2) Konteyner ve Kubernetes dünyasında daha iyi bağlam
Konteyner içinde çalışan process’lerin ağ trafiğini, syscalls’larını ve latency’sini daha net görürsünüz.
3) Güvenlikte davranış tabanlı izleme
İmza tabanlı yaklaşımlar yerine “bu servis normalde bunu yapmazdı” gibi davranışları yakalamak mümkündür.
4) Daha hızlı RCA (Root Cause Analysis)
Timeout’lar, tail latency, DNS sorunları, kernel scheduling problemleri… eBPF ile sorunun nerede olduğunu daha hızlı daraltırsınız.
eBPF Nasıl Çalışır? (Kavramsal Model)
Aşağıdaki parçalar eBPF’nin temelini oluşturur:
- Hook noktaları: Kernel’de “şurada bir şey olduğunda” çalış (syscall, kprobe, tracepoint, network hook…)
- BPF programı: Bu hook’a bağlanan küçük program
- BPF maps: Kernel ile user-space arasında veri paylaşımı (hash map, array, ring buffer)
- Loader / runtime: Programı derleyip yükleyen araç (libbpf, bcc, bpftool)
Basit akış:
- Bir olay olur (ör.
connect()syscall) - Hook tetiklenir
- eBPF programı çalışır ve sayacı artırır / event üretir
- User-space araç event’i okur ve raporlar
Gerçek Hayat Senaryoları (Nerede İşe Yarar?)
Aşağıdaki tabloda eBPF’nin sık görülen kullanım alanlarını özetleyelim:
| Problem | Klasik yaklaşım | eBPF ile yaklaşım | Kazanç |
|---|---|---|---|
| Ani CPU artışı | Top/htop ile tahmin | Kernel seviyesinde profiling | Daha net “kim yiyor?” |
| Zaman zaman timeout | Log artırma, redeploy | Socket seviyesinde latency izleme | Daha hızlı RCA |
| Şüpheli process davranışı | Auditd + ağır log | Syscall tracing + policy | Daha düşük overhead |
| K8s network karmaşası | Sidecar log’ları | Node seviyesinde flow görünürlüğü | Daha az kör nokta |
Örnek: Ödeme servisinde arada bir 2-3 saniyelik gecikme var. Log’da görünmüyor. eBPF ile bağlantı kurulma süresi mi, DNS mi, kernel queue mu tıkanıyor görebilirsiniz.
15 Dakikada Pratik: eBPF Araçlarıyla Hızlı Teşhis
Sıfırdan eBPF programı yazmadan önce, hazır araçlarla değer üretmek en mantıklısı.
Adım 1) Linux sürümünüzü kontrol edin
Modern eBPF için nispeten güncel kernel avantaj sağlar.
uname -r
Adım 2) bpftrace ile hızlı sorgu
bpftrace, “tek satırlık eBPF script’leri” çalıştırmanızı sağlar.
Ubuntu/Debian örneği:
sudo apt-get update
sudo apt-get install -y bpftrace
Örnek: En çok çalışan syscall’ları say
Aşağıdaki script, syscall’ları sayar ve Ctrl+C’de özet basar:
sudo bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'
comm: process adı@[comm] = count(): process bazlı sayaç
Bu size “hangi process sistem çağrılarını patlatıyor?” sorusuna hızlı bir cevap verir.
Adım 3) Bağlantı (TCP) problemlerini görünür kılın
Çoğu ekip “timeout var” dediğinde sadece uygulama log’una bakar. Oysa sorun TCP seviyesinde olabilir.
bcc araçları (dağıtıma göre paket adı değişebilir) veya alternatif olarak Cilium/Hubble gibi eBPF tabanlı ürünler kullanılabilir. Eğer ortamınızda mevcutsa şu tip araçlar çok iş görür:
tcpconnect: yeni TCP connect olaylarını izlemetcpretrans: retransmission tespiti (ağ kalitesi / packet loss sinyali)
Not: Kurulum paketleri dağıtıma göre farklılaştığı için burada komutları “konsept” olarak veriyorum; üretimde en yaygın yol, distro reposu veya container üzerinden bcc/bpftrace çalıştırmaktır.
Kubernetes’te eBPF: Cilium/Hubble ile Trafiği Okunur Hale Getirme
Kubernetes’te eBPF denince en popüler pratik kullanım Cilium (CNI) ve Hubble (network observability).
Neler kazanırsınız?
- Pod-to-pod trafik görünürlüğü (L3-L7)
- Servis bağımlılık haritası
- Network policy enforcement (iptables yerine eBPF datapath)
Ne zaman mantıklı?
- Mikroservis sayınız arttıysa
- “Hangi servis kime gidiyor?” sorusu cevaplanamıyorsa
- Network policy’leriniz karmaşıklaşıyorsa
Kısa karar rehberi:
- Sadece temel metrik istiyorum → Prometheus + basit dashboard
- Node seviyesinde “gerçek” network görünürlüğü istiyorum → eBPF tabanlı observability
- Network policy performansı kritik → Cilium değerlendir
eBPF’ye Geçerken Dikkat Edilmesi Gerekenler
1) Güvenlik ve yetkilendirme
eBPF güçlüdür; yükleme yetkisi olan bir kullanıcı ciddi etki yaratabilir. Root/privileged erişimi ve cluster security policy’leri iyi tasarlanmalı.
2) Kernel uyumluluğu
Her kernel özelliği her sürümde yoktur. Prod ortamınızın kernel versiyonlarını standardize etmek işinizi kolaylaştırır.
3) “Her şeyi eBPF ile çözerim” tuzağı
eBPF bir sihir değil. Uygulama metrikleri, doğru log tasarımı ve tracing ile birlikte düşünülmeli.
4) Veri hacmi ve maliyet
Event üretimini kontrol etmezseniz çok veri çıkar. Örnek stratejiler:
- Sampling (örnekleme)
- Sadece problem anında kısa süreli aktif etme
- Filtreleme (sadece belirli process/pod/port)
Sık Sorulan Sorular (FAQ)
1) eBPF nedir, kısaca ne işe yarar?
eBPF, Linux kernel içinde güvenli şekilde çalışan küçük programlarla sistem davranışını izleme, ağ görünürlüğü ve güvenlik politikaları uygulama imkânı verir.
2) eBPF performansı düşürür mü?
Doğru kullanılırsa overhead genelde düşüktür. Ancak çok sık event üretmek veya filtrelememek veri hacmini artırıp maliyet yaratabilir.
3) eBPF öğrenmek için C bilmek şart mı?
Şart değil. bpftrace ile script yazarak başlayabilirsiniz. İleri seviye için C/libbpf bilgisi faydalıdır.
4) eBPF sadece Kubernetes için mi?
Hayır. Bare-metal, VM, klasik Linux sunucularda da çok değerlidir. K8s sadece en popüler kullanım alanlarından biridir.
5) eBPF ile güvenlik ürünü yapılır mı?
Evet. Syscall izleme, runtime policy, anomali tespiti gibi alanlarda eBPF yaygın kullanılır (ör. Falco’nun eBPF tabanlı yaklaşımları).
Sonuç
eBPF, Linux’ta performans, observability ve güvenliği bir üst seviyeye taşıyan modern bir altyapı teknolojisi. Özellikle “prod’da sorun var ama nerede?” dediğiniz anlarda, düşük overhead ile doğru noktayı görmenizi sağlar.
Bugün aksiyon olarak:
- Bir sunucuda bpftrace kurup basit bir trace çalıştırın
- En çok syscall üreten process’leri görün
- Ardından ağ gecikmesi/timeout vakalarında TCP olaylarını izlemeyi deneyin
Denediğiniz senaryoyu (kernel sürümü, hangi problem, hangi çıktıyı aldınız) yorum olarak yazın; aynı senaryo için daha hedefli eBPF script’i önerip birlikte netleştirebilirim.