examples/operator-postgres-tls-demo/02-Install-feast.ipynb
Provide a reference implementation of a runbook to deploy a Feast environment on a Kubernetes cluster using Kind and the Feast Operator.
## Use this install command from a release branch (e.g. 'v0.46-branch')
!kubectl apply -f ../../infra/feast-operator/dist/install.yaml
## OR, for the latest code/builds, use one the following commands from the 'master' branch
# !make -C ../../infra/feast-operator install deploy IMG=quay.io/feastdev-ci/feast-operator:develop FS_IMG=quay.io/feastdev-ci/feature-server:develop
# !make -C ../../infra/feast-operator install deploy IMG=quay.io/feastdev-ci/feast-operator:$(git rev-parse HEAD) FS_IMG=quay.io/feastdev-ci/feature-server:$(git rev-parse HEAD)
!kubectl wait --for=condition=available --timeout=5m deployment/feast-operator-controller-manager -n feast-operator-system
Next, we'll use the running Feast Operator to install the feast services. Before doing that it is important to understand basic understanding of operator support of Volumes and volumeMounts and how to mount TLS certificates.
The Feast operator supports volumes and volumeMounts, allowing you to mount TLS certificates onto a pod. This approach provides flexibility in how you mount these files, supporting different Kubernetes resources such as Secrets, ConfigMaps, and Persistent Volumes (PVs).
In this example, we demonstrate how to mount TLS certificates using Kubernetes Secrets that were created in a previous notebook.
When connecting to PostgreSQL with TLS, some important parameters in the connection URL are:
sslrootcert – Specifies the path to the CA certificate file used to validate trusted certificates.sslcert – Provides the client certificate for mutual TLS (mTLS) encryption.sslkey – Specifies the private key for the client certificate.If mutual TLS authentication is not required, you can omit the sslcert and sslkey parameters. However, the sslrootcert parameter is still necessary for validating server certificates.
<b><font color=red> Note: Please deploy either option 1 or 2 only. Don't deploy both of them at the same time to avoid conflicts in the lateral steps. </font></b>
Option 1: Directly Setting the CA Certificate Path
In this approach, we specify the CA certificate path directly in the Feast PostgreSQL URL using the sslrootcert parameter.
You can refer to the v1_featurestore_postgres_db_volumes_tls.yaml file for the complete configuration details.
!kubectl apply -f ../../infra/feast-operator/config/samples/v1_featurestore_postgres_db_volumes_tls.yaml --namespace=feast
Option 2: Using an Environment Variable for the CA Certificate
In this approach, you define the CA certificate path as an environment variable. You can refer to the v1_featurestore_postgres_tls_volumes_ca_env.yaml file for the complete configuration details.
FEAST_CA_CERT_FILE_PATH=<path-to-ca-cert>
```python
!kubectl apply -f ../../infra/feast-operator/config/samples/v1_featurestore_postgres_tls_volumes_ca_env.yaml --namespace=feast
Validate the deployment status.
!kubectl wait --for=condition=available --timeout=8m deployment/feast-sample-db-ssl -n feast
!kubectl get all
Validate that the FeatureStore CR is in a Ready state.
!kubectl get feast
Verify that the DB includes the expected tables.
!kubectl exec postgresql-0 -- env PGPASSWORD=password psql -U admin -d feast -c '\dt'
Verify the client feature_store.yaml and create the sample feature store definitions.
!kubectl exec deploy/feast-sample-db-ssl -c online -- cat feature_store.yaml
!kubectl exec deploy/feast-sample-db-ssl -c online -- feast apply
print(" Feast apply is completed. You can go to next step.")
List the registered feast projects & feature views.
!kubectl exec deploy/feast-sample-db-ssl -c online -- feast projects list
!kubectl exec deploy/feast-sample-db-ssl -c online -- feast feature-views list
Finally, let's verify the feast version.
!kubectl exec deployment/feast-sample-db-ssl -c online -- feast version