Repository: kubernetes
Issue: Deleting a PVC is blocked because it is still referenced by a completed job
Labels: kind/bug,sig/storage,triage/accepted,wg/batch

### What happened?

When a job that mounts a PVC reaches a completed state, the PVC can't be deleted because it is still "bound" to the completed job. 

To successfully delete the PVC, you'll need to first delete the job, and then delete the PVC. 

### What did you expect to happen?

My expectation is that after the job is **complete**, the PVC should no longer be bound to that job. And therefore can be deleted independently. 

### How can we reproduce it (as minimally and precisely as possible)?

1. Create a PVC

```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pvc-with-job
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 800M
```

2. Create a job that uses that pvc and make sure the job is successful

```
apiVersion: batch/v1
kind: Job
metadata:
  name: test-pvc-not-deleted
spec:
  template:
    metadata:
    spec:
      containers:
      - command:
        - echo
        image: ubuntu:latest
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /example
          name: example
        name: test
      restartPolicy: Never
      volumes:
      - name: example
        persistentVolumeClaim:
          claimName: test-pvc-with-job
```

3. Run `kubectl get job` and observe that the job is successful. For example
```
 kubectl get jobs
 
NAME                   COMPLETIONS   DURATION   AGE
test-pvc-not-deleted   1/1           5s         87m
```

4. Attempt to delete the PVC (`kubectl delete pvc/test-pvc-with-job` - you will notice that the pvc deletion is stuck and is unable to get deleted)
```
kubectl get pvc test-pvc-with-job

NAME                STATUS        VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
test-pvc-with-job   Terminating   pvc-d7769c51-327f-40df-acc4-b0e412014ec3   800M       RWO            standard       101
```

### Anything else we need to know?

_No response_

### Kubernetes version

<details>

```console
$ kubectl version
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.1", GitCommit:"4c9411232e10168d7b050c49a1b59f6df9d7ea4b", GitTreeState:"clean", BuildDate:"2023-04-14T13:14:41Z", GoVersion:"go1.20.3", Compiler:"gc", Platform:"darwin/amd64"}
Kustomize Version: v5.0.1
Server Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.3", GitCommit:"9e644106593f3f4aa98f8a84b23db5fa378900bd", GitTreeState:"clean", BuildDate:"2023-03-15T13:33:12Z", GoVersion:"go1.19.7", Compiler:"gc", Platform:"linux/amd64"}
```

</details>


### Cloud provider

<details>
I ran this on minikube but I expected other cloud providers will experience the same limitation 
</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>