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

Before installing Valkey and the Percona PostgreSQL Operator, add the official Percona and Valkey Helm repositories to your environment:
helm repo add valkey https://valkey.io/valkey-helm/
helm repo add percona https://percona.github.io/percona-helm-charts

After 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"`
Note:
  1. Replace <namespace> with the Kubernetes namespace where you want the components installed.
  2. The value changeit is used as the Valkey password in this example.
  3. To automatically install the database, ensure that the Helm chart variable global.postgres.usePercona is 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

In version 2.1.6.0, the PostgreSQL password parameters in the 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"
Note: Previously, the postgresPassword parameter was explicitly hardcoded. If these fields are left commented out without further configuration during an upgrade, the Helm chart automatically generates a new, random password. This mismatch severs the connection to your existing database and causes application deployment failures.
Note: If you are upgrading from an older deployment, you must also migrate your key-value store architecture. For detailed steps, see Migrating from Bitnami Valkey to Official Valkey Chart

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.

  1. 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>

  2. In your values.yaml file, leave all PostgreSQL password configuration blocks commented out.

  3. 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.

  1. Ensure the target Kubernetes Secret containing your database password exists in the namespace.

  2. Open the values.yaml file, uncomment the secret configuration lines, and specify the custom properties:
    postgresPasswordSecretName: "your-custom-secret-name"
    postgresPasswordSecretKey: "password"
  3. 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.

  1. Open the values.yaml file and uncomment the postgresPassword property block.

  2. 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.