<p>I am still in the initial phase of understanding k8, so please forgive if you feel this lame. But I wanted to know if there is a way to have some kind of delay or ordered the execution of the containers in 1 single pod.
Let's say we have 1 Pod A and has 2 containers. For example, a kafka container exposing port 9092 and port 8081 and another container say a Kafka connect image which hits both of these ports. I wanted to know if there is a way to execute the Kafka container first and then execute Kafka connect container so that it won't get killed. </p>

<p>1) Can we have some delay or a sleep between 2 container creation?</p>

<p>2) Can we have some kind of priority of execution of containers within pods so that we can accomplish the above-mentioned situation?</p>

<p>PS: I have considered creating 2 pods and currently working on that. But also wanted to try to do this and also learn something new at the same time.Thanks.</p>

<p>No you can't, but you could change the startup command for the second image to poll the availability of the ports of the first container through <code>localhost</code>. When both ports accept connections, then you know you can continue with starting up the application in the second image.</p>

<p>If you cannot modify the second image yourself, what you can do is create a config map which contains your own startup script using whatever scripting language you might have in the image. Mount the config map into the container at some path and then override the command run for the container in the pod definition (where depends on how you are deploying it), to invoke your script mounted in from the config map.</p>

<p>Your script can then do the polling, and when happy that first container is running okay, then it will execute the original command the container used to start the application.</p>

<p>If you were to use two pods instead, then you can still use the same idea, but rather than <code>localhost</code> use the hostname for the service of the first pod. In the two pod case, you could run the script in an init container instead of hijacking the original startup command of the actual image.</p>
