kedacore / http-add-on

Add-on for KEDA to scale HTTP workloads
https://kedacore.github.io/http-add-on/
Apache License 2.0
372 stars 97 forks source link

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

Open zackijack opened 1 month ago

zackijack commented 1 month ago

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 commented 4 weeks ago

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