Unexpected pod duplication when using workloadRef with HPA and Deployment

[tamarubin]

Checklist:

• I've included steps to reproduce the bug.
• I've included the version of argo rollouts.

Describe the bug

We’ve run into an issue using Argo Rollouts with workloadRef in combination with HPA.

What we’re doing:
• We use a Rollout with workloadRef pointing to a Deployment.
• HPA targets the Rollout and has minReplicas: 2.
• The referenced Deployment is still set to replicas: 1.

What we observe:
• We consistently have 3 pods running:
• 2 pods are managed by the Rollout’s ReplicaSet (as expected due to HPA).
• 1 pod is created and managed directly by the Deployment controller.

This happens even though the Rollout is meant to “take over” the Deployment.

What’s expected:

We expected that the Rollout (when using workloadRef) would fully manage the workload and prevent the Deployment controller from spawning its own pods.

Notes:
• Setting replicas: 0 in the Deployment avoids duplication, but makes the Deployment appear “Unavailable” and can easily break if someone bumps replicas again.

version:
v1.8.3

Impacted by this bug? Give it a 👍. We prioritize the issues with the most 👍.

[kostis-codefresh]

The proper solution is as you found out to remove the replicas field from deployment. And actually this is an HPA best practice unrelated to Argo Rollouts

Even if you look at plain k8s docs the deployment does not have a replica field when HPA is active https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/

On a related note, you can see several examples of HPA here https://github.com/kostis-codefresh/rollouts-autoscaling-example (Although not with workloadref)

[tamarubin]

You’re correct that removing replicas from the Deployment is the right move when using HPA — that’s standard best practice. However, when using Argo Rollouts with workloadRef, the behavior is a bit more nuanced.

If the HPA targets the Rollout, and the Rollout is configured with a workloadRef pointing to a Deployment, the Rollout will not set replicas: on the Deployment unless the Rollout itself has spec.replicas set.

The key detail is:

If neither the Rollout nor the Deployment has a replicas: field defined, the Kubernetes API server defaults it to 1 during initial creation. That default value may persist and appear in the live object.

So even if you remove replicas: from your Deployment YAML, the field can still appear in the live object because of API server defaulting — not because Rollout is actively setting it. This can cause confusion, and duplication especially when you’re expecting the HPA to manage replicas.