External DB Integration
Waldur Helm can use an external PostgreSQL deployed within the same Kubernetes cluster using PostgreSQL operators.
Supported PostgreSQL Operators
For production deployments, see the comprehensive PostgreSQL Operators documentation which covers:
-
CloudNativePG ⭐ Recommended for new deployments
-
Zalando PostgreSQL Operator For existing deployments or specific use cases
Configuration Variables
To use external PostgreSQL, set the following variables in values.yaml:
-
externalDB.enabled- toggler for integration; requirespostgresql.enabledandpostgresqlha.enabledto befalse -
externalDB.secretName- name of the secret with PostgreSQL credentials for Waldur user -
externalDB.serviceName- name of the service linked to PostgreSQL primary/master -
externalDB.database- custom database name (optional, defaults to "waldur") -
externalDB.username- custom username (optional, defaults to "waldur")
CloudNativePG Integration Example
For CloudNativePG clusters, use this configuration:
1 2 3 4 5 6 | |
CloudNativePG Secret Management: CloudNativePG automatically creates secrets with predictable naming:
-
[cluster-name]-app- Application credentials (recommended for Waldur) -
[cluster-name]-superuser- Administrative credentials (disabled by default)
Each secret contains username, password, database name, host, port, and connection URIs.
Note: Replace waldur-postgres with your actual CloudNativePG cluster name. See the PostgreSQL Operators guide for complete setup instructions.
Zalando Integration Example
Zalando-managed PostgreSQL cluster example:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | |
Then configure Waldur to use this cluster:
1 2 3 4 5 6 | |
Backup setup
Enable backups for a cluster with the following addition to a manifest file:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 | |
You also need to create a secret file with the credentials for the storage:
1 2 3 4 5 6 7 8 9 10 11 12 | |
Trigger a base backup manually
Connect to the leader PSQL pod and execute the following commands:
1 2 3 4 5 6 7 8 9 10 11 12 13 | |
Restore DB from backup
The preferable option is creation a new instance of PostgreSQL cluster cloning data from the original one.
For this, create a manifest with the following content:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 | |
Then, apply the manifest to the cluster, change externalDB.{secretName, serviceName} after DB bootstrap and upgrade Waldur release.
Migration Recommendations
For New Deployments
-
Use CloudNativePG for modern Kubernetes-native PostgreSQL management
-
Follow the PostgreSQL Operators guide for complete setup
For Existing Zalando Deployments
-
Continue using Zalando if stable and meeting requirements
-
Consider migration to CloudNativePG for long-term benefits:
-
Active development and community support
-
Modern Kubernetes-native architecture
-
Enhanced monitoring and backup capabilities
-
Better integration with cloud-native ecosystem
Migration Process
-
Backup existing data using
pg_dump -
Deploy new operator cluster (CloudNativePG or updated Zalando)
-
Restore data using
pg_restore -
Update Waldur configuration to use new cluster
-
Test thoroughly before decommissioning old cluster
Support and Documentation
-
CloudNativePG: PostgreSQL Operators documentation
-
Zalando Operator: Official Zalando docs
-
General guidance: Both operators are covered in the PostgreSQL Operators guide