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,