|
64 | 64 |
|
65 | 65 | > _More advanced FeatureStore CR examples can be found in the feast-operator [samples directory](../../infra/feast-operator/config/samples)._ |
66 | 66 |
|
| 67 | +## Upgrading the Operator |
| 68 | +
|
| 69 | +### OLM-managed installations |
| 70 | +
|
| 71 | +If the operator was installed via OLM, upgrades are handled |
| 72 | +automatically. No manual steps are required — OLM recreates the operator Deployment |
| 73 | +during the upgrade process. |
| 74 | +
|
| 75 | +### kubectl-managed installations |
| 76 | +
|
| 77 | +For most upgrades, re-running the install command is sufficient: |
| 78 | +
|
| 79 | +```sh |
| 80 | +kubectl apply --server-side --force-conflicts -f https://raw.githubusercontent.com/feast-dev/feast/refs/heads/stable/infra/feast-operator/dist/install.yaml |
| 81 | +``` |
| 82 | + |
| 83 | +#### One-time step: upgrading from versions before 0.61.0 |
| 84 | + |
| 85 | +Version 0.61.0 updated the operator Deployment's `spec.selector` to include the |
| 86 | +`app.kubernetes.io/name: feast-operator` label, fixing a bug where the metrics service |
| 87 | +could accidentally target pods from other operators in shared namespaces. |
| 88 | + |
| 89 | +Because Kubernetes treats `spec.selector` as an immutable field, upgrading directly from |
| 90 | +a pre-0.61.0 version with `kubectl apply` will fail with: |
| 91 | + |
| 92 | +``` |
| 93 | +The Deployment "feast-operator-controller-manager" is invalid: spec.selector: Invalid value: ... field is immutable |
| 94 | +``` |
| 95 | + |
| 96 | +To resolve this, delete the existing operator Deployment before applying the new manifest: |
| 97 | + |
| 98 | +```sh |
| 99 | +kubectl delete deployment feast-operator-controller-manager -n feast-operator-system --ignore-not-found=true |
| 100 | +kubectl apply --server-side --force-conflicts -f https://raw.githubusercontent.com/feast-dev/feast/refs/heads/stable/infra/feast-operator/dist/install.yaml |
| 101 | +``` |
| 102 | + |
| 103 | +This is only required once. Existing FeatureStore CRs and their managed workloads (feature |
| 104 | +servers, registry, etc.) are not affected — the new operator pod will reconcile them |
| 105 | +automatically on startup. Future upgrades from 0.61.0 onward will not require this step. |
| 106 | + |
67 | 107 | {% hint style="success" %} |
68 | 108 | **Scaling & High Availability:** 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 | 109 |
|
|
0 commit comments