dynamicStableScale for non-server workloads

[sding3]

For a workload without a ingress and service (let's call this a non-server workload), argo-rollouts behaves as if dynamicStableScale has been configured to true.

dynamicStableScale is explicitly documented as "Only available when traffic routing is used". The fact that argo-rollouts begin to scale down the stable pods when rolling out an update to a non-server workload (which does not use traffic routing) contradicts with that documentation.

I don't see why the dynamicStableScale configuration requires traffic routing to work. All that it controls is whether to scale down the stable pods or not when canary pods are added, that doesn't seem like it should require traffic routing. Non-server workloads can benefit from argo rollout canary release strategy as well as being able to configure dynamicStableScale to true or false.

To Reproduce

Apply the following argo rollout resource:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: podinfo
  namespace: test
  labels:
    app: podinfo
spec:
  progressDeadlineSeconds: 60
  progressDeadlineAbort: true
  replicas: 5
  minReadySeconds: 5
  revisionHistoryLimit: 5
  strategy:
    canary:
      maxSurge: "20%"
      abortScaleDownDelaySeconds: 600
      stableMetadata:
        labels:
          role: canary-stable
      canaryMetadata:
        labels:
          role: canary-next
      steps:
      - setWeight: 50
      - pause: {}
  selector:
    matchLabels:
      app: podinfo
  template:
    metadata:
      labels:
        app: podinfo
    spec:
      containers:
      - name: podinfo
        image: ghcr.io/stefanprodan/podinfo:6.0.0
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 9898
          protocol: TCP
        - name: http-metrics
          containerPort: 9797
          protocol: TCP
        - name: grpc
          containerPort: 9999
          protocol: TCP
        command:
        - ./podinfo
        - --port=9898
        - --port-metrics=9797
        - --grpc-port=9999
        - --grpc-service-name=podinfo
        - --level=debug
        - --random-delay=false
        - --random-error=false

Then update the image to ghcr.io/stefanprodan/podinfo:6.0.1 to trigger rollout, and observe argo create the new pods and reduce the number of the old pods.

Expected behavior

argo should add new pods without deleting old pods.

[kostis-codefresh]

Maybe I am missing something here, but how would that work?

I don't see why the dynamicStableScale configuration requires traffic routing to work

If you don't use a traffic manager then Kubernetes will do standard pod based routing.

Let's take an example where the application has 10 pods and canary weight is 20%

With the existing behavior (where old pods are deleted)

1. Stable has 10 pods, canary is 0 pods
2. You request a canary to 20%
3. Stable has 8 pods and canary is 2 pods
4. Canary traffic is 2/10 total pods so 20% as requested

With what you suggest (old pods are never deleted)

1. Stable has 10 pods, canary is 0 pods
2. You request a canary to 20%
3. Stable has 10 pods and canary is 2 pods
4. Canary traffic is 2/12 total pods so 16% instead of 20% that you requested

And this gets worse as the canary increases

If I request a canary of 50% then if canary pods are 5, old pods are still 10 so my canary traffic is 5/15 equals 33% instead of the 50% I want.

Argo Rollouts doesn't really know if your service has an ingress or not. The assumption is that you have a service.

If you have a workload without a ingress and service why do you need Argo Rollouts in the first place? What is different from a standard K8s rolling deployment?

[japem]

If you have a workload without a ingress and service why do you need Argo Rollouts in the first place? What is different from a standard K8s rolling deployment?

A standard k8s rolling deployment does not provide the ability to roll back based on KPIs, only readiness checks which may not provide nearly enough information to determine whether to abort the rollout. This seems like a reasonable request to me.