Open zackijack opened 1 month 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
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:
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.