<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1558494949-ef010cbdcc31?w=1200&amp;q=80"><h2 id="the-invisible-revolution">The Invisible Revolution</h2>There’s a technology powering Cloudflare’s DDoS mitigation, Meta’s load balancers, and Cilium’s Kubernetes networking — and most developers have never heard of it.eBPF (extended Berkeley Packet Filter) lets you run custom programs in the Linux kernel without modifying kernel source code or loading kernel modules. It’s like being able to add sensors and circuits to a running engine without stopping the car.In 2026, eBPF has graduated from “interesting hack” to “critical infrastructure.” Here’s what you need to know.<img src="https://images.unsplash.com/photo-1629654297299-c8506221ca97?w=1000&amp;q=80" alt="Linux Kernel Architecture"> Photo by Gabriel Heinzer on Unsplash<hr><h2 id="how-ebpf-actually-works">How eBPF Actually Works</h2>When you write an eBPF program, it goes through a carefully controlled pipeline:<div><pre><code>Your C code
 ↓
LLVM/Clang (compile to eBPF bytecode)
 ↓
Kernel verifier (safety check — no infinite loops, bounded memory)
 ↓
JIT compiler (bytecode → native machine code)
 ↓
Attach to kernel hook point
 ↓
Runs on every event (packet, syscall, tracepoint...)
</code></pre></div>The verifier is the magic. It statically analyzes every possible execution path and rejects programs that could crash the kernel, access out-of-bounds memory, or loop forever. You get kernel-level access with safety guarantees.<hr><h2 id="the-hook-points-that-matter">The Hook Points That Matter</h2>eBPF programs attach to specific events in the kernel:<h3 id="xdp-express-data-path">XDP (eXpress Data Path)</h3>Runs at the network driver level, before the kernel’s networking stack even sees the packet. This is why Cloudflare can drop DDoS traffic at 10M+ packets/second — the malicious packets are discarded before any other processing.<div><pre><code>SEC("xdp")
int block_udp_flood(struct xdp_md *ctx) {
 void *data = (void *)(long)ctx-&gt;data;
 void *data_end = (void *)(long)ctx-&gt;data_end;
 
 struct ethhdr *eth = data;
 if ((void *)(eth + 1) &gt; data_end) return XDP_PASS;
 
 if (eth-&gt;h_proto != htons(ETH_P_IP)) return XDP_PASS;
 
 struct iphdr *ip = (void *)(eth + 1);
 if ((void *)(ip + 1) &gt; data_end) return XDP_PASS;
 
 // Drop all UDP from known bad IPs
 if (ip-&gt;protocol == IPPROTO_UDP &amp;&amp; is_blocked(ip-&gt;saddr))
 return XDP_DROP;
 
 return XDP_PASS;
}
</code></pre></div><h3 id="tc-traffic-control">TC (Traffic Control)</h3>Runs slightly later in the networking stack. Can both drop and modify packets. Used by Cilium for pod-to-pod network policy enforcement.<h3 id="kprobes--tracepoints">Kprobes / Tracepoints</h3>Attach to arbitrary kernel functions. Used for observability — trace every <code>execve()</code> syscall, monitor file opens, track TCP connection state.<h3 id="lsm-linux-security-module">LSM (Linux Security Module)</h3>eBPF programs can enforce security policies at LSM hooks. This is the basis for BPF-LSM, which lets you implement custom security policies like “block this process from opening network sockets.”<hr><h2 id="real-use-cases-in-2026">Real Use Cases in 2026</h2><h3 id="1-zero-copy-observability-with-cilium">1. Zero-Copy Observability with Cilium</h3>Cilium replaced iptables with eBPF for Kubernetes networking. The result:<ul><li>50-90% reduction in latency at scale</li><li>L7 visibility (HTTP, gRPC, Kafka) with no sidecar proxy</li><li>Network policies enforced in the kernel, not userspace</li></ul><div><pre><code>apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
 name: api-policy
spec:
 endpointSelector:
 matchLabels:
 app: api-server
 ingress:
 - fromEndpoints:
 - matchLabels:
 app: frontend
 toPorts:
 - ports:
 - port: "8080"
 protocol: TCP
 rules:
 http:
 - method: GET
 path: "/api/v1/.*"
</code></pre></div>This L7 policy is enforced at the kernel level — not via a proxy sidecar eating your CPU.<h3 id="2-continuous-profiling">2. Continuous Profiling</h3>Parca and Grafana Pyroscope use eBPF to collect CPU profiles from every process on your machine with ~1% overhead. Compare this to traditional profiling which requires instrumenting your code.<div><pre><code># Install Parca Agent on Kubernetes
helm install parca-agent parca-dev/parca-agent \
 --set image.tag=latest \
 --set config.kubernetes.enabled=true
</code></pre></div>You get flame graphs showing every function’s CPU usage across your entire fleet — without modifying a single line of application code.<h3 id="3-runtime-security-with-tetragon">3. Runtime Security with Tetragon</h3>Tetragon (from Isovalent/Cilium) uses eBPF for real-time security enforcement:<ul><li>Detect and block privilege escalation in real-time</li><li>Kill processes that attempt forbidden syscalls</li><li>Track file integrity at the kernel level</li><li>Zero agent overhead compared to traditional HIDS</li></ul><div><pre><code>apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
 name: block-shell-execution
spec:
 kprobes:
 - call: "security_bprm_check"
 syscall: false
 args:
 - index: 0
 type: "linux_binproto"
 selectors:
 - matchBinaries:
 - operator: "In"
 values:
 - "/bin/bash"
 - "/bin/sh"
 matchActions:
 - action: Sigkill
</code></pre></div><h3 id="4-service-mesh-without-sidecars">4. Service Mesh Without Sidecars</h3>The sidecar model (Istio, Linkerd) is being displaced by eBPF-based approaches. Ambient Mesh (Istio’s new mode) and Cilium Service Mesh handle L4/L7 traffic management in the kernel, eliminating the sidecar overhead entirely.Sidecar model: Each pod gets an Envoy container. 2 extra processes per pod, 100ms+ latency overhead, complex certificate management.eBPF model: A single DaemonSet pod per node. All traffic handled in-kernel. Orders of magnitude more efficient.<hr><h2 id="getting-started-with-ebpf-development">Getting Started with eBPF Development</h2><h3 id="option-1-go-with-libbpf-go">Option 1: Go with libbpf-go</h3><div><pre><code>//go:generate go run github.com/cilium/ebpf/cmd/bpf2go bpf trace.c

func main() {
 objs := bpfObjects{}
 if err := loadBpfObjects(&amp;objs, nil); err != nil {
 log.Fatal("Loading eBPF objects:", err)
 }
 defer objs.Close()

 // Attach to kprobe
 kp, err := link.Kprobe("sys_execve", objs.TraceExecve, nil)
 if err != nil {
 log.Fatal("Opening kprobe:", err)
 }
 defer kp.Close()

 // Read events from ring buffer
 rd, err := ringbuf.NewReader(objs.Events)
 if err != nil {
 log.Fatal("Opening ring buffer:", err)
 }
 defer rd.Close()

 for {
 record, err := rd.Read()
 if err != nil { break }
 fmt.Printf("exec: %s\n", record.RawSample)
 }
}
</code></pre></div><h3 id="option-2-python-with-bcc-great-for-exploration">Option 2: Python with bcc (great for exploration)</h3><div><pre><code>from bcc import BPF

program = """
int hello(void *ctx) {
 bpf_trace_printk("Hello, World!\\n");
 return 0;
}
"""

b = BPF(text=program)
b.attach_kprobe(event=b.get_syscall_fnname("clone"), fn_name="hello")
b.trace_print()
</code></pre></div><h3 id="option-3-use-existing-tools-fastest-path-to-value">Option 3: Use existing tools (Fastest path to value)</h3><div><pre><code># Install BPF Compiler Collection tools
apt-get install bpfcc-tools

# Watch all exec calls
execsnoop-bpfcc

# Trace TCP connections
tcpconnect-bpfcc

# Monitor file opens by command
opensnoop-bpfcc -n nginx
</code></pre></div><hr><h2 id="the-challenges-dont-ignore-these">The Challenges (Don’t Ignore These)</h2>Kernel version requirements: Most advanced features need kernel 5.15+. If you’re on older enterprise kernels, your options are limited.CO-RE (Compile Once – Run Everywhere): Different kernel versions have different data structures. CO-RE with BTF (BPF Type Format) lets you compile once and run on any kernel — but setting it up correctly takes work.Verifier complexity: As programs get more complex, the verifier can reject them in confusing ways. Debugging verifier errors is a skill unto itself.Security implications: eBPF programs run in the kernel. A malicious eBPF program is a rootkit. Enforce <code>CAP_BPF</code> permissions carefully, and consider using bpfman for privileged eBPF lifecycle management.<hr><h2 id="the-2026-ecosystem-landscape">The 2026 Ecosystem Landscape</h2><table><thead><tr><th>Tool</th><th>Category</th><th>Use Case</th></tr></thead><tbody><tr><td>Cilium</td><td>Networking</td><td>K8s CNI, service mesh</td></tr><tr><td>Tetragon</td><td>Security</td><td>Runtime enforcement</td></tr><tr><td>Falco</td><td>Security</td><td>Threat detection</td></tr><tr><td>Parca</td><td>Profiling</td><td>Continuous CPU profiling</td></tr><tr><td>Pyroscope</td><td>Profiling</td><td>Fleet-wide profiling</td></tr><tr><td>Pixie</td><td>Observability</td><td>Auto-instrumentation</td></tr><tr><td>Katran</td><td>Load Balancing</td><td>L4 LB (Facebook)</td></tr></tbody></table><hr><h2 id="should-you-care">Should You Care?</h2>Platform/infrastructure engineers: Yes, absolutely. Cilium and Tetragon should be on your radar now.Application developers: Indirectly. You’ll benefit from eBPF-powered observability and networking without needing to write eBPF code.Security engineers: Yes. eBPF-based runtime security is replacing legacy HIDS. Understand it or be left behind.eBPF won’t replace your application code. But it’s fundamentally changing the infrastructure that runs it. The teams shipping reliable, secure, observable systems in 2026 are building on eBPF foundations — whether they know it or not.<hr> <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

The Invisible Revolution
There’s a technology powering Cloudflare’s DDoS mitigation, Meta’s load balancers, and Cilium’s Kubernetes networking — and most developers have never heard of it.
eBPF (extended Berkeley Packet Filter) lets you run custom programs in the Linux kernel without modifying kernel source code or loading kernel modules. It’s like being able to add sensors and circuits to a running engine without stopping the car.
In 2026, eBPF has graduated from “interesting hack” to “critical infrastructure.” Here’s what you need to know.
Photo by Gabriel Heinzer on Unsplash
How eBPF Actually Works
When you write an eBPF program, it goes through a carefully controlled pipeline:
Your C code
    ↓
LLVM/Clang (compile to eBPF bytecode)
    ↓
Kernel verifier (safety check — no infinite loops, bounded memory)
    ↓
JIT compiler (bytecode → native machine code)
    ↓
Attach to kernel hook point
    ↓
Runs on every event (packet, syscall, tracepoint...)
The verifier is the magic. It statically analyzes every possible execution path and rejects programs that could crash the kernel, access out-of-bounds memory, or loop forever. You get kernel-level access with safety guarantees.
The Hook Points That Matter
eBPF programs attach to specific events in the kernel:
XDP (eXpress Data Path)
Runs at the network driver level, before the kernel’s networking stack even sees the packet. This is why Cloudflare can drop DDoS traffic at 10M+ packets/second — the malicious packets are discarded before any other processing.
SEC("xdp")
int block_udp_flood(struct xdp_md *ctx) {
    void *data = (void *)(long)ctx->data;
    void *data_end = (void *)(long)ctx->data_end;
    
    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end) return XDP_PASS;
    
    if (eth->h_proto != htons(ETH_P_IP)) return XDP_PASS;
    
    struct iphdr *ip = (void *)(eth + 1);
    if ((void *)(ip + 1) > data_end) return XDP_PASS;
    
    // Drop all UDP from known bad IPs
    if (ip->protocol == IPPROTO_UDP && is_blocked(ip->saddr))
        return XDP_DROP;
    
    return XDP_PASS;
}
TC (Traffic Control)
Runs slightly later in the networking stack. Can both drop and modify packets. Used by Cilium for pod-to-pod network policy enforcement.
Kprobes / Tracepoints
Attach to arbitrary kernel functions. Used for observability — trace every execve() syscall, monitor file opens, track TCP connection state.
LSM (Linux Security Module)
eBPF programs can enforce security policies at LSM hooks. This is the basis for BPF-LSM, which lets you implement custom security policies like “block this process from opening network sockets.”
Real Use Cases in 2026
1. Zero-Copy Observability with Cilium
Cilium replaced iptables with eBPF for Kubernetes networking. The result:
50-90% reduction in latency at scale
L7 visibility (HTTP, gRPC, Kafka) with no sidecar proxy
Network policies enforced in the kernel, not userspace
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-policy
spec:
  endpointSelector:
    matchLabels:
      app: api-server
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: GET
          path: "/api/v1/.*"
This L7 policy is enforced at the kernel level — not via a proxy sidecar eating your CPU.
2. Continuous Profiling
Parca and Grafana Pyroscope use eBPF to collect CPU profiles from every process on your machine with ~1% overhead. Compare this to traditional profiling which requires instrumenting your code.
# Install Parca Agent on Kubernetes
helm install parca-agent parca-dev/parca-agent \
  --set image.tag=latest \
  --set config.kubernetes.enabled=true
You get flame graphs showing every function’s CPU usage across your entire fleet — without modifying a single line of application code.
3. Runtime Security with Tetragon
Tetragon (from Isovalent/Cilium) uses eBPF for real-time security enforcement:
Detect and block privilege escalation in real-time
Kill processes that attempt forbidden syscalls
Track file integrity at the kernel level
Zero agent overhead compared to traditional HIDS
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-shell-execution
spec:
  kprobes:
  - call: "security_bprm_check"
    syscall: false
    args:
    - index: 0
      type: "linux_binproto"
    selectors:
    - matchBinaries:
      - operator: "In"
        values:
        - "/bin/bash"
        - "/bin/sh"
      matchActions:
      - action: Sigkill
4. Service Mesh Without Sidecars
The sidecar model (Istio, Linkerd) is being displaced by eBPF-based approaches. Ambient Mesh (Istio’s new mode) and Cilium Service Mesh handle L4/L7 traffic management in the kernel, eliminating the sidecar overhead entirely.
Sidecar model: Each pod gets an Envoy container. 2 extra processes per pod, 100ms+ latency overhead, complex certificate management.
eBPF model: A single DaemonSet pod per node. All traffic handled in-kernel. Orders of magnitude more efficient.
Getting Started with eBPF Development
Option 1: Go with libbpf-go
//go:generate go run github.com/cilium/ebpf/cmd/bpf2go bpf trace.c
func main() {
    objs := bpfObjects{}
    if err := loadBpfObjects(&objs, nil); err != nil {
        log.Fatal("Loading eBPF objects:", err)
    }
    defer objs.Close()
    // Attach to kprobe
    kp, err := link.Kprobe("sys_execve", objs.TraceExecve, nil)
    if err != nil {
        log.Fatal("Opening kprobe:", err)
    }
    defer kp.Close()
    // Read events from ring buffer
    rd, err := ringbuf.NewReader(objs.Events)
    if err != nil {
        log.Fatal("Opening ring buffer:", err)
    }
    defer rd.Close()
    for {
        record, err := rd.Read()
        if err != nil { break }
        fmt.Printf("exec: %s\n", record.RawSample)
    }
}
Option 2: Python with bcc (great for exploration)
from bcc import BPF
program = """
int hello(void *ctx) {
    bpf_trace_printk("Hello, World!\\n");
    return 0;
}
"""
b = BPF(text=program)
b.attach_kprobe(event=b.get_syscall_fnname("clone"), fn_name="hello")
b.trace_print()
Option 3: Use existing tools (Fastest path to value)
# Install BPF Compiler Collection tools
apt-get install bpfcc-tools
# Watch all exec calls
execsnoop-bpfcc
# Trace TCP connections
tcpconnect-bpfcc
# Monitor file opens by command
opensnoop-bpfcc -n nginx
The Challenges (Don’t Ignore These)
Kernel version requirements: Most advanced features need kernel 5.15+. If you’re on older enterprise kernels, your options are limited.
CO-RE (Compile Once – Run Everywhere): Different kernel versions have different data structures. CO-RE with BTF (BPF Type Format) lets you compile once and run on any kernel — but setting it up correctly takes work.
Verifier complexity: As programs get more complex, the verifier can reject them in confusing ways. Debugging verifier errors is a skill unto itself.
Security implications: eBPF programs run in the kernel. A malicious eBPF program is a rootkit. Enforce CAP_BPF permissions carefully, and consider using bpfman for privileged eBPF lifecycle management.
The 2026 Ecosystem Landscape
Tool
      Category
      Use Case
    
Cilium
      Networking
      K8s CNI, service mesh
    
Tetragon
      Security
      Runtime enforcement
    
Falco
      Security
      Threat detection
    
Parca
      Profiling
      Continuous CPU profiling
    
Pyroscope
      Profiling
      Fleet-wide profiling
    
Pixie
      Observability
      Auto-instrumentation
    
Katran
      Load Balancing
      L4 LB (Facebook)
    
Should You Care?
Platform/infrastructure engineers: Yes, absolutely. Cilium and Tetragon should be on your radar now.
Application developers: Indirectly. You’ll benefit from eBPF-powered observability and networking without needing to write eBPF code.
Security engineers: Yes. eBPF-based runtime security is replacing legacy HIDS. Understand it or be left behind.
eBPF won’t replace your application code. But it’s fundamentally changing the infrastructure that runs it. The teams shipping reliable, secure, observable systems in 2026 are building on eBPF foundations — whether they know it or not.
*Resources: eBPF.io
      Cilium Docs
      Learning eBPF (O’Reilly)*

eBPF in 2026: The Technology Quietly Rewriting Linux Infrastructure

댓글