When using kubectl to delete multiple sts pods simultaneously, it gets stuck and won't exit.

[yangjunmyfm192085]

What happened?

Use the following command to delete multiple pods. The kubectl command keeps getting stuck.

kubectl delete pod sts-pod-0 sts-pod-1 sts-pod-2 sts-pod-3 ....  --ignore-not-found=true 

What did you expect to happen?

The kubectl command deletes pods and exits normally.

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

Use the following command to delete multiple pods. The kubectl command keeps getting stuck.

kubectl delete sts-pod-0 sts-pod-1 sts-pod-2 sts-pod-3 ....  --ignore-not-found=true 

Anything else we need to know?

No response

Kubernetes version

Details

$ kubectl version
# paste output here
kubectl version
Client Version: v1.34.0

Cloud provider

Details

OS version

Details

# 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

Install tools

Details

Container runtime (CRI) and version (if applicable)

Details

Related plugins (CNI, CSI, ...) and versions (if applicable)

Details

[yangjunmyfm192085]

/assign

[yangjunmyfm192085]

/cc @249043822

[249043822]

Have you found the root cause of this problem? I think you can elaborate the problem.

[249043822]

/sig cli

[yangjunmyfm192085]

sure.
When kubectl deletes a pod:

1. delete request is sent.
2. get request is sent. If the resource no longer exists, or exists but its UID does not match the deletion request, the deletion is considered successful.
3. If the old resource is found to still exist, its changes are watched using a list watch method.

However, step 3, when watching resource changes, does not check if the resource's UID matches the old one, nor does it check if the resource no longer has a deletion timestamp (new resource creation). This causes the watch to detect new resources but not delete them, so it got stuck..

Deleting the sts pod might cause it to get stuck, because the old pod and the new pod have the same namespace and name.

[249043822]

/triage accepted