I am in a situation where my pod is composed by 3 containers called:

• application
• collectd
• fluentd

I want that: application starts only when both collectd and fluentd are up&running ..

So I created a simple postStart script placed in application container, that waits forever for liveness/readiness probe of collectd and fluentd. I developed this part with the assumption that kubernetes starts in parallel all the containers and in case there is something wrong (liveness probe down) restart automatically the failing containers.

But I found two strange behaviours, strictly connected one with the other:

1. the never-ending loop in the postStart script (that waits for liveness of other containers) blocks completely the spin-up of the other two. So that fluentd and collectd have never been started.
2. kubernetes run in alphabetical order the containers defined inside a pod. So if I call my first container zapplication (instead of application) everything works as expected.

Now what I am asking is if this behaviour is a feature or is it a bug?

(END OF QUESTION HERE, FREE THOUGHTS ABOUT THE POSSIBLE ANSWER FOLLOW)

I read a lot of articles and discussions that state there should be no assumption in the ordering of container start, but this doesn't seem the case. Moreover among all the possible kind of ordering the alphabetical one doesn't seem to me the most deterministic one.

It also seems really strange to me that a postStart script on a container has the power to completely block the other two. But it can be also the case that this is the feature that solves the problem of dependent containers!

\======================================================================== UPDATE 2/12/2016: I'll link here as a reference the issue on github https://github.com/kubernetes/kubernetes/issues/37805