Open yohancourbe opened 1 year ago
A partial workaround is to set the storage binding mode to Immediate
but as stated in the doc
The Immediate mode indicates that volume binding and dynamic provisioning occurs once the PersistentVolumeClaim is created. For storage backends that are topology-constrained and not globally accessible from all Nodes in the cluster, PersistentVolumes will be bound or provisioned without knowledge of the Pod's scheduling requirements. This may result in unschedulable Pods.
Is there a workaround on ArgoCD side? "Delayed/Relaxed wait for Ready"?
You can customize the health check for PersistentVolumeClaim so that if the state is Pending instead of Bound it's considered Healthy instead.
resource.customizations: |
PersistentVolumeClaim:
health.lua: |
hs = {}
if obj.status ~= nil then
if obj.status.phase ~= nil then
if obj.status.phase == "Pending" then
hs.status = "Healthy"
hs.message = obj.status.phase
return hs
end
if obj.status.phase == "Bound" then
hs.status = "Healthy"
hs.message = obj.status.phase
return hs
end
end
end
hs.status = "Progressing"
hs.message = "Waiting for certificate"
return hs
Checklist:
argocd version
.Describe the bug
When deploying an app that contains a PVC to a storage class with
volumeBindingMode
set toWaitForFirstConsumer
, the application sync is stuck due to a deadlock: the pod won't be created by Argo until the PVC is ready, and the PVC waits for a pod to use the claim before being ready.See https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode
To Reproduce
StorageClass
Expected behavior
ArgoCD should handle this deadlock by continuing with pod creation when the PVC is in state
WaitForFirstConsumer
Screenshots
n/a
Version
Logs