feat: introduce deletion timestamp metric for multiple resources

[IgorIgnatevBolt]

What this PR does / why we need it:

Some resources can be blocked by deletion from finalizers. To catch this and expose it to metrics, we can use the deletion timestamp metadata field.
Introduce a deletion_timestamp metric for the next resources:

• deployment kube_deployment_deletion_timestamp
• statefulset kube_statefulset_deletion_timestamp
• daemonset kube_daemonset_deletion_timestamp
• service kube_service_deletion_timestamp
• poddisruptionbudget kube_poddisruptionbudget_deletion_timestamp

Also formatting tables in docs

How does this change affect the cardinality of KSM: (increases, decreases or does not change cardinality)

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: IgorIgnatevBolt
Once this PR has been reviewed and has the lgtm label, please assign mrueg for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

This issue is currently awaiting triage.

If kube-state-metrics contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[IgorIgnatevBolt]

All commits were squashed into one.

[CatherineF-dev]

Hi, could you share more insights on use cases after these metrics are added?

Is it used for monitoring Kubernetes resources that are stuck in a terminating state?

[IgorIgnatevBolt]

@CatherineF-dev Hi, yes, if the resource deletion process is stuck for some reason or blocked by the finalizer, deletiontimestamp metric can help to detect such a case and raise an alert for investigation.

[richabanker]

/assign

[CatherineF-dev]

@IgorIgnatevBolt How will we know which resource should be deleted?

[IgorIgnatevBolt]

@IgorIgnatevBolt How will we know which resource should be deleted?

Maybe I misunderstood the question, but this PR is exactly about detection for such resources that were nominated by the controller manager for deletion but not deleted for some reason, eq blocked by finalizers

The controller managing that finalizer notices the update to the object setting the metadata.deletionTimestamp, indicating deletion of the object has been requested.