Kubernetes - 所有 PVC 已绑定，但“pod 具有未绑定的即时 PersistentVolumeClaims”

Question

Unfortunately I am unable to paste configs or kubectl output, but please bear with me.

Using helm to deploy a series of containers to K8s 1.14.6, all containers are deploying successfully except for those that have initContainer sections defined within them.

In these failing deployments, their templates define container and initContainer stanzas that reference the same persistent-volume (and associated persistent-volume-claim , both defined elsewhere).

The purpose of the initContainer is to copy persisted files from a mounted drive location into the appropriate place before the main container is established.

Other containers (without initContainer stanzas) mount properly and run as expected.

These pods which have initContainer stanzas, however, report "failed to initialize" or "CrashLoopBackOff" as they continually try to start up. The kubectl describe pod of these pods gives only a Warning in the events section that "pod has unbound immediate PersistentVolumeClaims." The initContainer section of the pod description says it has failed because "Error" with no further elaboration.

When looking at the associated pv and pvc entries from kubectl , however, none are left pending, and all report "Bound" with no Events to speak of in the description.

I have been able to find plenty of articles suggesting fixes when your pvc list shows Pending claims, yet none so far that address this particular set of circumstance when all pvc s are bound.

Answer 1

When a PVC is "Bound", 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).

When a volume is "not bound", in one of your Pod, this means the node where your Pod was scheduled is unable to attach your persistent volume. 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.

While the crashLoopBackOff think is something else. You should check for logs of your initContainer: kubectl logs -c <init-container-name> -p . From your explanation, I would suppose there's some permission issues when copying files over.