Kedify Architecture

Scroll to explore

Diagram description

Kedify brings KEDA and optional plugins into your Kubernetes cluster. The Kedify Agent manages the enabled components and connects the cluster to the hosted Kedify service over authenticated TLS gRPC. OTel, Predictive, HTTP and KPA extend the installation.

Replica control path

1. A scaler reads demand from an event source, HTTP traffic or application metrics.
2. KEDA handles workload activation and scale to zero, and exposes scaling metrics.
3. Kubernetes HPA computes active replica counts by default. When selected, KPA runs the 1 ↔ N loop inside the tenant’s controller boundary.
4. The selected autoscaler updates the workload’s scale subresource. Kubernetes schedules the requested pods; ready capacity still depends on nodes and application startup.

This describes ScaledObject replica scaling. ScaledJobs create finite Jobs; vertical controllers change container resources.

Components and connections

Component	Runs in	Responsibility and connection
KEDA and optional KPA	Kubernetes cluster	Read demand signals and reconcile scaling resources. See controller ownership.
Kedify Agent	Kubernetes cluster	Manages enabled component releases and Kedify resources; collects configured telemetry. Initiates an authenticated TLS gRPC connection to the Kedify service.
HTTP proxy and scaler	Kubernetes cluster	Route application requests and produce HTTP scaling metrics. See the HTTP request path.
OTel and predictive components	Kubernetes cluster, when enabled	Ingest application metrics or train/use forecasts. Their guides define storage and signal connections.
Kedify service and Dashboard	Hosted platform	Receive Agent telemetry and provide installation management, scaling visibility and Insights.

The application’s HTTP traffic path is described separately from the Agent’s hosted-service connection. See access and connectivity for egress and collection controls.

Resource ownership

The Kubernetes API catalog identifies resources you configure and resources controllers generate. Configure each field through its owner: an autoscaler, Helm/GitOps or a dashboard action. Overlapping writers can undo each other’s changes.

Multi-cluster scaling connects a central installation to member Kubernetes APIs. Multi-tenant scaling divides controller ownership by namespace. These are separate from viewing independent installations in one Dashboard.