Feature Request: Allow Custom Pod Spec Overrides (e.g., priorityClassName) for Main, Worker, and Webhook Deployments

[maxitromer]

Hello 8gears team,

First, thank you for maintaining the n8n Helm chart. It's a valuable resource for deploying n8n on Kubernetes.

I'm writing to request a feature that would greatly enhance the flexibility of the chart: the ability to include custom pod specifications (like priorityClassName) for the main, worker, and webhook deployments.

Problem:
Currently, it's not possible to set priorityClassName (or other custom fields within spec.template.spec) for the n8n, n8n-worker, and n8n-webhook deployments via values.yaml. Attempts to set it directly in the main, worker, or webhook sections, or by using extraManifests for patching, have been unsuccessful due to the chart's template logic or Kubernetes validation errors.

This limitation prevents users from fine-tuning pod scheduling and resource management, which is crucial in production environments.

Proposed Solution:
I suggest adding a generic podSpec field (or similar, e.g., template.spec) under the main, worker, and webhook sections in values.yaml. This field would allow users to provide arbitrary YAML that gets merged directly into the spec.template.spec of the respective Deployment.

Implementation Idea (for deployment.yaml):
You could implement this by adding a block like this within the spec.template.spec section of deployment.yaml (and similarly for deployment.worker.yaml and deployment.webhook.yaml):

    spec:
      # ... existing pod spec fields ...

      {{- with .Values.main.podSpec }}
      {{- toYaml . | nindent 6 }}
      {{- end }}

      containers:
        # ... existing containers ...

Then, in values.yaml, users could specify:

main:
  podSpec:
    priorityClassName: apps-prod-backend
    # any other custom pod spec fields

This approach would provide maximum flexibility without requiring extensive changes to the chart's core logic for every new Kubernetes feature.

Thank you for considering this request.