Cilium eBPF earns its complexity when Kubernetes needs identity-based policy, kernel-level service handling, and flow visibility. Use Cilium as the platform and datapath; use the separate cilium/ebpf Go library for your own loader or instrumentation tool, or choose another CNI for basic pod networking. Cilium runs verified eBPF programs inside the Linux kernel. It can replace long iptables paths for many packet decisions without adding a sidecar to every service. It is not the CNI standard itself. Skip it if you want the smallest possible network stack and have no need for kernel-level policy or visibility.

Last updated: 2026-07-31

What is Cilium eBPF?

Cilium is a Kubernetes networking and security platform. eBPF is the kernel technology it uses to process packets, enforce policy, load-balance services, and collect observability data.

The important distinction is that Cilium is the product and datapath. eBPF is the execution method. The cilium/ebpf package is a separate Go library for loading and managing eBPF programs.

The reversed search, ebpf cilium, usually points to this same confusion. People are looking for either the Cilium platform or the Go package maintained in the Cilium organization. Those are related, but they solve different problems.

The cilium/ebpf Go library solves a different problem

Use the Go library when you need to write your own loader, agent, exporter, or kernel instrumentation tool. It handles maps, programs, links, collections, and interaction with the eBPF system call from Go.

It does not compile arbitrary source code for you. A normal workflow looks like this:

1. Write an eBPF program in C or another supported source language.
2. Compile it with the required compiler and BPF target settings.
3. Generate Go bindings or load the object file.
4. Use the library to load the program into the kernel.
5. Attach it to a hook and read data from maps.
6. Close the link or pin it when the program should survive the loader.

What does the library leave for you to solve?

The library exposes the machinery. You still need to understand the hook, verifier error, map layout, and lifetime of the link. If you cannot explain where the program attaches, you are not debugging eBPF yet. You are guessing at a loader.

The usual building blocks are:

• Programs that run at a kernel hook.
• Maps that share state between kernel code and user space.
• Links that represent an attachment to a hook.
• Collections that group programs and maps from an object file.
• BTF metadata that describes kernel types.
• CO-RE, or Compile Once – Run Everywhere, for reducing kernel layout differences.

For a Cilium cluster, you usually do not write this loader yourself. Cilium already owns the loading, attachment, map updates, and lifecycle. Write custom Go code when the built-in datapath does not answer your question.

How does the Cilium eBPF datapath handle traffic?

The Cilium eBPF datapath attaches programs at several points in the kernel. The exact path depends on the feature, kernel support, and traffic direction. Not every packet takes every hook. That detail matters because diagrams often make the datapath look more uniform than it is.

A simplified packet path looks like this:

1. A pod sends traffic through its virtual ethernet device.
2. An eBPF program identifies the endpoint and traffic direction.
3. Cilium checks the relevant policy and identity.
4. A service lookup selects a backend when load balancing applies.
5. The packet is forwarded, dropped, redirected, or passed upward.
6. Events and counters are written to eBPF maps for user-space tools.

flowchart LR
 A[Pod traffic] --> B[Virtual ethernet device]
 B --> C[eBPF program]
 C --> D[Identity and policy]
 D --> E[Service map]
 E --> F[Forward, drop, redirect, or pass]
 C --> G[eBPF maps]
 G --> H[Monitoring and observability]

A simplified Cilium eBPF packet path.

Cilium uses maps for service backends, endpoint identities, policy state, connection tracking, and metrics. Updating a map is often cheaper and safer than rebuilding a giant rule chain every time a pod changes.

Which hooks does Cilium use?

Depending on the path, programs may attach through:

• XDP for very early ingress processing.
• Traffic Control hooks for ingress and egress handling.
• Socket and cgroup hooks for workload-aware decisions.
• Tracepoints and other tracing hooks for observability.
• Kernel networking hooks used by service translation and policy enforcement.

XDP is useful, but it is not the answer to every packet problem. It runs early, which limits the context available to the program. If you need richer metadata or normal stack behavior, a later hook may be the correct choice.

The same principle applies to load balancing. Cilium can move service translation into eBPF maps and avoid parts of the traditional kube-proxy path. That can simplify packet handling, but it also means you must inspect the actual loaded programs and maps when something fails. A service object looking correct in Kubernetes does not prove the datapath is correct.

For a narrower look at early packet forwarding, see this guide to eBPF load balancing with XDP.

Cilium is an eBPF CNI, but eBPF is not the CNI

Cilium can act as the CNI plugin that connects pods to the network. The CNI part handles the container runtime integration. The eBPF part handles much of the packet processing after the workload exists.

That distinction prevents a common installation mistake. An eBPF CNI is still a CNI plugin. You normally do not install it beside another primary CNI and hope the two systems divide the work. Both may try to create interfaces, routes, policies, or endpoint state. The failure usually looks like a kernel problem because the conflict appears inside the datapath.

The Container Network Interface specification defines the plugin model. Cilium supplies the implementation and adds policy, service handling, encryption, and observability features around it.

Before installing Cilium, check what already owns networking:

kubectl get pods -n kube-system
kubectl get daemonsets -n kube-system
kubectl get ciliumnodes

If another CNI is active, plan a migration instead of applying a second network plugin to a live cluster. Drain and replacement strategies differ by environment. The exact migration path depends on how the cluster was created and which CNI owns the existing pod interfaces.

The useful eBPF use cases are narrower than the marketing list

eBPF can attach to many kernel subsystems. That does not mean every possible use case belongs in Cilium.

Where does Cilium stop being the right tool?

The strongest use case is the combination of networking and policy. Cilium already knows which endpoint sent a packet, which identity it has, and which service it targets. That makes policy more useful than a list of IP addresses that changes whenever a deployment rolls.

DNS is another practical target. If a service fails because it resolves the wrong name or times out against the wrong resolver, packet captures often show symptoms without showing the owning workload. A focused DNS monitoring setup with eBPF gives you the missing context.

Custom observability is useful when you need a question Cilium does not answer. For example, you may want to count a specific kernel event, trace a file access, or attach a probe to a subsystem outside the network path. That is where the cilium/ebpf library earns its place.

Identity-based policy is where Cilium earns its complexity

IP-based policy breaks under normal Kubernetes behavior. Pods are replaced, addresses change, and services move between nodes. If your rules depend on stable IPs, the rules are already behind the cluster.

Cilium assigns identities from workload labels and uses those identities in policy decisions. A rule can describe the source, destination, port, protocol, and sometimes the application-level request without tying the decision to one temporary address.

Start with L3 and L4 policy:

• Which workload can reach another workload?
• Which port is allowed?
• Which protocol is allowed?
• Is ingress, egress, or both controlled?

Add L7 policy only when the application requirement justifies it. HTTP paths, gRPC methods, and Kafka operations need more context than a packet header provides. That often means a proxy or additional processing path. eBPF reduces overhead around the network path, but it does not make payload parsing free.

The wrong move is to apply a broad L7 policy because the feature exists. Start with a narrow rule, observe drops, and expand only when the traffic pattern is understood. Otherwise you will spend the outage reading policy YAML while the real failure sits in a proxy log.

A cilium ebpf tutorial that starts with diagnosis

Do not begin by changing kernel settings. First prove what the cluster has, what Cilium owns, and whether the kernel exposes the features the datapath needs.

What should you check before installation?

1. Check the cluster and kernel

Run this first:

kubectl get nodes
kubectl get pods -n kube-system
uname -r
bpftool feature probe kernel

The Kubernetes commands show whether the control plane and system pods are healthy. uname -r identifies the running kernel. bpftool feature probe kernel reports the BPF features and helpers exposed by that kernel.

If bpftool is missing, install the package supplied by your Linux distribution before continuing. Do not infer BPF support from the kernel version alone. Distribution backports make version-number guesses unreliable.

2. Confirm the CNI situation

Find the current network plugin before you install anything:

kubectl get daemonsets -n kube-system
kubectl get pods -n kube-system -o wide

Look for the existing CNI daemonset and the node-level pods it owns. If the cluster already runs another CNI, stop and follow a migration plan. Cilium cannot cleanly take over interfaces that another plugin still manages.

How do you prove the datapath works?

3. Install from the official project path

Use the Cilium documentation for the current installation method and kernel requirements. The CLI path is usually the shortest way to create a test installation:

cilium install
cilium status --wait

cilium install applies the selected installation configuration. cilium status --wait blocks until the agent and required components report ready. If it fails, save the output before trying another command. Repeating the install does not make a missing kernel hook appear.

4. Test the data path

Once the agent is ready, test traffic instead of trusting pod status:

cilium connectivity test
cilium endpoint list
cilium monitor

The connectivity test exercises common paths between workloads. cilium endpoint list shows whether Cilium knows the local endpoints and their identities. cilium monitor displays live datapath events while you reproduce a connection.

For a dropped packet, run the monitor during the failure:

cilium monitor --type drop

That tells you whether Cilium dropped the packet and often includes the reason. A timeout with no drop event points you toward routing, DNS, the application, or a path outside the local agent.

Read the kernel and Cilium state before changing policy

When the datapath fails, check the loaded state. Do not edit policy first because the policy file is the easiest thing to see.

sudo bpftool prog show
sudo bpftool map show
mount | grep /sys/fs/bpf

bpftool prog show lists loaded eBPF programs. bpftool map show lists the maps that hold runtime state. The mount command confirms whether the BPF filesystem is mounted where expected.

If the BPF filesystem is missing, read about mounting bpffs and handling loader permissions. A missing mount can break persistence and inspection, but adding broad capabilities is not the first fix. Check the service unit, mount namespace, and permissions that the loader actually runs with.

For Cilium agent errors, inspect the pod logs:

kubectl -n kube-system get pods -l k8s-app=cilium
kubectl -n kube-system logs <cilium-pod> --tail=200

On a systemd-managed host, also check the journal:

journalctl -b -p err
journalctl -u cilium --since "10 min ago"
dmesg -T | tail -50

journalctl shows service-level failures. dmesg shows kernel messages, including verifier errors, denied operations, missing helpers, and device problems. The kernel ring buffer is not a decoration. It is often the only place that names the failed hook.

L7 policy and encryption have real costs

Cilium can enforce policy below the application layer and add L7 controls where the traffic needs them. The trade-off is that richer decisions need richer processing.

Use L3 and L4 rules when you need reachability control. They are easier to reason about and usually stay close to the kernel datapath.

Use L7 rules when the security requirement is actually about application behavior. A rule that allows one HTTP method but denies another has value. A rule that parses every request because the dashboard offers the option has a cost.

Transparent encryption also needs a real operating plan. You must account for key distribution, node compatibility, MTU effects, rotation, and failure behavior. Encryption is not complete because a checkbox turned green.

The same rule applies to observability. Kernel events give you useful context, but they do not replace application logs. Pair flow data with journalctl, service logs, and request traces. Otherwise you know that a packet disappeared but not why the application sent it.

What are the main Cilium trade-offs?

Cilium earns its complexity when the cluster needs policy that follows workloads, service handling that does not depend on long rule chains, and visibility close to the packet path.

The costs are just as concrete:

• Kernel dependency: Required helpers, hooks, BTF data, and verifier behavior vary across distributions.
• Harder debugging: Failure may involve Kubernetes objects, eBPF maps, links, kernel logs, and policy identities.
• Migration risk: Replacing an existing CNI changes node networking and pod connectivity.
• L7 overhead: Application-aware rules may use additional processing and can fail in a different place than L3 or L4 policy.
• Upgrade coupling: Kernel, Cilium, CNI configuration, and service handling need coordinated testing.
• Operational knowledge: Someone must know how to read bpftool, dmesg, Cilium events, and policy output.

The common wrong claim is that eBPF removes operational complexity. It moves complexity into a faster and more capable layer. That is useful, but only if your team can inspect that layer when it breaks.

Who should use Cilium and who should skip it?

Use Cilium when:

• You run Kubernetes at a scale where pod churn makes IP-based policy painful.
• You need identity-based network policy.
• You want service load balancing and policy close to the kernel.
• You need flow visibility without adding a proxy to every workload.
• Your team can test kernel and CNI changes before production.
• You want one platform for networking, security policy, and observability.

Skip it when:

• You only need basic pod networking.
• Your cluster runs on kernels with limited BPF support.
• Your team cannot own the debugging path.
• You need a simple CNI with few moving parts.
• You are trying to remove every proxy from an application that still needs L7 features.
• You plan to install it beside an existing CNI without a migration design.

The right question is not whether Cilium is faster. The right question is whether the features justify the kernel-level operating burden. For a serious Kubernetes platform, often they do. For a small cluster with plain connectivity requirements, they may not.

Evaluate the secure networking company behind the project separately

To evaluate the secure networking company Cilium through its eBPF design, separate three decisions:

1. Is the open-source datapath technically suitable?
2. Can your team operate it without vendor support?
3. Do you want commercial support for the parts that fail outside business hours?

Cisco completed its acquisition of Isovalent on April 12, 2024. Isovalent is the company that created and commercially supports Cilium.

That fact matters for procurement and support planning. It does not prove that Cilium fits your cluster. Test the datapath, read the upgrade notes, inspect the licensing terms that apply to your use, and decide how much support you need before you call the technology a security strategy.

Cilium also does not make a cluster secure by itself. You still need least privilege, controlled loader permissions, audited policy changes, encrypted transport where required, and a response path for denied traffic. eBPF gives you a powerful enforcement point. It does not write the policy for you.

What does Cilium eBPF news cover?

Searches for Cilium eBPF news usually mix project releases, Linux kernel changes, and company announcements. Those are different subjects and should not be evaluated from the same headline.

For project changes, read the official documentation and release material. For kernel changes, check the kernel and distribution notes that affect your nodes. For commercial changes, read the company announcement and then verify what changed in support, licensing, or product scope.

A project release can change defaults or add a feature without changing the kernel requirements on your nodes. A kernel change can affect verifier behavior or available hooks without being a Cilium release. Keep those timelines separate or you will blame the wrong component.

What does Cilium eBPF news today mean?

The word today needs a date and an official source. On July 31, 2026, a headline published earlier may describe an old Cilium release, a kernel change, or a company event rather than a current production recommendation.

Do not treat a new eBPF feature as a production recommendation. Check whether your kernel exposes the required hook, whether Cilium enables it by default, and whether the feature changes packet handling or policy behavior. Then test it on one node group before moving the whole cluster.

If you are checking Cilium eBPF news today, compare the publication date with the date of the change itself. Then read the official project material, kernel notes, and company announcement separately. Headlines are useful for finding the event. They are not enough to decide whether your cluster should run it.

FAQ

Does Cilium replace a service mesh?

No. Cilium can handle network policy, service load balancing, encryption, and some L7 controls. A service mesh still may provide retries, request identity, traffic shaping, application-level telemetry, and other behavior that network policy does not cover.

Can I run Cilium on a cluster that already has another CNI?

Not as a casual second install. A cluster normally needs one primary CNI to own pod networking. If you want to move to Cilium, use a tested migration plan that accounts for node draining, existing interfaces, policies, and service behavior.

What happens when the kernel lacks a required eBPF feature?

Cilium may disable a feature, use a compatibility path, or fail to load the required program. Check bpftool feature probe kernel, the Cilium agent logs, dmesg, and the exact verifier error before changing policy or reinstalling the agent.

Is eBPF enough for compliance?

No. eBPF can support enforcement, auditing, and visibility, but compliance also depends on identity management, access controls, encryption, retention, change review, and evidence. Treat the datapath as one control in the system, not the whole system.

Should I write custom eBPF programs if Cilium already runs them?

Only when Cilium does not expose the signal or action you need. Start with Cilium events, cilium monitor, bpftool, and existing observability tools. Write a custom program after you can state the missing hook, data, and expected output.