feat(node-agent): advertise the RDMA extended resource from a simulator

[giuliocalzo]

Summary

Mock InfiniBand nodes did not report rdma/ib, so a workload gated on that resource stayed Pending however complete the node's IB surface was. On real hardware the Network Operator's k8s-rdma-shared-dev-plugin advertises it; that plugin cannot run against the mock, because it is a Go binary whose syscalls the LD_PRELOAD sysfs redirect never sees, and it discovers HCAs through netdevs the mock does not render.

A new node-agent simulator, internal/agent/rdmaplugin, stands in for it — the bridge role pcibus.Apply's NFD feature file plays for PCI presence:

• Profiles declare the resource under infiniband.rdma_resource; all five IB-enabled profiles ship rdma/ib = 64. Upstream that count is rdmaHcaMax, a pod-sharing limit rather than a device count, so a 4-GPU GB300 compute tray reports 64 while carrying 4 HCAs.
• Apply patches .status.capacity and Revoke withdraws the key, because kubelet never removes capacity it does not own. The simulator is an Applier only — no daemon, no re-assertion ticker — so the resource is republished on the next reconcile rather than on a clock of its own.
• It converges rather than only materializing. Renaming or dropping the block withdraws the previous key instead of stranding it, and a node already reporting the right value costs one GET rather than a write, which is what makes re-running Apply cheap.
• The node-agent container gains NODE_NAME, without which the compiled State carries no node identity and there is nothing to patch. This also fixes state.Node.NodeName being empty for every simulator in that container, same as feat(node-agent): Node Agent CDI Simulator #728.
• Validation moved out of chart helpers into Stage, so it also covers gpu.customConfig and the Control Plane source that will replace the file source.

MEP-0003's simulator and InfiniBand surface tables gain the package, plus a note on why a node resource with no other publisher is owned by a simulator while node labels stay delegated to NFD and GFD. Happy to drop those edits if @roma-glushko would rather fold this into ibhca.

Known limitations

• Pods requesting the resource schedule and run but get no device injection: the mock's IB surface reaches containers through the hostPath tree and LD_PRELOAD shims, not /dev/infiniband char devices.
• Advertising needs patch on nodes/status, which the chart's ClusterRole now grants.
• The DaemonSet's terminationGracePeriodSeconds: 2 is below nodeAgent.shutdownTimeout: 30s. Revoke is one GET plus one PATCH so it normally lands well inside 2s, but a SIGKILL at the grace boundary would leave a stale rdma/ib key on the node. Left alone here since raising it affects every container and slows rollouts.

Test plan

• make test — green outside the sandbox; pkg/gpu/allocwatch and pkg/network/mockib/daemon fail inside it only because unix-socket bind is blocked
• make lint-fix — 0 issues
• make helm-tests — 175 tests, 15 snapshots, snapshots refreshed for the new NODE_NAME env and the profile blocks
• internal/agent/rdmaplugin unit tests drive a fake node API that applies the patches it receives, so they assert on resulting capacity: advertise, no-op when already correct, update on count change, withdraw on rename/removal, revoke idempotently, tolerate a deleted node, republish after an external removal, and reject an unqualified name, a non-positive count or an empty NODE_NAME
• internal/agent/source sweeps every chart profile, so an IB profile that forgets the block fails CI
• Live check on a Kind cluster: kubectl get node -o jsonpath='{.status.capacity}' shows rdma/ib: 64 and is gone after helm uninstall

[roma-glushko]

@giuliocalzo let's consider whether Mokka Control Plane is the right place for this functionality. The Control Plane has access to K8s by definition, so it seems like a better place. I would like to keep node agent K8s agnostic as much as possible.

Let me know what do you think?

[giuliocalzo]

@giuliocalzo let's consider whether Mokka Control Plane is the right place for this functionality. The Control Plane has access to K8s by definition, so it seems like a better place. I would like to keep node agent K8s agnostic as much as possible.

Let me know what do you think?

@roma-glushko this feature is core one, very likely of internal/agent/pcibus/pcibus.go the agent should apply itself without the needs of the Control Plane