Using eBPF to solve problems that sidecars can’t in cloud-native deployments

Introduction

In the cloud-native native world, sidecars are auxiliary containers that run concurrently with a primary application or service. They are used to supplement the core service’s operation by offering extra features like logging, monitoring, networking, and security. Although sidecars have gained a lot of traction over the past five years, eBPF is challenging its position.

The powerful Linux kernel feature known as eBPF, or extended Berkeley Packet Filter, enables the execution of customized programs at various points in the networking stack.
eBPF may be used in cloud-native deployments to enforce complicated security policies, change network traffic at the packet level, and give visibility into network traffic. A viable option for complex, distributed systems, eBPF can also scale horizontally.

The limitations of sidecars

Although popular, sidecars have certain limits when it comes to extending the functionality of cloud-native apps. We will look at several issues that sidecars cannot resolve in this list and explain why.

1. Modifying network traffic at the packet level: Sidecars cannot alter individual packets as they move across the network since they were not intended to function at such a low level.
2. Enforcing complex security policies: Sidecars may be able to implement basic security policies, but they are not capable of handling complex or custom policies that require deep inspection of network traffic.
3. Providing visibility into network traffic: While sidecars can provide some visibility into network traffic, they are not able to provide the same level of granularity and detail as specialized tools like eBPF.
4. Implementing custom protocols: Sidecars are limited to the protocols and technologies that they are designed to support. They cannot be used to implement custom protocols or integrate with proprietary systems.
5. Scaling horizontally: Sidecars are typically deployed on a one-to-one basis with the main service they are supporting. This can lead to issues with scaling as the number of sidecars needed to support a service grows.

Implementing eBPF in cloud-native deployments

There are different ways one can get started with eBPF in cloud-native deployments. The most advanced projects for general-purpose eBPF in Kubernetes at the moment are Cilium and Hubble.
There are other projects which specifically focus on security and troubleshooting.

To learn more about eBPF and to get started with tinkering around with eBPF, I recommend the following resource:

BCC — Tools for BPF-based Linux IO analysis, networking, monitoring, and more