<p>I am currently trying to build a build-pipeline.
the pipeline currently is a job with several init containers.
One of the init containers is the actual image builder.</p>

<p>To make use of its cache feature, I'd need a mechanism of having the data remain on the storage, so the next iteration can use the cached data.</p>

<p>The only lead for that would be:</p>

<blockquote>
  <p>However, an administrator can configure a custom recycler pod template using the Kubernetes controller manager command line arguments as described here.</p>
</blockquote>

<p>(link for that) <a href="https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/" rel="nofollow noreferrer">https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/</a></p>

<p>But this link does not really explain anything.
And it actually sounds like I'd have to change the recycle policy globally, which is something I'd rather not do.</p>

<p>Leading to the question:</p>

<p>How to tackle this problem gracefully?</p>

scones
<p>You can use <a href="https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/" rel="nofollow noreferrer">Dynamic Volume Provisioning</a> running your workload in a <a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/" rel="nofollow noreferrer">StatefulSet</a> to store your cache. </p>

<p>Essentially, when you use it a PVC (Persistent Volume Claim) gets created that is associated with a Physical Volume (The PV also gets created initially) and the PVC is also associated with your pod. So the next time your pod restarts it uses the same Volume. The types of volumes supported will depend on your cloud provider.</p>
