The Network Observability eBPF Agent allows collecting and aggregating all the ingress and egress flows on a Linux host (required a Kernel 5.8+ with eBPF enabled).
To build the agent image and push it to your Docker / Quay repository, run:
# compile project
make build
# build the default image (quay.io/netobserv/netobserv-ebpf-agent:main):
make image-build
# push the default image (quay.io/netobserv/netobserv-ebpf-agent:main):
make image-push
# build and push on your own quay.io account (quay.io/myuser/netobserv-ebpf-agent:dev):
IMAGE_ORG=myuser VERSION=dev make images
# build and push on a different registry
IMAGE=dockerhub.io/myuser/plugin:tag make images
The eBPF Agent is configured by means of environment variables. Check the configuration documentation for more details.
The NetObserv eBPF Agent is designed to run as a DaemonSet in OpenShift/K8s. It is triggered and configured by our Network Observability Operator.
Anyway you can run it directly as an executable from your command line:
export TARGET_HOST=...
export TARGET_PORT=...
sudo -E bin/netobserv-ebpf-agent
To deploy locally, use instructions from flowlogs-dump (like tcpdump).
To deploy it as a Pod, you can check the deployment examples.
The Agent needs to be executed either with:
BPF
, PERFMON
, NET_ADMIN
, SYS_RESOURCE
. If you
deploy it in Kubernetes or OpenShift,
the container running the Agent needs to define the following securityContext
:
securityContext:
runAsUser: 0
capabilities:
add:
- BPF
- PERFMON
- NET_ADMIN
- SYS_RESOURCE
(Please notice that the runAsUser: 0
is still needed).
securityContext
:
securityContext:
privileged: true
runAsUser: 0
This option is only recommended if your Kernel does not recognize some of the above capabilities.
We found some Kubernetes distributions (e.g. K3s) that do not recognize the BPF
and
PERFMON
capabilities.
Here is a list of distributions where we tested both full privileges and capability approaches, and whether they worked (✅) or did not (❌):
Distribution | K8s Server version | Capabilities | Privileged |
---|---|---|---|
Amazon EKS (Bottlerocket AMI) | 1.22.6 | ✅ | ✅ |
K3s (Rancher Desktop) | 1.23.5 | ❌ | ✅ |
Kind | 1.23.5 | ❌ | ✅ |
OpenShift | 1.23.3 | ✅ | ✅ |
Install KinD and the ebpf agent and export KUBECONFIG
make create-and-deploy-kind-cluster
export KUBECONFIG=$(pwd)/scripts/kubeconfig
In order to delete the kind cluster:
make destroy-kind-cluster
The eBPF program is embedded into the pkg/ebpf/bpf_*
generated files.
This step is generally not needed unless you change the C code in the bpf
folder.
If you have Docker installed, you just need to run:
make docker-generate
If you can't install docker, you can install locally the following packages, then run make generate
:
dnf install -y kernel-devel make llvm clang glibc-devel.i686
make generate
Regularly tested on Fedora.
For egress traffic, you can see the source Pod metadata. For ingress traffic (e.g. an HTTP response), you see the destination Host metadata.
As part of our Network Observability solution, the eBPF Agent is designed to send the traced flows to our Flowlogs Pipeline component.
In addition, we provide a simple GRPC+Protobuf library to allow implementing your own collector. Check the packet counter code for an example of a simple collector using our library.
In your deployment file, make sure that the container runs as
the root user (runAsUser: 0
) and with the granted capabilities or privileges (see how to run section).
Despite Amazon Linux 2 enables eBPF by default in EC2, the EKS images are shipped with disabled eBPF.
You'd need either: