kedacore/charts

1. This repository is a Helm chart distribution repo, not an application codebase. Its primary job is to package and publish Kubernetes deployment manifests for KEDA and related add-ons.

2. The top-level product split is into three charts:

- keda: the core KEDA installation

- http-add-on: the HTTP autoscaling add-on

- external-scaler-azure-cosmos-db: a specialized external scaler integration

3. The keda chart is the main control plane package. Its templates deploy the core KEDA manager, metrics server, and validating webhooks, plus the Kubernetes RBAC, services, service accounts, pod disruption budgets, and monitoring resources that support them.

4. In the KEDA architecture, the manager is the operator-like component that reconciles KEDA custom resources. The metrics server exposes custom metrics to Kubernetes so the Horizontal Pod Autoscaler can scale workloads based on event sources. The webhook layer validates CRD objects at admission time.

5. The keda chart also installs the CRDs that define KEDA’s API surface: ScaledObject, ScaledJob, TriggerAuthentication, ClusterTriggerAuthentication, CloudEventSource, and ClusterCloudEventSource. These are the primary boundary between user intent and KEDA reconciliation.

6. Certificate-related templates in keda/templates/cert-manager show that the chart can manage webhook/serving TLS either with cert-manager or self-signed issuance. That makes TLS a deployment concern inside the chart, not an external app dependency.

7. The http-add-on chart is a multi-component add-on with its own control and data path:

- an operator component

- a scaler component

- an interceptor component

- CRDs for HTTPScaledObject and InterceptorRoute

8. In the HTTP add-on, the interceptor is the request-facing runtime that sits in front of HTTP workloads, while the scaler and operator coordinate autoscaling behavior through Kubernetes resources. The chart templates separate these into distinct deployments, services, RBAC, and service accounts, indicating clear runtime boundaries.

9. The external-scaler-azure-cosmos-db chart is a narrower integration package. It deploys a scaler service and scaler deployment that connect KEDA to Azure Cosmos DB change feed behavior, representing an extension point rather than core functionality.

10. docs/ contains packaged chart artifacts and repository index files. This indicates the repo is also the publishable Helm repository source, where release tarballs and chart indexes are stored for consumption by helm repo add and helm search.

11. samples/nginx-scaledobject.yml is a usage example rather than a runtime component. It demonstrates how consumers author KEDA custom resources to connect an application workload to autoscaling behavior.

12. The .github/workflows files show CI is organized around chart-specific validation pipelines. Separate workflows for core, HTTP add-on, and Cosmos DB scaler imply independent packaging, linting, and release checks per chart.

13. Architecturally, the important boundary is between chart packaging and cluster runtime. This repo does not run the autoscalers itself; it defines the Kubernetes objects that will run in a user’s cluster and the CRDs/controllers those objects depend on.

14. For a diagram, the main flows are: Helm renders templates → Kubernetes installs CRDs and control-plane deployments → KEDA/operator or add-on components watch custom resources → metrics/webhook/scaler services interact with Kubernetes and application workloads → HPA or workload scaling reacts to emitted metrics or HTTP traffic.