If we look at the spec section of the manifest file, we’ll see the following:

• containers: This section defines one or more containers that form the pod.

• containers.name: This is the container’s name, which isnginx-container in this case.

• containers.image: This is the container image, which isnginx in this case.

• containers.volumeMounts: This defines a list of volumes tha should be mounted to the container. It is similar to the volumes we read about in Chapter 4, Creating and Managing Container Images.

• containers.volumeMounts.mountPath: This defines the path to mount the volume on, which is /usr/share/nginx/html in this case. We will share this volume with the init container so that when the init container downloads the index.html file from example. com, this directory will contain the same file.

• containers.volumeMounts.name: This is the name of the volume, which ishtml-volume in this case.

• initContainers: This section defines one or more init containers that run before the main containers.

• initContainers.name: This is the init container’s name, which isinit-nginx in this case.

• initContainers.image: This is the init container image, which isbusybox:1.28 in this case.

• initContainers.command: This is the command that the busybox should execute. In this case, ‘mkdir -p /usr/share/nginx/html && wget -O /usr/share/ nginx/html/index.html http://example.com’ will download the content of example.com to the /usr/share/nginx/html directory.

• initContainers.volumeMounts: We will mount the same volume we defined in nginx-container on this container. So, anything we save in this volume will automatically appear in nginx-container.

• initContainers.volumeMounts.mountPath: This defines the path to mount the volume on, which is /usr/share/nginx/html in this case.

• initContainers.volumeMounts.name: This is the name of the volume, which is html-volume in this case.

• volumes: This section defines one or more volumes associated with the pod’s containers.

• volumes.name: This is the volume’s name, which ishtml-volume in this case.

• volumes.emptyDir: This defines anemptyDir volume. It is similar to a tmpfs volume in Docker. Therefore, it is not persistent and lasts just for the container’s lifetime.

So, let’s go ahead and apply the manifest and watch the pod come to life using the following commands:

$ kubectl delete pod nginx && kubectl apply -f nginx-init.yaml && \ kubectl get pod nginx -w

NAME	READY	STATUS	RESTARTS	AGE
nginx	0/1	Init:0/1	0	0s
nginx	0/1	PodInitializing	0	1s
nginx	1/1	Running	0	3s

Initially, we can see that the nginx pod shows a status of Init:0/1. This means that0 out of 1 init containers have started initializing. After some time, we can see that the pod reports its status, PodInitializing, which means that the init containers have started running. The pod reports a running status once the init containers have run successfully.

Now, once the pod starts to run, we can port-forward the container from port 80 to host port 8080 using the following command:

$ kubectl port-forward nginx 8080:80

Open a duplicate Terminal and try to curl the localhost on port 8080 by using the following command:

$ curl localhost:8080

<title>Example Domain</title>

Here, we can see the example domain response from our web server. This means that the init container worked perfectly fine.

As you may have understood by now, the life cycle of init containers ends before the primary containers start, and a pod can contain one or more main containers. So, let’s look at a few design patterns we can use in the main container.