Workloads corresponding to Jobs deleted with --cascede=orphan still consume resources

[mimowo]

What happened:

Job deleted with --cascade=orphan continues to reserve ClusterQueue resources.

Note this is a "known" issue, which is a follow up to https://github.com/kubernetes-sigs/kueue/issues/1726

What you expected to happen:

Jobs deleted with --cascade=orphan should free the cluster resources.

How to reproduce it (as minimally and precisely as possible):

1. Create a job with

   
   apiVersion: batch/v1

kind: Job metadata: name: sample-job namespace: default labels: kueue.x-k8s.io/queue-name: user-queue spec: parallelism: 3 completions: 3 suspend: true template: spec: containers:

• name: dummy-job image: gcr.io/k8s-staging-perf-tests/sleep:v0.0.3 args: ["1800s"] resources: requests: cpu: "1" memory: "200Mi" restartPolicy: Never

  
  2. Delete the job with `kubectl delete job/sample-job --cascade=orphan`

Issue: The deleted job continues to reserve cluster queue resources:

kubectl get clusterqueue -oyaml returns:

...
  status:
    admittedWorkloads: 1
    conditions:
    - lastTransitionTime: "2024-03-04T10:41:42Z"
      message: Can admit new workloads
      reason: Ready
      status: "True"
      type: Active
    flavorsReservation:
    - name: default-flavor
      resources:
      - borrowed: "0"
        name: cpu
        total: "3"
      - borrowed: "0"
        name: memory
        total: 600Mi
    flavorsUsage:
    - name: default-flavor
      resources:
      - borrowed: "0"
        name: cpu
        total: "3"
      - borrowed: "0"
        name: memory
        total: 600Mi
    pendingWorkloads: 0
    reservingWorkloads: 1

Anything else we need to know?:

Environment:

• Kubernetes version (use kubectl version):
• Kueue version (use git describe --tags --dirty --always):
• Cloud provider or hardware configuration:
• OS (e.g: cat /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Others:

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[tenzen-y]

/remove-lifecycle stale

I think that this is still a valid, known issue. I think that mentioning this in the documentation would be worth it.