If a pod is running in your cluster that has not been mutated yet (e.g. the security context is not set) and you want to delete it, it get stuck in the state Terminating. This due to Karydia trying to change the pod definition and denying the UPDATE event (which is created with the DELETE event).
Thus, this PR introduces a check that ignores pods that are in the state Terminating in the admission controller. I introduced a function from the Kubernetes internals to "calculate" the correct state of the pod, as the phase of the pod is still ´Terminating`, even though it is actually starting to terminate.
This function reliable detects a terminating pod. However, this internal state change (depending on the containers in the pod) may take a few seconds and one can experience a delay in the deletion process. However, the deletion will always
[Fixes #250]
Checklist
Before submitting this PR, please make sure:
[x] you have added unit tests
[x] you have added integration tests
[x] your code builds clean with make
[x] your code lets succeed unit tests with make test
Description
If a pod is running in your cluster that has not been mutated yet (e.g. the security context is not set) and you want to delete it, it get stuck in the state
Terminating. This due to Karydia trying to change the pod definition and denying theUPDATEevent (which is created with theDELETEevent).Thus, this PR introduces a check that ignores pods that are in the state
Terminatingin the admission controller. I introduced a function from the Kubernetes internals to "calculate" the correct state of the pod, as the phase of the pod is still ´Terminating`, even though it is actually starting to terminate.This function reliable detects a terminating pod. However, this internal state change (depending on the containers in the pod) may take a few seconds and one can experience a delay in the deletion process. However, the deletion will always
[Fixes #250]
Checklist
Before submitting this PR, please make sure:
makemake test