Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Multiple Services in spec.scaleTargetRef for Argo Rollouts with Canary Deployments #1169

Open
zackijack opened this issue Oct 15, 2024 · 1 comment

Comments

@zackijack
Copy link

Proposal

Currently, the http-add-on only supports a single service in spec.scaleTargetRef. However, when using Argo Rollouts with canary deployments, two services are needed: one for the stable version and one for the canary version, like in this example. This limitation prevents seamless integration with Argo Rollouts for canary deployments.

Maybe the HTTPScaledObject will look like this:

kind: HTTPScaledObject
apiVersion: http.keda.sh/v1alpha1
metadata:
    name: xkcd
spec:
    hosts:
        - myhost.com
    pathPrefixes:
        - /test
    scaleTargetRef:
        - name: xkcd
           kind: Rollout
           apiVersion: argoproj.io/v1alpha1
           service: xkcd-stable
           port: 8080
        - name: xkcd
           kind: Rollout
           apiVersion: argoproj.io/v1alpha1
           service: xkcd-canary
           port: 8080
    replicas:
        min: 1
        max: 10
    scaledownPeriod: 300
    scalingMetric:
        requestRate:
            granularity: 1s
            targetValue: 100
            window: 1m

Use-Case

I would like to request support for multiple services in spec.scaleTargetRef. This would allow users to specify both stable and canary services for more flexible and efficient canary deployments.

Is this a feature you are interested in implementing yourself?

Yes

Anything else?

Supporting multiple services in spec.scaleTargetRef will enable users to leverage the full potential of Argo Rollouts for canary deployments, allowing for more robust and reliable application scaling and traffic management.

@kahirokunn
Copy link
Contributor

With that yaml, it's not clear how much traffic should be sent to Canary and Stable using KedaHttpProxy.
For that reason, I think that if you want to implement a practical Canary, you'll also need features such as weight and sessionAffinity.

eg.

kind: HTTPScaledObject
apiVersion: http.keda.sh/v1alpha1
metadata:
    name: xkcd
spec:
    hosts:
        - myhost.com
    pathPrefixes:
        - /test
    scaleTargetRef:
        - name: xkcd
           kind: Rollout
           apiVersion: argoproj.io/v1alpha1
           service: xkcd-stable
           port: 8080
+          weight: 1
        - name: xkcd
           kind: Rollout
           apiVersion: argoproj.io/v1alpha1
           service: xkcd-canary
           port: 8080
+          weight: 99
+   sessionAffinity:
+       cookieName: flagger-cookie
+       maxAge: 21600
    replicas:
        min: 1
        max: 10
    scaledownPeriod: 300
    scalingMetric:
        requestRate:
            granularity: 1s
            targetValue: 100
            window: 1m

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

No branches or pull requests

2 participants