feat: Add support for any resource which implementes /scale subreso…

…urce (#852)

.golangci.yml

@@ -49,7 +49,6 @@ issues:
   exclude-rules:
     - path: _test\.go
       linters:
-        - gomnd
         - dupl
         - unparam
   # Exclude gci check for //+kubebuilder:scaffold:imports comments. Waiting to
@@ -60,6 +59,11 @@ issues:
     - path: operator/main.go
       linters:
         - gci
+  # Exlude httpso.Spec.ScaleTargetRef.Deployment until we remove it in v0.9.0
+    - linters:
+       - staticcheck
+      text: "SA1019: httpso.Spec.ScaleTargetRef.Deployment"
+
 linters-settings:
   funlen:
     lines: 80

CHANGELOG.md

@@ -21,7 +21,7 @@ This changelog keeps track of work items that have been completed and are ready
 
 ### New
 
-- **General**: TODO ([#TODO](https://github.com/kedacore/http-add-on/issues/TODO))
+- **General**: Support any resource which implements `/scale` subresource ([#438](https://github.com/kedacore/http-add-on/issues/438))
 
 ### Improvements
 
@@ -37,7 +37,7 @@ You can find all deprecations in [this overview](https://github.com/kedacore/htt
 
 New deprecation(s):
 
-- **General**: TODO ([#TODO](https://github.com/kedacore/http-add-on/issues/TODO))
+- **General**: Deprecated `KEDA_HTTP_DEPLOYMENT_CACHE_POLLING_INTERVAL_MS` in favor of `KEDA_HTTP_ENDPOINTS_CACHE_POLLING_INTERVAL_MS` ([#438](https://github.com/kedacore/http-add-on/issues/438))
 
 Previously announced deprecation(s):
 

Makefile

@@ -140,6 +140,9 @@ KUSTOMIZE = $(shell pwd)/bin/kustomize
 kustomize: ## Download kustomize locally if necessary.
 	GOBIN=$(shell pwd)/bin go install sigs.k8s.io/kustomize/kustomize/v5
 
+install: manifests kustomize ## Install CRDs into the K8s cluster specified in ~/.kube/config.
+	$(KUSTOMIZE) build config/crd | kubectl apply -f -
+
 deploy: manifests kustomize ## Deploy to the K8s cluster specified in ~/.kube/config.
 	cd config/interceptor && \
 	$(KUSTOMIZE) edit set image ghcr.io/kedacore/http-add-on-interceptor=${IMAGE_INTERCEPTOR_VERSIONED_TAG}

config/crd/bases/http.keda.sh_httpscaledobjects.yaml

@@ -102,9 +102,15 @@ spec:
                 description: The name of the deployment to route HTTP requests to
                   (and to autoscale).
                 properties:
+                  apiVersion:
+                    type: string
                   deployment:
-                    description: The name of the deployment to scale according to
-                      HTTP traffic
+                    description: 'Deprecated: The name of the deployment to scale
+                      according to HTTP traffic'
+                    type: string
+                  kind:
+                    type: string
+                  name:
                     type: string
                   port:
                     description: The port to route to
@@ -114,7 +120,6 @@ spec:
                     description: The name of the service to route to
                     type: string
                 required:
-                - deployment
                 - port
                 - service
                 type: object

config/interceptor/deployment.yaml

@@ -38,7 +38,7 @@ spec:
           value: "500ms"
         - name: KEDA_CONDITION_WAIT_TIMEOUT
           value: "20s"
-        - name: KEDA_HTTP_DEPLOYMENT_CACHE_POLLING_INTERVAL_MS
+        - name: KEDA_HTTP_ENDPOINTS_CACHE_POLLING_INTERVAL_MS
           value: "1000"
         - name: KEDA_HTTP_FORCE_HTTP2
           value: "false"

config/interceptor/role.yaml

@@ -5,9 +5,9 @@ metadata:
   name: interceptor
 rules:
 - apiGroups:
-  - apps
+  - ""
   resources:
-  - deployments
+  - endpoints
   verbs:
   - get
   - list

config/scaler/role.yaml

@@ -12,14 +12,6 @@ rules:
   - get
   - list
   - watch
-- apiGroups:
-  - apps
-  resources:
-  - deployments
-  verbs:
-  - get
-  - list
-  - watch
 - apiGroups:
   - http.keda.sh
   resources:

docs/design.md

@@ -23,7 +23,7 @@ The [operator](../operator) runs inside the Kubernetes namespace to which they'r
 
 - Update an internal routing table that maps incoming HTTP hostnames to internal applications.
 - Furnish this routing table information to interceptors so that they can properly route requests.
-- Create a [`ScaledObject`](https://keda.sh/docs/2.3/concepts/scaling-deployments/#scaledobject-spec) for the `Deployment` specified in the `HTTPScaledObject` resource.
+- Create a [`ScaledObject`](https://keda.sh/docs/latest/concepts/scaling-deployments/#scaledobject-spec) for the `Deployment` specified in the `HTTPScaledObject` resource.
 
 When the `HTTPScaledObject` is deleted, the operator reverses all of the aforementioned actions.
 

docs/faq.md

@@ -2,7 +2,7 @@
 
 ## Why does this project route HTTP requests?
 
-In order to autoscale a `Deployment`, KEDA-HTTP needs to be involved with routing HTTP requests. However, the project is minimally involved with routing and we're working on ways to get out of the "critical path" of an HTTP request as much as possible. For more information, please see our [scope](./scope.md) document.
+In order to autoscale a workload, KEDA-HTTP needs to be involved with routing HTTP requests. However, the project is minimally involved with routing and we're working on ways to get out of the "critical path" of an HTTP request as much as possible. For more information, please see our [scope](./scope.md) document.
 
 ## How is this project similar or different from [Osiris](https://github.com/deislabs/osiris)?
 
@@ -13,7 +13,7 @@ Osiris and KEDA-HTTP have similar features:
 
 However, Osiris and KEDA-HTTP differ in several ways:
 
-- Autoscaling concerns are implemented separately from the application resources - `Service`, `Ingress`, `Deployment` and more in KEDA-HTTP. With Osiris, those concerns are baked into each app resource.
+- Autoscaling concerns are implemented separately from the application resources - `Service`, `Ingress`, `Deployment`, `StatefulSet`, `/scale` and more in KEDA-HTTP. With Osiris, those concerns are baked into each app resource.
 - The KEDA-HTTP operator can automatically deploy and configure networking and compute resources necessary for an HTTP application to autoscale. Osiris does not have this functionality.
 - Osiris is currently archived in GitHub.
 

docs/ref/v0.6.0/http_scaled_object.md

@@ -0,0 +1,63 @@
+# The `HTTPScaledObject`
+
+>This document reflects the specification of the `HTTPScaledObject` resource for the `v0.7.0` version.
+
+Each `HTTPScaledObject` looks approximately like the below:
+
+```yaml
+kind: HTTPScaledObject
+apiVersion: http.keda.sh/v1alpha1
+metadata:
+    name: xkcd
+spec:
+    hosts:
+    - myhost.com
+    pathPrefixes:
+    - /test
+    scaleTargetRef:
+        deployment: xkcd
+        service: xkcd
+        port: 8080
+    replicas:
+        min: 5
+        max: 10
+
+```
+
+This document is a narrated reference guide for the `HTTPScaledObject`, and we'll focus on the `spec` field.
+
+## `hosts`
+
+These are the hosts to apply this scaling rule to. All incoming requests with one of these values in their `Host` header will be forwarded to the `Service` and port specified in the below `scaleTargetRef`, and that same `scaleTargetRef`'s workload will be scaled accordingly.
+
+## `pathPrefixes`
+
+These are the paths to apply this scaling rule to. All incoming requests with one of these values as path prefix will be forwarded to the `Service` and port specified in the below `scaleTargetRef`, and that same `scaleTargetRef`'s workload will be scaled accordingly.
+
+## `scaleTargetRef`
+
+This is the primary and most important part of the `spec` because it describes:
+
+1. The incoming host to apply this scaling rule to.
+2. What workload to scale.
+3. The service to which to route HTTP traffic.
+
+### `deployment`
+
+This is the name of the `Deployment` to scale. It must exist in the same namespace as this `HTTPScaledObject` and shouldn't be managed by any other autoscaling system. This means that there should not be any `ScaledObject` already created for this `Deployment`. The HTTP Add-on will manage a `ScaledObject` internally.
+
+### `service`
+
+This is the name of the service to route traffic to. The add-on will create autoscaling and routing components that route to this `Service`. It must exist in the same namespace as this `HTTPScaledObject` and should route to the same `Deployment` as you entered in the `deployment` field.
+
+### `port`
+
+This is the port to route to on the service that you specified in the `service` field. It should be exposed on the service and should route to a valid `containerPort` on the `Deployment` you gave in the `deployment` field.
+
+### `targetPendingRequests`
+
+>Default: 100
+
+This is the number of _pending_ (or in-progress) requests that your application needs to have before the HTTP Add-on will scale it. Conversely, if your application has below this number of pending requests, the HTTP add-on will scale it down.
+
+For example, if you set this field to 100, the HTTP Add-on will scale your app up if it sees that there are 200 in-progress requests. On the other hand, it will scale down if it sees that there are only 20 in-progress requests. Note that it will _never_ scale your app to zero replicas unless there are _no_ requests in-progress. Even if you set this value to a very high number and only have a single in-progress request, your app will still have one replica.

docs/ref/v0.7.0/http_scaled_object.md

@@ -0,0 +1,77 @@
+# The `HTTPScaledObject`
+
+>This document reflects the specification of the `HTTPScaledObject` resource for the `v0.7.0` version.
+
+Each `HTTPScaledObject` looks approximately like the below:
+
+```yaml
+kind: HTTPScaledObject
+apiVersion: http.keda.sh/v1alpha1
+metadata:
+    name: xkcd
+spec:
+    hosts:
+    - myhost.com
+    pathPrefixes:
+    - /test
+    scaleTargetRef:
+        name: xkcd
+        kind: Deployment
+        apiVersion: apps/v1
+        service: xkcd
+        port: 8080
+    replicas:
+        min: 5
+        max: 10
+
+```
+
+This document is a narrated reference guide for the `HTTPScaledObject`, and we'll focus on the `spec` field.
+
+## `hosts`
+
+These are the hosts to apply this scaling rule to. All incoming requests with one of these values in their `Host` header will be forwarded to the `Service` and port specified in the below `scaleTargetRef`, and that same `scaleTargetRef`'s workload will be scaled accordingly.
+
+## `pathPrefixes`
+
+These are the paths to apply this scaling rule to. All incoming requests with one of these values as path prefix will be forwarded to the `Service` and port specified in the below `scaleTargetRef`, and that same `scaleTargetRef`'s workload will be scaled accordingly.
+
+## `scaleTargetRef`
+
+This is the primary and most important part of the `spec` because it describes:
+
+1. The incoming host to apply this scaling rule to.
+2. What workload to scale.
+3. The service to which to route HTTP traffic.
+
+### `deployment` (DEPRECTATED: removed as part of v0.9.0)
+
+This is the name of the `Deployment` to scale. It must exist in the same namespace as this `HTTPScaledObject` and shouldn't be managed by any other autoscaling system. This means that there should not be any `ScaledObject` already created for this `Deployment`. The HTTP Add-on will manage a `ScaledObject` internally.
+
+### `name`
+
+This is the name of the workload to scale. It must exist in the same namespace as this `HTTPScaledObject` and shouldn't be managed by any other autoscaling system. This means that there should not be any `ScaledObject` already created for this workload. The HTTP Add-on will manage a `ScaledObject` internally.
+
+### `kind`
+
+This is the kind of the workload to scale.
+
+### `apiVersion`
+
+This is the apiVersion of the workload to scale.
+
+### `service`
+
+This is the name of the service to route traffic to. The add-on will create autoscaling and routing components that route to this `Service`. It must exist in the same namespace as this `HTTPScaledObject` and should route to the same `Deployment` as you entered in the `deployment` field.
+
+### `port`
+
+This is the port to route to on the service that you specified in the `service` field. It should be exposed on the service and should route to a valid `containerPort` on the `Deployment` you gave in the `deployment` field.
+
+### `targetPendingRequests`
+
+>Default: 100
+
+This is the number of _pending_ (or in-progress) requests that your application needs to have before the HTTP Add-on will scale it. Conversely, if your application has below this number of pending requests, the HTTP add-on will scale it down.
+
+For example, if you set this field to 100, the HTTP Add-on will scale your app up if it sees that there are 200 in-progress requests. On the other hand, it will scale down if it sees that there are only 20 in-progress requests. Note that it will _never_ scale your app to zero replicas unless there are _no_ requests in-progress. Even if you set this value to a very high number and only have a single in-progress request, your app will still have one replica.

docs/use_cases.md

@@ -19,11 +19,11 @@ Moving this application to Kubernetes may make sense for several reasons, but th
 
 If the application _is_ being moved to Kubernetes, you would follow these steps to get it autoscaling and routing with KEDA-HTTP:
 
-- Create a `Deployment` and `Service`
+- Create a workload and `Service`
 - [Install](./install.md) the HTTP Add-on
-- Create a single `HTTPScaledObject` in the same namespace as the `Deployment` and `Service` you created
+- Create a single `HTTPScaledObject` in the same namespace as the workload and `Service` you created
 
-At that point, the operator will create the proper autoscaling and routing infrastructure behind the scenes and the application will be ready to scale.
+At that point, the operator will create the proper autoscaling and routing infrastructure behind the scenes and the application will be ready to scale. Any request received by the interceptor with the proper host will be routed to the proper backend.
 
 ## Current HTTP Server in Kubernetes
 
@@ -36,6 +36,6 @@ In this case, the reasoning for adding the HTTP Add-on would be clear - adding a
 Getting the HTTP Add-on working can be done transparently and without downtime to the application:
 
 - [Install](./install.md) the add-on. This step will have no effect on the running application.
-- Create a new `HTTPScaledObject`. This step activates autoscaling for the `Deployment` that you specify and the application will immediately start scaling up and down based on incoming traffic through the interceptor that was created.
+- Create a new `HTTPScaledObject`. This step activates autoscaling for the workload that you specify and the application will immediately start scaling up and down based on incoming traffic through the interceptor that was created.
 
 [Go back to landing page](./)

docs/walkthrough.md

@@ -14,7 +14,7 @@ You'll need to install a `Deployment` and `Service` first. You'll tell the add-o
 $ helm install xkcd ./examples/xkcd -n ${NAMESPACE}
 ```
 
-You'll need to clone the repository to get access to this chart. If you have your own `Deployment` and `Service` installed, you can go right to creating an `HTTPScaledObject` in the next section.
+You'll need to clone the repository to get access to this chart. If you have your own workload and `Service` installed, you can go right to creating an `HTTPScaledObject` in the next section.
 
 >If you are running KEDA and the HTTP Add-on in cluster-global mode, you can install the XKCD chart in any namespace you choose. If you do so, make sure you add `--set ingressNamespace=${NAMESPACE}` to the above installation command.
 
@@ -25,10 +25,10 @@ You'll need to clone the repository to get access to this chart. If you have you
 You interact with the operator via a CRD called `HTTPScaledObject`. This CRD object instructs interceptors to forward requests for a given host to your app's backing `Service`. To get an example app up and running, read the notes below and then run the subsequent command from the root of this repository.
 
 ```console
-$ kubectl create -n $NAMESPACE -f examples/v0.3.0/httpscaledobject.yaml
+$ kubectl create -n $NAMESPACE -f examples/v0.7.0/httpscaledobject.yaml
 ```
 
->If you'd like to learn more about this object, please see the [`HTTPScaledObject` reference](./ref/v0.3.0/http_scaled_object.md).
+>If you'd like to learn more about this object, please see the [`HTTPScaledObject` reference](./ref/v0.7.0/http_scaled_object.md).
 
 ## Testing Your Installation
 
@@ -40,13 +40,13 @@ $ kubectl port-forward svc/keda-add-ons-http-interceptor-proxy -n ${NAMESPACE} 8
 
 ### Routing to the Right `Service`
 
-As said above, you need to route your HTTP traffic to the `Service` that the add-on has created. If you have existing systems - like an ingress controller - you'll need to anticipate the name of these created `Service`s. Each one will be named consistently like so, in the same namespace as the `HTTPScaledObject` and your application (i.e. `$NAMESPACE`):
+As said above, you need to route your HTTP traffic to the `Service` that the add-on has created during the installation. If you have existing systems - like an ingress controller - you'll need to anticipate the name of these created `Service`s. Each one will be named consistently like so, in the same namespace as the `HTTPScaledObject` and your application (i.e. `$NAMESPACE`):
 
 ```console
 keda-add-ons-http-interceptor-proxy
 ```
 
->This is installed by the [Helm chart](https://github.com/kedacore/charts/tree/master/http-add-on) as a `ClusterIP` `Service` by default.
+> This is installed by the [Helm chart](https://github.com/kedacore/charts/tree/master/http-add-on) as a `ClusterIP` `Service` by default.
 
 #### Installing and Using the [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/#using-helm) Ingress Controller
 
@@ -64,6 +64,8 @@ helm install ingress-nginx ingress-nginx/ingress-nginx -n ${NAMESPACE}
 
 An [`Ingress`](https://kubernetes.io/docs/concepts/services-networking/ingress/) resource was already created as part of the [xkcd chart](../examples/xkcd/templates/ingress.yaml), so the installed NGINX ingress controller will initialize, detect the `Ingress`, and begin routing to the xkcd interceptor `Service`.
 
+>NOTE: You may have to create an external service `type: ExternalName` pointing to the interceptor namespace and use it from `Ingress` manifest.
+
 When you're ready, please run `kubectl get svc -n ${NAMESPACE}`, find the `ingress-nginx-controller` service, and copy and paste its `EXTERNAL-IP`. This is the IP address that your application will be running at on the public internet.
 
 >Note: you should go further and set your DNS records appropriately and set up a TLS certificate for this IP address. Instructions to do that are out of scope of this document, though.

examples/v0.6.0/httpscaledobject.yaml

@@ -0,0 +1,16 @@
+kind: HTTPScaledObject
+apiVersion: http.keda.sh/v1alpha1
+metadata:
+    name: xkcd
+spec:
+    hosts:
+    - myhost.com
+    pathPrefixes:
+    - /test
+    scaleTargetRef:
+        name: xkcd
+        service: xkcd
+        port: 8080
+    replicas:
+        min: 5
+        max: 10

examples/v0.7.0/httpscaledobject.yaml

@@ -0,0 +1,18 @@
+kind: HTTPScaledObject
+apiVersion: http.keda.sh/v1alpha1
+metadata:
+    name: xkcd
+spec:
+    hosts:
+    - myhost.com
+    pathPrefixes:
+    - /test
+    scaleTargetRef:
+        name: xkcd
+        kind: Deployment
+        apiVersion: apps/v1
+        service: xkcd
+        port: 8080
+    replicas:
+        min: 5
+        max: 10

examples/xkcd/templates/externalservice.yaml

@@ -0,0 +1,9 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: {{ include "xkcd.fullname" . }}-proxy
+  labels:
+    {{- include "xkcd.labels" . | nindent 4 }}
+spec:
+  type: ExternalName
+  externalName: keda-http-add-on-interceptor-proxy.keda