Consider exposing node metadata.creationTimestamp via downward api

[steven-herchak]

What would you like to be added?

A pod's metadata.creationTimestamp would be useful information inside a container. This could be accomplished via downward API similar to other metadata currently available.

Why is this needed?

Consider a cronjob execution. When executed, the cronjob creates a job, and the job creates a pod with container(s). If the containers' logic depends on the time the cronjob was scheduled having the pod creationTime would be more useful than simply obtaining the current time.

[k8s-ci-robot]

This issue is currently awaiting triage.

If a SIG or subproject determines 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](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[neolit123]

/sig node for triage

[steven-herchak]

Another related feature is the ability for the batch.kubernetes.io/cronjob-scheduled-timestamp annotation that gets added to a job to be passed onto the child pod.

[kannon92]

Hey @steven-herchak,

I think the first one can be done as a downward API but not sure of reasons why it wasn't included. Maybe @thockin has an idea?

Downward API tends to expose variables in the pod spec. I'm not really sure how that relates to higher level workloads so I'm not sure if cronjobs would fit in that case.

[kannon92]

Opened up https://github.com/kubernetes/kubernetes/pull/123533 as I wanted to learn a bit more about how downward API actually works.

[sftim]

I like the idea of annotating the CronJob's timings into the Job and its Pods:

• the actual creation timestamp of the Job
  • create a suspended Job
  • capture the Job's creation timestamp and set the annotation in the Pod template
  • unsuspend the Job (can be atomic with adding the annotation)
  • this would mean registering a new annotation key
• when the CronJob should have created the Job: batch.kubernetes.io/cronjob-scheduled-timestamp
  • added at Job creation time

However, is it worth putting contributor time into that idea? Only if someone feels it's valuable.

[thockin]

Mostly the reason is that we only exposed things we had concrete demand for, rather than "everything".

We do support annotations in the volume-creating downward API, but not the env-creating one (I think it was not needed and syntax was ambiguous).

[sftim]

I guess one thing to note is that (IIRC) you can't implement the equivalent out of tree, because:

• at admission time, metadata.creationTimestamp isn't set, so a mutating admission controller can't intervene
  • have I got this right? I didn't check.
• after admission time, the Pod is liable to get bound to a node and its containers created, before a watch / informer cna catch up and mutate the annotations on the existing Pod (two process that race, and as soon as the Pod is running, it may be too late to expose the field

[kannon92]

I opened up https://github.com/kubernetes/kubernetes/pull/123533 and got some good feedback from @thockin. https://github.com/kubernetes/kubernetes/pull/123533#issuecomment-1972038281

I will be on paternity leave for most of 1.31 so if anyone is interested in bringing this up as a KEP, please feel free! I even have a good starting point if anyone is interested.

The main action items will be to get some RFC (request for comments) on other downward api fields in the podspec and see if we could implement ones that have actual usecases in a KEP.

And for

Another related feature is the ability for the batch.kubernetes.io/cronjob-scheduled-timestamp annotation that gets added to a job to be passed onto the child pod.

I would maybe consider opening that as a separate issue and explore that in the batch CronJob controller. One could add that label/annotation to the PodSpec and you would get that for free as part of the downward api support for labels/annotations.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale