Topic outline

  • Basics

    Init Container are part of a pod lifecycle. If init containers are configured each container runs sequentially before the application container can start. Each init container must run successfully to competition otherwise the pod will be started again until its operation succeeds.

    to clarify, in the further course the normal / regular or applictaion container is called application container.

    Setting up an init container, will be defined with the "initConainer" label in the "spec" scope.
    YAML configuration

    Differences from regular/application containers
    Init containers do not support readiness probes because they always run to completion.
    Each init container must succeed before the next can run.
    Resource limits an requests are handled differently.
    All init container in a pod sharing their resource limits an requests.
       - the sum of all app containers request/limit for a resource
       - the effective init request/limit for a resource

    Debugging
    kubectl get pod the field STATUS indicates the init containerstatus
    Example: STATUS = Init:1/2
    two init contianers are scheduled and one is already completed

    Example: Pod with two init containers and one application container. Each container prints his name an waits 200 seconds.

    When accessing the logs with kubectl logs initcontainer-pod you only get the application container logs.
    If you want to get the init container logs you must specify which log you want kubectl logs initcontainer-pod first-inicontainer
    • Common senarios

      There are many usecases for init containers. Here are a few examples to give you an idea how to use them practically.