Abstract

The sidecar model for Kubernetes observability - attaching an Envoy proxy or a language-specific agent container to every application pod - has real costs: memory overhead per pod, mTLS termination complexity, and a dependency on the service mesh control plane staying healthy during incidents. eBPF-based observability tools tap into kernel events at the network, filesystem, and scheduler layers without modifying the application or injecting a container. Cilium Hubble, Pixie, and Falco represent three different points in this design space, and understanding their tradeoffs helps teams decide what instrumentation layer they actually need.

What eBPF Programs Can See

An eBPF program attached to a kernel tracepoint or kprobe runs inside the kernel in a sandboxed JIT-compiled environment, verified by the eBPF verifier before load. Network-layer programs attached to TC (traffic control) hooks or XDP (eXpress Data Path) can inspect every packet before it reaches a socket buffer - without a userspace network proxy in the path. This makes it possible to build a service map showing which pods are communicating, at what rate, and with what latency, purely from kernel observations. Cilium Hubble uses exactly this approach: the Hubble observer runs as a daemonset, reads flow events from per-node ring buffers that Cilium’s eBPF dataplane populates, and streams them to a central relay that aggregates the service graph. Because Cilium’s CNI plugin is already doing the networking, Hubble adds observability with minimal marginal cost.

Continuous Profiling with Pixie

Pixie from New Relic takes a broader approach, using eBPF uprobes to instrument application-layer protocols - HTTP/2, gRPC, PostgreSQL wire protocol, Redis RESP - without any change to application code or container image. Pixie’s PEM (Pixie Edge Module) daemonset runs BPF programs that parse protocol messages in kernel space and emit structured records to an in-cluster data store. The result is per-endpoint request traces with latency histograms, error rates, and payload samples, available within seconds of deploying the agent. The limitation is language-specific: dynamic language runtimes like CPython or the JVM complicate uprobe placement because function addresses are not stable across interpreter versions. Pixie handles Go and C++ well; Python support is partial. Teams with mixed-language fleets typically layer Pixie for Go services alongside OpenTelemetry SDK instrumentation for Python and JVM workloads.

Runtime Security with Falco

Falco from the CNCF uses eBPF (or, on older kernels, a kernel module) to monitor syscall streams and match them against a rule engine that detects anomalous behavior: unexpected outbound connections, /etc/shadow reads by non-root processes, shell spawned inside a container, ptrace calls from non-privileged contexts. Falco rules are YAML with a filtering DSL that draws on syscall fields and Kubernetes metadata injected by the Falco metadata enrichment layer. Alerts fire to stdout, syslog, or a gRPC output plugin - the Falcosidekick fan-out tool routes alerts to Slack, PagerDuty, and Prometheus simultaneously. The operational footprint is one daemonset pod per node; there is no per-application change and no sidecar injection webhook required, which removes the dependency on cert-manager and the mutating admission webhook that sidecar-based security tools need.

Choosing a Layer

The three tools are not mutually exclusive. A practical baseline for a new Kubernetes cluster in early 2026 is Cilium as the CNI (replacing kube-proxy and the need for a separate service mesh in many cases), Hubble for network flow visibility, and Falco for runtime security. Pixie is additive for teams that need application-layer traces without SDK instrumentation during incident response. The combined memory overhead of these daemonsets is lower than running a full Istio sidecar on every pod in a dense cluster, and the operational dependency graph is simpler.