<p>What triggers init container to be run?</p>

<p>Will editing deployment descriptor (or updating it with helm), for example, changing the image tag, trigger the init container?</p>

<p>Will deleting the pod trigger the init container?</p>

<p>Will reducing replica set to null and then increasing it trigger the init container?</p>

<p>Is it possible to manually trigger init container?</p>

9ilsdx 9rvj 0lo
<blockquote>
  <p>What triggers init container to be run?</p>
</blockquote>

<p>Basically <code>initContainers</code> are run every time a <code>Pod</code>, which has such containers in its definition, is created and reasons of creation of a <code>Pod</code> can be quite different. As you can read in official <a href="https://kubernetes.io/docs/concepts/workloads/pods/init-containers/" rel="noreferrer">documentation</a> <strong><em>init containers</em></strong> <em>run before app containers in a <code>Pod</code></em> and they <em>always run to completion</em>. <em>If a Pod’s init container fails, Kubernetes repeatedly restarts the Pod until the init container succeeds.</em> So one of the things that trigger starting an <code>initContainer</code> is, among others, previous failed attempt of starting it.</p>

<blockquote>
  <p>Will editing deployment descriptor (or updating it with helm), for
  example, changing the image tag, trigger the init container?</p>
</blockquote>

<p>Yes, basically every change to <code>Deployment</code> definition that triggers creation/re-creation of <code>Pods</code> managed by it, also triggers their <code>initContainers</code> to be run. It doesn't matter if you manage it by helm or manually. Some slight changes like adding for example a new set of labels to your <code>Deployment</code> don't make it to re-create its <code>Pods</code> but changing the container <code>image</code> for sure causes the controller (<code>Deployment</code>, <code>ReplicationController</code> or <code>ReplicaSet</code>) to re-create its <code>Pods</code>.</p>

<blockquote>
  <p>Will deleting the pod trigger the init container?</p>
</blockquote>

<p>No, deleting a <code>Pod</code> will not trigger the init container. If you delete a <code>Pod</code> which is not managed by any controller it will be simply gone and no automatic mechanism will care about re-creating it and running its <code>initConainers</code>. If you delete a <code>Pod</code> which is managed by a controller, let's say a <code>replicaSet</code>, it will detect that there are less <code>Pods</code> than declared in its yaml definition and it will try to create such missing <code>Pod</code> to match the desired/declared state. So I would like to highlight it again that it is not the deletion of the <code>Pod</code> that triggers its <code>initContainers</code> to be run, but <code>Pod</code> creation, no matter manual or managed by the controller such as <code>replicaSet</code>, which of course can be triggered by manual deletion of the <code>Pod</code> managed by such controller.</p>

<blockquote>
  <p>Will reducing replica set to null and then increasing it trigger the
  init container?</p>
</blockquote>

<p>Yes, because when you reduce the number of replicas to 0, you make the controller delete all <code>Pods</code> that fall under its management. When they are re-created, all their startup processes are repeated including running <code>initContainers</code> being part of such <code>Pods</code>.</p>

<blockquote>
  <p>Is it possible to manually trigger init container?</p>
</blockquote>

<p>As @David Maze already stated in his comment <em>The only way to run an init container is by creating a new pod, but both updating a deployment and deleting a deployment-managed pod should trigger that.</em> I would say it depends what you mean by the term <em>manually</em>. If you ask whether this is possible to trigger somehow an <code>initContainer</code> without restarting / re-creating a <code>Pod</code> - no, it is not possible. Starting <code>initContainers</code> is tightly related with <code>Pod</code> creation or in other words with its startup process.</p>

<p>Btw. all what you're asking in your question is quite easy to test. You have a lot of working examples in <em>kubernetes official docs</em> that you can use for testing different scenarios and you can also create simple <code>initContainer</code> by yourself e.g. using <code>busybox</code> image which only task is to <code>sleep</code> for the required number of seconds. Here you have some useful links from different k8s docs sections related to <em>initContainers</em>:</p>

<p><a href="https://kubernetes.io/docs/concepts/workloads/pods/init-containers/" rel="noreferrer">Init Containers</a></p>

<p><a href="https://kubernetes.io/docs/tasks/debug-application-cluster/debug-init-containers/" rel="noreferrer">Debug Init Containers</a></p>

<p><a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-initialization/" rel="noreferrer">Configure Pod Initialization</a></p>
