Bitnami package for PostgreSQL

PostgreSQL (Postgres) is an open source object-relational database known for reliability and data integrity. ACID-compliant, it supports foreign keys, joins, views, triggers and stored procedures.

Overview of PostgreSQL

Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.

TL;DR

helm install my-release oci://registry-1.docker.io/bitnamicharts/postgresql

Looking to use PostgreSQL in production? Try VMware Tanzu Application Catalog, the enterprise edition of Bitnami Application Catalog.

Introduction

This chart bootstraps a PostgreSQL deployment on a Kubernetes cluster using the Helm package manager.

For HA, please see this repo

Bitnami charts can be used with Kubeapps for deployment and management of Helm Charts in clusters.

Prerequisites

• Kubernetes 1.23+
• Helm 3.8.0+
• PV provisioner support in the underlying infrastructure

Installing the Chart

To install the chart with the release name my-release:

helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/postgresql

Note: You need to substitute the placeholders REGISTRY_NAME and REPOSITORY_NAME with a reference to your Helm chart registry and repository. For example, in the case of Bitnami, you need to use REGISTRY_NAME=registry-1.docker.io and REPOSITORY_NAME=bitnamicharts.

The command deploys PostgreSQL on the Kubernetes cluster in the default configuration. The Parameters section lists the parameters that can be configured during installation.

Tip: List all releases using helm list

Configuration and installation details

Resource requests and limits

Bitnami charts allow setting resource requests and limits for all containers inside the chart deployment. These are inside the resources value (check parameter table). Setting requests is essential for production workloads and these should be adapted to your specific use case.

To make this process easier, the chart contains the resourcesPreset values, which automatically sets the resources section according to different presets. Check these presets in the bitnami/common chart. However, in production workloads using resourcePreset is discouraged as it may not fully adapt to your specific needs. Find more information on container resource management in the official Kubernetes documentation.

Rolling VS Immutable tags

It is strongly recommended to use immutable tags in a production environment. This ensures your deployment does not change automatically if the same tag is updated with a different image.

Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.

Customizing primary and read replica services in a replicated configuration

At the top level, there is a service object which defines the services for both primary and readReplicas. For deeper customization, there are service objects for both the primary and read types individually. This allows you to override the values in the top level service object so that the primary and read can be of different service types and with different clusterIPs / nodePorts. Also in the case you want the primary and read to be of type nodePort, you will need to set the nodePorts to different values to prevent a collision. The values that are deeper in the primary.service or readReplicas.service objects will take precedence over the top level service object.

Use a different PostgreSQL version

To modify the application version used in this chart, specify a different version of the image using the image.tag parameter and/or a different repository using the image.repository parameter.

LDAP

LDAP support can be enabled in the chart by specifying the ldap. parameters while creating a release. The following parameters should be configured to properly enable the LDAP support in the chart.

• ldap.enabled: Enable LDAP support. Defaults to false.
• ldap.uri: LDAP URL beginning in the form ldap[s]://<hostname>:<port>. No defaults.
• ldap.base: LDAP base DN. No defaults.
• ldap.binddn: LDAP bind DN. No defaults.
• ldap.bindpw: LDAP bind password. No defaults.
• ldap.bslookup: LDAP base lookup. No defaults.
• ldap.nss_initgroups_ignoreusers: LDAP ignored users. root,nslcd.
• ldap.scope: LDAP search scope. No defaults.
• ldap.tls_reqcert: LDAP TLS check on server certificates. No defaults.

For example:

ldap.enabled="true"
ldap.uri="ldap://my_ldap_server"
ldap.base="dc=example\,dc=org"
ldap.binddn="cn=admin\,dc=example\,dc=org"
ldap.bindpw="admin"
ldap.bslookup="ou=group-ok\,dc=example\,dc=org"
ldap.nss_initgroups_ignoreusers="root\,nslcd"
ldap.scope="sub"
ldap.tls_reqcert="demand"

Next, login to the PostgreSQL server using the psql client and add the PAM authenticated LDAP users.

Note: Parameters including commas must be escaped as shown in the above example.

postgresql.conf / pg_hba.conf files as configMap

This helm chart also supports to customize the PostgreSQL configuration file. You can add additional PostgreSQL configuration parameters using the primary.extendedConfiguration/readReplicas.extendedConfiguration parameters as a string. Alternatively, to replace the entire default configuration use primary.configuration.

You can also add a custom pg_hba.conf using the primary.pgHbaConfiguration parameter.

In addition to these options, you can also set an external ConfigMap with all the configuration files. This is done by setting the primary.existingConfigmap parameter. Note that this will override the two previous options.

Initialize a fresh instance

The Bitnami PostgreSQL image allows you to use your custom scripts to initialize a fresh instance. In order to execute the scripts, you can specify custom scripts using the primary.initdb.scripts parameter as a string.

In addition, you can also set an external ConfigMap with all the initialization scripts. This is done by setting the primary.initdb.scriptsConfigMap parameter. Note that this will override the two previous options. If your initialization scripts contain sensitive information such as credentials or passwords, you can use the primary.initdb.scriptsSecret parameter.

The allowed extensions are .sh, .sql and .sql.gz.

Securing traffic using TLS

TLS support can be enabled in the chart by specifying the tls. parameters while creating a release. The following parameters should be configured to properly enable the TLS support in the chart:

• tls.enabled: Enable TLS support. Defaults to false
• tls.certificatesSecret: Name of an existing secret that contains the certificates. No defaults.
• tls.certFilename: Certificate filename. No defaults.
• tls.certKeyFilename: Certificate key filename. No defaults.

For example:

• First, create the secret with the cetificates files:

  kubectl create secret generic certificates-tls-secret --from-file=./cert.crt --from-file=./cert.key --from-file=./ca.crt
  

• Then, use the following parameters:

  volumePermissions.enabled=true
  tls.enabled=true
  tls.certificatesSecret="certificates-tls-secret"
  tls.certFilename="cert.crt"
  tls.certKeyFilename="cert.key"
  

  Note TLS and VolumePermissions: PostgreSQL requires certain permissions on sensitive files (such as certificate keys) to start up. Due to an on-going issue regarding kubernetes permissions and the use of containerSecurityContext.runAsUser, you must enable volumePermissions to ensure everything works as expected.

Sidecars

If you need additional containers to run within the same pod as PostgreSQL (e.g. an additional metrics or logging exporter), you can do so via the sidecars config parameter. Simply define your container according to the Kubernetes container spec.

# For the PostgreSQL primary
primary:
  sidecars:
  - name: your-image-name
    image: your-image
    imagePullPolicy: Always
    ports:
    - name: portname
     containerPort: 1234
# For the PostgreSQL replicas
readReplicas:
  sidecars:
  - name: your-image-name
    image: your-image
    imagePullPolicy: Always
    ports:
    - name: portname
     containerPort: 1234

Metrics

The chart optionally can start a metrics exporter for prometheus. The metrics endpoint (port 9187) is not exposed and it is expected that the metrics are collected from inside the k8s cluster using something similar as the described in the example Prometheus scrape configuration.

The exporter allows to create custom metrics from additional SQL queries. See the Chart's values.yaml for an example and consult the exporters documentation for more details.

Use of global variables

In more complex scenarios, we may have the following tree of dependencies

                     +--------------+
                     |              |
        +------------+   Chart 1    +-----------+
        |            |              |           |
        |            --------+------+           |
        |                    |                  |
        |                    |                  |
        |                    |                  |
        |                    |                  |
        v                    v                  v
+-------+------+    +--------+------+  +--------+------+
|              |    |               |  |               |
|  PostgreSQL  |    |  Sub-chart 1  |  |  Sub-chart 2  |
|              |    |               |  |               |
+--------------+    +---------------+  +---------------+

The three charts below depend on the parent chart Chart 1. However, subcharts 1 and 2 may need to connect to PostgreSQL as well. In order to do so, subcharts 1 and 2 need to know the PostgreSQL credentials, so one option for deploying could be deploy Chart 1 with the following parameters:

postgresql.auth.username=testuser
subchart1.postgresql.auth.username=testuser
subchart2.postgresql.auth.username=testuser
postgresql.auth.password=testpass
subchart1.postgresql.auth.password=testpass
subchart2.postgresql.auth.password=testpass
postgresql.auth.database=testdb
subchart1.postgresql.auth.database=testdb
subchart2.postgresql.auth.database=testdb

If the number of dependent sub-charts increases, installing the chart with parameters can become increasingly difficult. An alternative would be to set the credentials using global variables as follows:

global.postgresql.auth.username=testuser
global.postgresql.auth.password=testpass
global.postgresql.auth.database=testdb

This way, the credentials will be available in all of the subcharts.

Backup and restore PostgreSQL deployments

To back up and restore Bitnami PostgreSQL Helm chart deployments on Kubernetes, you need to back up the persistent volumes from the source deployment and attach them to a new deployment using Velero, a Kubernetes backup/restore tool.

These are the steps you will usually follow to back up and restore your PostgreSQL cluster data:

• Install Velero on the source and destination clusters.
• Use Velero to back up the PersistentVolumes (PVs) used by the deployment on the source cluster.
• Use Velero to restore the backed-up PVs on the destination cluster.
• Create a new deployment on the destination cluster with the same chart, deployment name, credentials and other parameters as the original. This new deployment will use the restored PVs and hence the original data.

Refer to our detailed tutorial on backing up and restoring PostgreSQL deployments on Kubernetes for more information.

NetworkPolicy

To enable network policy for PostgreSQL, install a networking plugin that implements the Kubernetes NetworkPolicy spec, and set networkPolicy.enabled to true.

For Kubernetes v1.5 & v1.6, you must also turn on NetworkPolicy by setting the DefaultDeny namespace annotation. Note: this will enforce policy for all pods in the namespace:

kubectl annotate namespace default "net.beta.kubernetes.io/network-policy={\"ingress\":{\"isolation\":\"DefaultDeny\"}}"

With NetworkPolicy enabled, traffic will be limited to just port 5432.

For more precise policy, set networkPolicy.allowExternal=false. This will only allow pods with the generated client label to connect to PostgreSQL. This label will be displayed in the output of a successful install.

Differences between Bitnami PostgreSQL image and Docker Official image

• The Docker Official PostgreSQL image does not support replication. If you pass any replication environment variable, this would be ignored. The only environment variables supported by the Docker Official image are POSTGRES_USER, POSTGRES_DB, POSTGRES_PASSWORD, POSTGRES_INITDB_ARGS, POSTGRES_INITDB_WALDIR and PGDATA. All the remaining environment variables are specific to the Bitnami PostgreSQL image.
• The Bitnami PostgreSQL image is non-root by default. This requires that you run the pod with securityContext and updates the permissions of the volume with an initContainer. A key benefit of this configuration is that the pod follows security best practices and is prepared to run on Kubernetes distributions with hard security constraints like OpenShift.
• For OpenShift up to 4.10, let set the volume permissions, security context, runAsUser and fsGroup automatically by OpenShift and disable the predefined settings of the helm chart: primary.securityContext.enabled=false,primary.containerSecurityContext.enabled=false,volumePermissions.enabled=false,shmVolume.enabled=false
• For OpenShift 4.11 and higher, let set OpenShift the runAsUser and fsGroup automatically. Configure the pod and container security context to restrictive defaults and disable the volume permissions setup: primary. podSecurityContext.fsGroup=null,primary.podSecurityContext.seccompProfile.type=RuntimeDefault,primary.containerSecurityContext.runAsUser=null,primary.containerSecurityContext.allowPrivilegeEscalation=false,primary.containerSecurityContext.runAsNonRoot=true,primary.containerSecurityContext.seccompProfile.type=RuntimeDefault,primary.containerSecurityContext.capabilities.drop=['ALL'],volumePermissions.enabled=false,shmVolume.enabled=false

Setting Pod's affinity

This chart allows you to set your custom affinity using the XXX.affinity parameter(s). Find more information about Pod's affinity in the kubernetes documentation.

As an alternative, you can use of the preset configurations for pod affinity, pod anti-affinity, and node affinity available at the bitnami/common chart. To do so, set the XXX.podAffinityPreset, XXX.podAntiAffinityPreset, or XXX.nodeAffinityPreset parameters.

Persistence

The Bitnami PostgreSQL image stores the PostgreSQL data and configurations at the /bitnami/postgresql path of the container.

Persistent Volume Claims are used to keep the data across deployments. This is known to work in GCE, AWS, and minikube. See the Parameters section to configure the PVC or to disable persistence.

If you already have data in it, you will fail to sync to standby nodes for all commits, details can refer to the code present in the container repository. If you need to use those data, please covert them to sql and import after helm install finished.

Parameters

Global parameters

Common parameters

PostgreSQL common parameters

PostgreSQL Primary parameters

PostgreSQL read only replica parameters (only used when architecture is set to replication)

Backup parameters

Volume Permissions parameters

Other Parameters

Metrics Parameters

Specify each parameter using the --set key=value[,key=value] argument to helm install. For example,

helm install my-release \
    --set auth.postgresPassword=secretpassword
    oci://REGISTRY_NAME/REPOSITORY_NAME/postgresql

Note: You need to substitute the placeholders REGISTRY_NAME and REPOSITORY_NAME with a reference to your Helm chart registry and repository. For example, in the case of Bitnami, you need to use REGISTRY_NAME=registry-1.docker.io and REPOSITORY_NAME=bitnamicharts.

The above command sets the PostgreSQL postgres account password to secretpassword.

NOTE: Once this chart is deployed, it is not possible to change the application's access credentials, such as usernames or passwords, using Helm. To change these application credentials after deployment, delete any persistent volumes (PVs) used by the chart and re-deploy it, or use the application's built-in administrative tools if available. Warning Setting a password will be ignored on new installation in case when previous PostgreSQL release was deleted through the helm command. In that case, old PVC will have an old password, and setting it through helm won't take effect. Deleting persistent volumes (PVs) will solve the issue. Refer to issue 2061 for more details

Alternatively, a YAML file that specifies the values for the parameters can be provided while installing the chart. For example,

helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/postgresql

Note: You need to substitute the placeholders REGISTRY_NAME and REPOSITORY_NAME with a reference to your Helm chart registry and repository. For example, in the case of Bitnami, you need to use REGISTRY_NAME=registry-1.docker.io and REPOSITORY_NAME=bitnamicharts. Tip: You can use the default values.yaml

Troubleshooting

Find more information about how to deal with common errors related to Bitnami's Helm charts in this troubleshooting guide.

Upgrading

To 15.0.0

This major bump changes the following security defaults:

• runAsGroup is changed from 0 to 1001
• readOnlyRootFilesystem is set to true
• resourcesPreset is changed from none to the minimum size working in our test suites (NOTE: resourcesPreset is not meant for production usage, but resources adapted to your use case).
• global.compatibility.openshift.adaptSecurityContext is changed from disabled to auto.

This could potentially break any customization or init scripts used in your deployment. If this is the case, change the default values to the previous ones.

To 14.0.0

This major version adapts the NetworkPolicy objects to the most recent Bitnami standards. Now there is a separate object for primary and for readReplicas, being located in their corresponding sections. It is also enabled by default in other to comply with the best security standards.

Check the parameter section for the new value structure.

To 13.0.0

This major version changes the default PostgreSQL image from 15.x to 16.x. Follow the official instructions to upgrade to 16.x.

To 12.0.0

This major version changes the default PostgreSQL image from 14.x to 15.x. Follow the official instructions to upgrade to 15.x.

To 11.0.0

In this version the application version was bumped to 14.x series. Also, this major release renames several values in this chart and adds missing features, in order to be inline with the rest of assets in the Bitnami charts repository.

• replication.enabled parameter is deprecated in favor of architecture parameter that accepts two values: standalone and replication.
• replication.singleService and replication.uniqueServices parameters are deprecated. When using replication, each statefulset (primary and read-only) has its own headless service & service allowing to connect to read-only replicas through the service (round-robin) or individually.
• postgresqlPostgresPassword, postgresqlUsername, postgresqlPassword, postgresqlDatabase, replication.user, replication.password, and existingSecret parameters have been regrouped under the auth map. The auth map uses a new perspective to configure authentication, so please read carefully each sub-parameter description.
• extraEnv has been deprecated in favor of primary.extraEnvVars and readReplicas.extraEnvVars.
• postgresqlConfiguration, pgHbaConfiguration, configurationConfigMap, postgresqlExtendedConf, and extendedConfConfigMap have been deprecated in favor of primary.configuration, primary.pgHbaConfiguration, primary.existingConfigmap, primary.extendedConfiguration, and primary.existingExtendedConfigmap.
• postgresqlInitdbArgs, postgresqlInitdbWalDir, initdbScripts, initdbScriptsConfigMap, initdbScriptsSecret, initdbUser and initdbPassword have been regrouped under the primary.initdb map.
• postgresqlMaxConnections, postgresqlPostgresConnectionLimit, postgresqlDbUserConnectionLimit, postgresqlTcpKeepalivesInterval, postgresqlTcpKeepalivesIdle, postgresqlTcpKeepalivesCount, postgresqlStatementTimeout and postgresqlPghbaRemoveFilters parameters are deprecated. Use XXX.extraEnvVars instead.
• primaryAsStandBy has been deprecated in favor of primary.standby.
• securityContext and containerSecurityContext have been deprecated in favor of primary.podSecurityContext, primary.containerSecurityContext, readReplicas.podSecurityContext, and readReplicas.containerSecurityContext.
• livenessProbe and readinessProbe maps have been deprecated in favor of primary.livenessProbe, primary.readinessProbe, readReplicas.livenessProbe and readReplicas.readinessProbe maps.
• persistence map has been deprecated in favor of primary.persistence and readReplicas.persistence maps.
• networkPolicy map has been completely refactored.
• service map has been deprecated in favor of primary.service and readReplicas.service maps.
• metrics.service.port has been regrouped under the metrics.service.ports map.
• serviceAccount.enabled and serviceAccount.autoMount have been deprecated in favor of serviceAccount.create and serviceAccount.automountServiceAccountToken.

How to upgrade to version 11.0.0

To upgrade to 11.0.0 from 10.x, it should be done reusing the PVC(s) used to hold the PostgreSQL data on your previous release. To do so, follow the instructions below (the following example assumes that the release name is postgresql):

NOTE: Please, create a backup of your database before running any of these actions.

1. Obtain the credentials and the names of the PVCs used to hold the PostgreSQL data on your current release:

export POSTGRESQL_PASSWORD=$(kubectl get secret --namespace default postgresql -o jsonpath="{.data.postgresql-password}" | base64 --decode)
export POSTGRESQL_PVC=$(kubectl get pvc -l app.kubernetes.io/instance=postgresql,role=primary -o jsonpath="{.items[0].metadata.name}")

1. Delete the PostgreSQL statefulset (notice the option --cascade=false) and secret:

kubectl delete statefulsets.apps postgresql-postgresql --namespace default --cascade=false
kubectl delete secret postgresql --namespace default

1. Upgrade your release using the same PostgreSQL version:

CURRENT_VERSION=$(kubectl exec postgresql-postgresql-0 -- bash -c 'echo $BITNAMI_IMAGE_VERSION')
helm upgrade postgresql bitnami/postgresql \
  --set auth.postgresPassword=$POSTGRESQL_PASSWORD \
  --set primary.persistence.existingClaim=$POSTGRESQL_PVC \
  --set image.tag=$CURRENT_VERSION

1. You will have to delete the existing PostgreSQL pod and the new statefulset is going to create a new one

kubectl delete pod postgresql-postgresql-0

1. Finally, you should see the lines below in PostgreSQL container logs:

$ kubectl logs $(kubectl get pods -l app.kubernetes.io/instance=postgresql,app.kubernetes.io/name=postgresql,app.kubernetes.io/component=primary -o jsonpath="{.items[0].metadata.name}")
...
postgresql 08:05:12.59 INFO  ==> Deploying PostgreSQL with persisted data...
...

NOTE: the instructions above reuse the same PostgreSQL version you were using in your chart release. Otherwise, you will find an error such as the one below when upgrading since the new chart major version also bumps the application version. To workaround this issue you need to upgrade database, please refer to the official PostgreSQL documentation for more information about this.

$ kubectl logs $(kubectl get pods -l app.kubernetes.io/instance=postgresql,app.kubernetes.io/name=postgresql,app.kubernetes.io/component=primary -o jsonpath="{.items[0].metadata.name}")
    ...
postgresql 08:10:14.72 INFO  ==> ** Starting PostgreSQL **
2022-02-01 08:10:14.734 GMT [1] FATAL:  database files are incompatible with server
2022-02-01 08:10:14.734 GMT [1] DETAIL:  The data directory was initialized by PostgreSQL version 11, which is not compatible with this version 14.1.

To 10.0.0

On November 13, 2020, Helm v2 support was formally finished, this major version is the result of the required changes applied to the Helm Chart to be able to incorporate the different features added in Helm v3 and to be consistent with the Helm project itself regarding the Helm v2 EOL.

• Previous versions of this Helm Chart use apiVersion: v1 (installable by both Helm 2 and 3), this Helm Chart was updated to apiVersion: v2 (installable by Helm 3 only). Here you can find more information about the apiVersion field.
• Move dependency information from the requirements.yaml to the Chart.yaml
• After running helm dependency update, a Chart.lock file is generated containing the same structure used in the previous requirements.lock
• The different fields present in the Chart.yaml file has been ordered alphabetically in a homogeneous way for all the Bitnami Helm Chart.
• The term master has been replaced with primary and slave with readReplicas throughout the chart. Role names have changed from master and slave to primary and read.

Considerations when upgrading to this version

• If you want to upgrade to this version using Helm v2, this scenario is not supported as this version does not support Helm v2 anymore.
• If you installed the previous version with Helm v2 and wants to upgrade to this version with Helm v3, please refer to the official Helm documentation about migrating from Helm v2 to v3.

Useful links

• Bitnami Tutorial
• Helm docs
• Helm Blog

How to upgrade to version 10.0.0

To upgrade to 10.0.0 from 9.x, it should be done reusing the PVC(s) used to hold the PostgreSQL data on your previous release. To do so, follow the instructions below (the following example assumes that the release name is postgresql):

NOTE: Please, create a backup of your database before running any of those actions.

1. Obtain the credentials and the names of the PVCs used to hold the PostgreSQL data on your current release:

export POSTGRESQL_PASSWORD=$(kubectl get secret --namespace default postgresql -o jsonpath="{.data.postgresql-password}" | base64 --decode)
export POSTGRESQL_PVC=$(kubectl get pvc -l app.kubernetes.io/instance=postgresql,role=primary -o jsonpath="{.items[0].metadata.name}")

1. Delete the PostgreSQL statefulset (notice the option --cascade=false):

kubectl delete statefulsets.apps postgresql-postgresql --namespace default --cascade=false

1. Upgrade your release using the same PostgreSQL version:

helm upgrade postgresql bitnami/postgresql \
  --set postgresqlPassword=$POSTGRESQL_PASSWORD \
  --set persistence.existingClaim=$POSTGRESQL_PVC

1. Delete the existing PostgreSQL pod and the new statefulset will create a new one:

kubectl delete pod postgresql-postgresql-0

1. Finally, you should see the lines below in PostgreSQL container logs:

$ kubectl logs $(kubectl get pods -l app.kubernetes.io/instance=postgresql,app.kubernetes.io/name=postgresql,role=primary -o jsonpath="{.items[0].metadata.name}")
...
postgresql 08:05:12.59 INFO  ==> Deploying PostgreSQL with persisted data...
...

To 9.0.0

In this version the chart was adapted to follow the Helm standard labels.

• Some inmutable objects were modified to adopt Helm standard labels introducing backward incompatibilities.

How to upgrade to version 9.0.0

To upgrade to 9.0.0 from 8.x, it should be done reusing the PVC(s) used to hold the PostgreSQL data on your previous release. To do so, follow the instructions below (the following example assumes that the release name is postgresql):

NOTE: Please, create a backup of your database before running any of those actions.

1. Obtain the credentials and the names of the PVCs used to hold the PostgreSQL data on your current release:

export POSTGRESQL_PASSWORD=$(kubectl get secret --namespace default postgresql -o jsonpath="{.data.postgresql-password}" | base64 --decode)
export POSTGRESQL_PVC=$(kubectl get pvc -l app=postgresql,role=master -o jsonpath="{.items[0].metadata.name}")

1. Delete the PostgreSQL statefulset (notice the option --cascade=false):

kubectl delete statefulsets.apps postgresql-postgresql --namespace default --cascade=false

1. Upgrade your release using the same PostgreSQL version:

helm upgrade postgresql bitnami/postgresql \
  --set postgresqlPassword=$POSTGRESQL_PASSWORD \
  --set persistence.existingClaim=$POSTGRESQL_PVC

1. Delete the existing PostgreSQL pod and the new statefulset will create a new one:

kubectl delete pod postgresql-postgresql-0

1. Finally, you should see the lines below in PostgreSQL container logs:

$ kubectl logs $(kubectl get pods -l app.kubernetes.io/instance=postgresql,app.kubernetes.io/name=postgresql,role=master -o jsonpath="{.items[0].metadata.name}")
...
postgresql 08:05:12.59 INFO  ==> Deploying PostgreSQL with persisted data...
...

License

Copyright © 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.