From Fedora Project Wiki
< Changes
Line 162: | Line 162: | ||
* https://bpfman.io/main/ | * https://bpfman.io/main/ | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
== Release Notes == | == Release Notes == |
Revision as of 07:42, 10 January 2024
Fedora 40: Bpfman as default eBPF manager (Self-Contained Change proposal)
Summary
Owner
- Name: Daniel Mellado
- Email: dmellado@fedoraproject.org
- Name: Dave Tucker
- Email: datucker@redhat.com
- Name: Toke Høiland-Jørgensen
- Email: thoiland@redhat.com
Current status
- Targeted release: Fedora Linux 40
- Last updated: 2024-01-10
- [<will be assigned by the Wrangler> devel thread]
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
bpfman operates as an eBPF manager, focusing on simplifying the deployment and administration of eBPF programs. bpfman is a software stack that aims to make it easy to load, unload, modify and monitor eBPF programs whether on a single host, or in a Kubernetes cluster. bpfman includes the following core components:
- bpfman: A system daemon that supports loading, unloading, modifying and monitoring of eBPF programs exposed over a gRPC API.
- eBPF CRDS: bpfman provides a set of CRDs (XdpProgram, TcProgram, etc.) that provide a way to express intent to load eBPF programs as well as a bpfman generated CRD (BpfProgram) used to represent the runtime state of loaded programs.
- bpfman-agent: The agent runs in a container in the bpfman daemonset and ensures that the requested eBPF programs for a given node are in the desired state.
- bpfman-operator: An operator, built using Operator SDK, that manages the installation and lifecycle of bpfman-agent and the CRDs in a Kubernetes cluster.
bpfman is developed in Rust and built on top of Aya, a Rust eBPF library.
Feedback
Benefit to Fedora
Scope
- Proposal owners:
- Other developers:
- Release engineering: #Releng issue number
- Policies and guidelines: N/A (not needed for this Change)
- Trademark approval: N/A (not needed for this Change)
- Alignment with Community Initiatives: N/A
Upgrade/compatibility impact
How To Test
User Experience
Dependencies
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), No