Feast on Kubernetes

This page covers deploying Feast on Kubernetes, including the Feast Operator and feature servers.

Overview

Kubernetes is a common target environment for running Feast in production. You can use Kubernetes to:

  1. Run Feast feature servers for online feature retrieval.

  2. Run scheduled and ad-hoc jobs (e.g. materialization jobs) as Kubernetes Jobs.

  3. Operate Feast components using Kubernetes-native primitives.

circle-info

Planning a production deployment? See the Feast Production Deployment Topologies guide for architecture diagrams, sample FeatureStore CRs, RBAC policies, infrastructure recommendations, and scaling best practices across Minimal, Standard, and Enterprise topologies.

Feast Operator

To deploy Feast components on Kubernetes, use the included feast-operatorarrow-up-right.

For first-time Operator users, it may be a good exercise to try the Feast Operator Quickstartarrow-up-right. The quickstart demonstrates some of the Operator's built-in features, e.g. git repos, feast apply jobs, etc.

Deploy Feast feature servers on Kubernetes

Basic steps

  1. Install the Operator

Install the latest release:

OR, install a specific version:

  1. Deploy a Feature Store

Verify the status:

The above will install a simple FeatureStore CRarrow-up-right like the following. By default, it will run the Online Store feature server:

More advanced FeatureStore CR examples can be found in the feast-operator samples directoryarrow-up-right.

Upgrading the Operator

OLM-managed installations

If the operator was installed via OLM, upgrades are handled automatically. No manual steps are required — OLM recreates the operator Deployment during the upgrade process.

kubectl-managed installations

For most upgrades, re-running the install command is sufficient:

One-time step: upgrading from versions before 0.61.0

Version 0.61.0 updated the operator Deployment's spec.selector to include the app.kubernetes.io/name: feast-operator label, fixing a bug where the metrics service could accidentally target pods from other operators in shared namespaces.

Because Kubernetes treats spec.selector as an immutable field, upgrading directly from a pre-0.61.0 version with kubectl apply will fail with:

To resolve this, delete the existing operator Deployment before applying the new manifest:

This is only required once. Existing FeatureStore CRs and their managed workloads (feature servers, registry, etc.) are not affected — the new operator pod will reconcile them automatically on startup. Future upgrades from 0.61.0 onward will not require this step.

circle-check

Sample scaling CRs are available at v1_featurestore_scaling_static.yamlarrow-up-right and v1_featurestore_scaling_hpa.yamlarrow-up-right.

Last updated

Was this helpful?