bug: Multi-Attach error with RWO PVC when enabling worker/webhook: chart mounts same PVC across pods on different nodes

[chris2k20]

Summary

When running this chart on a multi-node Kubernetes cluster with a ReadWriteOnce (RWO) PVC, enabling worker (and/or webhook) can lead to a Multi-Attach error because multiple pods try to mount/attach the same PVC while being scheduled on different nodes.

This results in pods stuck in Pending with events like:

Multi-Attach error for volume "pvc-..." Volume is already used by pod(s) ...

Environment

• Chart version: 2.0.1
• n8n version/image: latest
• Kubernetes version: v1.28.8
• StorageClass / CSI driver: hetzner-cloud
• PVC access mode: ReadWriteOnce (RWO)
• Cluster: multi-node (pods can be scheduled across different nodes)

Values (relevant parts)

Example configuration (simplified):

main:
  persistence:
    enabled: true
    # uses an RWO StorageClass
worker:
  enabled: true
  replicaCount: 1
# webhook:
#   enabled: true

Steps to reproduce

1. Install the chart with main.persistence.enabled=true using an RWO StorageClass.
2. Enable worker (and/or webhook) so that additional pods are created.
3. Let the scheduler place pods on different nodes (default behavior in multi-node clusters).
4. Observe worker/webhook pod stuck in Pending and Multi-Attach errors in pod events.

Actual behavior

• n8n main pod mounts the PVC on node A
• n8n-worker (or webhook) is scheduled on node B
• Kubernetes/CSI attempts to attach the same RWO volume to node B → fails with Multi-Attach
• Worker/webhook pod stays Pending

Expected behavior

One of the following (depending on chart intent):

• Chart should not force/mount the same PVC into worker/webhook by default, OR
• Chart should support separate PVCs per component (main/worker/webhook), OR
• Chart should clearly document that enabling worker/webhook with main.persistence.enabled requires ReadWriteMany (RWX) storage or single-node scheduling constraints, OR
• Provide an option to configure podAffinity/nodeAffinity to ensure all pods that mount the same RWO PVC land on the same node.

Why this matters

In queue mode, main/worker/webhook often run as separate deployments and can be scheduled across nodes. If the chart shares the same persistence claim across components, RWO becomes a frequent footgun on multi-node clusters.

Suggested improvement

• Add values to configure separate persistence for worker and webhook (or disable volume mounts there)
• Alternatively, add an explicit guard/validation/warning when:
  • main.persistence.enabled=true
  • worker/webhook enabled
  • and accessMode is RWO (or RWX not configured)
• Improve documentation for queue-mode deployments regarding persistence and storage recommendations.

Additional context

I can provide full values.yaml, pod manifests, and event logs if needed.

[julzds]

Hi,
this seems to be the same issue described here: #189
Would like to see a more permanent fix in the helm chart itself instead of the workaround I posted. Very good to see a PR that seems to address the issue.