concept init container in category kubernetes
This is an excerpt from Manning's book Learn Kubernetes in a Month of Lunches MEAP V07.
Init containers work differently to sidecars. You can have multiple init containers defined for the Pod and they run in sequence - in the order they're written in the Pod spec. Each init container needs to complete successfully before the next one starts, and all must complete successfully before the Pod containers are started. Figure 7.6 shows the startup sequence for a Pod with init containers.
Figure 7.6 Init containers are useful for startup tasks to prep the Pod for the app containers
All containers can access volumes defined in the Pod, so the major use-case is for an init container to write data which prepares the environment for the application container. Listing 7.3 shows a simple extension to the HTTP server in the sleep Pod from the last exercise. An init container runs and generates an HTML file which it writes in a mount for an EmptyDir volume - the server container responds to HTTP requests using that file.
Listing 7.3 - sleep-with-html-server.yaml, an init container in the Pod spec
spec: # Pod spec in the Deployment template initContainers: # init containers have their own array - name: init-html # and they run in sequence image: kiamol/ch03-sleep command: ['sh', '-c', "echo '<!DOCTYPE html...' > /data/index.html"] volumeMounts: - name: data mountPath: /data # init containers can mount Pod volumesThis example uses the same sleep image for the init container - but it can be any image. You might use an init container to set up the application environment using tools that you don't want to be present in the running application. An init container can use a Docker image with the Git command line installed and clone a repository into the shared filesystem. The app container gets access to the files without you having to set up the Git client in your app image.
Deploy the update from listing 7.3 and see how init containers work.
# apply the updated spec with the init container: kubectl apply -f sleep/sleep-with-html-server.yaml # check the Pod containers: kubectl get pod -l app=sleep -o jsonpath='{.items[0].status.containerStatuses[*].name}' # and the init containers: kubectl get pod -l app=sleep -o jsonpath='{.items[0].status.initContainerStatuses[*].name}' # check logs from the init container - there are none: kubectl logs -l app=sleep -c init-html # and check the file is available in the sidecar: kubectl exec deploy/sleep -c server -- ls -l /data-roYou'll pick up a few things from this exercise. App containers are guaranteed not to run until init containers complete successfully, so your app can safely make assumptions about the environment which the init container prepares - in this case the HTML file is sure to exist before the server container starts. And init containers are a different part of the Pod spec, but some management features work in the same way as app pods - you can read the logs from init containers even after they have exited. My output is in figure 7.7.
This is an excerpt from Manning's book Kubernetes in Action, Second Edition MEAP V05.
5.5.1 Introducing init containers
A pod manifest can specify a list of containers to run when the pod starts and before the pod’s normal containers are started. These containers are intended to initialize the pod and are appropriately called init containers. As the following figure shows, they run one after the other and must all finish successfully before the main containers of the pod are started.
$ kubectl get events -w
Table 6.2 List of pod conditions
Pod Condition
Description
PodScheduled
Indicates whether or not the pod has been scheduled to a node.
Initialized
The pod’s init containers have all completed successfully.
ContainersReady
All containers in the pod indicate that they are ready. This is a necessary but not sufficient condition for the entire pod to be ready.
Ready
The pod is ready to provide services to its clients. The containers in the pod and the pod’s readiness gates are all reporting that they are ready. Note: this is explained in chapter 10.
This is an excerpt from Manning's book Kubernetes in Action.
But you can prevent a pod’s main container from starting until a precondition is met. This is done by including an init containers in the pod.
Listing 17.2. An init container defined in a pod: fortune-client.yaml
spec: initContainers: #1 - name: init image: busybox command: - sh - -c - 'while true; do echo "Waiting for fortune service to come up..."; #2 ➥ wget http://fortune -q -T 1 -O /dev/null >/dev/null 2>/dev/null #2 ➥ && break; sleep 1; done; echo "Service is up! Starting main #2 ➥ container."'