Skip to content

Allow customization of how keda scales up and down instead of allowin… - #282

Open
PedroMiguelFMoreira wants to merge 4 commits into
n8n-io:mainfrom
PedroMiguelFMoreira:keda-advanced-scaling
Open

PedroMiguelFMoreira wants to merge 4 commits into
n8n-io:mainfrom
PedroMiguelFMoreira:keda-advanced-scaling

Conversation

@PedroMiguelFMoreira

@PedroMiguelFMoreira PedroMiguelFMoreira commented Oct 30, 2026 •

Copy link
Copy Markdown
Contributor

Allow customization of how KEDA scales workers and webhook processors up and down, instead of jumping straight to the computed replica count.

Description

When KEDA is enabled with minReplicaCount >= 1, replica changes between min and max are handled by the Kubernetes HPA. By default, the HPA can scale directly to the target count in a single step (e.g. 3→20 on scale-up or 20→3 on scale-down), which can cause sudden capacity swings and disrupt in-flight workflow executions.

This change exposes KEDA's advanced ScaledObject configuration on both worker and webhook-processor ScaledObjects via new values:

  • keda.worker.advanced
  • keda.webhookProcessor.advanced

When set, these are rendered into the ScaledObject's spec.advanced block (typically horizontalPodAutoscalerConfig.behavior) so operators can cap how many pods are added or removed per interval. Default remains {}, preserving existing behavior for current deployments.

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation update
  • Example/configuration update
  • CI/CD improvements

Related Issues

Fixes # (issue)
Relates to # (issue)

Testing Performed

Deployment Testing (if applicable)

  • Tested with minimal configuration
  • Tested with production configuration
  • Tested upgrade path from previous version
  • All pods start successfully
  • Application is accessible

Specific Testing for Changes

Describe any specific testing you performed for your changes:

  • helm template test charts/n8n -f charts/n8n/examples/keda-autoscaling.yaml --dry-run=client — renders successfully with advanced: {} (no advanced block in ScaledObject)
  • Verified ScaledObject templates include spec.advanced only when keda.worker.advanced / keda.webhookProcessor.advanced is non-empty
  • Confirmed default {} leaves existing KEDA Redis scaling behavior unchanged

Breaking Changes

If this includes breaking changes, describe what they are and provide migration instructions:

  • None. advanced defaults to {} and is omitted from rendered ScaledObjects unless configured.

Checklist

  • My code follows the project's style guidelines
  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation, README.md, examples
  • My changes generate no new warnings or errors
  • I have added examples that demonstrate the changes (if applicable)
  • All new and existing tests pass

@cubic-dev-ai cubic-dev-ai Bot left a comment •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All reported issues were addressed across 5 files

Architecture diagram
sequenceDiagram
    participant User as Helm User
    participant Helm as Helm Chart
    participant K8s as Kubernetes API
    participant KEDA as KEDA Operator
    participant HPA as HPA Controller
    participant Deploy as Worker/Webhook Deployment

    User->>Helm: Provide values.yaml with keda.worker.advanced
    Note over Helm: NEW: Advanced config passthrough
    alt Worker ScaledObject
        Helm->>K8s: Render scaledobject-worker.yaml with advanced block
    else Webhook Processor ScaledObject
        User->>Helm: Provide keda.webhookProcessor.advanced
        Helm->>K8s: Render scaledobject-webhook-processor.yaml with advanced block
    end
    
    Note over K8s: ScaledObject created with advanced config
    K8s->>KEDA: Watch ScaledObject
    KEDA->>KEDA: Evaluate triggers (Redis queue depth)
    KEDA->>HPA: NEW: Compute target replica count per behavior policies
    
    alt Scale up with behavior policy (e.g., 2 pods/min)
        HPA->>HPA: NEW: Apply scaleUp policies (max 2 pods/min)
        HPA->>Deploy: Scale replicas incrementally
    else Scale down with stabilization (e.g., 300s window)
        HPA->>HPA: CHANGED: Wait stabilization window (300s)
        HPA->>Deploy: Remove at most 1 pod/min
    else Default behavior (no advanced config)
        HPA->>Deploy: Scale directly to target replicas
    end
    
    Deploy-->>HPA: Current replica count
    HPA-->>KEDA: Status update
    KEDA-->>K8s: Update ScaledObject status
    K8s-->>User: Helm release status
Loading

Click Fix with cubic on a comment, or reply @cubic-dev-ai fix this, and cubic writes the fix.

View guided diff | Re-trigger cubic

Comment thread charts/n8n/values.yaml Resolved
@PedroMiguelFMoreira

Copy link
Copy Markdown
Contributor Author

Hello @TMWilds not sure if I can ask you for your help once again, if you could review this PR I would appreciate it. 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant