Skip to content

Instantly share code, notes, and snippets.

@Billy99

Billy99/gist:b871e60f04944d4b03c9c0106d2c8a43

Last active March 21, 2025 17:04
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save Billy99/b871e60f04944d4b03c9c0106d2c8a43 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save Billy99/b871e60f04944d4b03c9c0106d2c8a43 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
gistfile1.txt
$ kubectl explain clusterbpfapplication
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
DESCRIPTION:
ClusterBpfApplication is the schema for the cluster scoped BPF Applications
API. Using this API allows applications to load one or more eBPF programs on
a Kubernetes cluster using bpfman to load the programs.
The clusterBpfApplication.status field can be used to determine if any
errors occurred in the loading of the eBPF programs. Because one eBPF
program can be loaded on multiple Kubernetes nodes, and then attached
multiple times on each Kubernetes node, clusterBpfApplication.status is just
a summary, all loaded or something failed. bpfman creates a
ClusterBpfApplicationState CRD instance for each Kubernetes Node for each
ClusterBpfApplication instance. The ClusterBpfApplicationState CRD provides
load status for each eBPF program and each of it's attachment points
(links).
FIELDS:
apiVersion <string>
APIVersion defines the versioned schema of this representation of an object.
Servers should convert recognized schemas to the latest internal value, and
may reject unrecognized values. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
kind <string>
Kind is a string value representing the REST resource this object
represents. Servers may infer this from the endpoint the client submits
requests to. Cannot be updated. In CamelCase. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
metadata <ObjectMeta>
Standard object's metadata. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec <Object>
spec defines the desired state of the ClusterBpfApplication. The
ClusterBpfApplication describes the set of one or more cluster scoped eBPF
programs that should be loaded for a given application and attributes for
how they should be loaded. eBPF programs that are grouped together under the
same ClusterBpfApplication instance can share maps and global data between
the eBPF programs loaded on the same Kubernetes Node.
status <Object>
status reflects the status of a BPF Application and indicates if all the
eBPF programs for a given instance loaded successfully or not.
$ kubectl explain clusterbpfapplication.status
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: status <Object>
DESCRIPTION:
status reflects the status of a BPF Application and indicates if all the
eBPF programs for a given instance loaded successfully or not.
FIELDS:
conditions <[]Object>
For a ClusterBpfApplication instance or a BpfApplication instance,
conditions contains the summary state for all eBPF programs defined in the
instance for all the Kubernetes nodes in the cluster.
For a ClusterBpfApplicationState instance or a BpfApplicationState instance,
conditions contains the summary state for all eBPF programs defined in the
instance for a given Kubernetes nodes.
$ kubectl explain clusterbpfapplication.spec
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: spec <Object>
DESCRIPTION:
spec defines the desired state of the ClusterBpfApplication. The
ClusterBpfApplication describes the set of one or more cluster scoped eBPF
programs that should be loaded for a given application and attributes for
how they should be loaded. eBPF programs that are grouped together under the
same ClusterBpfApplication instance can share maps and global data between
the eBPF programs loaded on the same Kubernetes Node.
FIELDS:
byteCode <Object> -required-
bytecode is a required field and configures where the eBPF program's
bytecode should be loaded from. The image must contain one or more
eBPF programs.
globalData <map[string]string>
globalData is an optional field that allows the user to set global variables
when the program is loaded. This allows the same compiled bytecode to be
deployed by different BPF Applications to behave differently based on
globalData configuration values. It uses an array of raw bytes. This is a
very low level primitive. The caller is responsible for formatting the byte
string appropriately considering such things as size, endianness, alignment
and packing of data structures.
mapOwnerSelector <Object>
mapOwnerSelector is an optional field used to share maps across
applications. eBPF programs loaded with the same ClusterBpfApplication or
BpfApplication instance do not need to use this field. This label selector
allows maps from a different ClusterBpfApplication or BpfApplication
instance to be used by this instance.
TBD: mapOwnerSelector is currently not supported due to recent code rework.
nodeSelector <Object> -required-
nodeSelector is a required field and allows the user to specify which
Kubernetes nodes to deploy the eBPF programs to. To select all nodes use
standard metav1.LabelSelector semantics and make it empty.
programs <[]Object>
programs is the list of eBPF programs in a BPF Application CRD that should
be loaded in kernel memory. eBPF programs in this list will be loaded on the
system based the nodeSelector. Even if an eBPF program is loaded in kernel
memory, it cannot be triggered until an attachment point is provided. The
different program types have different ways of attaching. The attachment
points can be added at creation time or modified (added or removed) at a
later time to activate or deactivate the eBPF program as desired.
CAUTION: When programs are added or removed from the list, that requires all
programs in the list to be reloaded, which could be temporarily service
effecting. Modifying the list is currently not allowed.
$ kubectl explain clusterbpfapplication.spec.byteCode
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: byteCode <Object>
DESCRIPTION:
bytecode is a required field and configures where the eBPF program's
bytecode should be loaded from. The image must contain one or more
eBPF programs.
FIELDS:
image <Object>
image used to specify a bytecode container image.
path <string>
path is used to specify a bytecode object via filepath.
$ kubectl explain clusterbpfapplication.spec.programs
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: programs <[]Object>
DESCRIPTION:
programs is the list of eBPF programs in a BPF Application CRD that should
be loaded in kernel memory. eBPF programs in this list will be loaded on the
system based the nodeSelector. Even if an eBPF program is loaded in kernel
memory, it cannot be triggered until an attachment point is provided. The
different program types have different ways of attaching. The attachment
points can be added at creation time or modified (added or removed) at a
later time to activate or deactivate the eBPF program as desired.
CAUTION: When programs are added or removed from the list, that requires all
programs in the list to be reloaded, which could be temporarily service
effecting. Modifying the list is currently not allowed.
FIELDS:
fentry <Object>
fentry is an optional field, but required when the type field is set to
FEntry. fentry defines the desired state of the application's FEntry
programs. FEntry programs are attached to the entry of a Linux kernel
function or to another eBPF program function. They are attached to the first
instruction, before control passes to the function. FEntry programs are
similar to KProbe programs, but have higher performance.
fexit <Object>
fexit is an optional field, but required when the type field is set to
FExit. fexit defines the desired state of the application's FExit programs.
FExit programs are attached to the exit of a Linux kernel function or to
another eBPF program function. The program is invoked when the function
returns, independent of where in the function that occurs. FExit programs
are similar to KRetProbe programs, but get invoked with the input arguments
and the return values. They also have higher performance over KRetProbe
programs.
kprobe <Object>
kprobe is an optional field, but required when the type field is set to
KProbe. kprobe defines the desired state of the application's Kprobe
programs. KProbe programs are attached to a Linux kernel function. Unlike
FEntry programs, which must always be attached at the entry point of a Linux
kernel function, KProbe programs can be attached at any point in the
function using the optional offset field. However, caution must be taken
when using the offset, ensuring the offset is still in the function
bytecode. FEntry programs have less overhead than KProbe programs.
kretprobe <Object>
kretprobe is an optional field, but required when the type field is set to
KRetProbe. kretprobe defines the desired state of the application's
KRetProbe programs. KRetProbe programs are attached to the exit of a Linux
kernel function. FExit programs have less overhead than KRetProbe programs
and FExit programs have access to both the input arguments as well as the
return values. KRetProbes only have access to the return values.
name <string> -required-
name is the name of the function that is the entry point for the eBPF
program.
tc <Object>
tc is an optional field, but required when the type field is set to TC. tc
defines the desired state of the application's TC programs. TC programs are
attached to network devices (interfaces). The program can be attached on
either packet ingress or egress, so the program will be called on every
incoming or outgoing packet seen by the network device. The TC hook point is
in Linux's Traffic Control (tc) subsystem, which is after the Linux kernel
has allocated an sk_buff. TCX is newer implementation of TC with enhanced
performance and better support for running multiple programs on a given
network device. This makes TC useful for packet classification actions.
tcx <Object>
tcx is an optional field, but required when the type field is set to TCX.
tcx defines the desired state of the application's TCX programs. TCX
programs are attached to network devices (interfaces). The program can be
attached on either packet ingress or egress, so the program will be called
on every incoming or outgoing packet seen by the network device. The TCX
hook point is in Linux's Traffic Control (tc) subsystem, which is after the
Linux kernel has allocated an sk_buff. This makes TCX useful for packet
classification actions. TCX is newer implementation of TC with enhanced
performance and better support for running multiple programs on a given
network device.
tracepoint <Object>
tracepoint is an optional field, but required when the type field is set to
Tracepoint. tracepoint defines the desired state of the application's
Tracepoint programs. Whereas KProbes hook to dynamically to any Linux kernel
function, Tracepoint programs are programs that can only be attached at
predefined locations in the Linux kernel. Use the following command to see
the available attachment points:
`sudo find /sys/kernel/debug/tracing/events -type d`
While KProbes are more flexible in where in the kernel the probe can be
attached, the functions and data structure rely on the kernel your system is
running. Tracepoints tend to be more stable across kernel versions and may
be better for portability.
type <string> -required-
enum: XDP, TC, TCX, FEntry, ....
type is a required field used to specify the type of the eBPF program. The
type dictates which eBPF hook point to use. This is where the eBPF program
is executed.
Allowed values are FEntry, FExit, KProbe, KRetProbe, TC, TCX, TracePoint,
UProbe, URetProbe and XDP.
When set to FEntry, the program is attached to the entry of a Linux kernel
function or to another eBPF program function. When using the FEntry program
type, the fentry field is required. See fentry for more details on FEntry
programs.
When set to FExit, the program is attached to the exit of a Linux kernel
function or to another eBPF program function. When using the FExit program
type, the fexit field is required. See fexit for more details on FExit
programs.
When set to KProbe, the program is attached to entry of a Linux kernel
function. When using the KProbe program type, the kprobe field is required.
See kprobe for more details on KProbe programs.
When set to KRetProbe, the program is attached to exit of a Linux kernel
function. When using the KRetProbe program type, the kretprobe field is
required. See kretprobe for more details on KRetProbe programs.
When set to TC, the eBPF program can attach to network devices (interfaces).
The program can be attached on either packet ingress or egress, so the
program will be called on every incoming or outgoing packet seen by the
network device. When using the TC program type, the tc field is required.
See tc for more details on TC programs.
When set to TCX, the eBPF program can attach to network devices
(interfaces). The program can be attached on either packet ingress or
egress, so the program will be called on every incoming or outgoing packet
seen by the network device. When using the TCX program type, the tcx field
is required. See tcx for more details on TCX programs.
When set to Tracepoint, the program can attach to one of the predefined set
of Linux kernel functions. When using the Tracepoint program type, the
tracepoint field is required. See tracepoint for more details on Tracepoint
programs.
When set to UProbe, the program can attach in user-space. The UProbe is
attached to a binary, library or function name, and optionally an offset in
the code. When using the UProbe program type, the uprobe field is required.
See uprobe for more details on UProbe programs.
When set to URetProbe, the program can attach in user-space.
The URetProbe is attached to the return of a binary, library or function
name, and optionally an offset in the code. When using the URetProbe
program type, the uretprobe field is required. See uretprobe for more
details on URetProbe programs.
When set to XDP, the eBPF program can attach to network devices (interfaces)
and will be called on every incoming packet received by the network device.
When using the XDP program type, the xdp field is required. See xdp for more
details on XDP programs.
uprobe <Object>
uprobe is an optional field, but required when the type field is set to
UProbe. uprobe defines the desired state of the application's UProbe
programs. UProbe programs are user-space probes. A target must be provided,
which is the library name or absolute path to a binary or library where the
probe is attached. Optionally, a function name can also be provided to
provide finer granularity on where the probe is attached. They can be
attached at any point in the binary, library or function using the optional
offset field. However, caution must be taken when using the offset, ensuring
the offset is still in the desired bytecode.
uretprobe <Object>
uretprobe is an optional field, but required when the type field is set to
URetProbe. uretprobe defines the desired state of the application's
URetProbe programs. URetProbe programs are user-space probes. A target must
be provided, which is the library name or absolute path to a binary or
library where the probe is attached. Optionally, a function name can also be
provided to provide finer granularity on where the probe is attached. They
are attached to the return point of the binary, library or function, but can
be set anywhere using the optional offset field. However, caution must be
taken when using the offset, ensuring the offset is still in the desired
bytecode.
xdp <Object>
xdp is an optional field, but required when the type field is set to XDP.
xdp defines the desired state of the application's XDP programs. XDP program
can be attached to network devices (interfaces) and will be called on every
incoming packet received by the network device. The XDP hook point is just
after the packet has been received off the wire, but before the Linux kernel
has allocated an sk_buff, which is used to pass the packet through the
kernel networking stack.
$ kubectl explain clusterbpfapplication.spec.programs.fentry
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: fentry <Object>
DESCRIPTION:
fentry is an optional field, but required when the type field is set to
FEntry. fentry defines the desired state of the application's FEntry
programs. FEntry programs are attached to the entry of a Linux kernel
function or to another eBPF program function. They are attached to the first
instruction, before control passes to the function. FEntry programs are
similar to KProbe programs, but have higher performance.
FIELDS:
function <string> -required-
function is required and specifies the name of the Linux kernel function to
attach the FEntry program.
links <[]Object>
The hook point for a FEntry program is a Linux kernel function. Unlike a
KProbe program, the FEntry function name is required at load time instead
of attach time. Therefore, the FEntry function is not part of links.
links is optional, but instead of being a list of hook points like other
eBPF program types, links for FEntry is a list of one, which indicates
whether the FEntry program should be attached or not. The FEntry program is
loaded in kernel memory when the BPF Application CRD is created and the
selected Kubernetes nodes are active. The FEntry program will not be
triggered until the program has also been attached. To attach, add an entry
to links with mode set to Attach. To detach, remove the link entry.
$ kubectl explain clusterbpfapplication.spec.programs.fentry.links
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: links <[]Object>
DESCRIPTION:
The hook point for a FEntry program is a Linux kernel function. Unlike a
KProbe program, the FEntry function name is required at load time instead
of attach time. Therefore, the FEntry function is not part of links.
links is optional, but instead of being a list of hook points like other
eBPF program types, links for FEntry is a list of one, which indicates
whether the FEntry program should be attached or not. The FEntry program is
loaded in kernel memory when the BPF Application CRD is created and the
selected Kubernetes nodes are active. The FEntry program will not be
triggered until the program has also been attached. To attach, add an entry
to links with mode set to Attach. To detach, remove the link entry.
FIELDS:
mode <string> -required-
enum: Attach, Detach
mode is required and its presence indicates that the FEntry program should
be attached. mode should be set to Attach. To detach the FEntry program,
remove the link entry.
$ kubectl explain clusterbpfapplication.spec.programs.fexit
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: fexit <Object>
DESCRIPTION:
fexit is an optional field, but required when the type field is set to
FExit. fexit defines the desired state of the application's FExit programs.
FExit programs are attached to the exit of a Linux kernel function or to
another eBPF program function. The program is invoked when the function
returns, independent of where in the function that occurs. FExit programs
are similar to KRetProbe programs, but get invoked with the input arguments
and the return values. They also have higher performance over KRetProbe
programs.
FIELDS:
function <string> -required-
function is required and specifies the name of the Linux kernel function to
attach the FExit program.
links <[]Object>
The hook point for a FExit program is a Linux kernel function. Unlike a
KRetProbe program, the FExit function name is required at load time instead
of attach time. Therefore, the FExit function is not part of links.
links is optional, but instead of being a list of hook points like other
eBPF program types, links for FExit is a list of one, which indicates
whether the FExit program should be attached or not. The FExit program is
loaded in kernel memory when the BPF Application CRD is created and the
selected Kubernetes nodes are active. The FExit program will not be
triggered until the program has also been attached. To attach, add an entry
to links with mode set to Attach. To detach, remove the link entry.
$ kubectl explain clusterbpfapplication.spec.programs.fexit.links
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: links <[]Object>
DESCRIPTION:
The hook point for a FExit program is a Linux kernel function. Unlike a
KRetProbe program, the FExit function name is required at load time instead
of attach time. Therefore, the FExit function is not part of links.
links is optional, but instead of being a list of hook points like other
eBPF program types, links for FExit is a list of one, which indicates
whether the FExit program should be attached or not. The FExit program is
loaded in kernel memory when the BPF Application CRD is created and the
selected Kubernetes nodes are active. The FExit program will not be
triggered until the program has also been attached. To attach, add an entry
to links with mode set to Attach. To detach, remove the link entry.
FIELDS:
mode <string> -required-
enum: Attach, Detach
mode is required and its presence indicates that the FExit program should
be attached. mode should be set to Attach. To detach the FExit program,
remove the link entry.
$ kubectl explain clusterbpfapplication.spec.programs.kprobe
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: kprobe <Object>
DESCRIPTION:
kprobe is an optional field, but required when the type field is set to
KProbe. kprobe defines the desired state of the application's Kprobe
programs. KProbe programs are attached to a Linux kernel function. Unlike
FEntry programs, which must always be attached at the entry point of a Linux
kernel function, KProbe programs can be attached at any point in the
function using the optional offset field. However, caution must be taken
when using the offset, ensuring the offset is still in the function
bytecode. FEntry programs have less overhead than KProbe programs.
FIELDS:
links <[]Object>
links is optional and is the list of hook points to which the KProbe program
should be attached. The eBPF program is loaded in kernel memory when the BPF
Application CRD is created and the selected Kubernetes nodes are active. The
eBPF program will not be triggered until the program has also been attached
to a hook point described in this list. Items may be added or removed from
the list at any point, causing the eBPF program to be attached or detached.
The hook point for a KProbe program is a Linux kernel function. By default,
the eBPF program is triggered at the entry of the hook point, but the hook
point can be adjusted using an optional offset.
$ kubectl explain clusterbpfapplication.spec.programs.kprobe.links
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: links <[]Object>
DESCRIPTION:
links is optional and is the list of hook points to which the KProbe program
should be attached. The eBPF program is loaded in kernel memory when the BPF
Application CRD is created and the selected Kubernetes nodes are active. The
eBPF program will not be triggered until the program has also been attached
to a hook point described in this list. Items may be added or removed from
the list at any point, causing the eBPF program to be attached or detached.
The hook point for a KProbe program is a Linux kernel function. By default,
the eBPF program is triggered at the entry of the hook point, but the hook
point can be adjusted using an optional offset.
FIELDS:
function <string> -required-
function is required and specifies the name of the Linux kernel function to
attach the KProbe program.
offset <integer>
offset is optional and the value is added to the address of the hook point
function.
$ kubectl explain clusterbpfapplication.spec.programs.kretprobe
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: kretprobe <Object>
DESCRIPTION:
kretprobe is an optional field, but required when the type field is set to
KRetProbe. kretprobe defines the desired state of the application's
KRetProbe programs. KRetProbe programs are attached to the exit of a Linux
kernel function. FExit programs have less overhead than KRetProbe programs
and FExit programs have access to both the input arguments as well as the
return values. KRetProbes only have access to the return values.
FIELDS:
links <[]Object>
links is optional and is the list of hook points to which the KRetProbe
program should be attached. The eBPF program is loaded in kernel memory when
the BPF Application CRD is created and the selected Kubernetes nodes are
active. The eBPF program will not be triggered until the program has also
been attached to a hook point described in this list. Items may be added or
removed from the list at any point, causing the eBPF program to be attached
or detached.
The hook point for a KRetProbe program is a Linux kernel function.
$ kubectl explain clusterbpfapplication.spec.programs.kretprobe.links
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: links <[]Object>
DESCRIPTION:
links is optional and is the list of hook points to which the KRetProbe
program should be attached. The eBPF program is loaded in kernel memory when
the BPF Application CRD is created and the selected Kubernetes nodes are
active. The eBPF program will not be triggered until the program has also
been attached to a hook point described in this list. Items may be added or
removed from the list at any point, causing the eBPF program to be attached
or detached.
The hook point for a KRetProbe program is a Linux kernel function.
FIELDS:
function <string> -required-
function is required and specifies the name of the Linux kernel function to
attach the KRetProbe program.
$ kubectl explain clusterbpfapplication.spec.programs.tc
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: tc <Object>
DESCRIPTION:
tc is an optional field, but required when the type field is set to TC. tc
defines the desired state of the application's TC programs. TC programs are
attached to network devices (interfaces). The program can be attached on
either packet ingress or egress, so the program will be called on every
incoming or outgoing packet seen by the network device. The TC hook point is
in Linux's Traffic Control (tc) subsystem, which is after the Linux kernel
has allocated an sk_buff. TCX is newer implementation of TC with enhanced
performance and better support for running multiple programs on a given
network device. This makes TC useful for packet classification actions.
FIELDS:
links <[]Object>
links is optional and is the list of hook points to which the TC program
should be attached. The TC program is loaded in kernel memory when the BPF
Application CRD is created and the selected Kubernetes nodes are active.
The TC program will not be triggered until the program has also been
attached to an attachment point described in this list. Items may be added
or removed from the list at any point, causing the TC program to be
attached or detached.
The hook point for a TC program is an interface (or network device). An
interface can be specified by name, or using the primaryNodeInterface flag,
which indicates to use the primary interface of a Kubernetes node or
container. Optionally, the TC program can be installed in a set of
containers.
$ kubectl explain clusterbpfapplication.spec.programs.tc.links
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: links <[]Object>
DESCRIPTION:
links is optional and is the list of hook points to which the TC program
should be attached. The TC program is loaded in kernel memory when the BPF
Application CRD is created and the selected Kubernetes nodes are active.
The TC program will not be triggered until the program has also been
attached to an attachment point described in this list. Items may be added
or removed from the list at any point, causing the TC program to be
attached or detached.
The hook point for a TC program is an interface (or network device). An
interface can be specified by name, or using the primaryNodeInterface flag,
which indicates to use the primary interface of a Kubernetes node or
container. Optionally, the TC program can be installed in a set of
containers.
FIELDS:
containers <Object>
containers is an optional field that identifies the set of containers in
which to attach the TC program. If containers is not specified, the TC
program will be attached in the root network namespace.
direction <string> -required-
enum: Ingress, Egress
direction is required and specifies the direction of traffic the TC program
should attach to for a given network device. Allowed values are:
Ingress and Egress
interfaceSelector <Object> -required-
interfaceSelector is required and is used to determine the network interface
(or interfaces) the TC program is attached. Either a list of interface
names (which can be a list of one name) or primaryNodeInterface flag must be
provided, but not both.
priority <integer> -required-
priority is required and specifies the order of the TC program is executed
in relation to other TC programs with the same hook point. It is a value
from 0 to 1000, where lower values have higher precedence.
proceedOn <[]string>
proceedOn is optional and allows the user to call other TC programs in a
chain, or not call the next program in a chain based on the exit code of
a TC program. Allowed values are:
UnSpec, OK, ReClassify, Shot, Pipe, Stolen, Queued, Repeat, ReDirect,
Trap and DispatcherReturn
Multiple values are supported. Default is Pipe and DispatcherReturn. So
using the default values, if a TC program returns Pipe, the next TC
program in the chain will be called. If a TC program returns Stolen, the
next TC program in the chain will NOT be called.
$ kubectl explain clusterbpfapplication.spec.programs.tc.links.containers
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: containers <Object>
DESCRIPTION:
containers is an optional field that identifies the set of containers in
which to attach the TC program. If containers is not specified, the TC
program will be attached in the root network namespace.
FIELDS:
containerNames <[]string>
containerNames is optional and indicate the name(s) of container(s). If
none are specified, all containers in the pod are selected.
namespace <string>
namespace is optional and indicates the target namespaces. If not provided,
the default Kubernetes namespace is used.
pods <Object> -required-
pods is required and indicate the target pods. To select all pods use the
standard metav1.LabelSelector semantics and make it empty.
$ kubectl explain clusterbpfapplication.spec.programs.tc.links.interfaceSelector
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: interfaceSelector <Object>
DESCRIPTION:
interfaceSelector is required and is used to determine the network interface
(or interfaces) the TC program is attached. Either a list of interface
names (which can be a list of one name) or primaryNodeInterface flag must be
provided, but not both.
FIELDS:
interfaces <[]string>
interfaces is optional and is a list of network interface names to attach
the eBPF program.
primaryNodeInterface <boolean>
primaryNodeInterface is optional and indicates to attach the eBPF program to
the primary interface on the Kubernetes node. Only 'true' is accepted.
kubectl explain clusterbpfapplication.spec.programs.tcx
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: tcx <Object>
DESCRIPTION:
tcx is an optional field, but required when the type field is set to TCX.
tcx defines the desired state of the application's TCX programs. TCX
programs are attached to network devices (interfaces). The program can be
attached on either packet ingress or egress, so the program will be called
on every incoming or outgoing packet seen by the network device. The TCX
hook point is in Linux's Traffic Control (tc) subsystem, which is after the
Linux kernel has allocated an sk_buff. This makes TCX useful for packet
classification actions. TCX is newer implementation of TC with enhanced
performance and better support for running multiple programs on a given
network device.
FIELDS:
links <[]Object>
links is optional and is the list of hook points to which the TCX program
should be attached. The TCX program is loaded in kernel memory when the BPF
Application CRD is created and the selected Kubernetes nodes are active.
The TCX program will not be triggered until the program has also been
attached to an attachment point described in this list. Items may be added
or removed from the list at any point, causing the TCX program to be
attached or detached.
The hook point for a TCX program is an interface (or network device). An
interface can be specified by name, or using the primaryNodeInterface flag,
which indicates to use the primary interface of a Kubernetes node or
container. Optionally, the TCX program can be installed in a set of
containers.
$ kubectl explain clusterbpfapplication.spec.programs.tcx.links
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: links <[]Object>
DESCRIPTION:
links is optional and is the list of hook points to which the TCX program
should be attached. The TCX program is loaded in kernel memory when the BPF
Application CRD is created and the selected Kubernetes nodes are active.
The TCX program will not be triggered until the program has also been
attached to an attachment point described in this list. Items may be added
or removed from the list at any point, causing the TCX program to be
attached or detached.
The hook point for a TCX program is an interface (or network device). An
interface can be specified by name, or using the primaryNodeInterface flag,
which indicates to use the primary interface of a Kubernetes node or
container. Optionally, the TCX program can be installed in a set of
containers.
FIELDS:
containers <Object>
containers is an optional field that identifies the set of containers in
which to attach the TCX program. If containers is not specified, the TCX
program will be attached in the root network namespace.
direction <string> -required-
enum: Ingress, Egress
direction is required and specifies the direction of traffic the TCX program
should attach to for a given network device. Allowed values are:
Ingress and Egress
interfaceSelector <Object> -required-
interfaceSelector is required and is used to determine the network interface
(or interfaces) the TCX program is attached. Either a list of interface
names (which can be a list of one name) or primaryNodeInterface flag must be
provided, but not both.
priority <integer> -required-
priority is required and specifies the order of the TCX program is executed
in relation to other TCX programs with the same hook point. It is a value
from 0 to 1000, where lower values have higher precedence.
$ kubectl explain clusterbpfapplication.spec.programs.tracepoint
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: tracepoint <Object>
DESCRIPTION:
tracepoint is an optional field, but required when the type field is set to
Tracepoint. tracepoint defines the desired state of the application's
Tracepoint programs. Whereas KProbes hook to dynamically to any Linux kernel
function, Tracepoint programs are programs that can only be attached at
predefined locations in the Linux kernel. Use the following command to see
the available attachment points:
`sudo find /sys/kernel/debug/tracing/events -type d`
While KProbes are more flexible in where in the kernel the probe can be
attached, the functions and data structure rely on the kernel your system is
running. Tracepoints tend to be more stable across kernel versions and may
be better for portability.
FIELDS:
links <[]Object>
links is optional and is the list of hook points to which the Tracepoint
program should be attached. The Tracepoint program is loaded in kernel
memory when the BPF Application CRD is created and the selected Kubernetes
nodes are active. The Tracepoint program will not be triggered until the
program has also been attached to an attachment point described in this
list. Items may be added or removed from the list at any point, causing the
Tracepoint program to be attached or detached.
The hook point for a Tracepoint program is a one of a predefined set of
Linux kernel functions. n interface (or network device).
$ kubectl explain clusterbpfapplication.spec.programs.tracepoint.links
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: links <[]Object>
DESCRIPTION:
links is optional and is the list of hook points to which the Tracepoint
program should be attached. The Tracepoint program is loaded in kernel
memory when the BPF Application CRD is created and the selected Kubernetes
nodes are active. The Tracepoint program will not be triggered until the
program has also been attached to an attachment point described in this
list. Items may be added or removed from the list at any point, causing the
Tracepoint program to be attached or detached.
The hook point for a Tracepoint program is a one of a predefined set of
Linux kernel functions.
FIELDS:
name <string> -required-
name is required and refers to the name of a Linux kernel Tracepoint to
attach the eBPF program.
$ kubectl explain clusterbpfapplication.spec.programs.uprobe
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: uprobe <Object>
DESCRIPTION:
uprobe is an optional field, but required when the type field is set to
UProbe. uprobe defines the desired state of the application's UProbe
programs. UProbe programs are user-space probes. A target must be provided,
which is the library name or absolute path to a binary or library where the
probe is attached. Optionally, a function name can also be provided to
provide finer granularity on where the probe is attached. They can be
attached at any point in the binary, library or function using the optional
offset field. However, caution must be taken when using the offset, ensuring
the offset is still in the desired bytecode.
FIELDS:
links <[]Object>
links is optional and is the list of hook points to which the UProbe
or URetProbe program should be attached. The eBPF program is loaded in
kernel memory when the BPF Application CRD is created and the selected
Kubernetes nodes are active. The eBPF program will not be triggered until
the program has also been attached to a hook point described in this list.
Items may be added or removed from the list at any point, causing the eBPF
program to be attached or detached.
The hook point for a UProbe and URetProbe program is a user-space binary,
library or function. By default, the eBPF program is triggered at the entry
of the hook point, but the hook point can be adjusted using an optional
offset. Optionally, the eBPF program can be installed in a set of containers
or limited to a specified PID.
$ kubectl explain clusterbpfapplication.spec.programs.uprobe.links
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: links <[]Object>
DESCRIPTION:
links is optional and is the list of hook points to which the UProbe
or URetProbe program should be attached. The eBPF program is loaded in
kernel memory when the BPF Application CRD is created and the selected
Kubernetes nodes are active. The eBPF program will not be triggered until
the program has also been attached to a hook point described in this list.
Items may be added or removed from the list at any point, causing the eBPF
program to be attached or detached.
The hook point for a UProbe and URetProbe program is a user-space binary,
library or function. By default, the eBPF program is triggered at the entry
of the hook point, but the hook point can be adjusted using an optional
offset. Optionally, the eBPF program can be installed in a set of containers
or limited to a specified PID.
FIELDS:
containers <Object>
containers is an optional field that identifies the set of containers in
which to attach the UProbe or URetProbe program. If containers is not
specified, the eBPF program will be attached in the bpfman-agent container.
function <string>
function is optional and specifies the name of user-space function to attach
the UProbe or URetProbe program. If not provided, the eBPF program will be
triggered on the entry of the target.
offset <integer>
offset is optional and the value is added to the address of the hook point
function.
pid <integer>
pid is optional and if provided, limits the execution of the UProbe or
URetProbe to the provided process identification number (PID). If pid is not
provided, the UProbe or URetProbe executes for all PIDs.
target <string> -required-
target is required and is the user-space library name or the absolute path
to a binary or library.
$ kubectl explain clusterbpfapplication.spec.programs.uretprobe
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: uretprobe <Object>
DESCRIPTION:
uretprobe is an optional field, but required when the type field is set to
URetProbe. uretprobe defines the desired state of the application's
URetProbe programs. URetProbe programs are user-space probes. A target must
be provided, which is the library name or absolute path to a binary or
library where the probe is attached. Optionally, a function name can also be
provided to provide finer granularity on where the probe is attached. They
are attached to the return point of the binary, library or function, but can
be set anywhere using the optional offset field. However, caution must be
taken when using the offset, ensuring the offset is still in the desired
bytecode.
FIELDS:
links <[]Object>
links is optional and is the list of hook points to which the UProbe
or URetProbe program should be attached. The eBPF program is loaded in
kernel memory when the BPF Application CRD is created and the selected
Kubernetes nodes are active. The eBPF program will not be triggered until
the program has also been attached to a hook point described in this list.
Items may be added or removed from the list at any point, causing the eBPF
program to be attached or detached.
The hook point for a UProbe and URetProbe program is a user-space binary,
library or function. By default, the eBPF program is triggered at the entry
of the hook point, but the hook point can be adjusted using an optional
offset. Optionally, the eBPF program can be installed in a set of containers
or limited to a specified PID.
$ kubectl explain clusterbpfapplication.spec.programs.uretprobe.links
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: links <[]Object>
DESCRIPTION:
links is optional and is the list of hook points to which the UProbe
or URetProbe program should be attached. The eBPF program is loaded in
kernel memory when the BPF Application CRD is created and the selected
Kubernetes nodes are active. The eBPF program will not be triggered until
the program has also been attached to a hook point described in this list.
Items may be added or removed from the list at any point, causing the eBPF
program to be attached or detached.
The hook point for a UProbe and URetProbe program is a user-space binary,
library or function. By default, the eBPF program is triggered at the entry
of the hook point, but the hook point can be adjusted using an optional
offset. Optionally, the eBPF program can be installed in a set of containers
or limited to a specified PID.
FIELDS:
containers <Object>
containers is an optional field that identifies the set of containers in
which to attach the UProbe or URetProbe program. If containers is not
specified, the eBPF program will be attached in the bpfman-agent container.
function <string>
function is optional and specifies the name of user-space function to attach
the UProbe or URetProbe program. If not provided, the eBPF program will be
triggered on the entry of the target.
offset <integer>
offset is optional and the value is added to the address of the hook point
function.
pid <integer>
pid is optional and if provided, limits the execution of the UProbe or
URetProbe to the provided process identification number (PID). If pid is not
provided, the UProbe or URetProbe executes for all PIDs.
target <string> -required-
target is required and is the user-space library name or the absolute path
to a binary or library.
$ kubectl explain clusterbpfapplication.spec.programs.xdp
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: xdp <Object>
DESCRIPTION:
xdp is an optional field, but required when the type field is set to XDP.
xdp defines the desired state of the application's XDP programs. XDP program
can be attached to network devices (interfaces) and will be called on every
incoming packet received by the network device. The XDP hook point is just
after the packet has been received off the wire, but before the Linux kernel
has allocated an sk_buff, which is used to pass the packet through the
kernel networking stack.
FIELDS:
links <[]Object>
links is optional and is the list of hook points to which the XDP program
should be attached. The XDP program is loaded in kernel memory when the BPF
Application CRD is created and the selected Kubernetes nodes are active.
The XDP program will not be triggered until the program has also been
attached to an attachment point described in this list. Items may be added
or removed from the list at any point, causing the XDP program to be
attached or detached.
The hook point for an XDP program is an interface (or network device). An
interface can be specified by name, or using the primaryNodeInterface flag,
which indicates to use the primary interface of a Kubernetes node or
container. Optionally, the XDP program can be installed in a set of
containers.
$ kubectl explain clusterbpfapplication.spec.programs.xdp.links
GROUP: bpfman.io
KIND: ClusterBpfApplication
VERSION: v1alpha1
FIELD: links <[]Object>
DESCRIPTION:
links is optional and is the list of hook points to which the XDP program
should be attached. The XDP program is loaded in kernel memory when the BPF
Application CRD is created and the selected Kubernetes nodes are active.
The XDP program will not be triggered until the program has also been
attached to an attachment point described in this list. Items may be added
or removed from the list at any point, causing the XDP program to be
attached or detached.
The hook point for an XDP program is an interface (or network device). An
interface can be specified by name, or using the primaryNodeInterface flag,
which indicates to use the primary interface of a Kubernetes node or
container. Optionally, the XDP program can be installed in a set of
containers.
FIELDS:
containers <Object>
containers is an optional field that identifies the set of containers in
which to attach the XDP program. If containers is not specified, the XDP
program will be attached in the root network namespace.
interfaceSelector <Object> -required-
interfaceSelector is required and is used to determine the network interface
(or interfaces) the XDP program is attached. Either a list of interface
names (which can be a list of one name) or primaryNodeInterface flag must be
provided, but not both.
priority <integer> -required-
priority is required and specifies the order of the XDP program is executed
in relation to other XDP programs with the same hook point. It is a value
from 0 to 1000, where lower values have higher precedence.
proceedOn <[]string>
proceedOn is optional and allows the user to call other XDP programs in a
chain, or not call the next program in a chain based on the exit code of
an XDP program. Allowed values are:
Aborted, Drop, Pass, TX, ReDirect and DispatcherReturn
Multiple values are supported. Default is Pass and DispatcherReturn. So
using the default values, if an XDP program returns Pass, the next XDP
program in the chain will be called. If an XDP program returns Drop, the
next XDP program in the chain will NOT be called.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment