A beginners guide to init containers
Civo Academy - Introduction to Init Containers in Kubernetes
Description
Understand what an init container is though the process of writing, creating, and deploying.
Transcription
What are Init Containers and how do they work?
In this video, we'll be discussing the init container. Init containers are just like regular containers, but they run to completion and run before the main container starts. There are various use cases for init containers, such as init containers can contain certain utilities or custom code for the setup that is not present for the app container.
It can also change the file system before starting the app container based on certain logic. It can also be used to limit the attack surface by keeping certain tools as part of init containers. Init containers can also delay the start of the main containers by having some precondition check; unless they are met, it will keep trying the init containers.
Writing and using init containers in Kubernetes
To write the init containers, we have to specify that in the spec section. In the spec section of the pod, we have to define the init containers. There can be one or more init containers. It will be running sequentially. The first init container runs, and then it completes. Then the second one runs, it completes, and then the containers will start. None of the pod's lifecycle or probes can be used for init containers. That's pretty much it about the init containers.
Creating an init container with a YAML file
Let's see this YAML file. You can see that we have containers. The main container is nginx. It has a volumeMount, shared volumeMount. For the init container, what it's trying to do is it's trying just to get the HTML from civo.com and put that as an index.html file. The init container will do a wget on civo.com, get the HTML file, and then the nginx container will use that HTML file and will be serving that.
Let's see that in action: firstly, we will use the kubectl apply -f init1.yaml command. Then, we can verify by using the kubectl get pods command. You can see the pod is initializing, and it's running. Let's exec into the pod using the kubectl exec -it init-demo1 sh command and use the curl localhost command. We can see the HTML file has been changed. Now we'll do an exit, verify by using the kubectl get pods command, and describe the pod using the kubectl describe pod init-demo1 command. In the pod description, we can see the busybox was pulled first. Next, the init container was started, and then the nginx container was started. That's how it is there, and you can also see the init container over here and what command it started.
Working with multiple init containers in Kubernetes
Now, there's another example that I have, which is multiple init containers. Let's quickly see that as well. I'll use the cat command on init2.yaml, which looks like cat init2.yaml. You can see that this is a multi-container, multiple init container pod. We have a main busy box container, and in the init containers, we are checking for two services, whether they exist or not. Hence, unless and until the services exist, we can see that it will check for appservice, and it'll check for dbservice. This particular pod will always remain pending if they do not exist.
First, let's see whether we have service and let me show you the service. For that, use the cat init2svc.yaml command. You can see that these are the other services we will create so that the pod comes into the running state. Next, let's make sure that it's not running at the moment, and for that, we'll use the command kubectl delete -f init2svc.yaml.
Let's apply the pod YAML first by using the kubectl apply -f init2.yaml command. It created the pod. Now, verify it through the kubectl get pods command. Its status is init zero over two. Therefore, not even one init container has been completed successfully. We can also describe the newly created pod through kubectl describe pod init-demo2. We can see it has just started, and it will keep on retrying unless and until the init container is completed. It's waiting. Now, we'll apply the services through kubectl apply -f init2svc.yaml. As soon as we apply the services, the pod starts initializing, and the pod starts running.
Conclusion
In this lecture, we have seen how init containers work and how a single init container and multiple init containers work. In any scenario, the init container will work to completion, and then only the main or the app container will start in the pod. That's it for this lecture, thank you for watching.