Kubernetes Init Containers

In our latest Short Take video, Jerry Lozano delves into the concepts of Init Containers within Kubernetes pods. Init Containers are more than just a startup phase—they’re the prerequisite checklist ensuring your pod launches successfully. Jerry breaks down their significance, typical use cases, setup nuances, and their pivotal role in setting up the execution environment for all pod containers.

Video Transcript

Welcome to another Short Take from RX-M on the implementation of Kubernetes. My name is Jerry Lozano and today’s Short Take will be about a concept known as init containers–an optional part of a pod. We’ll talk in this Short Take about exactly what an init container is, what the typical use cases are for init containers, and finally we’ll discuss how they’re set up, how they’re specified as part being part of a pod.

Okay so what is an init container? It’s really a startup container–an initial startup container–that’s specified along with the pod. And the interesting thing about an init container is that it must complete successfully otherwise no other containers in the pod will launch. The purpose of an init container is to do startup tasks that would be common and useful to all the remaining containers within the pod. You can think of an init container as performing a checklist of prerequisites for the pod; since an init container, if it fails, prevents the pod from launching, then this checklist, unless completed successfully, would fail the pod. 

A pod specification can have zero or more init containers; they can be specified in the pod spec but remember all the init containers must complete before the remaining containers of the pod can launch. Here is an example yaml file calling out one init container as part of this pod. Init containers have their own image and they can perform their own tasks. In this case we are doing a git clone. The actual working container–which is going to be running busybox and is going to be listing the files that were cloned–this will never execute unless the init container successfully brings down the repo.

What is the need for init containers? Perhaps to install software prior to a pod running or for that matter any other resource needed by the pod and its containers for proper execution. One example would be the creation and initialization of volume data storage that would be needed by the running containers. Another example might be to locate the proxies that perhaps frequently change in your environment for network traffic. If we can’t get to the proxies we can’t respond to requests coming in on the network. In fact you can think of an init container as setting up or making sure that the execution environment for the pod is good. Maybe locating, connecting to other services that exist in the cluster. I mean where is the Kafka broker today? That maybe our pod needs to work with. And again I mentioned that init containers could be taking the role of a checklist to ensure that prerequisites are met for a pod. There’s no reason to continue this pod execution unless we can find the Kafka broker. Maybe we don’t have good credentials to connect to other needed services. If that’s true let’s stop now. 

I’d point out that some prerequisites maybe are better handled in other sections of the spec file.For example, minimum memory requirements or CPU availability would probably be best handled in the container resource requests section of a spec file. One reason to use init containers is the same reason that we use constructors in object-oriented programming. For those of you familiar with OOP, you know that we carefully control the construction, the initialization of every object with code. We make sure that we don’t create objects that aren’t fully initialized and that’s exactly what an init container does for us within a pod; it gives us an opportunity to write code, to execute code that sets up the environment for the entire pod. 

Okay how do we actually set up init containers? In a pod manifest deployment file  we can optionally specify a subsection under spec and under spec it’s called initContainers. In this example we have two init containers: init-myapp and init mydb. They both are running busybox and you can see that they’re just ensuring–this is your checklist example–that myservice is running and that mydb is running and until and unless we can establish that connection to myservice and mydb this pod will not launch the real container listed over here. 

You’ll notice that the initContainers section has the same subfields as does containers, including name, image, command, args, and many others. The only difference in the sub fields of containers and initContainers is that initContainers doesn’t have the need for liveliness probes or any probes for that matter. Init containers should start, they should execute, and they should stop so we don’t need to be probing them once every 3 minutes to see if they’re still there. So there’s no reason to use those subfields under initContainers but otherwise it’s the same set of subfields. 

Okay, so there is our brief introduction to init containers. They’re just containers that are part of a pod that must run to completion. Failure of any init container means that the pod itself has failed. Init containers do any initialization that needs to be separated from the running containers and they can also be used as a pre-launch checklist to make sure that we have a good execution environment for the remaining containers of the pod.

Thank you for uh watching this Short Take. I hope you learned something about init containers and we hope to see you again in another Short Take and even more importantly we hope to see you in a full-blown class on Kubernetes! Thank you see you soon!