feat: add configurable binding conditions support

[ttsuuubasa]

Summary

Add configurable Binding Conditions support to the DRA example driver, allowing the scheduler to defer final device binding decisions until the driver confirms device readiness on the node.

Motivation

The DRA example driver serves as a reference implementation for developers building their own DRA drivers. By demonstrating how to implement Binding Conditions — including the required ResourceSlice fields and end-to-end demo scripts — this PR helps driver developers understand the expected behavior and integration patterns for this feature introduced in Kubernetes 1.34.

Changes

Kubelet Plugin

• Feature flag: Add --binding-conditions CLI flag (env: BINDING_CONDITIONS, default: false).
• GPU Profile: When enabled, EnumerateDevices() sets BindingConditions and BindingFailureConditions on each device in the ResourceSlice.
• Helm chart: Add kubeletPlugin.bindingConditions: false to values.yaml and wire it to the kubelet plugin container env in kubeletplugin.yaml.
• Demo manifest: binding-conditions.yaml — sample manifest demonstrating the workflow.
• Kind cluster config: Enable DRADeviceBindingConditions feature gate.

Controller & E2E Tests

• dra-example-controller: New controller binary using controller-runtime with a plugin architecture.
  • plugins/bindingconditions.go: Watches allocated ResourceClaim objects and automatically satisfies binding conditions by setting the device condition to True.
  • controller.go: Generic ClaimReconciler that dispatches to registered plugins.
  • main.go: Plugin registry, flag parsing (--enable-plugin), manager setup.
• Helm templates: controller-deployment.yaml, updated clusterrole.yaml with RBAC for ResourceClaims, new values.yaml fields (controller.plugins).
• Dockerfile: Add dra-example-controller binary to the container image.
• E2E tests: Gated by BINDING_CONDITIONS=true; verify ResourceSlice fields and pod readiness lifecycle.
• Demo documentation: README.md with step-by-step walkthrough.

Testing

# E2E with binding conditions
BINDING_CONDITIONS=true make setup-e2e
BINDING_CONDITIONS=true make test-e2e

# Or run only binding conditions tests
BINDING_CONDITIONS=true go run github.com/onsi/ginkgo/v2/ginkgo --tags=e2e --focus="BindingConditions" ./test/e2e/...

Requirements

• Kubernetes 1.34+
• Feature gate: DRADeviceBindingConditions=true

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: ttsuuubasa
Once this PR has been reviewed and has the lgtm label, please assign nojnhuh for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[nojnhuh]

The example driver should be applying the condition itself instead of relying on users to do this. This better reflects how the feature is implemented and used with real drivers. The example driver doesn't have to wait for anything interesting before applying the condition, but we should include a comment saying where a real driver would wait for some real signal before adding the condition.

[ttsuuubasa]

Given the nature of the BindingConditions feature, I believe that we need to implement a controller on the example driver side to handle this. Is my understanding correct?

[nojnhuh]

Yes, the example driver doesn't run any controller currently. Ideally we set it up to be fairly generic to accommodate other features too, e.g. #71.

[ttsuuubasa]

@nojnhuh
I have added an implementation of a controller for setting BindingConditions. To ensure generality, each piece of logic is designed to be implemented as a plugin, allowing the corresponding processing to be executed by implementing its own plugin.

[nojnhuh]

Can we start putting feature-specific docs in their own directory? I think this would fit somewhere like demo/binding-conditions/README.md.

[ttsuuubasa]

I’m planning to create a new directory and move the content currently documented in the README there.

[ttsuuubasa]

@nojnhuh
The feature-specific docs for the Binding Conditions demo have been moved under demo/binding-conditions.

[nojnhuh]

Instead of a script like this, could we add validation to the e2e tests? If we update the driver to add the condition, I think all an e2e test would need to check is that the binding conditions are added to the devices in the ResourceSlices and that the Pods still become Ready and Running. We can assume that Kubernetes is behaving correctly otherwise.

[ttsuuubasa]

I’m trying to implement this in the e2e tests instead of using the current script.

[ttsuuubasa]

I have added an e2e test that verifies whether binding conditions are set on the ResourceSlice and that the Pod reaches the Running state after the controller sets the binding conditions.