Reproducing Production Issues in your CI Pipeline Using eBPF
summary
eBPF captures kernel send/receive events (and OpenSSL calls for TLS) to record real production requests into Pixie, which converts them into structured HTTP events and a Pixie -> curl generator that runs as a CI step. Examples show recorded traffic catching an API rename that produced 404s and a load replay that raises latency over 1s; eBPF overhead is small (2–5% for Pixie overall). Pipeline uses a GitHub Action + k8s job parallelism to fail builds on functional or performance regressions.
AI-written summary · about
chapters (14)
- 0:00Intro
- 1:03The Challenge with Testing
- 2:02Why Traffic Replay?
- 2:36Ways to Replay Traffic for Testing
- 6:58What is BPF7 An Analogy
- 10:05Pixie's Protocol Tracer
- 12:01What about TLS traffic?
- 13:00Pixie Architecture
- 19:17Integrating with Pixie
- 20:22CI Demo Use Cases (with Code)
- 22:34Filter the data
- 23:20Adding recurring tests to Github Actions
- 24:36Traffic Replay catches the error
- 24:53What happened?
related talks
26mTriaging Real-time Security Threats with eBPF-powered Observability
17meBPF in Microservices Observability
28mBpftrace Meets Pixie: Dynamic Monitoring of K8s Clusters Unleashed
25mExpanding eBPF’s Reach: From Batteries-Included Auto-Instrumentation To E2E Observability Pipelines
52mMonitoring Kafka without instrumentation using eBPF
29mKubernetes Observability with eBPF
42mCommunity Driven Breakout Session: eBPF and Auto-Instrumentation
32mBuzzing across the eBPF Landscape and into the Hive