GPU Admission on Kueue: policy before the queue

Raw ClusterQueue quota answers "is there capacity?" It does not answer "may this team run this GPU flavor, from this registry, with these FinOps labels, under this soft budget?" That gap is where GPU jobs sneak past platform policy.

This guide is scoped to gpu-admission-kueue and the GPU Admission on Kueue case. Claims about behaviour and evidence apply on that project's corpus only (kind, upstream Kueue, emulated nvidia.com/gpu).

The gap ClusterQueue leaves open

Kueue is strong at admission and cohort borrowing while leaving kube-scheduler to place pods. That is why it often wins over replacing the scheduler (see Kueue vs Volcano vs KAI).

What ClusterQueue still does not express cleanly for GPU platforms:

• team or namespace caps beyond raw device counts
• allowed GPU flavors / resource shapes
• required FinOps or ownership labels
• GPU-hour or soft budget ceilings
• image registry allowlists for GPU workloads

Without an extra gate, a correctly labeled Workload that fits quota can still be the wrong job for your policy.

AdmissionCheck as the extension point

Upstream Kueue AdmissionChecks let an external controller participate after quota is reserved. In gpu-admission-kueue:

1. Kueue reserves quota for the Workload.
2. The admission controller evaluates a cluster-scoped GPUAdmissionPolicy.
3. It sets the check to Ready (ALLOW), Retry (HOLD) on soft quota pressure, or Rejected (DENY).
4. Every decision writes an ASC-compatible evidence envelope (ConfigMap) with policy version and inputs.

Controller name used in the project: gpu-admission.justrunme.com/admission-check. The design stays on upstream Kueue, not a fork.

Fail-closed by default

That is the same fail-closed posture as the tool gate on the MCP plane (Agent Security Contract): unavailable policy must not become an implicit allow.

What the evidence covers

From the case and repo evidence files (checked 2026-11-02):

• 8 e2e scenarios on kind with upstream Kueue: allow_golden, missing_labels, disallowed_flavor, bad_registry, ghcr_evil_prefix, over_quota_hold, malformed_policy, controller_down_fail_closed
• GPUs are emulated as an extended resource — nothing here measures physical GPU utilization
• CI run linked from the case evidence narrative

Read those numbers as suite results on this corpus, not as a multi-cluster production SLO.

When you need this guide vs the comparison

Operational checklist

• Keep kube-scheduler as placer unless you explicitly chose Volcano/KAI
• Define GPUAdmissionPolicy for flavors, labels, registries and soft budgets before enabling the check
• Register the AdmissionCheck with the documented controller name
• Verify fail-closed: stop the controller in a lab and confirm Workloads stay Pending
• Store and retain evidence envelopes with policy version
• Rehearse HOLD under soft quota and DENY on bad registry / missing labels
• Pin Kueue and controller versions; treat the kind corpus as methodology, not capacity planning
• Export admission metrics next to GPU queue wait and inference cost signals

References

• GPU Admission on Kueue case: https://justrunme.com/cases/gpu-admission-kueue/
• Repository: https://github.com/justrunme/gpu-admission-kueue
• Kueue AdmissionChecks concepts: https://kueue.sigs.k8s.io/docs/concepts/admission_check/
• Related comparison: Kueue vs Volcano vs KAI
• Agent Security Contract (evidence envelope lineage): https://justrunme.com/cases/agent-security-contract/