# KEDA HTTP Addon Cluster-Global Design This document is a description of the design changes involved with [PR #269](https://github.com/kedacore/http-add-on/pull/269) in the [KEDA HTTP Addon project](https://github.com/kedacore/http-add-on). >Although the overall design herein is finalized, this is a living document. Details will be added as appropriate. ## Overview The three components -- scaler, interceptor and operator -- are loosely coupled and communicate in two ways: - The routing table - The HTTP pending queue sizes This overview section will describe how these two communication mechanisms will change to allow for cluster-global operation. ### Routing Table The operator writes to a `ConfigMap` and both scaler and interceptor watch and read from it. This patch will add a `namespace` field to the routing table, to indicate the namespace to which the interceptor should forward requests. Instead of mapping an incoming host to a cluster-internal `$service:$port` address, the interceptor will now map an incoming host to a `$service.$namespace:$port` hostname. In both namespace-local mode as well as cluster-global mode, all interceptors, scalers and operators run in the same namespace. In either mode, the routing table `ConfigMap` will be stored in a configurable namespace, b ut recommended to be the same namespace as the running components. ### HTTP Pending Request Queue The scaler does standardized RPC calls to each running interceptor to calculate the aggregate size of the HTTP pending request queue for each host. This implementation won't change. ## Operator Very little needs to change with the operator. Since it's built atop the [controller-runtime](https://pkg.go.dev/sigs.k8s.io/controller-runtime) framework, which has cluster-global functionality built in, it can already reconcile changes from any `HTTPScaledObject` in the cluster, regardless of namespace. The operator will add a configuration variable to specify the namespace it intends to watch, and this variable can be left blank to indicate cluster-global operation (in fact, before this patch, there is a bug that leaves the namespace field blank in all cases). When the operator reconciles a new `HTTPScaledObject`, it will ensure that all resources (i.e. the `ScaledObject`) are created in the same namespace as the given `HTTPScaledObject`. Since the routing table is changed to include a namespace for the target application, the operator will use the namespace of the incoming `HTTPScaledObject` as the namespace for the corresponding routing table entry. ## Interceptor Since the interceptor is responsible for routing requests to the appropriate backing application, the interceptor needs to become namespace-aware. The interceptor must: - Decode the new routing table version that includes the namespace - Forward to the proper in-cluster `$service.$namespace:$port` hostname - Fetch the routing table `ConfigMap` from the configured namespace - Be able to watch backing application `Deployment`s in any given namespace. It is currently only able to watch `Deployment`s in a single, fixed namespace. ## Scaler Scaler functionality need not be aware of target application namespaces, but since the scaler fetches the routing table `ConfigMap`, it has to make some minor changes: - Decode the new routing table format that includes the namespace - Fetch the routing table `ConfigMap` from the configured namespace ## Aside: KEDA The KEDA operator can either be run scoped to a single namespace or at cluster-global scope. This design will have the following rules related to KEDA: - KEDA and the HTTP Addon must be run in the same mode - cluster-global or namespace-scoped - Only one cluster-global KEDA and HTTP Addon may be run at a time - If any cluster-global deployment is run, no namespace-scoped deployments may be run