A beginners guide to init containers
A beginners guide to init containers
Understand what an init container is though the process of writing, creating, and deploying.
What is an init container?
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 with init containers
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.
How can we create an init container?
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.
Multiple init containers
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.
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.