<p>In Kubernetes, there is deletionTimestamp to signal an ongoing deletion and there are finalizers to model tasks during the process of deletion.
However, it could be, that during the deletion, the specification of a parent object changes in a way that would effective make cancelling the deletion the most desirable solution.</p>
<p>I'd expect a clear and complete documentation of deletionTimestamp and finalization covering the entire lifecycle of deletionTimestamp. It seems that most people seem to assume that it is either zero or nonzero and cannot be changed while it is nonzero. However, there seems to be no documentation on that. I also do not want to &quot;just check&quot;, because just check is subject to change and may stop working tomorrow.</p>

<p>The answer is No,</p>
<p>Finalizers are namespaced keys that tell Kubernetes to wait until specific conditions are met before it fully deletes resources marked for deletion. Finalizers alert controllers to clean up resources the deleted object owned. Documentation is <a href="https://kubernetes.io/docs/concepts/overview/working-with-objects/finalizers/" rel="nofollow noreferrer">here</a></p>
<p>Reason being garbage collection used this identifier, In foreground cascading deletion, the owner object you're deleting first enters a deletion in progress state Read through this for detailed understanding
<a href="https://kubernetes.io/docs/concepts/architecture/garbage-collection/#foreground-deletion" rel="nofollow noreferrer">Foreground cascading deletion</a></p>
