- Yair Mark
Yesterday I was looking at a piece of work where Kubernetes pods were being started up and noticed that some of the pods had the status
Init:1/2. I found more detail about this here.
What this status is referring to is a concept called Init Containers. The idea behind these containers is that you use them if there are some setup processes you need to run before running a container.
You can of course run these processes in the main container but using init containers is ideal for running processes that should only be run once when the pod is first initialized. This is a much cleaner approach than some of the other ways of handling this.
The alternate approaches I have seen to this is use one container but:
- Run the setup process
- Make the setup process output a file that indicates the setup process is complete
- Wait for that file to be output
- Repeat the first 3 points for any other setup processes
- Run the main container
Using the init container approach you have a container/s just for the setup:
- This runs the setup
- Once the container/s complete the main container starts
A few points to note about init containers based on the official docs:
- Run before the main container: These init containers always run before the main container starts
- Run to completion: The main container knows to run as the init containers have to be run to completion
- This is also why init containers cannot and do not need readiness and liveness probes - they either run to completion or fail
- Container Array:You slot these into the container array in the pod spec. The ordering is the order that will be used if multiple init containers are specified
- On Failures:These init containers will restart if they fail
- This depends on the restart policy specified