Skip to content

feat(argo-workflows): add deploymentStrategy values for controller and server#3869

Closed
joestadler wants to merge 1 commit intoargoproj:mainfrom
joestadler:feat-argo-workflows-deployment-strategy
Closed

feat(argo-workflows): add deploymentStrategy values for controller and server#3869
joestadler wants to merge 1 commit intoargoproj:mainfrom
joestadler:feat-argo-workflows-deployment-strategy

Conversation

@joestadler
Copy link
Copy Markdown

Why

The workflow-controller Deployment and the argo-server Deployment didn't expose a way to set spec.strategy. The controller template only set type: Recreate when replicas == 1; otherwise no strategy was rendered on either Deployment, so Kubernetes fell back to the default RollingUpdate { maxUnavailable: 25%, maxSurge: 25% }.

For operators running 2 replicas, that default allows an old pod to terminate before its replacement is Ready, producing a brief gap that surfaces to users as a white screen during chart upgrades. A PDB doesn't help here — PDBs only govern voluntary disruptions (drains), not rolling updates. The argo-cd chart already exposes deploymentStrategy per component for exactly this reason; this PR brings argo-workflows in line.

What

Adds controller.deploymentStrategy and server.deploymentStrategy values (default {}). When set, the value is rendered into spec.strategy on the corresponding Deployment.

Backwards compatible:

New capability: operators running 2+ replicas can now opt into zero-downtime rolls:

controller:
  replicas: 2
  deploymentStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
server:
  replicas: 2
  deploymentStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1

Verified locally with helm template:

Scenario Controller strategy Server strategy
Defaults (replicas=1, no override) type: Recreate (none)
replicas=2, no override (none) (none)
replicas=2 + override RollingUpdate maxUnavailable=0 RollingUpdate maxUnavailable=0

Checklist

  • Bumped chart version: 1.0.13 → 1.0.14
  • Updated README.md via ./scripts/helm-docs.sh
  • Updated artifacthub.io/changes annotation in Chart.yaml
  • New values are backwards compatible with sensible defaults ({})
  • Commits are DCO signed
  • Single chart in this PR (argo-workflows only)

…d server

The workflow-controller Deployment and the argo-server Deployment did not
expose a way to set spec.strategy. The controller template only set
`type: Recreate` when `replicas == 1`; otherwise no strategy was rendered
on either Deployment, so Kubernetes used the default RollingUpdate
(25%/25%). For operators running 2 replicas this allowed an old pod to
terminate before its replacement was Ready, producing a brief gap that
shows up to UI users as a white screen during chart upgrades. A PDB does
not help here — PDBs only govern voluntary disruptions, not rolling
updates.

This adds `controller.deploymentStrategy` and `server.deploymentStrategy`
values (default `{}`) that thread into the respective Deployment specs
when set, mirroring the pattern in the argo-cd chart. Backwards
compatible: when `controller.deploymentStrategy` is unset, the existing
`type: Recreate` default for `replicas: 1` is preserved; for `replicas: 2+`
the K8s default applies as before.

Operators running 2+ replicas can now opt into zero-downtime rolls with
something like:

    controller:
      replicas: 2
      deploymentStrategy:
        type: RollingUpdate
        rollingUpdate:
          maxUnavailable: 0
          maxSurge: 1

Signed-off-by: joestadler <[email protected]>
@joestadler joestadler closed this May 1, 2026
@joestadler joestadler deleted the feat-argo-workflows-deployment-strategy branch May 1, 2026 17:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant