Observabilitas Tanpa Instrumentasi: Bagaimana eBPF Menggantikan Armada Sidecar
Engineering Team
67% Tim Kubernetes Telah Beralih ke Observabilitas eBPF
Menurut Survei Tahunan CNCF 2026, 67% tim Kubernetes kini menggunakan alat berbasis eBPF untuk setidaknya satu pilar observabilitas (metrik, trace, atau log) — naik dari 29% di 2024 dan 41% di 2025. Pergeseran ini bukan lagi bertahap; ini adalah gelombang besar.
Alasannya sederhana: observabilitas berbasis sidecar tradisional (proxy Envoy, sidecar OpenTelemetry Collector, agen Datadog) mengonsumsi sumber daya yang besar, menambah latensi ke setiap permintaan, dan memerlukan perubahan kode atau modifikasi kontainer untuk instrumentasi. eBPF melakukan semuanya dari kernel — tanpa perubahan aplikasi apa pun.
Apa Itu eBPF dan Mengapa Penting
eBPF (extended Berkeley Packet Filter) adalah teknologi yang memungkinkan program sandbox berjalan di dalam kernel Linux tanpa mengubah kode sumber kernel atau memuat modul kernel. Awalnya dirancang untuk pemfilteran paket jaringan, eBPF telah berkembang menjadi framework programmability kernel tujuan umum.
Cara Kerjanya
- Tulis program kecil dalam C atau Rust (atau gunakan framework tingkat tinggi)
- Lampirkan ke hook point kernel — syscall, event jaringan, tracepoint, entry/exit fungsi
- Verifier eBPF kernel memeriksa program untuk keamanan (tanpa infinite loop, tanpa akses di luar batas, eksekusi terbatas)
- Kompiler JIT menerjemahkan bytecode eBPF ke instruksi mesin native
- Program dijalankan pada hook point dengan performa mendekati native
Untuk observabilitas, ini berarti Anda dapat mencegat setiap permintaan HTTP, pencarian DNS, koneksi TCP, operasi file system, dan eksekusi proses — tanpa memodifikasi kode aplikasi apa pun, tanpa menyuntikkan sidecar, dan tanpa me-restart pod.
// Program eBPF sederhana untuk melacak permintaan HTTP
SEC("kprobe/tcp_v4_connect")
int trace_connect(struct pt_regs *ctx) {
struct sock *sk = (struct sock *)PT_REGS_PARM1(ctx);
u32 pid = bpf_get_current_pid_tgid() >> 32;
u16 dport = sk->__sk_common.skc_dport;
u32 daddr = sk->__sk_common.skc_daddr;
struct event_t event = {
.pid = pid,
.dport = ntohs(dport),
.daddr = daddr,
.timestamp = bpf_ktime_get_ns(),
};
bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU,
&event, sizeof(event));
return 0;
}
Mengapa Penting untuk Observabilitas
Observabilitas tradisional memerlukan instrumentasi — menambahkan kode, library, atau kontainer sidecar ke aplikasi Anda. Pendekatan ini memiliki tiga masalah fundamental:
- Overhead sumber daya — Setiap sidecar mengonsumsi CPU dan memori. Di kluster 500 pod dengan sidecar Envoy, sidecar itu sendiri dapat mengonsumsi 30-40% dari total sumber daya kluster.
- Celah cakupan — Anda hanya dapat mengamati apa yang Anda instrumentasi. Biner pihak ketiga, event level kernel, dan infrastruktur jaringan tetap menjadi blind spot.
- Beban pemeliharaan — Setiap bahasa, framework, dan runtime membutuhkan library instrumentasi sendiri.
eBPF menyelesaikan ketiganya: berjalan di kernel (overhead aplikasi nol), melihat semua yang dilihat kernel (tanpa celah), dan bekerja terlepas dari bahasa atau framework aplikasi.
Stack Observabilitas eBPF di 2026
Ekosistem telah matang menjadi seperangkat alat yang teruji, masing-masing mencakup domain observabilitas tertentu:
Cilium + Hubble: Observabilitas Jaringan
Cilium adalah CNI (Container Network Interface) de facto untuk Kubernetes. Hubble, komponen observabilitas Cilium, menyediakan:
- Visibilitas flow L3/L4 — Setiap koneksi TCP/UDP antar pod
- Parsing protokol L7 — HTTP, gRPC, Kafka, DNS, dan PostgreSQL tanpa perubahan aplikasi
- Audit kebijakan jaringan — Melihat kebijakan mana yang mengizinkan atau menolak traffic secara real time
- Pemetaan dependensi layanan — Pembuatan graph layanan otomatis berdasarkan pola traffic
Pixie: Application Performance Monitoring
Pixie (proyek sandbox CNCF) menggunakan eBPF untuk menyediakan APM tanpa instrumentasi:
- Tracing protokol otomatis — HTTP/1.1, HTTP/2, gRPC, PostgreSQL, MySQL, Redis, Kafka, DNS
- Profiling CPU kontinu — Flame graph untuk setiap proses dari stack trace eBPF
- Dynamic logging — Tambahkan trace point ke aplikasi yang berjalan tanpa redeploy
- Capture request/response lengkap — Lihat header HTTP, query SQL, payload gRPC aktual
Tetragon: Keamanan Runtime dan Audit
Tetragon (oleh Isovalent/Cilium) adalah alat keamanan observabilitas dan penegakan runtime berbasis eBPF:
- Pelacakan eksekusi proses — Setiap event exec, fork, dan exit
- Pemantauan akses file — Lacak baca, tulis, dan perubahan izin
- Audit koneksi jaringan — Log setiap koneksi keluar dengan konteks proses
- Penegakan kebijakan keamanan — Blokir aktivitas mencurigakan secara real time
Grafana Beyla: Auto-Instrumentasi
Grafana Beyla adalah agen auto-instrumentasi berbasis eBPF yang menghasilkan trace dan metrik kompatibel OpenTelemetry:
- Mendeteksi permintaan HTTP, gRPC, SQL, dan Redis di level kernel
- Memancarkan span OpenTelemetry dengan propagasi konteks trace
- Terintegrasi dengan Grafana Cloud, Tempo, Mimir, dan backend OpenTelemetry lainnya
Performa: Angka yang Penting
Penghematan sumber daya dari observabilitas berbasis eBPF sangat dramatis. Berikut benchmark dunia nyata dari kluster Kubernetes produksi 500 pod:
Perbandingan Penggunaan Memori
| Komponen | Pendekatan Sidecar | Pendekatan eBPF | Penghematan |
|---|---|---|---|
| Sidecar Envoy (500 pod) | 50 GB | 0 (Cilium CNI) | 50 GB |
| Sidecar OTel Collector (500 pod) | 15 GB | 0 (Beyla DaemonSet) | 15 GB |
| Agen Cilium (20 node) | N/A | 8 GB | -8 GB |
| Agen Beyla (20 node) | N/A | 2 GB | -2 GB |
| Total | 75 GB | 12 GB | Pengurangan 84% |
Overhead CPU
| Metrik | Pendekatan Sidecar | Pendekatan eBPF |
|---|---|---|
| Latensi tambahan per permintaan | 1-5ms | <0.1ms |
| Overhead CPU per node | 8-12% | <1% |
| Dampak tail latency (p99) | +15-30ms | <1ms |
Panduan Migrasi: Dari Sidecar ke eBPF
Fase 1: Deploy Alat eBPF Bersama Sidecar (Minggu 1-2)
- Install Cilium sebagai CNI Anda
- Deploy Hubble untuk observabilitas jaringan
- Deploy Beyla sebagai DaemonSet untuk trace auto-instrumentasi
- Jalankan kedua observabilitas sidecar dan eBPF secara paralel
Fase 2: Validasi dan Tuning (Minggu 3-4)
- Verifikasi bahwa alat eBPF menangkap sinyal yang sama
- Sesuaikan deteksi protokol Beyla untuk layanan spesifik Anda
- Siapkan dashboard yang mencerminkan dashboard berbasis sidecar yang ada
Fase 3: Hapus Sidecar Secara Bertahap (Minggu 5-8)
- Mulai dengan layanan non-kritis: hapus sidecar OTel Collector
- Pantau regresi kualitas data
- Hapus sidecar Envoy dari layanan yang tidak memerlukan manajemen traffic lanjutan
Fase 4: Stack eBPF Penuh (Minggu 9-12)
- Hapus sidecar yang tersisa
- Deploy Tetragon untuk keamanan runtime
- Konsolidasi alerting pada sinyal berbasis eBPF
- Klaim kembali sumber daya yang dibebaskan
Pertanyaan yang Sering Diajukan
Apakah observabilitas eBPF bekerja dengan beban kerja non-Kubernetes?
Ya. eBPF berjalan di level kernel Linux, jadi bekerja dengan beban kerja apa pun — kontainer, VM, bare metal, layanan systemd.
Bisakah eBPF menggantikan distributed tracing?
Untuk banyak tim, ya. Beyla dan Pixie menghasilkan distributed trace dari observasi kernel. Namun, trace eBPF terbatas pada batas request/response — tidak dapat melacak logika bisnis kustom di dalam fungsi Anda.
Bagaimana dengan traffic terenkripsi (TLS)?
Alat eBPF dapat melacak traffic TLS dengan melampirkan ke fungsi library TLS (misalnya OpenSSL’s SSL_read dan SSL_write) daripada lapisan jaringan.
Apakah eBPF aman? Bisakah program eBPF yang bermasalah merusak kernel?
Tidak. Verifier eBPF memeriksa setiap program sebelum loading. Program yang bermasalah akan gagal dimuat — tidak akan pernah merusak kernel.
Bagaimana eBPF menangani layanan throughput tinggi (100K+ request/detik)?
eBPF menangani throughput tinggi melalui agregasi di kernel dan sampling. Alih-alih mengirim setiap event ke user-space, program eBPF dapat menghitung histogram dan counter di kernel maps.