<p>Unfortunately I am unable to paste configs or <code>kubectl</code> output, but please bear with me.</p>
<p>Using helm to deploy a series of containers to K8s 1.14.6, all containers are deploying successfully <strong>except</strong> for those that have <code>initContainer</code> sections defined within them.</p>
<p>In these failing deployments, their templates define <code>container</code> and <code>initContainer</code> stanzas that reference the same <code>persistent-volume</code> (and associated <code>persistent-volume-claim</code>, both defined elsewhere).</p>
<p>The purpose of the <code>initContainer</code> is to copy persisted files from a mounted drive location into the appropriate place before the main <code>container</code> is established.</p>
<p>Other containers (without <code>initContainer</code> stanzas) mount properly and run as expected.</p>
<p>These pods which have <code>initContainer</code> stanzas, however, report &quot;failed to initialize&quot; or &quot;CrashLoopBackOff&quot; as they continually try to start up. The <code>kubectl describe pod</code> of these pods gives only a Warning in the events section that &quot;pod has unbound immediate PersistentVolumeClaims.&quot; The <code>initContainer</code> section of the pod description says it has failed because &quot;Error&quot; with no further elaboration.</p>
<p>When looking at the associated <code>pv</code> and <code>pvc</code> entries from <code>kubectl</code>, however, none are left pending, and all report &quot;Bound&quot; with no Events to speak of in the description.</p>
<p>I have been able to find plenty of articles suggesting fixes when your <code>pvc</code> list shows Pending claims, yet none so far that address this particular set of circumstance when all <code>pvc</code>s are bound.</p>

Taylor Lopez
<p>When a PVC is &quot;Bound&quot;, this means that you do have a PersistentVolume object in your cluster, whose claimRef refers to that PVC (and usually: that your storage provisioner is done creating the corresponding volume in your storage backend).</p>
<p>When a volume is &quot;not bound&quot;, in one of your Pod, this means the node where your Pod was scheduled is unable to attach your persistent volume. If you're sure there's no mistake in your Pods volumes, you should then check logs for your csi volumes attacher pod, when using CSI, or directly in nodes logs when using some in-tree driver.</p>
<p>While the crashLoopBackOff thing is something else. You should check for logs of your initContainer: <code>kubectl logs -c &lt;init-container-name&gt; -p</code>. From your explanation, I would suppose there's some permission issues when copying files over.</p>
