Pod init hooks

[bkeroackdsc]

I have a container in a pod whose only job is to populate some configuration values within the pod-local etcd on startup. This works fine except that after it exits successfully Kubernetes continually respawns it over and over again.

My current hack is to append && tail -f /dev/null to the container command to allow it to "run" indefinitely.

It would be great if Kubernetes allowed one to specify certain containers as non-respawning in the pod spec.

[mikedanese]

Is it possible for you to use a container lifecycle hook? http://godoc.org/github.com/GoogleCloudPlatform/kubernetes/pkg/api/v1#Lifecycle

RestartPolicy is almost what you want but it is applied over all the containers in a pod. http://godoc.org/github.com/GoogleCloudPlatform/kubernetes/pkg/api/v1#RestartPolicy

[bkeroackdsc]

@mikedanese RestartPolicy would be perfect if only it were per-container rather than pod.

I wouldn't mind trying to implement this if there's interest.

[mikedanese]

cc @bgrant0607 @davidopp for api changes.

[thockin]

The corner cases around mixed-restart-policy pods is not worth the energy.
This is what lifecycle hooks should do, and if they aren't sufficient, we
should make them sufficient.

On Mon, Jun 15, 2015 at 8:26 PM, Mike Danese notifications@github.com
wrote:

cc @bgrant0607 https://github.com/bgrant0607 for api changes.

—
Reply to this email directly or view it on GitHub
#9836 (comment)
.

[davidopp]

It's true that the most common use cases of sidecar containers, for example data loader and log saver, will run forever. However, IIRC we've occasionally told people to use sidecar containers for various kinds of initial configuration, and in those cases it seems that having the sidecar run once to completion and the other pod restart would be desirable.

I guess the lifecycle hook proposal would be that you merge the configuration container logic into the main container's logic, so that you have just one container, and have the PreStart hook invoke the former?

Anyway, I don't have a strong opinion.

[thockin]

We've thrown out the idea of having two stages in a pod - stage 1 only
completes when stage 0 is done. E.g. all the containers in stage 1 have
completed successfully. Like so many other things, it is a matter of
priority and making time for it among the ocean of other things going on :)

On Mon, Jun 15, 2015 at 10:47 PM, David Oppenheimer <
notifications@github.com> wrote:

It's true that the most common use cases of sidecar containers, for
example data loader and log saver, will run forever. However, IIRC we've
occasionally told people to use sidecar containers for various kinds of
initial configuration, and in those cases it seems that having the sidecar
run once to completion and the other pod restart would be desirable.

I guess the lifecycle hook proposal would be that you merge the
configuration container logic into the main container's logic, so that you
have just one container, and have the PreStart hook invoke the former?

Anyway, I don't have a strong opinion.

—
Reply to this email directly or view it on GitHub
#9836 (comment)
.

[davidopp]

Yeah, I was assuming the user would be responsible for orchestrating the dependency between the two containers (e.g. the application in the main container would wait until the configuration data was populated by the other container before finishing its startup).

[bgrant0607]

Pod-level hook or container volume #831 would be the right solution.

Original discussion re. restart policy was #127.

[bgrant0607]

Closing as a dupe of #4282