Expose pod start time via the Downward API

[0xmichalis]

Use-case: a Job or Pod that needs to set timeouts in various points in its lifecycle. For example, a deployer pod that has a global timeout to finish its work and various steps need to use a timeout too.

Deployer pod with a timeout of 10 minutes:

1. Scales down old replica sets for a deployment
2. Waits for all pods to be terminated
3. Executes something
4. Scales up new replica set

The wait part in the second step needs a timeout of (10m - (time.Now - podStartTime)). The only way to achieve this currently is to use a pod client in the pod and query the api server.

cc: @mfojtik @pmorie

[mfojtik]

I'm not sure about implementation as the creationTime is set in status after the Pod is created, which means having an env var that points to that field will always result to that env var being empty (because the vars are set before pod is created).

[0xmichalis]

@mfojtik the creation time is metadata but I also think the pod IP is accessible via the downward API, isn't that also status?

[liggitt]

also, creationTime != scheduled time != started time... I don't think I'd want processes in a pod timing anything from when the pod was created

[0xmichalis]

Right, we want the start time. But the status is still accessible via the downward api.

[bgrant0607]

cc @erictune @pmorie

[smarterclayton]

I think this is very reasonable to support.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[0xmichalis]

Or exec uptime -s

/close

[leourbina]

@Kargakis will uptime return the actual uptime of the pod? What if the pod has been restarted (say, due to an intermittent failure)? I'd be nice to know the actual time the pod was started, which if I understand this correctly may not line up with uptime -s.

Any chance that this could be reconsidered as something to add into the API?

[pcn]

Or exec uptime -s

Uptime seems to reflect the hosts' uptime, and not that of the pod.