HTTPScaledObject with existing ScaledObject and interceptor proxy setup

[KasyapG]

Hello Team,

We are trying to use KEDA`s HTTP ADD-On and have below concerns.

1. We have a requirement of scaling applications on http requests and also want CPU and Memory as fallback scalers. Currently we are using Keda scaledobject with Prometheus, CPU and Memory. Could you please confirm if creating HTTPScaledobject on same deployment target will create issues as Kubernetes does not allow multiple HPAs targetting same deployment.
2. While we are doing poc on an application with below scaled object we are unable to create HPA and the I see the scaledobject created is unable to recognize the target on which hpa to be created.

apiVersion: http.keda.sh/v1alpha1 kind: HTTPScaledObject metadata: name: test1-api-http-scaler namespace: <ns> spec: scaleTargetRef: kind: Deployment name: test1-api service: test1-api namespace: <ns> port: 8080 replicas: min: 1 max: 5 scalingMetric: requestRate: targetValue: 10 granularity: 1s

Could you please help me understand on the both the queries

Regards,
Kasyap G

[JorTurFer]

Hello
I transfer this issue to the add-on repo and we can continue there.

[JorTurFer]

Hi @KasyapG ,
short answer: No, you can't have both

long answer: You can have a single HPA managing a workload. ScaledObject uses HPA under the hood and HTTPScaledObject uses ScaledObject under the hood, so if you create a ScaledObject and a HTTPScaledObject, you're generating 2 HPA to manage the same workload and depending on your KEDA version you'll get admission errors or unexpected scaling behaviours.

To achieve this, you could disable the SO creation and just include the trigger in your already existing ScaleedObject

[KasyapG]

Thank you @JorTurFer

The httpscaledobject is now showing target details.

However, I am trying to use the httpscaledobject and it is unable to show any metrics. And I do not see any scaling happening.

I only have httpscaledobject on the application.

I have followed the below instructions

https://github.com/kedacore/http-add-on/blob/main/docs/install.md

Could you please let me know if there is any step that is needed for metrics to be identified.

Regards,
Kasyap G

[JorTurFer]

so, you have deployed a HTTPScaledObject and it doesn't work, right? Do you see the ScaledObject generated by this? Is there any error in keda add-on operator?

[KasyapG]

We have the http scaledobject created and the I noticed that external sclaer pod mentions that the "there isn't any valid interceptor endpoint".

keda-add-ons-http-controller-manager ->

keda-add-ons-http-external-scaler ->

[JorTurFer]

Do you have any network policy or so managing the traffic? based on scaler error, it looks like your scaler can't reach the interceptors

[KasyapG]

I can check that, however could you please let ne know how does the traffic is intercepted once the request hits the ingress. How will the http addon know that the request has come to ingress.

In the httpscaledobject what exactly is the value for service parameter?

Regards,
Kasyap G

[linkvt]

Hi @KasyapG ,

the traffic flow looks like this:

1. Client sends request that is received by your ingress controller
2. Ingress controller see's a matching Ingress/HTTPRoute/... resource for the client request
3. Ingress controller sends the traffic to a proxy service (see below) which "forwards" the traffic to the Interceptor
4. The interceptor see's the incoming traffic, checks HTTPScaledObjects for matchers based on host/... and routes the traffic to your application pods
   • if your deployment is scaled to 0 the interceptor buffers the request before forwarding

Without the HTTP Add-on you would create an Ingress/HTTPRoute/... that points directly to your applications Service, but with the HTTP Add-on you point it to a proxy Service of the interceptor instead.

Example proxy service and ingress:

apiVersion: v1
kind: Service
metadata:
  name: app-proxy
  namespace: default
spec:
  type: ExternalName
  externalName: keda-add-ons-http-interceptor-proxy.keda

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  namespace: default
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - backend:
          service:
            name: app-proxy # not your normal "app" service
            port:
              number: 8080
        path: /
        pathType: Prefix

In the HTTPSO (which is in the same namespace as your app) you will then specify the normal app service that points to your application pods.

The interceptor will receive all traffic from the ingress controller, buffer it if scaling is needed and forward it to the application pods.

As Jorge mentioned the problem you see is because the Scaler cannot find any endpoints of the Interceptor to connect to.
Can you check the pods/deployment of the scaler to verify that the following env vars are pointing to the service of the interceptor?

    env:
    - name: KEDA_HTTP_SCALER_TARGET_ADMIN_NAMESPACE
      value: keda
    - name: KEDA_HTTP_SCALER_TARGET_ADMIN_SERVICE
      value: keda-add-ons-http-interceptor-admin

BTW: We are currently implementing a new resource (InterceptorRoute) that makes your use-case simpler as you can add just this resource to an existing ScaledObject. Documentation will also be improved very soon.

[KasyapG]

Hello @linkvt ,

Thank you for the update.

For your point "Without the HTTP Add-on you would create an Ingress/HTTPRoute/... that points directly to your applications Service, but with the HTTP Add-on you point it to a proxy Service of the interceptor instead."

How is this being achieved is there any update being done to our ingress controller (or does require a change to point to the proxy)?

Are there changes needed on the ingress controller apart from the keda http Add-on installation?

And I have noticed the args that you have mentioned are present under the keda-add-ons-http-external-scaler

[linkvt]

Hi,

there are no changes needed on your ingress controller but you would need to update your ingress resource as shown in the code snippet for the service/ingress, see app-ingress.

With regards to the scaler error: The env vars look good and it should work in theory as you also used our helm chart. Does the error still appear, maybe it was old and from the initial deployment?
If it is still there: Do you see a service in namespace keda with name keda-add-ons-http-interceptor-admin ?

Do you see EndpointSlices for that service? Should look like this:

❯ kubectl get endpointslices -n keda -l kubernetes.io/service-name=keda-add-ons-http-interceptor-admin
NAME                                        ADDRESSTYPE   PORTS   ENDPOINTS      AGE
keda-add-ons-http-interceptor-admin-2kmjk   IPv4          9090    10.244.0.199   27d

[KasyapG]

• So we should create a proxy svc (app-proxy) for each deployment (microservice) and also update the app-ingress to point to the proxy service?

• Also I do see the endpointslices for the admin service.

• You might be right the logs are old, I do not see the error today however I do not any scaling happening, the metrics is always 0 even with load.

• The application is not scaling and ultimately failing as it is unable to scale.

Regards,
Kasyap G

[linkvt]

Hi @KasyapG ,

So we should create a proxy svc (app-proxy) for each deployment (microservice) and also update the app-ingress to point to the proxy service?

Yes correct! After that change traffic will flow from ingress controller through interceptor to the pods.

[KasyapG]

Is HTTP Add-On feature stable and recommended for prod deployments?

[linkvt]

Not yet as indicated by the note in the README, but we are very close. We are improving the HTTP Addon heavily since 2-3 months and made really good changes already with new features and massive performance improvements.
IMO we will have it production ready with the new InterceptorRoute CRD very soon, but there are still a few things to do before our GA as shown in #911 .
It does make sense though to do some experiments with it and try maybe using it on non-prod envs to get some experience.