Repository: kubernetes
Issue: grace-period=0 --force  Forced deletion failed
Labels: kind/bug,sig/node,priority/important-longterm,needs-triage

### What happened?

<img width="1510" alt="image" src="https://user-images.githubusercontent.com/29618214/200506702-f2db6a88-4587-4db8-afd4-95cbe68d31cc.png">
A case where Forced deletion does not stop! (Example: container is in sleep 9999 state) when I first kubectl delete pod --grace-perios=30 and then when kubectl delete pod --grace-perios=0 -force. The second time the force delete will not have any effect on the kubelet.
According to the latest documentation, gracePeriod, when set to 0 and force, triggers the kubelet to start cleaning up immediately.
But looking at the source code, I found that if gracePeriod=0 and force. kubelt triggers the handler.HandlePodRemoves function and then goes to the kl.deletePod function, which is correct. But in the real processing, the UpdatePod function is used (I looked at several versions of the code before 1.22 and they all use the deletePod function). When entering the update, there is no judgment that gracePeriod=0 and force. All as a normal updatePod to deal with, which also led to, the second gracePeriod = 0 was treated as a normal update, stored in the lastUndeliveredWorkUpdate cache. And the first delete because of the need to interact with the CRI, need to wait for the CRI to return the results, so you need to wait for the first 30s processing success before processing this forced deletion. This is not in line with the documentation logic and code logic. There should be gracePeriod=0 to handle the logic code of forced delete.
Here is the source code flow.
1.kubelet.go      handler.HandlePodRemoves(u.Pods)
<img width="974" alt="image" src="https://user-images.githubusercontent.com/29618214/200509330-339d156a-9d48-4b8f-a230-411b17af5313.png">
2.kubelet.go      deletepod
<img width="943" alt="image" src="https://user-images.githubusercontent.com/29618214/200509507-eb48d317-9d70-4354-9c6f-6ff8e8940aaf.png">
3.kubelet.go      kl.podWorkers.UpdatePod()
<img width="1038" alt="image" src="https://user-images.githubusercontent.com/29618214/200509674-966b0625-022b-4d6d-abb3-606f423f35c8.png">
4. pod_workers.go  
<img width="1158" alt="image" src="https://user-images.githubusercontent.com/29618214/200509877-78ed297f-ad0f-4804-89ba-793613ecb287.png">
The code that follows is the gracePeriod time that is waited for when the kill container is in place.
I looked at the code in version 1.19 and found that after the HandlePodRemoves function is triggered, there are two steps.
1. Close the podupdate channel and remove the lastUndeliveredWorkUpdate.
2. Open the goroutine to call CRI to remove the container.
The code after version 1.22 does not have this step of the operation, that is, the abandonment of gracePeriod = 0 and force forced deletion, this problem should be marked in the documentation, but I did not see. I changed the source code locally and tested it to achieve force deletion, is this a bug and do I need to pull request?








### What did you expect to happen?

After the first grace-period=30, the second grace-period=0 should be deleted immediately.
Now the situation is that apiserver will delete the pod, but kubelet will not delete the container

### How can we reproduce it (as minimally and precisely as possible)?

Start a container   
1.docker run name sh -c "sleep 99999"
2.kubectl delete pod name --grace-period=30
3.kubectl delete pod name --grace-period=0 --force
The third process will not execute successfully

### Anything else we need to know?

no

### Kubernetes version

<details>

```console
$ kubectl version 1.22.2
# paste output here
```

</details>


### Cloud provider

<details>
null
</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>