OpenShift Init Container: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 8: Line 8:
* [[OpenShift_Pod_Concepts#Init_Container|OpenShift Pod Concepts]]
* [[OpenShift_Pod_Concepts#Init_Container|OpenShift Pod Concepts]]
* [[Kuberentes Init Containers]]
* [[Kuberentes Init Containers]]
=Overview=
An ''init container'' is a specialized container that runs before the [[OpenShift_Pod_Concepts#Application_Container|application containers]], and can contain utilities or setup scripts not present in the application image. If a pod declares init containers, the application containers are only run after all init container complete successfully.
An init container always runs to completion, and if more than one init containers are declared, each one is executed sequentially and must complete successfully before the next one is started. This is the reason init containers do not support readiness probes: they must succeed. If an init container fails, Kubernetes will restart the Pod repeatedly until the init container succeeds, unless the pod has a "[[OpenShift_Pod_Definition#restartPolicy|restartPolicy]]" of "Never".
While an init container is executed, it shows as "Init:*/*", alongside the deployment container.
oc get pods
NAME        READY    '''STATUS'''    RESTARTS  AGE
a-1-7k94g    0/1      '''Init:0/1'''  0          3m
a-1-deploy  1/1      Running    0          3m
Init containers support all the fields and the features of the [[OpenShift_Pod_Concepts#Application_Container|application containers]] including resource limits, volumes and security settings. However, the resource requests and limits for an Init Container are handled slightly differently, as described in [[#Resources|Resources]] below.
Init containers can be used to run utilities that do not belong in application [[OpenShift_Pod_Concepts#Application_Container|application container]] images for security reasons. The can contain utilities for setup. The application image builder and deployer roles can work independently without the need to jointly build a single app image. Because they use Linux namespaces so that they have different filesystem views from application containers, they can be given access to Secrets that application containers should not be able to access.
Ultimately, they can be used to implement a dependency mechanism: they run to completion before any application containers start, whereas application containers run in parallel, so init containers provide an easy way to block or delay the startup of application containers until some set of preconditions are met.


=Declaration=
=Declaration=

Revision as of 01:28, 19 September 2019

External

Internal

Declaration

Declared within the context of a pod, under the "initContainers" field.

A simple example: 

apiVersion: v1
kind: Pod
[...]
spec:
  containers:
  - name: app-container1
    [...]
  initContainers:
  - name: init-container1
    image: busybox
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']

Life Cycle

https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#detailed-behavior

Timeout

An init container must finish initializing within ... otherwise it puts the deployment into an error state: 

NAME         READY     STATUS    RESTARTS   AGE
a-1-deploy   0/1       Error     0          13m

Resources

https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#resources

Troubleshooting Init Containers

The logs of init containers can be accessed by identifying the name of the init container with: 

oc describe po/a-1-0g52b

...
Init Containers:
 b-dependency-checker:
  ...

and then getting the logs from that specific container: 

oc logs -f -c b-dependency-checker po/a-1-0g52b

Application Dependency Example

https://github.com/NovaOrdis/playground/tree/master/openshift/applications/service-dependency

TODO: write a step-by-step article.

Retrieved from "https://kb.novaordis.com/index.php?title=OpenShift_Init_Container&oldid=61938"