Installing Required Dependencies (Valkey and PostgreSQL)
To enable data caching and transactional storage capabilities for UnO Agentic AI Builder, you must install Valkey and the Percona PostgreSQL Operator in your Kubernetes cluster.
v2.1.6+Prerequisite: Adding Helm Repositories
helm repo add valkey https://valkey.io/valkey-helm/
helm repo add percona https://percona.github.io/percona-helm-chartsAfter adding the repositories, run helm repo update to synchronize
your local chart cache.
Procedure: Installing the Dependencies
Step 1: Initialize Valkey and Percona Postgres Operator
Run the following commands to create the Valkey credentials secret and install the foundational runtime charts:
kubectl -n "$NS" create secret generic valkey-password-secret \
--from-literal=password='changeit' && \
helm upgrade --install valkey valkey/valkey \
-n "$NS" \
--version 0.9.4 \
--set architecture=standalone \
--set auth.enabled=true \
--set auth.usersExistingSecret=valkey-password-secret \
--set auth.aclUsers.default.passwordKey=password \
--set auth.aclUsers.default.permissions="~* &* +@all" \
--set dataStorage.enabled=true \
--set dataStorage.requestedSize=8Gi \
--set dataStorage.keepPvc=true
helm install pg-operator percona/pg-operator \
--version 2.8.0 \
-n "$NS"
Note: The pg-operator is installed automatically in the same namespace specified by `-n "$NS"`
- Replace
<namespace>with the Kubernetes namespace where you want the components installed. - The value
changeitis used as the Valkey password in this example. - To automatically install the database, ensure that the Helm chart variable
global.postgres.usePerconais set to true (this is the default).
Step 2: Configure Percona PostgreSQL Operator Scope
To enable full PostgreSQL orchestration support for UnO Agentic AI Builder, choose one of the following operational namespace scopes for your operator deployment:
Option 1: Watch a Specific Namespace
Use this option if the operator should manage PostgreSQL clusters only in a single namespace.
helm install pg-operator percona/pg-operator \
--version 2.8.0 \
-n <namespace> --set watchNamespace="$NS"
Option 2: Watch All Namespaces
Use this option if the operator should manage PostgreSQL clusters across all namespaces.
helm install pg-operator percona/pg-operator \
--version 2.8.0 \
-n <namespace> --set watchAllNamespaces=true
Results
The baseline external database dependencies are registered. Both Valkey and the Percona PostgreSQL Operator are configured and ready to service the primary application workloads.
For more details, see the official Helm chart documentation: https://artifacthub.io/packages/helm/percona/pg-operator
v2.1.6+
PostgreSQL Password Configuration Changes
values.yaml file are commented out by
default:# The password for the postgres user. If no value is defined, the chart
# automatically generates a password and stores it in a secret named
# {{ .Release.Name }}-postgres-password.
#postgresPassword: ""
#postgresPasswordSecretName: '{{ .Release.Name }}-postgres-password'
#postgresPasswordSecretKey: "password"To maintain your existing database connection during the migration, you must apply one of
the following three configuration methods before running the helm
upgrade command.
Method 1: Pre-create the Default Helm Secret (Recommended)
This approach keeps the values.yaml file clean and commented out by
supplying the credentials externally beforehand.
-
Manually create a Kubernetes Secret in your target namespace. The name properties must match the release pattern exactly:
-
Secret Name:
<your-release-name>-postgres-password -
Data Key:
password -
Value:
<your-existing-database-password>
-
-
In your
values.yamlfile, leave all PostgreSQL password configuration blocks commented out. -
The Helm chart automatically detects and binds to this secret, utilizing the existing password instead of generating a new one.
Method 2: Use a Custom Existing Kubernetes Secret
Use this method if you prefer to store database passwords in a pre-existing secret with a custom naming convention.
-
Ensure the target Kubernetes Secret containing your database password exists in the namespace.
-
Open the
values.yamlfile, uncomment the secret configuration lines, and specify the custom properties:postgresPasswordSecretName: "your-custom-secret-name" postgresPasswordSecretKey: "password" -
Keep the
#postgresPassword: ""line commented out.
Method 3: Explicitly Define the Password in values.yaml
Use this method to maintain a hardcoded password configuration within your deployment parameters.
-
Open the
values.yamlfile and uncomment thepostgresPasswordproperty block. -
Provide your existing database password string directly:
postgresPassword: "your-old-password-here"
Next Step: Once you have secured your PostgreSQL password configuration using
one of the methods above, proceed with executing the helm upgrade
command for the deployment.