I have multiple helm charts creating a single deployment each (usually creating one pod each).
The requirement is to serialise the deployment of pods ie before the second pod can be deployed the first pod needs to be in a running state. (coz second pod reads values from the first pod). The third pod again should only come up with the second pod is up and running or completed.
I tried using Umbrella helm hooks for this but hooks are evaluated on a chart object level rather than a collection of charts.
I was looking into having a init container that regularly checks the readiness probe (not sure if this can be done) of the first pod before running the second pod? not sure -- ideas, please...
Init Containers
If you don't mind letting your previous services run to completion before running the next ones you can take advantage of the Init Containers feature: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
They run to completion before any app Containers start, whereas app Containers run in parallel, so Init Containers provide an easy way to block or delay the startup of app Containers until some set of preconditions are met.
Behavior
During the startup of a Pod, the Init Containers are started in order, after the network and volumes are initialized. Each Container must exit successfully before the next is started. If a Container fails to start due to the runtime or exits with failure, it is retried according to the Pod restartPolicy. However, if the Pod restartPolicy is set to Always, the Init Containers use RestartPolicy OnFailure.
A Pod cannot be Ready until all Init Containers have succeeded. The ports on an Init Container are not aggregated under a service. A Pod that is initializing is in the Pending state but should have a condition Initializing set to true.
If the Pod is restarted, all Init Containers must execute again.
https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#detailed-behavior
Caveats
Please review the differences and limitations in the documentation before deciding to use this feature.
ie.
Differences from regular Containers
Init Containers support all the fields and features of app Containers, including resource limits, volumes, and security settings. However, the resource requests and limits for an Init Container are handled slightly differently,