Guides
The guides give the steps for the two tasks this operator exists for: the install, and the pairing that gives a controller to one pod.
How the pieces fit
Four kinds of Dynamic Resource Allocation (DRA) object take a controller from the radio to your container.
The operator publishes what exists. It writes one ResourceSlice
for each node, and the slice lists that node’s paired controllers
with their attributes. The slices are the inventory the scheduler
reads.
A DeviceClass names a kind of device a workload can ask for. The
deploy base ships only the operator’s own bluetooth-adapter; the
class your workloads claim through is yours to create, and
Install the operator gives the YAML:
bluetooth-input names a paired input device. A class can be
generic like that one, or specific down to a single device;
Generic or specific
weighs the choice. A workload asks
with a ResourceClaim, or with a ResourceClaimTemplate under a
Deployment. The claim’s selector is a
Common Expression Language (CEL)
expression over the published attributes:
device.attributes["bluetooth.liken.sh"].address == "A0:AB:51:33:B7:12"
selects one controller by its MAC address.
The scheduler matches the claim against the slices, allocates one
device, and places the pod on that device’s node. The
bluetooth.liken.sh driver then delivers the device: the kubelet
calls it to prepare the claim, and the container starts with the
controller’s evdev nodes.