You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/how-to-guides/feast-on-kubernetes.md
+4-2Lines changed: 4 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -65,7 +65,9 @@ spec:
65
65
> _More advanced FeatureStore CR examples can be found in the feast-operator [samples directory](../../infra/feast-operator/config/samples)._
66
66
67
67
{% hint style="success" %}
68
-
Important note: Scaling a Feature Store Deployment should only be done if the configured data store(s) will support it.
68
+
**Scaling:** The Feast Operator supports horizontal scaling via static replicas, HPA autoscaling, or external autoscalers like [KEDA](https://keda.sh). Scaling requires DB-backed persistence for all enabled services.
69
69
70
-
Please check the how-to guide for some specific recommendations on [how to scale Feast](./scaling-feast.md).
70
+
See the [Horizontal Scaling with the Feast Operator](./scaling-feast.md#horizontal-scaling-with-the-feast-operator) guide for configuration details, or check the general recommendations on [how to scale Feast](./scaling-feast.md).
71
71
{% endhint %}
72
+
73
+
> _Sample scaling CRs are available at [`v1_featurestore_scaling_static.yaml`](../../infra/feast-operator/config/samples/v1_featurestore_scaling_static.yaml) and [`v1_featurestore_scaling_hpa.yaml`](../../infra/feast-operator/config/samples/v1_featurestore_scaling_hpa.yaml)._
Copy file name to clipboardExpand all lines: docs/how-to-guides/scaling-feast.md
+155-1Lines changed: 155 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,4 +23,158 @@ However, this process does not scale for large data sets, since it's executed on
23
23
Feast supports pluggable [Compute Engines](../getting-started/components/compute-engine.md), that allow the materialization process to be scaled up.
24
24
Aside from the local process, Feast supports a [Lambda-based materialization engine](https://rtd.feast.dev/en/master/#alpha-lambda-based-engine), and a [Bytewax-based materialization engine](https://rtd.feast.dev/en/master/#bytewax-engine).
25
25
26
-
Users may also be able to build an engine to scale up materialization using existing infrastructure in their organizations.
26
+
Users may also be able to build an engine to scale up materialization using existing infrastructure in their organizations.
27
+
28
+
### Horizontal Scaling with the Feast Operator
29
+
30
+
When running Feast on Kubernetes with the [Feast Operator](./feast-on-kubernetes.md), you can horizontally scale the FeatureStore deployment using `spec.replicas` or HPA autoscaling. The FeatureStore CRD implements the Kubernetes [scale sub-resource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource), so you can also use `kubectl scale`:
31
+
32
+
```bash
33
+
kubectl scale featurestore/my-feast --replicas=3
34
+
```
35
+
36
+
**Prerequisites:** Horizontal scaling requires **DB-backed persistence** for all enabled services (online store, offline store, and registry). File-based persistence (SQLite, DuckDB, `registry.db`) is incompatible with multiple replicas because these backends do not support concurrent access from multiple pods.
37
+
38
+
#### Static Replicas
39
+
40
+
Set a fixed number of replicas via `spec.replicas`:
41
+
42
+
```yaml
43
+
apiVersion: feast.dev/v1
44
+
kind: FeatureStore
45
+
metadata:
46
+
name: sample-scaling
47
+
spec:
48
+
feastProject: my_project
49
+
replicas: 3
50
+
services:
51
+
onlineStore:
52
+
persistence:
53
+
store:
54
+
type: postgres
55
+
secretRef:
56
+
name: feast-data-stores
57
+
registry:
58
+
local:
59
+
persistence:
60
+
store:
61
+
type: sql
62
+
secretRef:
63
+
name: feast-data-stores
64
+
```
65
+
66
+
#### Autoscaling with HPA
67
+
68
+
Configure a HorizontalPodAutoscaler to dynamically scale based on metrics. HPA autoscaling is configured under `services.scaling.autoscaling` and is mutually exclusive with `spec.replicas > 1`:
69
+
70
+
```yaml
71
+
apiVersion: feast.dev/v1
72
+
kind: FeatureStore
73
+
metadata:
74
+
name: sample-autoscaling
75
+
spec:
76
+
feastProject: my_project
77
+
services:
78
+
scaling:
79
+
autoscaling:
80
+
minReplicas: 2
81
+
maxReplicas: 10
82
+
metrics:
83
+
- type: Resource
84
+
resource:
85
+
name: cpu
86
+
target:
87
+
type: Utilization
88
+
averageUtilization: 70
89
+
onlineStore:
90
+
persistence:
91
+
store:
92
+
type: postgres
93
+
secretRef:
94
+
name: feast-data-stores
95
+
server:
96
+
resources:
97
+
requests:
98
+
cpu: 200m
99
+
memory: 256Mi
100
+
registry:
101
+
local:
102
+
persistence:
103
+
store:
104
+
type: sql
105
+
secretRef:
106
+
name: feast-data-stores
107
+
```
108
+
109
+
{% hint style="info" %}
110
+
When autoscaling is configured, the operator automatically sets the deployment strategy to `RollingUpdate` (instead of the default `Recreate`) to ensure zero-downtime scaling. You can override this by explicitly setting `deploymentStrategy` in the CR.
111
+
{% endhint %}
112
+
113
+
#### Validation Rules
114
+
115
+
The operator enforces the following rules:
116
+
- `spec.replicas > 1`and `services.scaling.autoscaling` are **mutually exclusive** -- you cannot set both.
117
+
- Scaling with `replicas > 1` or any `autoscaling` config is **rejected** if any enabled service uses file-based persistence.
118
+
- S3 (`s3://`) and GCS (`gs://`) backed registry file persistence is allowed with scaling, since these object stores support concurrent readers.
119
+
120
+
#### Using KEDA (Kubernetes Event-Driven Autoscaling)
121
+
122
+
[KEDA](https://keda.sh) is also supported as an external autoscaler. KEDA should target the FeatureStore's scale sub-resource directly (since it implements the Kubernetes scale API). This is the recommended approach because the operator manages the Deployment's replica count from `spec.replicas` — targeting the Deployment directly would conflict with the operator's reconciliation.
123
+
124
+
When using KEDA, do **not** set `scaling.autoscaling` or `spec.replicas > 1` -- KEDA manages the replica count through the scale sub-resource.
125
+
126
+
1. **Ensure DB-backed persistence** -- The CRD's CEL validation rules automatically enforce DB-backed persistence when KEDA scales `spec.replicas` above 1 via the scale sub-resource. The operator also automatically switches the deployment strategy to `RollingUpdate` when `replicas > 1`.
127
+
128
+
2. **Configure the FeatureStore** with DB-backed persistence:
129
+
130
+
```yaml
131
+
apiVersion: feast.dev/v1
132
+
kind: FeatureStore
133
+
metadata:
134
+
name: sample-keda
135
+
spec:
136
+
feastProject: my_project
137
+
services:
138
+
onlineStore:
139
+
persistence:
140
+
store:
141
+
type: postgres
142
+
secretRef:
143
+
name: feast-data-stores
144
+
registry:
145
+
local:
146
+
persistence:
147
+
store:
148
+
type: sql
149
+
secretRef:
150
+
name: feast-data-stores
151
+
```
152
+
153
+
3. **Create a KEDA `ScaledObject`** targeting the FeatureStore resource:
KEDA-created HPAs are not owned by the Feast operator. The operator will not interfere with them, but it also will not clean them up if the FeatureStore CR is deleted. You must manage the KEDA `ScaledObject` lifecycle independently.
178
+
{% endhint %}
179
+
180
+
For the full API reference, see the [FeatureStore CRD reference](../../infra/feast-operator/docs/api/markdown/ref.md).
// FeastProject is the Feast project id. This can be any alphanumeric string with underscores and hyphens, but it cannot start with an underscore or hyphen. Required.
// Volumes specifies the volumes to mount in the FeatureStore deployment. A corresponding `VolumeMount` should be added to whichever feast service(s) require access to said volume(s).
303
313
Volumes []corev1.Volume`json:"volumes,omitempty"`
314
+
// Scaling configures horizontal scaling for the FeatureStore deployment (e.g. HPA autoscaling).
315
+
// For static replicas, use spec.replicas instead.
316
+
Scaling*ScalingConfig`json:"scaling,omitempty"`
317
+
}
318
+
319
+
// ScalingConfig configures horizontal scaling for the FeatureStore deployment.
320
+
typeScalingConfigstruct {
321
+
// Autoscaling configures a HorizontalPodAutoscaler for the FeatureStore deployment.
0 commit comments