1

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.

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 "just check", because just check is subject to change and may stop working tomorrow.

1 Answers1

1

The answer is No,

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 here

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 Foreground cascading deletion

Bijendra
  • 9,467
  • 8
  • 39
  • 66
  • While this covers the default behaviour, it does not explicitly state if deletion can be blocked by finalizers by just not removing their marker or if they can explicitly unset the deletionTimestamp. – Timm Felden Feb 16 '23 at 09:24
  • 1
    Created an issue in the documentation to clarify this. If the issue is processed as you imply, your answer is correct. Issue is https://github.com/kubernetes/website/issues/39490 – Timm Felden Feb 16 '23 at 10:08