* Add a way to turn off the profiling for all three http add-on components
Signed-off-by: Jirka Kremser <jiri.kremser@gmail.com>
* linter - The linter 'exportloopref' is deprecated (since v1.60.2) due to: Since Go1.22 (loopvar) this linter is no longer relevant. Replaced by copyloopvar.
Signed-off-by: Jirka Kremser <jiri.kremser@gmail.com>
---------
Signed-off-by: Jirka Kremser <jiri.kremser@gmail.com>
* fix: Standardize to keda-add-ons-http-interceptor-proxy
Signed-off-by: kahirokunn <okinakahiro@gmail.com>
* docs: remove outdated note about service naming
Both the Helm chart and raw manifests now use the same default service name. This commit removes a redundant note in the documentation to avoid confusion.
Signed-off-by: kahirokunn <okinakahiro@gmail.com>
---------
Signed-off-by: kahirokunn <okinakahiro@gmail.com>
* support portName in HTTPScaledObject service scaleTargetRef
Signed-off-by: Jan Wozniak <wozniak.jan@gmail.com>
* mutually exclusive port and portName
Co-authored-by: Jirka Kremser <535866+jkremser@users.noreply.github.com>
Signed-off-by: Jan Wozniak <wozniak.jan@gmail.com>
* make manifests
Signed-off-by: Jan Wozniak <wozniak.jan@gmail.com>
* fix CEL syntax
Signed-off-by: Jan Wozniak <wozniak.jan@gmail.com>
* e2e test for portName
Signed-off-by: Jan Wozniak <wozniak.jan@gmail.com>
* use service lister instead of endpoints cache to get port from portName
Signed-off-by: Jan Wozniak <wozniak.jan@gmail.com>
* docs for v0.8.1 HTTPScaledObject
Signed-off-by: Jan Wozniak <wozniak.jan@gmail.com>
---------
Signed-off-by: Jan Wozniak <wozniak.jan@gmail.com>
Co-authored-by: Jirka Kremser <535866+jkremser@users.noreply.github.com>
* fix: include trailing 0 window buckets in RPS calculation
fixes: https://github.com/kedacore/http-add-on/issues/1075
Signed-off-by: Jan Wozniak <wozniak.jan@gmail.com>
* add low level test for request drop to 0
Signed-off-by: Jan Wozniak <wozniak.jan@gmail.com>
---------
Signed-off-by: Jan Wozniak <wozniak.jan@gmail.com>
* fix: aligning the interceptor metrics vars with the OTEL spec
Signed-off-by: Joe Wogan <joe.wogan@10xbanking.com>
* chore: update skip urls in linkinator GithubAction
Signed-off-by: Joe Wogan <joe.wogan@10xbanking.com>
* chore: removing unused metricsCfg references
Signed-off-by: Joe Wogan <joe.wogan@10xbanking.com>
---------
Signed-off-by: Joe Wogan <joe.wogan@10xbanking.com>
* feat: Adding support to the interceptor proxy for TLS on the wire
Signed-off-by: Joe Wogan <joe.wogan@10xbanking.com>
* chore: adding e2e tests and tidying up changes
Signed-off-by: Joe Wogan <joe.wogan@10xbanking.com>
* chore: changing interceptor tls port for e2e tests
Signed-off-by: Joe Wogan <joe.wogan@10xbanking.com>
---------
Signed-off-by: Joe Wogan <joe.wogan@10xbanking.com>
* chore: Update skip-scaledobject-creation to align with KEDA annotations
Signed-off-by: Jorge Turrado <jorge_turrado@hotmail.es>
* use magic string during test to prevent not detected chained changes
Signed-off-by: Jorge Turrado <jorge_turrado@hotmail.es>
---------
Signed-off-by: Jorge Turrado <jorge_turrado@hotmail.es>
* feat: Add support to collect metrics using either a prometheus compatible endpoint or by sending metrics to an OTEL http endpoint
Signed-off-by: Joe Wogan <joe.wogan@10xbanking.com>
* fix: use UpDounCounter rather than gauge for pending request count and
specify otel image for e2e tests
Signed-off-by: Joe Wogan <joe.wogan@10xbanking.com>
---------
Signed-off-by: Joe Wogan <joe.wogan@10xbanking.com>
* Queue Pinger: Don't return error if fetchAndSaveCounts fails.
Returning the error here cancels the whole queuePinger.start loop, causing the server to (theoretically) crash.
Due to a separate bug, instead of crashing, the server can get wedged in an unhealthy state.
Fixes#870.
Signed-off-by: Andrew Garrett <andrewgarrett@google.com>
* Update CHANGELOG
Signed-off-by: Andrew Garrett <andrewgarrett@google.com>
* Update CHANGELOG.md
Signed-off-by: Jorge Turrado Ferrero <Jorge_turrado@hotmail.es>
* Update CHANGELOG.md
Signed-off-by: Jorge Turrado Ferrero <Jorge_turrado@hotmail.es>
---------
Signed-off-by: Andrew Garrett <andrewgarrett@google.com>
Signed-off-by: Jorge Turrado Ferrero <Jorge_turrado@hotmail.es>
Co-authored-by: Jorge Turrado Ferrero <Jorge_turrado@hotmail.es>
* fix verify-codegen
Signed-off-by: Pedro Tôrres <pedrotorres@microsoft.com>
* make codegen
Signed-off-by: Pedro Tôrres <pedrotorres@microsoft.com>
---------
Signed-off-by: Pedro Tôrres <pedrotorres@microsoft.com>
* README
Signed-off-by: Tom Kerkhove <kerkhove.tom@gmail.com>
* Reshuffle
Signed-off-by: Tom Kerkhove <kerkhove.tom@gmail.com>
* Split again
Signed-off-by: Tom Kerkhove <kerkhove.tom@gmail.com>
* Links
Signed-off-by: Tom Kerkhove <kerkhove.tom@gmail.com>
Signed-off-by: Tom Kerkhove <kerkhove.tom@gmail.com>
* docs: Provide capability to become listed end-users
Signed-off-by: GitHub <noreply@github.com>
* fix: Remove duplicate lines
Signed-off-by: Tom Kerkhove <kerkhove.tom@gmail.com>
* docs: Provide information concerning roadmap
Relates to https://github.com/kedacore/http-add-on/issues/446
* docs: Provide dedicated roadmap file
* docs: Link to dedicated roadmap
Signed-off-by: Tom Kerkhove <kerkhove.tom@gmail.com>
* Link from "here" to "roadmap" for accessibility.
Signed-off-by: Aaron Wislang <asw101@users.noreply.github.com>
Co-authored-by: Aaron Wislang <aaron.wislang@microsoft.com>
* updating the release process document
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* adding information about the chart's images.tag field in values.yaml
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* swapping watch broadcaster channel behavior
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* small test refactor
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* more comments in test
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* more comments and interface implementation check for fake deployment cache
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* adding comment to closeableWatcher
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* forgot the beginning of comment
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* adding error checking to the closeableWatcher
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* removing resultCalls from the closeable watcher
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* removing the closeableWatcher in favor of the fake watcher functionality in client-go
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* closeableWatcher => reopeningWatcher
The core functionality needed was automatic reopening of watch channels. This commit
implements that while removing some ancillary things like specifying whether
to reopen etc...
Signed-off-by: Aaron <aaron@ecomaz.net>
* fixing nil ptr exception
Signed-off-by: Aaron <aaron@ecomaz.net>
* clarifying comments
Signed-off-by: Aaron <aaron@ecomaz.net>
* add test for addEvt in deployment cache
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* Adding TestRunProxyServerCountMiddleware
Currently failing :)
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* adding resize timeout to the queue fake
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* StartTestServer => NewTestServer
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* StartTestServer => NewTestServer
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* Going back to StartTestServer
I forgot that it actually does start the test server in the background
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* using targetFromURL
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* more StartTestServer
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* Keeping track of the running queue count in the fake
Also protecting that map with a mutex
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* finishing the interceptor test
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* adding test comment
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* more movement over to targetFromURL
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* additional checks
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* adding test for 'interceptor' as host in GetScalerMetrics
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
* running table-driven tests in parallel
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
This commit reuses the `http.RoundTripper` so that we pool connections.
Before, we were creating a new round tripper -- and hence, a new
connection pool -- every time we forwarded a request. The result
was that we were not reusing connection, and were attempting to
create _new_ connections every time we forwarded a request.
Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
about: Template to keep track of the progress for a new KEDA HTTP add-on release.
title: "Release: "
labels: governance,release-management
assignees: tomkerkhove,jorturfer
---
This issue template is used to track the rollout of a new KEDA HTTP add-on version.
For the full release process, we recommend reading [this document]([https://github.com/kedacore/keda/blob/main/RELEASE-PROCESS.md](https://github.com/kedacore/http-add-on/blob/main/RELEASE-PROCESS.md)).
## Required items
- [ ] List items that are still open, but required for this release
# Timeline
We aim to release this release in the week of <weekrange,exampleMarch27-31>.
## Progress
- [ ] Add the new version to GitHub Bug report template
- [ ] Create KEDA release
- [ ] Prepare & ship Helm chart
- [ ] Publish on Artifact Hub ([repo](https://github.com/kedacore/external-scalers))
@ -9,6 +9,7 @@ _Provide a description of what has been changed_
### Checklist
- [ ] Commits are signed with Developer Certificate of Origin (DCO)
- [ ] Changelog has been updated and is aligned with our [changelog requirements](https://github.com/kedacore/keda/blob/main/CONTRIBUTING.md#Changelog)
- [ ] Any necessary documentation is added, such as:
This page contains a list of organizations who are using KEDA's HTTP Add-on in production or at stages of testing.
## Adopters
| Organization | Status | More Information (Blog post, etc.) |
| ------------ | ---------| ---------------|
| PropulsionAI ||[PropulsionAI](https://propulsionhq.com) allows you to add AI to your apps, without writing code.|
| REWE Digital ||From delivery service to market — [REWE Digital](https://www.rewe-digital.com) strengthens leading technological position of REWE Group in food retail sector. |
## Become an adopter!
You can easily become an adopter by sending a pull request to this file.
New changelog entries must be inline with our changelog guidelines.
Please refer to https://github.com/kedacore/keda/blob/main/CONTRIBUTING.md#Changelog to learn more.
-->
This changelog keeps track of work items that have been completed and are ready to be shipped in the next release.
## History
- [Unreleased](#unreleased)
- [v0.10.0](#v0100)
- [v0.9.0](#v090)
- [v0.8.0](#v080)
- [v0.7.0](#v070)
- [v0.6.0](#v060)
- [v0.5.0](#v050)
## Unreleased
### Breaking Changes
- **General**: TODO ([#TODO](https://github.com/kedacore/http-add-on/issues/TODO))
### New
- **General**: Add failover service on cold-start ([#1280](https://github.com/kedacore/http-add-on/pull/1280))
- **General**: Add configurable tracing support to the interceptor proxy ([#1021](https://github.com/kedacore/http-add-on/pull/1021))
- **General**: Allow using HSO and SO with different names ([#1293](https://github.com/kedacore/http-add-on/issues/1293))
- **General**: Support profiling for KEDA components ([#4789](https://github.com/kedacore/keda/issues/4789))
- **General**: Add possibility to skip TLS verification for upstreams in interceptor ([#1307](https://github.com/kedacore/http-add-on/pull/1307))
### Improvements
- **Interceptor**: Support HTTPScaledObject scoped timeout ([#813](https://github.com/kedacore/http-add-on/issues/813))
### Fixes
- **General**: TODO ([#TODO](https://github.com/kedacore/http-add-on/issues/TODO))
### Deprecations
- **General**: TODO ([#TODO](https://github.com/kedacore/http-add-on/issues/TODO))
### Other
- **Documentation**: Correct the service name used in the walkthrough documentation ([#1244](https://github.com/kedacore/http-add-on/pull/1244))
## v0.10.0
### New
- **General**: Fix infrastructure crashes when deleting ScaledObject while scaling
- **General**: Fix kubectl active printcolumn ([#1211](https://github.com/kedacore/http-add-on/issues/1211))
- **General**: Support InitialCooldownPeriod for HTTPScaledObject [#1213](https://github.com/kedacore/http-add-on/issues/1213)
### Other
- **Documentation**: Correct the service name used in the walkthrough documentation ([#1244](https://github.com/kedacore/http-add-on/pull/1244))
## v0.9.0
### Breaking Changes
- **General**: Drop support for deprecated field `spec.scaleTargetRef.deployment` ([#1061](https://github.com/kedacore/http-add-on/issues/1061))
### New
- **General**: Support portName in HTTPScaledObject service scaleTargetRef ([#1174](https://github.com/kedacore/http-add-on/issues/1174))
- **General**: Support setting multiple TLS certs for different domains on the interceptor proxy ([#1116](https://github.com/kedacore/http-add-on/issues/1116))
- **Interceptor**: Add support for for AWS ELB healthcheck probe ([#1198](https://github.com/kedacore/http-add-on/issues/1198))
### Fixes
- **General**: Align the interceptor metrics env var configuration with the OTEL spec ([#1031](https://github.com/kedacore/http-add-on/issues/1031))
- **General**: Include trailing 0 window buckets in RPS calculation ([#1075](https://github.com/kedacore/http-add-on/issues/1075))
### Other
- **General**: Sign images with Cosign ([#1062](https://github.com/kedacore/http-add-on/issues/1062))
## v0.8.0
### New
- **General**: Add configurable TLS on the wire support to the interceptor proxy ([#907](https://github.com/kedacore/http-add-on/issues/907))
- **General**: Add support for collecting metrics using a Prometheus compatible endpoint or by sending metrics to an OpenTelemetry's HTTP endpoint ([#910](https://github.com/kedacore/http-add-on/issues/910))
- **General**: Propagate HTTPScaledObject labels and annotations to ScaledObject ([#840](https://github.com/kedacore/http-add-on/issues/840))
- **General**: Provide support for allowing HTTP scaler to work alongside other core KEDA scalers ([#489](https://github.com/kedacore/http-add-on/issues/489))
- **General**: Support aggregation windows ([#882](https://github.com/kedacore/http-add-on/issues/882))
### Fixes
- **General**: Ensure operator is aware about changes on underlying ScaledObject ([#900](https://github.com/kedacore/http-add-on/issues/900))
### Deprecations
You can find all deprecations in [this overview](https://github.com/kedacore/http-add-on/labels/breaking-change) and [join the discussion here](https://github.com/kedacore/http-add-on/discussions/categories/deprecations).
- **General**: Deprecated `targetPendingRequests` in favor of `spec.scalingMetric.*.targetValue` ([#959](https://github.com/kedacore/http-add-on/discussions/959))
### Other
- **General**: Align with the new format of Ingress in the example demo ([#979](https://github.com/kedacore/http-add-on/pull/979))
- **General**: `host` field has been removed in favor of `hosts` in `HTTPScaledObject` ([#552](https://github.com/kedacore/http-add-on/issues/552)|[#888](https://github.com/kedacore/http-add-on/pull/888))
### New
- **General**: Support any resource which implements `/scale` subresource ([#438](https://github.com/kedacore/http-add-on/issues/438))
- **General**: Add new user agent probe ([#862](https://github.com/kedacore/http-add-on/issues/862))
- **General**: Fix external scaler getting into bad state when retrieving queue lengths fails. ([#870](https://github.com/kedacore/http-add-on/issues/870))
- **General**: Increase ScaledObject polling interval to 15 seconds ([#799](https://github.com/kedacore/http-add-on/issues/799))
- **General**: Set forward request RawPath to original request RawPath ([#864](https://github.com/kedacore/http-add-on/issues/864))
### Deprecations
You can find all deprecations in [this overview](https://github.com/kedacore/http-add-on/labels/breaking-change) and [join the discussion here](https://github.com/kedacore/http-add-on/discussions/categories/deprecations).
New deprecation(s):
- **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))
### Other
- **General**: Bump golang version ([#853](https://github.com/kedacore/http-add-on/pull/853))
## v0.6.0
### New
- **General**: Add manifests to deploy the Add-on ([#716](https://github.com/kedacore/http-add-on/issues/716))
You can find all deprecations in [this overview](https://github.com/kedacore/http-add-on/labels/breaking-change) and [join the discussion here](https://github.com/kedacore/http-add-on/discussions/categories/deprecations).
New deprecation(s):
- **General**: `host` field deprecated in favor of `hosts` in `HTTPScaledObject` ([#552](https://github.com/kedacore/http-add-on/issues/552))
### Other
- **General**: Adding a changelog validating script to check for formatting and order ([#761](https://github.com/kedacore/http-add-on/pull/761))
- **General**: Skip not required CI checks on PRs on new commits ([#801](https://github.com/kedacore/http-add-on/pull/801))
## v0.5.0
### Breaking Changes
None.
### New
- **General**: Log incoming requests using the Combined Log Format ([#669](https://github.com/kedacore/http-add-on/pull/669))
- **Routing**: Add multi-host support to `HTTPScaledObject` ([#552](https://github.com/kedacore/http-add-on/issues/552))
- **Routing**: Support path-based routing ([#338](https://github.com/kedacore/http-add-on/issues/338))
### Improvements
- **General**: Automatically tag Docker image with commit SHA ([#567](https://github.com/kedacore/http-add-on/issues/567))
- **Operator**: Migrate project to Kubebuilder v3 ([#625](https://github.com/kedacore/http-add-on/issues/625))
- **RBAC**: Introduce fine-grained permissions per component and reduce required permissions ([#612](https://github.com/kedacore/http-add-on/issues/612))
- **Routing**: New routing table implementation that relies on the live state of HTTPScaledObjects on the K8s Cluster instead of a ConfigMap that is updated periodically ([#605](https://github.com/kedacore/http-add-on/issues/605))
### Fixes
- **General**: Changes to HTTPScaledObjects now take effect ([#605](https://github.com/kedacore/http-add-on/issues/605))
- **General**: HTTPScaledObject is the owner of the underlying ScaledObject ([#703](https://github.com/kedacore/http-add-on/issues/703))
- **Controller**: Use kedav1alpha1.ScaledObject default values ([#607](https://github.com/kedacore/http-add-on/issues/607))
- **Routing**: Lookup host without port ([#608](https://github.com/kedacore/http-add-on/issues/608))
### Deprecations
You can find all deprecations in [this overview](https://github.com/kedacore/http-add-on/labels/breaking-change) and [join the discussion here](https://github.com/kedacore/http-add-on/discussions/categories/deprecations).
New deprecation(s):
- **General**: `host` field deprecated in favor of `hosts` in `HTTPScaledObject` ([#552](https://github.com/kedacore/http-add-on/issues/552))
Previously announced deprecation(s):
- None.
### Other
- **General**: Use kubernetes e2e images for e2e test and samples ([#665](https://github.com/kedacore/http-add-on/issues/665))
- **e2e tests**: Use the same e2e system as in core ([#686](https://github.com/kedacore/http-add-on/pull/686))
- [Locally Build & Deploy KEDA HTTP Addon](#locally-build--deploy-keda-http-addon)
- [Pre-requisite:](#pre-requisite)
- [Building:](#building)
- [Deploying:](#deploying)
- [Load testing with k9s:](#load-testing-with-k9s)
- [Developer Certificate of Origin: Signing your work](#developer-certificate-of-origin-signing-your-work)
- [Every commit needs to be signed](#every-commit-needs-to-be-signed)
- [I didn't sign my commit, now what?!](#i-didnt-sign-my-commit-now-what)
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
## Project governance
You can learn about the governance of KEDA [here](https://github.com/kedacore/governance).
## Including Documentation Changes
For any contribution you make that impacts the behavior or experience of the KEDA HTTP Add-on, please make sure you include updates to the documentation in the same pull request, and if appropriate, changes to [the KEDA main documentation repository](https://github.com/kedacore/keda-docs). Contributions that do not include documentation or samples will be rejected.
## Development Environment Setup
We have a comprehensive how-to document that details the setup and configuration of the development environment for this project.
Please find it at [docs/developing.md](./docs/developing.md).
## Locally Build & Deploy KEDA HTTP Addon
### Pre-requisite:
- A running Kubernetes cluster with KEDA installed.
$ make docker-build # build docker images of the components
```
### Deploying:
Custom HTTP Add-on as an image
- Make your changes in the code
- Build and publish images with your changes, remembering to update the information for registry of your choice:
```bash
IMAGE_REGISTRY=docker.io IMAGE_REPO=johndoe make docker-publish
```
> Note: If you need to build images to other architecture from your machine, you can use multi-arch building with `IMAGE_REGISTRY=docker.io IMAGE_REPO=johndo make publish-multiarch`.
There are local clusters with local registries provided, in such cases make sure to use and push your images to its local registry. In the case of MicroK8s, the address is `localhost:32000` and the command would look like the following.
```bash
IMAGE_REGISTRY=localhost:32000 IMAGE_REPO=johndo make deploy
```
### Load testing with k9s:
K9s integrates Hey, a CLI tool to benchmark HTTP endpoints similar to AB bench. This preliminary feature currently supports benchmarking port-forwards and services. You can use this feature in load testing as follows:
- Install an application to scale, we use the provided sample -
- 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. We use the provided sample HTTPScaledObject -
(c) HTTP traffic needs to route through the Service that the add on has set up. Find interceptor proxy service i.e. ‘keda-add-ons-http-interceptor-proxy’ and port forward it using <SHIFT+F>
(d) Search for the same port-forward in the list you get by command - “:pf”
(e) Enter the port-forward and apply <CTRL+L> to start a benchmark
(f) You can enter the port-forward to see the run stat details and performance.
```
>You can customize the benchmark in k9s also. It's explained well in [here](https://k9scli.io/topics/bench/).
## Developer Certificate of Origin: Signing your work
### Every commit needs to be signed
The Developer Certificate of Origin (DCO) is a lightweight way for contributors to certify that they wrote or otherwise have the right to submit the code they are contributing to the project. Here is the full text of the DCO, reformatted for readability:
```
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or
(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.
(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.
```
Contributors sign-off that they adhere to these requirements by adding a `Signed-off-by` line to commit messages.
```
This is my commit message
Signed-off-by: Random J Developer <random@developer.example.org>
```
Git even has a `-s` command line option to append this automatically to your commit message:
```console
$ git commit -s -m 'This is my commit message'
```
Each Pull Request is checked whether or not commits in a Pull Request do contain a valid Signed-off-by line.
### I didn't sign my commit, now what?!
No worries - You can easily replay your changes, sign them and force push them!
The KEDA HTTP Add On allows Kubernetes users to automatically scale their HTTP servers up and down (including to/from zero) based on incoming HTTP traffic. Please see our [use cases document](./docs/use_cases.md) to learn more about how and why you would use this project.
The KEDA HTTP Add-on allows Kubernetes users to automatically scale their HTTP servers up and down (including to/from zero) based on incoming HTTP traffic. Please see our [use cases document](./docs/use_cases.md) to learn more about how and why you would use this project.
| 🚧 **Project status: beta** 🚧|
|---------------------------------------------|
| ⚠ The HTTP add-on currently is in [beta](https://github.com/kedacore/http-add-on/releases/tag/0.1.0). We can't yet recommend it for production usage because we are still developing and testing it. It may have "rough edges" including missing documentation, bugs and other issues. It is currently provided as-is without support.
| :loudspeaker: **KEDA is actively relying on community contributions to help grow & maintain the add-on. The KEDA maintainers are assisting the community to evolve the add-on but not directly responsible for it.** Feel free to [open a new discussion](https://github.com/kedacore/http-add-on/discussions/new/choose) in case of questions.<br/><br/>⚠ The HTTP Add-on currently is in [beta](https://github.com/kedacore/http-add-on/releases/latest). We can't yet recommend it for production usage because we are still developing and testing it. It may have "rough edges" including missing documentation, bugs and other issues. It is currently provided as-is without support.<br/><br/>:bulb: For production-ready needs, you can consider using the [Kedify HTTP Scaler](https://kedify.io/scalers/http), a commercial alternative offering robust and reliable scaling for KEDA. |
## HTTP Autoscaling Made Simple
[KEDA](https://github.com/kedacore/keda) provides a reliable and well tested solution to scaling your workloads based on external events. The project supports a wide variety of [scalers](https://keda.sh/docs/2.2/scalers/) - sources of these events, in other words. These scalers are systems that produce precisely measurable events via an API.
[KEDA](https://github.com/kedacore/keda) provides a reliable and well tested solution to scaling your workloads based on external events. The project supports a wide variety of [scalers](https://keda.sh/docs/latest/scalers/) - sources of these events, in other words. These scalers are systems that produce precisely measurable events via an API.
KEDA does not, however, include an HTTP-based scaler out of the box for several reasons:
@ -23,15 +38,21 @@ For these reasons, the KEDA core project has purposely not built generic HTTP-ba
This project, often called KEDA-HTTP, exists to provide that scaling. It is composed of simple, isolated components and includes an opinionated way to put them together.
## Adopters - Become a listed KEDA user!
We are always happy to start list users who run KEDA's HTTP Add-on in production or are evaluating it, learn more about it [here](ADOPTERS.md).
We welcome pull requests to list new adopters.
## Walkthrough
Although this is currently a **beta release** project, we have prepared a walkthrough document that with instructions on getting started for basic usage.
Although this is currently a **beta release** project, we have prepared a walkthrough document with instructions on getting started for basic usage.
See that document at [docs/walkthrough.md](./docs/walkthrough.md)
## Design
The HTTP add-on is composed of multiple mostly independent components. This design was chosen to allow for highly
The HTTP Add-on is composed of multiple mostly independent components. This design was chosen to allow for highly
customizable installations while allowing us to ship reasonable defaults.
- We have written a complete design document. Please see it at [docs/design.md](./docs/design.md).
@ -42,6 +63,11 @@ customizable installations while allowing us to ship reasonable defaults.
Please see the [complete installation instructions](./docs/install.md).
## Roadmap
We use GitHub issues to build our backlog, a complete overview of all open items and our planning.
Learn more about our [roadmap](ROADMAP.md).
## Contributing
This project follows the KEDA contributing guidelines, which are outlined in [CONTRIBUTING.md](https://github.com/kedacore/.github/blob/main/CONTRIBUTING.md).
@ -49,7 +75,7 @@ This project follows the KEDA contributing guidelines, which are outlined in [CO
If you would like to contribute code to this project, please see [docs/developing.md](./docs/developing.md).
---
We are a Cloud Native Computing Foundation (CNCF) sandbox project.
We are a Cloud Native Computing Foundation (CNCF) graduated project.
The process of releasing a new version of the KEDA HTTP Add-on involves a few steps, detailed below.
>The process herein is largely automated but we recognize that there may be more that we can automate. If you find something that _can_ and _should_ be automated, and you believe that you know how, please [submit an issue](https://github.com/kedacore/http-add-on/issues/new?assignees=&labels=needs-discussion%2Cfeature-request&template=Feature_request.md) explaining how.
## 1: Current and new versions
Please go to the [releases page](https://github.com/kedacore/http-add-on/releases) and observe what the most recent release is. Specifically, note what the _tag_ of the release is. For example, if [version 0.3.0](https://github.com/kedacore/http-add-on/releases/tag/v0.3.0) is the latest release (it is as the time of this writing), the tag for that is `v0.3.0`.
To determine the new version, follow [SemVer guidelines](https://semver.org). Most releases will increment the PATCH or MINOR version number.
## 2. Changelog
Add a new section in [CHANGELOG.md](CHANGELOG.md) for the new version that is being released along with the new features, patches and deprecations it introduces.
It should not include every single change but solely what matters to our customers, for example issue template that has changed is not important.
## 3. Add the new version to GitHub Bug report template
Add the new released version to the list in `KEDA Version` dropdown in [2_bug_report.yml](https://github.com/kedacore/http-add-on/blob/main/.github/ISSUE_TEMPLATE/2_bug_report.yml).
## 4. Update documentation references to current version
Update the links to current version within the file `walkthrough.md`
> >If you'd like to learn more about this object, please see the [`HTTPScaledObject` reference](THE REFERENCE).
## 5: Create a new GitHub release
[Create a new release](https://github.com/kedacore/http-add-on/releases/new) on the GitHub releases page, using your new release number.
The title of the release should be "Version 1.2.3", substituting `1.2.3` with the new version number, and the Git tag should be `v1.2.3`, again substituting `1.2.3` with your new version number.
The release description should be a short to medium length summary of what has changed since the last release. The following link will give you a list of commits made since the `v0.3.0` tag: [github.com/kedacore/http-add-on/compare/v0.3.0...main](https://github.com/kedacore/http-add-on/compare/v0.3.0...main). Replace `v0.3.0` for your appropriate most recent last tag to get the commit list and base your release summary on that list.
After you create the new release, automation in a GitHub action will build and deploy new container images.
## 6: Submit a PR to the [Helm Charts Repository](https://github.com/kedacore/charts)
The scope of the changes you'll need to make to the Helm chart vary, but the below list is the minimum set of fields to change:
- The `appVersion` field in `Chart.yaml`. If you've chosen `1.2.3` as the version number, this field should read:
```yaml
appVersion: 1.2.3
```
- The `images.tag` field in `values.yaml`. If you've chosen `1.2.3` as the version number, this field should read:
```yaml
images:
# tag is the image tag to use for all images.
# for example, if the operator image is "myoperator" and
# tag is "mytag", the operator image used will be
# "myoperator:mytag". `latest` is used to indicate the latest
# stable release in the official images, `canary` is
# the build for the latest commit to the `main` branch,
# and you can target any other commit with `sha-<GIT_SHA[0:7]>`
tag: 1.2.3
```
>Note: The container images generated by CI/CD in step 2 will have the same tag as the tag you created in the release, minus the `v` prefix. You can always see what images created by going to the container registry page for the [interceptor](https://github.com/kedacore/http-add-on/pkgs/container/http-add-on-interceptor), [operator](https://github.com/kedacore/http-add-on/pkgs/container/http-add-on-operator) or [scaler](https://github.com/kedacore/http-add-on/pkgs/container/http-add-on-scaler)
Once you've made changes to the chart, here's how to do submit the change to the charts repository:
- Submit a Pull Request (PR) to the [github.com/kedacore/charts](https://github.com/kedacore/charts) repository with your changes. Also ensure that you follow the [Shipping a new version](https://github.com/kedacore/charts/blob/master/CONTRIBUTING.md#shipping-a-new-version) guidelines in the charts documentation to complete the chart release.
- Your chart changes must go into the [http-add-on](https://github.com/kedacore/charts/tree/master/http-add-on) directory. The release artifact will go into the [docs](https://github.com/kedacore/charts/tree/master/docs) directory.
- Ensure that you add a link to the HTTP Add-on repository and the new release number, so that PR reviewers are aware what the work relates to
- Work with the maintainers of that repository to get the chart merged
After your PR is merged, you've completed the release. Congratulations! You can optionally write a blog post about it; see the next section if you're interested.
## 7: Publish release on Artifact Hub
Publish release on Artifact Hub by creating a new version in [kedacore/external-scalers](https://github.com/kedacore/external-scalers/tree/main/artifacthub/add-ons-http).
## 8: Write a blog post on the documentation site (_optional_)
If you believe that your release is large enough to warrant a blog post on the [keda.sh/blog](https://keda.sh/blog/) site, please go to [github.com/kedacore/keda-docs](https://github.com/kedacore/keda-docs) and submit a new PR with a blog article about the release.
Include in the article a longer summary of changes and any important information about the new functionality, bugfixes, or anything else appropriate. The post should go into the [content/blog](https://github.com/kedacore/keda-docs/tree/master/content/blog) directory.
KEDA uses [GitHub issues](https://docs.github.com/en/issues/tracking-your-work-with-issues/about-issues) to track open work items with [GitHub Projects (beta)](https://docs.github.com/en/issues/trying-out-the-new-projects-experience/about-projects) to plan for upcoming releases.
This document provides insights to the community on how we use it and what to expect.
You can find our roadmap [here](https://github.com/orgs/kedacore/projects/6/views/1).
## Using our roadmap
Here is some guidance on how to use our roadmap.
### Upcoming Release
As we work towards our next release, we are planning and tracking work as part of the next release cycle.
You can find an overview of the items in our upcoming release:
- As list with the respective categories ([link](https://github.com/orgs/kedacore/projects/6/views/5))
- As list with the respective priorities ([link](https://github.com/orgs/kedacore/projects/6/views/2))
- As a board with the current status ([link](https://github.com/orgs/kedacore/projects/6/views/4))
### Triaging
All newly created issues are automatically added to the roadmap and waiting to be triaged by a maintainer.
You can find an overview of all issues pending to be triaged [here](https://github.com/orgs/kedacore/projects/6/views/6).
This project is primarily a composition of mostly independent components. We've chosen this design so that you can swap out components as you want/need to while still achieving (roughly) the same functionality.
@ -8,7 +8,7 @@ There are three major components in this system. You can find more detail and di
- [Operator](../operator) - This component listens for events related to `HTTPScaledObject`s and creates, updates or removes internal machinery as appropriate.
- [Interceptor](../interceptor) - This component accepts and routes external HTTP traffic to the appropriate internal application, as appropriate.
- [Scaler](../scaler) - This component tracks the size of the pending HTTP request queue for a given app and reports it to KEDA. It acts as an [external scaler](https://keda.sh/docs/2.1/scalers/external-push/).
- [Scaler](../scaler) - This component tracks the size of the pending HTTP request queue for a given app and reports it to KEDA. It acts as an [external scaler](https://keda.sh/docs/latest/scalers/external-push/).
- [KEDA](https://keda.sh) - KEDA acts as the scaler for the user's HTTP application.
## Functionality Areas
@ -19,18 +19,32 @@ We've split this project into a few different major areas of functionality, whic
We've introduced a new [Custom Resource (CRD)](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) called `HTTPScaledObject.http.keda.sh` - `HTTPScaledObject` for short. Fundamentally, this resource allows an application developer to submit their HTTP-based application name and container image to the system, and have the system deploy all the necessary internal machinery required to deploy their HTTP application and expose it to the public internet.
The [operator](../operator) runs inside the Kubernetes namespace to which they're deploying their application and watches for these `HTTPScaledObject` resources. When one is created, it will create a `Deployment` and `Service` for the app, interceptor, and scaler, and a [`ScaledObject`](https://keda.sh/docs/2.1/concepts/scaling-deployments/) which KEDA then uses to scale the application.
The [operator](../operator) runs inside the Kubernetes namespace to which they're deploying their application and watches for these `HTTPScaledObject` resources. When one is created, it does the following:
When the `HTTPScaledObject` is deleted, the operator then removes all of the aforementioned resources.
- 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/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.
### Autoscaling for HTTP Apps
After an `HTTPScaledObject` is created and the operator creates the appropriate resources, there is a public IP address (and DNS entry, if configured) and the interceptor takes over. When HTTP traffic enters the system from the public internet, the interceptor accepts it and forwards it to the app's `Service` IP (it is most commonly configured as a `ClusterIP` service).
After an `HTTPScaledObject` is created and the operator creates the appropriate resources, you must send HTTP requests through the interceptor so that the application is scaled. A Kubernetes `Service` called `keda-add-ons-http-interceptor-proxy` was created when you `helm install`ed the add-on. Send requests to that service.
At the same time, the interceptor keeps track of the size of the pending HTTP requests - HTTP requests that it has forwarded but the app hasn't returned. The scaler periodically makes HTTP requests to the interceptor via an internal HTTP endpoint - on a separate port from the public server - to get the size of the pending queue. Based on this queue size, it reports scaling metrics as appropriate to KEDA. As the queue size increases, the scaler instructs KEDA to scale up as appropriate. Similarly, as the queue size decreases, the scaler instructs KEDA to scale down.
The interceptor keeps track of the number of pending HTTP requests - HTTP requests that it has forwarded but the app hasn't returned. The scaler periodically makes HTTP requests to the interceptor via an internal RPC endpoint - on a separate port from the public server - to get the size of the pending queue. Based on this queue size, it reports scaling metrics as appropriate to KEDA. As the queue size increases, the scaler instructs KEDA to scale up as appropriate. Similarly, as the queue size decreases, the scaler instructs KEDA to scale down.
#### The Horizontal Pod Autoscaler
The HTTP Add-on works with the Kubernetes [Horizonal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details) (HPA) -- via KEDA itself -- to execute scale-up and scale-down operations (except for scaling between zero and non-zero replicas). The add-on furnishes KEDA with two metrics - the current number of pending requests for a host, and the desired number (called `targetPendingRequests` in the [HTTPScaledObject](./ref/v0.3.0/http_scaled_object.md)). KEDA then sends these metrics to the HPA, which uses them as the `currentMetricValue` and `desiredMetricValue`, respectively, in the [HPA Algorithm](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details).
The net effect is that the add-on scales up when your app grows to more pending requests than the `targetPendingRequests` value, and scales down when it has fewer than that value.
>The aforementioned HPA algorithm is pasted here for convenience: `desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]`. The value of `targetPendingRequests` will be passed in where `desiredMetricValue` is expected, and the point-in-time metric for number of pending requests will be passed in where `currentMetricValue` is expected.
## Architecture Overview
Although the HTTP add on is very configurable and supports multiple different deployments, the below diagram is the most common architecture that is shipped by default.
Although the HTTP Add-on is very configurable and supports multiple different deployments, the below diagram is the most common architecture that is shipped by default.
@ -9,6 +9,7 @@ to have the following tools installed:
- [Golang](http://golang.org/) for development
- [Docker](https://docker.com) for building the images and testing it locally
- [Pre-commit](https://pre-commit.com/) for static checks (_optional_)
## Prerequisites
@ -34,42 +35,160 @@ the service, you can host your own with a series of amazing tools like:
Follow the [install instructions](./install.md) to check out how to install and get this add-on up and running.
## Build scripts
This project uses [Mage](https://magefile.org) as opposed to Make because it's way faster to build and push images, as well as to run tests and other common tasks. Please install [version v1.11.0](https://github.com/magefile/mage/releases/tag/v1.11.0) or above to have access to the task runner.
### In the Root Directory
The Magefile located in the root directory has targets useful for the whole project. There is another magefile [in the operator directory](../operator/magefile.go), which has targets more specific to the operator module.
The Makefile located in the root directory has targets useful for the whole project.
The most useful and common commands from the root directory are listed below. Please see the "In the Operator Directory" section for the operator-specific targets. Whther you're in the root or the operator directory, you can always run the following general helper commands:
> All commands are case sensitive.
- `mage -l`: shows a list of all available commands
> All commands are case insensitive, so `buildAll` and `buildall` are the same.
- `mage build`: Builds all the binaries for local testing.
- `mage test`: Tests the entire codebase
- `mage dockerbuild`: Builds all docker images
- Please see the below "Environment Variables" section for more information on this command
- `mage dockerpush`: Pushes all docker images, without building them first
- Please see the below "Environment Variables" section for more information on this command
### In the Operator Directory
- `mage Manifests`: Builds all the manifest files for Kubernetes, it's important to build after every change
to a Kustomize annotation.
- `mage All`: Generates the operator.
- `make build`: Builds all the binaries for local testing
- `make test`: Run all unit tests
- `make e2e-test`: Run all e2e tests
- `make docker-build`: Builds all docker images
- `make docker-publish`: Build and push all Docker images
- `make publish-multiarch`: Build and push all Docker images for `linux/arm64` and `linux/amd64`
- `make manifests`: Generate all the manifest files for Kubernetes, it's important to build after every change
- `make deploy`: Deploys the HTTP Add-on to the cluster selected in `~/.kube/config` using `config` folder manifests
- `make pre-commit`: Execute static checks
### Required Environment Variables
Some of the above commands require several environment variables to be set. You should set them once in your environment to ensure that you can run these targets. We recommend using [direnv](https://direnv.net) to set these environment variables once, so that you don't need to remember to do it.
Some of the above commands support changes in the default values:
- `KEDAHTTP_SCALER_IMAGE`: the fully qualified name of the [scaler](../scaler) image. This is used to build, push, and install the scaler into a Kubernetes cluster (required)
- `KEDAHTTP_INTERCEPTOR_IMAGE`: the fully qualified name of the [interceptor](../interceptor) image. This is used to build, push, and install the interceptor into a Kubernetes cluster (required)
- `KEDAHTTP_OPERATOR_IMAGE`: the fully qualified name of the [operator](../operator) image. This is used to build, push, and install the operator into a Kubernetes cluster (required)
- `KEDAHTTP_NAMESPACE`: the Kubernetes namespace to which to install the add on and other required components (optional, defaults to `kedahttp`)
- `IMAGE_REGISTRY`: Image registry to be used for docker images
- `IMAGE_REPO`: Repository to be used for docker images
- `VERSION`: Tag to be used for docker images
- `BUILD_PLATFORMS`: Built platform targeted for multi-arch docker images
>Suffic any `*_IMAGE` variable with `<keda-git-sha>` and the build system will automatically replace it with `sha-$(git rev-parse --short HEAD)`
## Debugging and Observing Components
The below tips assist with debugging, introspecting, or observing the current state of a running HTTP add-on installation. They involve making network requests to cluster-internal (i.e. `ClusterIP``Service`s).
There are generally two ways to communicate with these services. In the following sections, we'll assume you are using the `kubectl proxy` method, but the most instructions will be simple enough to adapt to other methods.
We'll also assume that you have set the `$NAMESPACE` environment variable in your environment to the namespace in which the HTTP add-on is installed.
### Use `kubectl proxy`
`kubectl proxy` establishes an authenticated connection to the Kubernetes API server, runs a local web server, and lets you execute REST API requests against `localhost` as if you were executing them against the Kubernetes API server.
To establish one, run the following command in a separate terminal window:
```console
kubectl proxy -p 9898
```
>You'll keep this proxy running throughout all of your testing, so make sure you keep this terminal window open.
### Use a dedicated running pod
The second way to communicate with these services is almost the opposite as the previous. Instead of bringing the API server to you with `kubectl proxy`, you'll be creating an execution environment closer to the API server.
First, launch a container with an interactive console in Kubernetes with the following command (substituting your namespace in for `$NAMESPACE`):
```console
kubectl run -it alpine --image=alpine -n $NAMESPACE
```
Then, when you see a `curl` command below, replace the entire path up to and including the `/proxy/` segment with just the name of the service and its port. For example, `curl -L localhost:9898/api/v1/namespaces/$NAMESPACE/services/keda-add-ons-http-interceptor-admin:9090/proxy/routing_ping` would just become `curl -L keda-add-ons-http-interceptor-admin:9090/routing_ping`
### Interceptor
Any interceptor pod has both a _proxy_ and _admin_ server running inside it. The proxy server is where users send HTTP requests to, and the admin server is for internal use. The admin server runs on a separate port, fronted by a separate `Service`.
The admin server also performs following tasks:
1. Prompt the interceptor to re-fetch the routing table, or
2. Print out the interceptor's current routing table (useful for debugging)
#### Configuration
Run the following `curl` command to get the running configuration of the interceptor:
The output of this command is a JSON map where the keys are the deployment name and the values are the latest known number of replicas for that deployment.
### Operator
Like the interceptor, the operator has an admin server that has HTTP endpoints against which you can run `curl` commands.
#### Configuration
Run the following `curl` command to get the running configuration of the operator:
The operator has a similar `/routing_table` endpoint as the interceptor. That data returned from this endpoint, however, is the source of truth. Interceptors fetch their copies of the routing table from this endpoint. Accessing data from this endpoint is similar.
Fetch the operator's routing table with the following command:
The external scaler fetches pending queue counts from each interceptor in the system, aggregates and stores them, and then returns them to KEDA when requested. KEDA fetches these data via the [standard gRPC external scaler interface](https://keda.sh/docs/2.3/concepts/external-scalers/#external-scaler-grpc-interface).
For convenience, the scaler also provides a plain HTTP server from which you can also fetch these metrics. Fetch the queue counts from this HTTP server with the following command:
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)?
## How is this project similar or different from [Osiris](https://github.com/deislabs/osiris)?
Osiris and KEDA-HTTP have similar features:
@ -13,28 +13,30 @@ 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
- Osiris is currently archived in GitHub.
## How is this Project Similar or Different from [KNative](https://knative.dev/)?
## How is this project similar or different from [Knative](https://knative.dev/)?
KNative serving and KEDA-HTTP both have core support for autoscaling, including scale-to-zero of compute workloads. KEDA-HTTP is focused solely on deploying production-grade autoscaling HTTP applications, while KNative builds in additional functionality:
Knative Serving and KEDA-HTTP both have core support for autoscaling, including scale-to-zero of compute workloads. KEDA-HTTP is focused solely on deploying production-grade autoscaling HTTP applications, while Knative builds in additional functionality:
- Pure [event-based workloads](https://knative.dev/docs/eventing/). [KEDA core](https://github.com/kedacore/keda), without KEDA-HTTP, can support such workloads natively.
- Complex deployment strategies like [blue-green](https://knative.dev/docs/serving/samples/blue-green-deployment/)
- Supporting other autoscaling mechanisms beyond the built-in [HPA](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/), such as the [KNative Pod Autoscaler (KPA)](https://knative.dev/docs/serving/autoscaling/autoscaling-concepts/#knative-pod-autoscaler-kpa)
- Complex deployment strategies like [blue-green](https://knative.dev/docs/serving/samples/blue-green-deployment/).
- Supporting other autoscaling mechanisms beyond the built-in [HPA](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/), such as the [Knative Pod Autoscaler (KPA)](https://knative.dev/docs/serving/autoscaling/autoscaling-concepts/#knative-pod-autoscaler-kpa).
Additionally, KNative supports a service mesh, while KEDA-HTTP does not out of the box (support for that is forthcoming).
Additionally, Knative supports a service mesh, while KEDA-HTTP does not out of the box (support for that is forthcoming).
## How is this Project Similar or Different from [OpenFaaS](https://www.openfaas.com/)
## How is this project similar or different from [OpenFaaS](https://www.openfaas.com/)
OpenFaaS and KEDA-HTTP both can deploy and autoscale HTTP workloads onto Kubernetes, but they have several important differences that make them suitable for different use cases:
- OpenFaaS requires the use of a CLI to deploy code to production
- OpenFaaS requires the use of a CLI to deploy code to production.
- OpenFaaS primarily supports the event-based "functions as a service" pattern. This means:
- You deploy code, in a supported language, to handle an HTTP request and OpenFaaS takes care of serving and invoking your code for you
- You deploy complete containers with your HTTP server process in them to KEDA-HTTP
- You don't need to build a container image to deploy code to OpenFaaS, while you do to deploy to KEDA-HTTP
- OpenFaaS can run either on or off Kubernetes, while KEDA-HTTP is Kubernetes-only
- OpenFaaS requires several additional components when running in Kubernetes, like Prometheus. The documentation refers to this as the [PLONK stack](https://docs.openfaas.com/deployment/#plonk-stack)
- You deploy code, in a supported language, to handle an HTTP request and OpenFaaS takes care of serving and invoking your code for you.
- You deploy complete containers with your HTTP server process in them to KEDA-HTTP.
- You don't need to build a container image to deploy code to OpenFaaS, while you do to deploy to KEDA-HTTP.
- OpenFaaS can run either on or off Kubernetes, while KEDA-HTTP is Kubernetes-only.
- OpenFaaS requires several additional components when running in Kubernetes, like Prometheus. The documentation refers to this as the [PLONK stack](https://docs.openfaas.com/deployment/#plonk-stack).
The HTTP Add On is highly modular and, as expected, builds on top of KEDA core. Below are some additional components:
The HTTP Add-on is highly modular and, as expected, builds on top of KEDA core. Below are some additional components:
- **Operator** - watches for `ScaledHTTPObject` CRD resources and creates necessary backing Kubernetes resources (e.g. `Deployment`s, `Service`s, `ScaledObject`s, and so forth)
- **Operator** - watches for `HTTPScaledObject` CRD resources and creates necessary backing Kubernetes resources (e.g. `Deployment`s, `Service`s, `ScaledObject`s, and so forth)
- **Scaler** - communicates scaling-related metrics to KEDA. By default, the operator will install this for you as necessary.
- **Interceptor** - a cluster-internal proxy that proxies incoming HTTP requests, communicating HTTP queue size metrics to the scaler, and holding requests in a temporary request queue when there are not yet any available app `Pod`s ready to serve. By default, the operator will install this for you as necessary.
>There is [pending work](https://github.com/kedacore/http-add-on/issues/354) that may eventually make this component optional.
>There is [pending work in KEDA](https://github.com/kedacore/keda/issues/615) that will eventually make this component optional. See [issue #6 in this repository](https://github.com/kedacore/http-add-on/issues/6) for even more background
## Before You Start: Cluster-global vs. Namespaced Installation
Both KEDA and the HTTP Add-on can be installed in either cluster-global or namespaced mode. In the former case, your `ScaledObject`s and `HTTPScaledObject`s (respectively) can be installed in any namespace, and one installation will detect and process it. In the latter case, you must install your `ScaledObject`s and `HTTPScaledObject`s in a specific namespace.
You have the option of installing KEDA and the HTTP Add-on in either mode, but if you install one as cluster-global, the other must also be cluster-global. Similarly, if you install one as namespaced, the also must also be namespaced in the same namespace.
## Installing KEDA
Before you install any of these components, you need to install KEDA. Below are simplified instructions for doing so with [Helm](https://helm.sh), but if you need anything more customized, please see the [official KEDA deployment documentation](https://keda.sh/docs/2.0/deploy/). If you need to install Helm, refer to the [installation guide](https://helm.sh/docs/intro/install/).
>This document will rely on environment variables such as `${NAMESPACE}` to indicate a value you should customize and provide to the relevant command. In the above `helm install` command, `${NAMESPACE}` should be the namespace you'd like to install KEDA into. KEDA and the HTTP Addon provide scaling functionality to only one namespace per installation.
>This document will rely on environment variables such as `${NAMESPACE}` to indicate a value you should customize and provide to the relevant command. In the below`helm install` command, `${NAMESPACE}` should be the namespace you'd like to install KEDA into.
helm install keda kedacore/keda --namespace ${NAMESPACE} --set watchNamespace=${NAMESPACE}
helm install keda kedacore/keda --namespace ${NAMESPACE} --create-namespace
```
## Install via Helm Chart
>The above command installs KEDA in cluster-global mode. Add `--set watchNamespace=<target namespace>` to install KEDA in namespaced mode.
This repository is within KEDA's default helm repository on [kedacore/charts](http://github.com/kedacore/charts), you can install it by running:
## Install the Add-on via Helm Chart
The Helm chart for this project is within KEDA's default helm repository at [kedacore/charts](http://github.com/kedacore/charts), you can install it by running:
>The above command installed the HTTP Add-on in cluster-global mode. Add `--set operator.watchNamespace=<target namespace>` to install the HTTP Add-on in namepaced mode. If you do this, you must also install KEDA in namespaced mode and use the same target namespace.
>Installing the HTTP add on won't affect any running workloads in your cluster. You'll need to install an `HTTPScaledObject` for each individual `Deployment` you want to scale. For more on how to do that, please see the [walkthrough](./walkthrough.md).
>Installing the HTTP Add-on won't affect any running workloads in your cluster. You'll need to install an `HTTPScaledObject` for each individual `Deployment` you want to scale. For more on how to do that, please see the [walkthrough](./walkthrough.md).
### Customizing the Installation
There are a few values that you can pass to the above `helm install` command by including `--set NAME=VALUE` on the command line.
- `images.operator` - the name of the operator's Docker image, not including the tag. Defaults to [`ghcr.io/kedacore/http-add-on-operator`](https://github.com/orgs/kedacore/packages/container/package/http-add-on-operator).
- `images.scaler` - the name of the scaler's Docker image, not including the tag. Defaults to [`ghcr.io/kedacore/http-add-on-scaler`](https://github.com/orgs/kedacore/packages/container/package/http-add-on-scaler).
- `images.interceptor` - the name of the interceptor's Docker image, not including the tag. Defaults to [`ghcr.io/kedacore/http-add-on-interceptor`](https://github.com/orgs/kedacore/packages/container/package/http-add-on-interceptor).
- `images.operator` - the name of the operator's Docker image, not including the tag. Defaults to [`ghcr.io/kedacore/http-add-on-operator`](https://github.com/kedacore/http-add-on/pkgs/container/http-add-on-operator).
- `images.scaler` - the name of the scaler's Docker image, not including the tag. Defaults to [`ghcr.io/kedacore/http-add-on-scaler`](https://github.com/kedacore/http-add-on/pkgs/container/http-add-on-scaler).
- `images.interceptor` - the name of the interceptor's Docker image, not including the tag. Defaults to [`ghcr.io/kedacore/http-add-on-interceptor`](https://github.com/kedacore/http-add-on/pkgs/container/http-add-on-interceptor).
- `images.tag` - the tag to use for all the above docker images. Defaults to the [latest stable release](https://github.com/kedacore/http-add-on/releases).
>If you want to install the latest build of the HTTP Addon, set `version` to `canary`:
>If you want to install the latest build of the HTTP Add-on, set `version` to `canary`:
For an exhaustive list of configuration options, see the official HTTP Addon chart [values.yaml file](https://github.com/kedacore/charts/blob/master/http-add-on/values.yaml).
For an exhaustive list of configuration options, see the official HTTP Add-on chart [values.yaml file](https://github.com/kedacore/charts/blob/master/http-add-on/values.yaml).
### A Note for Developers and Local Cluster Users
Local clusters like [Microk8s](https://microk8s.io/) offer in-cluster image registries. These are popular tools to speed up and ease local development. If you use such a tool for local development, we recommend that you use and push your images to its local registry. When you do, you'll want to set your `images.*` variables to the address of the local registry. In the case of MicroK8s, that address is `localhost:32000` and the `helm install` command would look like the following:
- Within the Istio virtual service definition, add a proxy service as a route destination.
- Set the host of this proxy service to `keda-add-ons-http-interceptor-proxy`` (the KEDA HTTP Addon interceptor service).
- Set the port to `8080`` (the default interceptor port).
**Example yaml**
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: example
namespace: default
spec:
http:
- route:
- destination:
host: keda-add-ons-http-interceptor-proxy
port: 8080
```
2. **Namespace Alignment:**
- Ensure that both the KEDA HTTP Addon and the Istio virtual service are deployed within the same Kubernetes namespace. This ensures proper communication between the components.
### Behavior
- When a user makes a request, the Istio virtual service routes it to the KEDA HTTP Addon interceptor service.
- The interceptor service captures request metrics and relays them to the KEDA scaler component.
- Based on these metrics and scaling rules defined in the KEDA configuration, the KEDA scaler automatically scales the target workload (e.g., a deployment) up or down (including scaling to zero).
### Troubleshooting Tips
1. **Error: `context marked done while waiting for workload reach > 0 replicas`**
- This error indicates that the `KEDA_CONDITION_WAIT_TIMEOUT` value (default: 20 seconds) might be too low. The workload scaling process may not be complete within this timeframe.
- To increase the timeout:
- If using Helm, adjust the `interceptor.replicas.waitTimeout`` parameter (see reference below).
- You might encounter 502 errors during POST requests when the request is routed through the interceptor service. This could be due to insufficient timeout settings.
- To adjust timeout parameters:
- If using Helm, modify the following parameters (see reference below):
- If `minReplica` is set to 0 in the HTTPScaledObject, the application will immediately scale down to 0.
- There's currently no built-in mechanism to delay this initial scaling.
- A PR is in progress to add this support: [https://github.com/kedacore/keda/pull/5478](https://github.com/kedacore/keda/pull/5478)
- As a workaround, keep `minReplica` initially as 1 and update it to 0 after the desired delay.
---
## Azure Front Door
### Configuration Steps
1. **Service Setup in Front Door:**
- Set up Azure Front Door to route traffic to your AKS cluster.
- Ensure that the `Origin Host` header matches the actual AKS host. Front Door enforces case-sensitive routing, so configure the `Origin Host` exactly as the AKS host name.
2. **KEDA HTTP Add-on Integration:**
- Use an `HTTPScaledObject` to manage scaling based on incoming traffic.
- Front Door should route traffic to the KEDA HTTP Add-on interceptor service in your AKS cluster.
3. **Case-Sensitive Hostnames:**
- Be mindful that Azure Front Door treats the `Origin Host` header in a case-sensitive manner.
- Ensure consistency between the AKS ingress hostname (e.g., `foo.bar.com`) and Front Door configuration.
### Troubleshooting Tips
- **404 Error for Hostnames with Different Case:**
- Requests routed with inconsistent casing (e.g., `foo.Bar.com` vs. `foo.bar.com`) will trigger 404 errors. Make sure the `Origin Host` header matches the AKS ingress host exactly.
- If you encounter errors like `PANIC=value method k8s.io/apimachinery/pkg/types.NamespacedName.MarshalLog called using nil *NamespacedName pointer`, verify the `Origin Host` header configuration.
### Expected Behavior
- Azure Front Door routes traffic to AKS based on a case-sensitive host header.
- The KEDA HTTP Add-on scales the workload in response to traffic, based on predefined scaling rules.
# Configuring metrics for the KEDA HTTP Add-on interceptor proxy
### Exportable metrics:
* **Pending request count** - the number of pending requests for a given host.
* **Total request count** - the total number of requests for a given host with method, path and response code attributes.
There are currently 2 supported methods for exposing metrics from the interceptor proxy service - via a Prometheus compatible metrics endpoint or by pushing metrics to a OTEL HTTP collector.
### Configuring the Prometheus compatible metrics endpoint
When configured, the interceptor proxy can expose metrics on a Prometheus compatible endpoint.
This endpoint can be enabled by setting the `OTEL_PROM_EXPORTER_ENABLED` environment variable to `true` on the interceptor deployment (`true` by default) and by setting `OTEL_PROM_EXPORTER_PORT` to an unused port for the endpoint to be made avaialble on (`2223` by default).
### Configuring the OTEL HTTP exporter
When configured, the interceptor proxy can export metrics to a OTEL HTTP collector.
The OTEL exporter can be enabled by setting the `OTEL_EXPORTER_OTLP_METRICS_ENABLED` environment variable to `true` on the interceptor deployment (`false` by default). When enabled the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable must also be configured so the exporter knows what collector to send the metrics to (e.g. http://opentelemetry-collector.open-telemetry-system:4318).
If you need to provide any headers such as authentication details in order to utilise your OTEL collector you can add them into the `OTEL_EXPORTER_OTLP_HEADERS` environment variable. The frequency at which the metrics are exported can be configured by setting `OTEL_METRIC_EXPORT_INTERVAL` to the number of seconds you require between each export interval (`30` by default).
# Configuring TLS for the KEDA HTTP Add-on interceptor proxy
The interceptor proxy has the ability to run both a HTTP and HTTPS server simultaneously to allow you to scale workloads that use either protocol. By default, the interceptor proxy will only serve over HTTP, but this behavior can be changed by configuring the appropriate environment variables on the deployment.
The TLS server can be enabled by setting the environment variable `KEDA_HTTP_PROXY_TLS_ENABLED` to `true` on the interceptor deployment (`false` by default). The TLS server will start on port `8443` by default, but this can be configured by setting `KEDA_HTTP_PROXY_TLS_PORT` to your desired port number. The TLS server will require valid TLS certificates to start, the path to the certificates can be configured via the `KEDA_HTTP_PROXY_TLS_CERT_PATH` and `KEDA_HTTP_PROXY_TLS_KEY_PATH` environment variables (`/certs/tls.crt` and `/certs/tls.key` by default).
For setting multiple TLS certs, set `KEDA_HTTP_PROXY_TLS_CERT_STORE_PATHS` with comma-separated list of directories that will be recursively searched for any valid cert/key pairs. Currently, two naming patterns are supported
* `XYZ.crt` + `XYZ.key` - this is a convention when using Kubernetes Secrets of type tls
* `XYZ.pem` + `XYZ-key.pem`
To disable certificate chain verification, set `KEDA_HTTP_PROXY_TLS_SKIP_VERIFY` to `false`
The matching between certs and requests is performed during the TLS ClientHelo message, where the SNI service name is compared to SANs provided in each cert and the first matching cert will be used for the rest of the TLS handshake.
# Configuring tracing for the KEDA HTTP Add-on interceptor proxy
### Supported Exporters:
* **console** - The console exporter is useful for development and debugging tasks, and is the simplest to set up.
* **http/protobuf** - To send trace data to an OTLP endpoint (like the collector or Jaeger >= v1.35.0) you’ll want to configure an OTLP exporter that sends to your endpoint.
* * **grpc** - To configure exporter to send trace data over gRPC connection to an OTLP endpoint (like the collector or Jaeger >= v1.35.0) you’ll want to configure an OTLP exporter that sends to your endpoint.
### Configuring tracing with console exporter
To enable tracing with the console exporter, the `OTEL_EXPORTER_OTLP_TRACES_ENABLED` environment variable should be set to `true` on the interceptor deployment. (`false` by default).
Secondly set `OTEL_EXPORTER_OTLP_TRACES_PROTOCOL` to `console` (`console` by default). Other protocols include (`http/protobuf` and `grpc`).
Finally set `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT` to `"http://localhost:4318/v1/traces"` (`"http://localhost:4318/v1/traces"` by default).
### Configuring tracing with OTLP exporter
When configured, the interceptor proxy can export metrics to a OTEL HTTP collector.
To enable tracing with otlp exporter, the `OTEL_EXPORTER_OTLP_TRACES_ENABLED` environment variable should be set to `true` on the interceptor deployment. (`false` by default).
Secondly set `OTEL_EXPORTER_OTLP_TRACES_PROTOCOL` to `otlphttp` (`console` by default). Other protocols include (`http/protobuf` and `grpc`)
Finally set `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT` to the collector to send the traces to (e.g. http://opentelemetry-collector.open-telemetry-system:4318/v1/traces) (`"http://localhost:4318/v1/traces"` by default).
NOTE: full path is required to be set including <scheme><url><port><path>
Optional variables
`OTEL_EXPORTER_OTLP_HEADERS` - To pass any extra headers to the spans to utilise your OTEL collector e.g. authentication details (`"key1=value1,key2=value2"`)
`OTEL_EXPORTER_OTLP_TRACES_INSECURE` - To send traces to the tracing via HTTP rather than HTTPS (`false` by default)
`OTEL_EXPORTER_OTLP_TRACES_TIMEOUT` - The batcher timeout in seconds to send batch of data points (`5` by default)
>This document reflects the specification of the `HTTPScaledObject` resource for the latest version
>This document reflects the specification of the `HTTPScaledObject` resource for the `v0.1.0` version.
Each `HTTPScaledObject` looks approximately like the below:
@ -24,11 +24,11 @@ This is the primary and most important part of the `spec` because it describes (
### `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.
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 addon 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.
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.
This annotation will disable the ScaledObject generation and management but keeping the routing and metrics available. This is done removing the current ScaledObject if it has been already created, allowing to use user managed ScaledObjects pointing the add-on scaler directly (supporting all the ScaledObject configurations and multiple triggers). You can read more about this [here](./../../walkthrough.md#integrating-http-add-on-scaler-with-other-keda-scalers)
## `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`
>Default: "/"
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.
### `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 workload you gave.
### `portName`
Alternatively, the port can be referenced using it's `name` as defined in the `Service`.
### `scaledownPeriod`
>Default: 300
The period to wait after the last reported active before scaling the resource back to 0.
> Note: This time is measured on KEDA side based on in-flight requests, so workloads with few and random traffic could have unexpected scale to 0 cases. In those case we recommend to extend this period to ensure it doesn't happen.
## `scalingMetric`
This is the second most important part of the `spec` because it describes how the workload has to scale. This section contains 2 nested sections (`requestRate` and `concurrency`) which are mutually exclusive between themselves.
### `requestRate`
This section enables scaling based on the request rate.
> **NOTE**: Requests information is stored in memory, aggragating long periods (longer than 5 minutes) or too fine granularity (less than 1 second) could produce perfomance issues or memory usage increase.
> **NOTE 2**: Although updating `window` and/or `granularity` is something doable, the process just replaces all the stored request count infomation. This can produce unexpected scaling behaviours until the window is populated again.
#### `targetValue`
>Default: 100
This is the target value for the scaling configuration.
#### `window`
>Default: "1m"
This value defines the aggregation window for the request rate calculation.
#### `granularity`
>Default: "1s"
This value defines the granualarity of the aggregated requests for the request rate calculation.
### `concurrency`
This section enables scaling based on the request concurrency.
> **NOTE**: This is the only scaling behaviour before v0.8.0
#### `targetValue`
>Default: 100
This is the target value for the scaling configuration.
>This document reflects the specification of the `HTTPScaledObject` resource for the `v0.2.0` version.
Each `HTTPScaledObject` looks approximately like the below:
```yaml
kind: HTTPScaledObject
apiVersion: http.keda.sh/v1alpha1
metadata:
name: xkcd
spec:
host: "myhost.com"
targetPendingRequests: 100
scaleTargetRef:
deployment: xkcd
service: xkcd
port: 8080
```
This document is a narrated reference guide for the `HTTPScaledObject`, and we'll focus on the `spec` field.
## `host`
This is the host to apply this scaling rule to. All incoming requests with this value in their `Host` header will be forwarded to the `Service` and port specified in the below `scaleTargetRef`, and that same `scaleTargetRef`'s `Deployment` 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 `Deployment` 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.
>This document reflects the specification of the `HTTPScaledObject` resource for the `v0.3.0` version.
Each `HTTPScaledObject` looks approximately like the below:
```yaml
kind: HTTPScaledObject
apiVersion: http.keda.sh/v1alpha1
metadata:
name: xkcd
spec:
host: "myhost.com"
targetPendingRequests: 100
scaleTargetRef:
deployment: xkcd
service: xkcd
port: 8080
```
This document is a narrated reference guide for the `HTTPScaledObject`, and we'll focus on the `spec` field.
## `host`
This is the host to apply this scaling rule to. All incoming requests with this value in their `Host` header will be forwarded to the `Service` and port specified in the below `scaleTargetRef`, and that same `scaleTargetRef`'s `Deployment` 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 `Deployment` 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.
>This document reflects the specification of the `HTTPScaledObject` resource for the `v0.6.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
scaledownPeriod: 300
```
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`
>Default: "/"
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.
### `scaledownPeriod`
>Default: 300
The period to wait after the last reported active before scaling the resource back to 0.
> Note: This time is measured on KEDA side based on in-flight requests, so workloads with few and random traffic could have unexpected scale to 0 cases. In those case we recommend to extend this period to ensure it doesn't happen.
>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
scaledownPeriod: 300
```
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`
>Default: "/"
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.
### `scaledownPeriod`
>Default: 300
The period to wait after the last reported active before scaling the resource back to 0.
> Note: This time is measured on KEDA side based on in-flight requests, so workloads with few and random traffic could have unexpected scale to 0 cases. In those case we recommend to extend this period to ensure it doesn't happen.
This annotation will disable the ScaledObject generation and management but keeping the routing and metrics available. This is done removing the current ScaledObject if it has been already created, allowing to use user managed ScaledObjects pointing the add-on scaler directly (supporting all the ScaledObject configurations and multiple triggers). You can read more about this [here](./../../walkthrough.md#integrating-http-add-on-scaler-with-other-keda-scalers)
## `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`
>Default: "/"
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` (DEPRECTATED: removed as part of v0.9.0)
>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.
### `scaledownPeriod`
>Default: 300
The period to wait after the last reported active before scaling the resource back to 0.
> Note: This time is measured on KEDA side based on in-flight requests, so workloads with few and random traffic could have unexpected scale to 0 cases. In those case we recommend to extend this period to ensure it doesn't happen.
## `scalingMetric`
This is the second most important part of the `spec` because it describes how the workload has to scale. This section contains 2 nested sections (`requestRate` and `concurrency`) which are mutually exclusive between themselves.
### `requestRate`
This section enables scaling based on the request rate.
> **NOTE**: Requests information is stored in memory, aggragating long periods (longer than 5 minutes) or too fine granularity (less than 1 second) could produce perfomance issues or memory usage increase.
> **NOTE 2**: Although updating `window` and/or `granularity` is something doable, the process just replaces all the stored request count infomation. This can produce unexpected scaling behaviours until the window is populated again.
#### `targetValue`
>Default: 100
This is the target value for the scaling configuration.
#### `window`
>Default: "1m"
This value defines the aggregation window for the request rate calculation.
#### `granularity`
>Default: "1s"
This value defines the granualarity of the aggregated requests for the request rate calculation.
### `concurrency`
This section enables scaling based on the request concurrency.
> **NOTE**: This is the only scaling behaviour before v0.8.0
#### `targetValue`
>Default: 100
This is the target value for the scaling configuration.
This annotation will disable the ScaledObject generation and management but keeping the routing and metrics available. This is done removing the current ScaledObject if it has been already created, allowing to use user managed ScaledObjects pointing the add-on scaler directly (supporting all the ScaledObject configurations and multiple triggers). You can read more about this [here](./../../walkthrough.md#integrating-http-add-on-scaler-with-other-keda-scalers)
## `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`
>Default: "/"
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.
### `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 workload you gave.
### `portName`
Alternatively, the port can be referenced using it's `name` as defined in the `Service`.
### `scaledownPeriod`
>Default: 300
The period to wait after the last reported active before scaling the resource back to 0.
> Note: This time is measured on KEDA side based on in-flight requests, so workloads with few and random traffic could have unexpected scale to 0 cases. In those case we recommend to extend this period to ensure it doesn't happen.
## `scalingMetric`
This is the second most important part of the `spec` because it describes how the workload has to scale. This section contains 2 nested sections (`requestRate` and `concurrency`) which are mutually exclusive between themselves.
### `requestRate`
This section enables scaling based on the request rate.
> **NOTE**: Requests information is stored in memory, aggragating long periods (longer than 5 minutes) or too fine granularity (less than 1 second) could produce perfomance issues or memory usage increase.
> **NOTE 2**: Although updating `window` and/or `granularity` is something doable, the process just replaces all the stored request count infomation. This can produce unexpected scaling behaviours until the window is populated again.
#### `targetValue`
>Default: 100
This is the target value for the scaling configuration.
#### `window`
>Default: "1m"
This value defines the aggregation window for the request rate calculation.
#### `granularity`
>Default: "1s"
This value defines the granualarity of the aggregated requests for the request rate calculation.
### `concurrency`
This section enables scaling based on the request concurrency.
> **NOTE**: This is the only scaling behaviour before v0.8.0
#### `targetValue`
>Default: 100
This is the target value for the scaling configuration.
This annotation will disable the ScaledObject generation and management but keeping the routing and metrics available. This is done removing the current ScaledObject if it has been already created, allowing to use user managed ScaledObjects pointing the add-on scaler directly (supporting all the ScaledObject configurations and multiple triggers). You can read more about this [here](./../../walkthrough.md#integrating-http-add-on-scaler-with-other-keda-scalers)
## `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`
>Default: "/"
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.
### `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 workload you gave.
### `portName`
Alternatively, the port can be referenced using it's `name` as defined in the `Service`.
### `scaledownPeriod`
>Default: 300
The period to wait after the last reported active before scaling the resource back to 0.
> Note: This time is measured on KEDA side based on in-flight requests, so workloads with few and random traffic could have unexpected scale to 0 cases. In those case we recommend to extend this period to ensure it doesn't happen.
## `scalingMetric`
This is the second most important part of the `spec` because it describes how the workload has to scale. This section contains 2 nested sections (`requestRate` and `concurrency`) which are mutually exclusive between themselves.
### `requestRate`
This section enables scaling based on the request rate.
> **NOTE**: Requests information is stored in memory, aggragating long periods (longer than 5 minutes) or too fine granularity (less than 1 second) could produce perfomance issues or memory usage increase.
> **NOTE 2**: Although updating `window` and/or `granularity` is something doable, the process just replaces all the stored request count infomation. This can produce unexpected scaling behaviours until the window is populated again.
#### `targetValue`
>Default: 100
This is the target value for the scaling configuration.
#### `window`
>Default: "1m"
This value defines the aggregation window for the request rate calculation.
#### `granularity`
>Default: "1s"
This value defines the granualarity of the aggregated requests for the request rate calculation.
### `concurrency`
This section enables scaling based on the request concurrency.
> **NOTE**: This is the only scaling behaviour before v0.8.0
#### `targetValue`
>Default: 100
This is the target value for the scaling configuration.
Running production HTTP servers in Kubernetes is complicated and involves many pieces of infrastructure. The HTTP Add On (called the "add on" hereafter) aims to autoscale these HTTP servers, but does not aim to extend beyond that scope. Generally, this project only aims to do two things:
Running production HTTP servers in Kubernetes is complicated and involves many pieces of infrastructure. The HTTP Add-on (called the "add-on" hereafter) aims to autoscale these HTTP servers, but does not aim to extend beyond that scope. Generally, this project only aims to do two things:
1. Autoscale arbitrary HTTP servers based on the volume of traffic incoming to it, including to zero
2. Route HTTP traffic from a given source to an arbitrary HTTP server, as far as we need to efficiently accomplish (1)
1. Autoscale arbitrary HTTP servers based on the volume of traffic incoming to it, including to zero.
2. Route HTTP traffic from a given source to an arbitrary HTTP server, as far as we need to efficiently accomplish (1).
The addon only provides this functionality to workloads that _opt in_ to it. We provide more detail below.
The add-on only provides this functionality to workloads that _opt in_ to it. We provide more detail below.
## Autoscaling HTTP
### Autoscaling HTTP
To autoscale HTTP servers, the HTTP Add On needs access to metrics that it can report to KEDA, so that KEDA itself can scale the target HTTP server. The mechanism by which the addon does this is to use an [interceptor](../interceptor) and [external scaler](../scaler). An operator watches for a `HTTPScaledObject` resource and creates these components as necessary.
To autoscale HTTP servers, the HTTP Add-on needs access to metrics that it can report to KEDA, so that KEDA itself can scale the target HTTP server. The mechanism by which the add-on does this is to use an [interceptor](../interceptor) and [external scaler](../scaler). An operator watches for a `HTTPScaledObject` resource and creates these components as necessary.
The HTTP Add On only includes the necessary infrastructure to respond to new, modified, or deleted `HTTPScaledObject`s, and when one is created, the addon only creates the infrastructure needed specifically to accomplish autoscaling.
The HTTP Add-on only includes the necessary infrastructure to respond to new, modified, or deleted `HTTPScaledObject`s, and when one is created, the add-on only creates the infrastructure needed specifically to accomplish autoscaling.
>As stated above, the current architecture requires an "interceptor", which needs to proxy incoming HTTP requests in order to provide autoscaling metrics. That means the scope of the HTTP add-on currently needs to include the app's network traffic routing system.
>As stated above, the current architecture requires an "interceptor", which needs to proxy incoming HTTP requests in order to provide autoscaling metrics. That means the scope of the HTTP Add-on currently needs to include the app's network traffic routing system.
To learn more, we recommend reading about our [design](design.md) or go through our [FAQ](faq.md).
@ -19,21 +19,23 @@ 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`
- [Install](./install.md) the HTTP Add On
- Create a single `HTTPScaledObject` in the same namespace as the `Deployment` and `Service` you created
- Create a workload and `Service`
- [Install](./install.md) the HTTP Add-on
- 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
In this use case, an HTTP application is already running in Kubernetes, possibly (but not necessarily) already serving in production to the public internet.
In this case, the reasoning for adding the HTTP Add On would be clear - adding autoscaling based on incoming HTTP traffic.
In this case, the reasoning for adding the HTTP Add-on would be clear - adding autoscaling based on incoming HTTP traffic.
### How You'd Move This Application to KEDA-HTTP
Getting the HTTP add on working can be done transparently and without downtime to the application:
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.
- [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 workload that you specify and the application will immediately start scaling up and down based on incoming traffic through the interceptor that was created.
After you've installed KEDA and the HTTP Add On (this project, we'll call it the "add on" for short), this document will show you how to get started with an example app.
After you've installed KEDA and the HTTP Add-on (this project, we'll call it the "add-on" for short), this document will show you how to get started with an example app.
If you haven't installed KEDA and the HTTP Add On (this project), please do so first. Follow instructions [install.md](./install.md) to complete your installation. Before you continue, make sure that you have your `NAMESPACE` environment variable set to the same value as it was when you installed.
If you haven't installed KEDA and the HTTP Add-on (this project), please do so first. Follow instructions [install.md](./install.md) to complete your installation.
>Before you continue, make sure that you have your `NAMESPACE` environment variable set to the same value as it was when you installed.
## Creating An Application
You'll need to install a `Deployment` and `Service` first. You'll tell the add on to begin scaling it up and down after this step. Use the below [Helm](https://helm.sh) command to create the resources you need.
You'll need to install a `Deployment` and `Service` first. You'll tell the add-on to begin scaling it up and down after this step. We've provided a [Helm](https://helm.sh) chart in this repository that you can use to try it out. Use this command to create the resources you need.
```shell
```console
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.
#### xkcd exposed with GatewayAPI
Alternatively if you'd like to try the addon along with GatewayAPI, you can install first GatewayAPI CRDs and some GatewayAPI implementation, for example as described in a [section below](#installing-and-using-the-eg-gatewayapi) and install the application as with `httproute=true` which will deploy properly configured `HTTPRoute` too.
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.
>To remove the app, run `helm delete xkcd -n ${NAMESPACE}`
## Creating an `HTTPScaledObject`
You interact with the operator via a CRD called `HTTPScaledObject`. This CRD object points the To get an example app up and running, read the notes below and then run the subsequent command from the root of this repository.
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.
>If you'd like to learn more about this object, please see the [`HTTPScaledObject` reference](./ref/http_scaled_object.md).
>If you'd like to learn more about this object, please see the [`HTTPScaledObject` reference](./ref/v0.10.0/http_scaled_object.md).
## Testing Your Installation
You've now installed a web application and activated autoscaling by creating an `HTTPScaledObject` for it. For autoscaling to work properly, HTTP traffic needs to route through the `Service` that the addon has set up. You can use `kubectl port-forward` to quickly test things out:
You've now installed a web application and activated autoscaling by creating an `HTTPScaledObject` for it. For autoscaling to work properly, HTTP traffic needs to route through the `Service` that the add-on has set up. You can use `kubectl port-forward` to quickly test things out:
```shell
k port-forward svc/xkcd-interceptor-proxy -n ${NAMESPACE} 8080:80
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`):
```shell
<deploymentname>-interceptor-proxy
```console
keda-add-ons-http-interceptor-proxy
```
>The service will always be a `ClusterIP` type and will be created in the same namespace as the `HTTPScaledObject` you created.
#### Installing and Using the [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/#using-helm) Ingress Controller
As mentioned above, the `Service` that the add-on creates will be inaccessible over the network from outside of your Kubernetes cluster.
@ -52,7 +61,7 @@ While you can access it via the `kubectl port-forward` command above, we recomme
First, install the controller using the commands below. These commands use Helm v3. For other installation methods, see the [installation page](https://kubernetes.github.io/ingress-nginx/deploy/).
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.
#### Installing and Using the [eg](https://gateway.envoyproxy.io/latest/install/install-helm/) GatewayAPI
Similarly to exposing your service with `Ingress`, you can expose your service with `HTTPRoute` as part of [GatewayAPI](https://github.com/kubernetes-sigs/gateway-api). Following steps describe how to install one of may GatewayAPI implementations - Envoy Gateway.
You should install the `xkcd` helm chart with `--set httproute=true` as [explained above](#xkcd-exposed-with-gatewayapi).
The helm chart is publically available and hosted by DockerHub
> 💡 Note the `ExternalName` type `Service` used to route traffic from `Ingress` defined in one namespace to the interceptor `Service` defined in another is not necessary with GatewayAPI.
> The GatewayAPI defines [`ReferenceGrant`](https://gateway-api.sigs.k8s.io/api-types/referencegrant/) to allow `HTTPRoutes` referencing `Services` and other types of backend from different `Namespaces`.
You can see the IP address for following rest of the document with
```console
kubectl get gateway -n envoy-gateway-system
```
For example (your IP will likely differ)
```
NAME CLASS ADDRESS PROGRAMMED AGE
eg eg 172.24.255.201 True 16s
```
### Making an HTTP Request to your App
Now that you have your application running and your ingress configured, you can issue an HTTP request. To do so, you'll need to know the IP address to request. If you're using an ingress controller, that is the IP of the ingress controller's `Service`. If you're using a "raw" `Service` with `type: LoadBalancer`, that is the IP address of the `Service` itself.
Regardless, you can use the below `curl` command to make a request to your application:
```console
curl -H "Host: myhost.com" <YourIP>/test
```
>Note the `-H` flag above to specify the `Host` header. This is needed to tell the interceptor how to route the request. If you have a DNS name set up for the IP, you don't need this header.
You can also use port-forward to interceptor service for making the request:
### Integrating HTTP Add-On Scaler with other KEDA scalers
For scenerios where you want to integrate HTTP Add-On scaler with other keda scalers, you can set the `"httpscaledobject.keda.sh/skip-scaledobject-creation"` annotation to true on your `HTTPScaledObject`. The reconciler will then skip the KEDA core ScaledObject creation which will allow you to create your own `ScaledObject` and add HTTP scaler as one of your triggers.
> 💡 Ensure that your ScaledObject is created with a different name than the `HTTPScaledObject` to ensure your ScaledObject is not removed by the reconciler.
If you don't know how to set the external scaler in the ScaledObject, you can deploy first your HTTPScaledObject with no annotation set in order to obtain the latest trigger spec to use on your own managed ScaledObject.
1. Deploy your `HTTPScaledObject` with annotation set to false
3. Apply the `"httpscaledobject.keda.sh/skip-scaledobject-creation"` annotation with `true` and apply the change. This will remove the originally created `ScaledObject` allowing you to create your own.