Origin: Ability to specify the order of pods creation

[jwendell]

It would be nice if we had the ability to specify an order of creation of pods. Something like: Create this pod 'B' only after pod 'A' is created [and ready?].

A typical use case: A template that defines two pods. One for the app and the other one for the database. The database should be up and running in order to the app start correctly.

What do you think?

[pweil-]

This is something that has been discussed upstream a couple of times. Currently two proposals are open that touch on this subject:

https://github.com/kubernetes/kubernetes/issues/3312 (see the dependency management proposal section)
https://github.com/kubernetes/kubernetes/issues/1589

[derekmahar]

@jwendell Have you tried to design your pods so that pod B restarts until pod A is ready or has set certain conditions? For example, in the case of your database and application pods, before it starts, the application pod could repeatedly submit a simple query to the database until the query is successful.

Another approach might be to introduce an intermediate pod (sometimes called a "sidekick") that polls the database and starts the application pod only after the database is available. The disadvantage of this approach is that it would "fragment" the deployment specification such that the application pod would be described outside the deployment specification file in which the database and sidekick pods exist. (If you were to include all pods in the same deployment specification, Kubernetes would start them all at the same time which is not what you would want.)

A useful facility in Kubernetes might be to have a container (or pod) depend on the termination of another container or pod, but I think @thockin effectively rejected this idea when he rejected the dependency management proposal in his last comment in https://github.com/kubernetes/kubernetes/issues/3312#issuecomment-69214513.

[derekmahar]

I think the last sentence in my previous comment was incorrect. One can use container lifecycle hooks to order the execution of containers.

[jwendell]

@derekmahar yep, we tried something like that, but this is a workaround actually, not a proper, elegant solution...

[derekmahar]

@jwendell What do you propose instead? I think a kind of event driven system might work where a pod or container (this may operate at both levels) notifies Kubernetes that it is ready to process requests and then Kubernetes starts any pods that depend on this pod and are waiting for this event. However, given their rejection of the dependency management proposal, I'm not too optimistic that the developers would accept this proposal given how similar it is to the former.

[thockin]

Ideas of what is appropriate can and do shift over time. I can only speak
for myself - I am sympathetic to this use-case. I get it. But I also see
it as a very slippery slope into a LOT of complex semantics, and I REALLY
want to exhaust every possible idea before considering whether thsi should
be part of the core system.

On Fri, Sep 9, 2016 at 6:48 AM, Derek Mahar [email protected]
wrote:

@jwendell https://github.com/jwendell What do you propose instead? I
think a kind of event driven system might work where a pod or container
(this may operate at both levels) notifies Kubernetes that it is ready to
process requests and then Kubernetes starts any pods that depend on this
pod and are waiting for this event. However, given their rejection
https://github.com/kubernetes/kubernetes/issues/3312#issuecomment-69214513
of the dependency management proposal
https://github.com/kubernetes/kubernetes/issues/3312#dependency-management-proposal,
I'm not too optimistic that the developers would accept this proposal given
how similar it is to the former.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift/origin/issues/7575#issuecomment-245917796,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVO4f_OP53FOOYYWwugGvGvqyUetzks5qoWOYgaJpZM4HhGUF
.

[derekmahar]

How about pod lifecycle hooks? Like container lifecycle hooks, pod hooks would give the users access to key points in the pod lifecycle. Pods could then exploit these hooks to communicate state with other pods using persistent volumes or etcd.

[prabhakar-pal]

Hello All,

Is there any update on this and is there any other mechanism to take care of this usecase?

[mohkharma]

Hi All,

do we have any updates on this impotent feature.
Thanks

[clidro]

@mohkharma @prabhakar-pal did you guys look into Init Containers
https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#resources
it solved the pain I had with order load of the next services:
Console -> vault -> config-server -> IIAM

[PavelSosin]

I would like to add the following considerations:

1. As I understand, the current assumption is that either all images are pooled from the same repository or all repositories have the same latency and the same download performance - both are not true
2. Docker image pulling has to be sequential - since Dockerhub uses Amazon platform it can serve many pull request in parallel way. The is no constraints from the server side
3. All containers are equally critical, there is no fail-over mechanism. In mission critical scenario Cluster providing only critical services is better then nothing. Also timeout mechanism for resource creation can be helpful to avoid infinite Kubernetes starting state.