Pod stuck in PodInitializing due to PVC of type read write many mounted two times on same Pod
Article ID: 383624
Updated On:
Products
Issue/Introduction
When a deployment is applied with a complex configuration multiple PVC at multiple endpoints and other subcomponents
The deployment could fail to start with misleading symptoms IP of the pod is not generated and pod init containers are not started
No logs are visible and pod status is PodInitializing
In the logs a warning can be observed
master./csi-controller/csi-attacher.stderr.log.7:33207:W1123 03:57:13.515216 10551 csi_handler.go:189] VA csi-bad3096aaef30ce82cbf006725bb55bf76c407d998eecdc4a11dd1874422fce5 for volume pvc-bad86dfc-2d8b-43b1-9d53-0a27cdd3b50c has attached status true but actual state false. Adding back to VA queue for forced reprocessing
Environment
TKGi 1.19
TKGI 1.20
CSI with driver name csi.trident.netapp.io possibly others could also be affected
NFS StorageClass with multiple PVC in RWX (read write many) provisioned
Cause
Having in the deployment similar to the example below where same PVC is mounted two times under different name:
volumeMounts:
.......
- mountPath: /opt/share/jdbc
name: workflow-test-jdbc
subPath: jdbc
- mountPath: /opt/usr/shared/resources/custom-binaries
name: workflow-test-binaries
subPath: custom-binaries
volumes:
........
- name: workflow-test-jdbc
persistentVolumeClaim:
claimName: operator-shared-pvc
- name: workflow-test-binaries
persistentVolumeClaim:
claimName: operator-shared-pvc
Where the PVC above is of type RWX and allows multiple mounts
Resolution
Update the deployment by removing one of the duplicate volumes and correct the mountpath to correct volume
volumeMounts:
.......
- mountPath: /opt/share/jdbc
name: workflow-test-jdbc
subPath: jdbc
- mountPath: /opt/usr/shared/resources/custom-binaries
name: workflow-test-jdbc
subPath: custom-binaries
volumes:
........
- name: workflow-test-jdbc
persistentVolumeClaim:
claimName: operator-shared-pvc
After this update the pod will start
Feedback
