content_image/689845.jpg
The Deployment’s Pod template specification contains a single volume and two containers: 

• The volume config-directory  is of type emptyDir , so it’s created as an empty directory on the node hosting this Pod. 

• The init container Kubernetes calls during startup is built from the image we just created, and we set a single argument /config  used by the image’s ENTRYPOINT . This argument instructs the init container to copy its content to the specified directory. The directory /config  is mounted from the volume config- directory . 

• The application container mounts the volume config-directory  to access the configuration that was copied over by the init container. 

Figure 20-2 illustrates how the application container accesses the configuration data created by an init container over a shared volume. 

<img src='content_image/689845.jpg'>

Now to change the configuration from the development to the production environ‐ ment, all we need to do is exchange the image of the init container. We can do this either by changing the YAML definition or by updating with kubectl. However, it is not ideal to have to edit the resource descriptor for each environment. If you are on Red Hat OpenShift, an enterprise distribution of Kubernetes, OpenShift Templates  can help address this. OpenShift Templates can create different resource descriptors for the different environments from a single template. 

