# Enable predictive scaling

Install Predictor through the Agent chart or as a separate release. Choose one owner for the release and keep the selected chart version and values in Helm/GitOps.

## Installing Kedify Predictor Using Helm

For an existing Agent installation, add this to its maintained values file and apply it using your existing [Helm/GitOps workflow](https://docs.kedify.io/installation/helm/):

```yaml
kedify-predictor:
  enabled: true
```

Keep the existing organization, API key and other component values. Predictor settings belong under `kedify-predictor` when installed as this sub-chart.

### Installing Using Standalone Helm Chart

For a separate release, select a published chart version and save its values before installing:

```bash
export PREDICTOR_CHART_VERSION='<selected-chart-version>'
helm show values oci://ghcr.io/kedify/charts/kedify-predictor \
  --version "$PREDICTOR_CHART_VERSION" > predictor-values.yaml
# Edit predictor-values.yaml for storage, resources and your KEDA service address.
helm upgrade --install kedify-predictor oci://ghcr.io/kedify/charts/kedify-predictor \
  --version "$PREDICTOR_CHART_VERSION" --namespace keda --create-namespace \
  --values predictor-values.yaml
```

The standalone values have no `kedify-predictor` prefix. For example:

```yaml
settings:
  storage:
    modelsPvcSize: 600Mi
    dbPvcSize: 2Gi
resources:
  limits:
    memory: 700Mi
  requests:
    cpu: 300m
    memory: 256Mi
```

#### Setting up External PostgreSQL as Metric Store

By default, Kedify Predictor uses SQLite file-based DB and uses Kubernetes PVC and PV to store it. Training jobs and the predictor must access the same data and serialized models. Select storage that supports their placement and concurrent access; cross-node sharing generally needs ReadWriteMany. The v0.1.6 source defaults to ReadWriteOnce, so verify your storage class and scheduling before using job-based training. Use external PostgreSQL and `noSharedVolumes` when shared storage is unsuitable.

If you want to use an existing KEDA ScaledObject/ScaledJob as the live metric source, KEDA must be installed (or installed via kedify-agent), and raw-metrics gRPC must be enabled.

In order to use external DB follow these instructions:

##### 1. (Optional) Set up PostgreSQL or skip this step if you already have one

```bash
# create k8s secret with password
kubectl create secret generic postgres-credentials -n keda \
        --from-literal=postgres-password='AdminPassword' \
        --from-literal=password='KedifyUserPassword'

# install helm chart with postgresql
helm upgrade -i -n keda postgres oci://registry-1.docker.io/bitnamicharts/postgresql \
        --set auth.database=kedify \
        --set auth.username=kedify \
        --set auth.existingSecret=postgres-credentials
```

##### 2. Install predictor with following helm values

```bash
cat <<VALS | helm upgrade -i kedify-predictor oci://ghcr.io/kedify/charts/kedify-predictor -n keda -f -
kedaPredictionController:
  noSharedVolumes: true
db:
  type: postgres
  host: postgres-postgresql
  port: '5432'
  name: kedify
  user: kedify
  # password: KedifyUserPassword
  existingSecret: postgres-credentials
  existingSecretPasswordKey: password
VALS
```

### Enabling KEDA to Feed the Metrics to Predictor

If you want to use an existing KEDA’s ScaledObject as a source for metrics, you need to enable the raw-metrics gRPC API on KEDA operator. To do this, tweak the helm charts for KEDA so that it has the `RAW_METRICS_GRPC_PROTOCOL` environment variable set to `enabled` and `RAW_METRICS_MODE` to `pollinginterval` or `hpa`. This feature is available in the Kedify KEDA distribution since version `v2.18.1` (verify the selected build). If you choose to use `pollinginterval` as the mode, the frequency of metric ingestion can be controlled by `.spec.pollingInterval` on ScaledObject or ScaledJob.

Add these entries to the Agent chart’s existing `keda.env` list; preserve any entries already configured:

```yaml
keda:
  env:
    - name: RAW_METRICS_GRPC_PROTOCOL
      value: enabled
    - name: RAW_METRICS_MODE
      value: pollinginterval
```

Apply through the same Helm/GitOps owner, then check the operator rollout and Predictor’s source status. For a separately managed KEDA chart, use `env` at that chart’s root.

### OTLP Receiver

Another possible metric source to Kedify Predictor is the integrated [OTLP](https://opentelemetry.io/docs/specs/otlp/) gRPC receiver. It naturally fits to the OpenTelemetry ecosystem using the well-known protocol. This way, the Kedify Predictor Kubernetes service can be configured under the OTel Collector [exporters section](https://opentelemetry.io/docs/collector/configuration/#exporters).

Example:

```yaml
# Other collector configuration omitted.
exporters:
  otlp/keda:
    endpoint: kedify-predictor.keda.svc:4317
# Other collector configuration omitted.
```

Then, if enabled also by creating the corresponding MetricPredictor (MP) resource, it will start storing the metrics.

Example:

```yaml
kind: MetricPredictor
apiVersion: keda.kedify.io/v1alpha1
metadata:
  name: otel-source
spec:
  source:
    otel:
      metricName: http_requests_total
      metricType: gauge # default gauge (gauge,sum,histogram,exponentialhistogram,summary)
      # metric has to have these labels in order to be recorded
      # requiredLabels:
      #   namespace: prod
      #   service: myapp
  model:
    type: Prophet
    name: kedify-predictor-otlp
    defaultHorizon: 5m
    retrainInterval: 1d
```

This will make sure that any incoming metric called `http_requests_total` will be stored as is in metric DB. Further requirements for incoming metric, can be provided by `requiredLabels` field. Then all the key-value label pairs needs to be present on the incoming metric.

If any further calculations are required for the metrics (like aggregating them among the existing pods/labels). You may want to use OTel transformers (for simple linear transformations) or [OTel Scaler](https://docs.kedify.io/scalers/otel-scaler/) and reference it in MP as `.spec.source.keda`.

For more info, consult [this page](https://docs.kedify.io/how-to/predictive-scaler-otlp/).

### Getting Started

With this, your installation of Kedify Predictor is now complete and you can continue with:

- a how-to tutorial with a [demo application](https://docs.kedify.io/how-to/predictive-scaler-example/)

- a [demo application](https://docs.kedify.io/how-to/predictive-scaler-otlp/) using OTLP receiver and weather data

- full scaler [docs](https://docs.kedify.io/scalers/predictive-scaler/)

## Continue with this topic

**Reference:** [Helm values and component configuration](https://docs.kedify.io/reference/helm-values/) · [Predictive scaler trigger configuration](https://docs.kedify.io/reference/predictive-scaler/) · [MetricPredictor API reference](https://docs.kedify.io/reference/kubernetes-api/metricpredictor/).

[Next
Forecast and scale a sample workload](https://docs.kedify.io/how-to/predictive-scaler-example/)

---
Canonical: https://docs.kedify.io/how-to/predictive-scaler-installation/
Source: src/content/docs/how-to/predictive-scaler-installation.md
Documentation index: https://docs.kedify.io/llms.txt