For several years now, the Linux kernel has included the extended Berkeley Packet Filter (eBPF), a virtual machine that provides the ability to attach filters to particular sockets. But eBPF goes far beyond packet filtering and allows custom scripts to be triggered at various points within the kernel with very little overhead. By allowing you to run sandboxed programs within the operating system kernel, application developers can run eBPF programs to add additional capabilities to the operating system at run time. Some of our projects require troubleshooting and profiling at the system call level, and our teams found that tools like bcc and bpftrace have made their jobs easier. Observability and network infrastructure also benefit from eBPF — for example, the Cilium project can implement traffic load balancing and observability without sidecar overhead in Kubernetes, and Hubble provides further security and traffic observability on top of it. The Falco project uses eBPF for security monitoring, and the Katran project uses eBPF to build more efficient L4 load balancing. The eBPF community is growing rapidly, and we're seeing more and more synergy with the field of observability.
For several years now, the Linux kernel has included the extended Berkeley Packet Filter (eBPF), a virtual machine that provides the ability to attach filters to particular sockets. But eBPF goes far beyond packet filtering and allows custom scripts to be triggered at various points within the kernel with very little overhead. Although this technology isn't new, it's now coming into its own with the increasing use of microservices deployed as orchestrated containers. Kubernetes and service mesh technology such as Istio are commonly used, and they employ sidecars to implement control functionality. With new tools — Bumblebee in particular makes building, running and distributing eBPF programs much easier — eBPF can be seen as an alternative to the traditional sidecar. A maintainer of Cilium, a tool in this space, has even proclaimed the demise of the sidecar. An approach based on eBPF reduces some overhead in performance and operation that comes with sidecars, but it doesn't support common features such as SSL termination.
For several years now, the Linux kernel has included the extended Berkeley Packet Filter (eBPF) virtual machine and provided the ability to attach eBPF filters to particular sockets. But extended BPF goes far beyond packet filtering and allows custom scripts to be triggered at various points within the kernel with very little overhead. Although this technology isn't new, it's now coming into its own with the increasing use of microservices deployed as orchestrated containers. Service-to-service communications can be complex in these systems, making it difficult to correlate latency or performance issues back to an API call. We're now seeing tools released with prewritten eBPF scripts for collecting and visualizing packet traffic or reporting on CPU utilization. With the rise of Kubernetes, we’re seeing a new generation of security enforcement and instrumentation based on eBPF scripts that help tame the complexity of a large microservices deployment.
