### What happened?

A pod which is deleted during image pull continues the pull, and starts. It may even succeed if the SIGTERM handler exists with 0.

### What did you expect to happen?

Pods which are deleted long before running, for example, during image pull should not start.

### How can we reproduce it (as minimally and precisely as possible)?

0. Setup a watch for the pods: `kubectl get pods -w --output-watch-events -oyaml`
1. Create the following job using a large image:
```yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: indexed-job
spec:
  completions: 1
  parallelism: 1
  backoffLimit: 0
  completionMode: Indexed
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: usybox
          image: nvidia/cuda:11.8.0-devel-ubuntu22.04
          command: ["bash"]
          args:
          - "-c"
          - |
            #!/bin/bash
            terminate() {
              echo "SIGTERM received, exiting with status 0"
              exit 0
            }
            trap 'terminate' SIGTERM
            while true; do
              sleep 1
            done
```

2. Delete the pod `kubectl delete pods/<pod-name>`
3. Observe the events for the pod. There will be update indicating the pod has `Running` phase, and then `Succeeded`.
Example timeline for testing:
1. `2024-05-20T10:36:13Z` - pod created, scheduled and started to pull the image; phase `Pending`, state `ContainerCreating`
2. `2024-05-20T10:36:37Z` - manual deletion, `deletionTimestamp: "2024-05-20T10:37:07Z"`
3. `2024-05-20T10:37:28Z` - pod is running; `phase=Running`
4. `2024-05-20T10:37:29Z` - pod is completed, `phase=Succeeded`

### Anything else we need to know?

This is closely related to https://github.com/kubernetes/kubernetes/issues/122905. If the pull is interrupted it should also address this issue, but maybe there is some easier fix just for this issue.

Currently the issue is mostly about surprise when a user is not expecting a deleted pod to start. Especially since the pod might be deleted long (tested about 1min, but potentially even longer) before it starts.

### Kubernetes version

<details>

```console
Client Version: v1.28.1
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.29.1-gke.1589020
```

</details>


### Cloud provider

<details>
GKE, Kind
</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>

Pod deleted during image pull still starts
This is a GitHub Issue
repo:kubernetes
owner:kubernetes
Title : Pod deleted during image pull still starts
Issue date:

--- start body ---
### What happened?

A pod which is deleted during image pull continues the pull, and starts. It may even succeed if the SIGTERM handler exists with 0.

### What did you expect to happen?

Pods which are deleted long before running, for example, during image pull should not start.

### How can we reproduce it (as minimally and precisely as possible)?

0. Setup a watch for the pods: `kubectl get pods -w --output-watch-events -oyaml`
1. Create the following job using a large image:
```yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: indexed-job
spec:
  completions: 1
  parallelism: 1
  backoffLimit: 0
  completionMode: Indexed
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: usybox
          image: nvidia/cuda:11.8.0-devel-ubuntu22.04
          command: ["bash"]
          args:
          - "-c"
          - |
            #!/bin/bash
            terminate() {
              echo "SIGTERM received, exiting with status 0"
              exit 0
            }
            trap 'terminate' SIGTERM
            while true; do
              sleep 1
            done
```

2. Delete the pod `kubectl delete pods/<pod-name>`
3. Observe the events for the pod. There will be update indicating the pod has `Running` phase, and then `Succeeded`.
Example timeline for testing:
1. `2024-05-20T10:36:13Z` - pod created, scheduled and started to pull the image; phase `Pending`, state `ContainerCreating`
2. `2024-05-20T10:36:37Z` - manual deletion, `deletionTimestamp: "2024-05-20T10:37:07Z"`
3. `2024-05-20T10:37:28Z` - pod is running; `phase=Running`
4. `2024-05-20T10:37:29Z` - pod is completed, `phase=Succeeded`

### Anything else we need to know?

This is closely related to https://github.com/kubernetes/kubernetes/issues/122905. If the pull is interrupted it should also address this issue, but maybe there is some easier fix just for this issue.

Currently the issue is mostly about surprise when a user is not expecting a deleted pod to start. Especially since the pod might be deleted long (tested about 1min, but potentially even longer) before it starts.

### Kubernetes version

<details>

```console
Client Version: v1.28.1
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.29.1-gke.1589020
```

</details>


### Cloud provider

<details>
GKE, Kind
</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>

--- end body ---
