mirror of
https://github.com/bitnami/charts.git
synced 2026-03-10 15:07:49 +08:00
[bitnami/*] Reorder Chart sections (#24455)
* [bitnami/*] Reorder Chart sections Signed-off-by: Jota Martos <jotamartos@vmware.com> * [bitnami/*] Fix linter Signed-off-by: Jota Martos <jotamartos@vmware.com> --------- Signed-off-by: Jota Martos <jotamartos@vmware.com>
This commit is contained in:
Juan José Martos
@@ -44,23 +44,232 @@ The command deploys PostgreSQL on the Kubernetes cluster in the default configur
|
||||
|
||||
> **Tip**: List all releases using `helm list`
|
||||
|
||||
## Uninstalling the Chart
|
||||
## Configuration and installation details
|
||||
|
||||
To uninstall/delete the `my-release` deployment:
|
||||
### Resource requests and limits
|
||||
|
||||
```console
|
||||
helm delete my-release
|
||||
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](https://github.com/bitnami/charts/blob/main/bitnami/common/templates/_resources.tpl#L15). 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/).
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/tutorials/understand-rolling-tags-containers)
|
||||
|
||||
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:
|
||||
|
||||
```text
|
||||
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"
|
||||
```
|
||||
|
||||
The command removes all the Kubernetes components but PVC's associated with the chart and deletes the release.
|
||||
Next, login to the PostgreSQL server using the `psql` client and add the PAM authenticated LDAP users.
|
||||
|
||||
To delete the PVC's associated with `my-release`:
|
||||
> Note: Parameters including commas must be escaped as shown in the above example.
|
||||
|
||||
```console
|
||||
kubectl delete pvc -l release=my-release
|
||||
### 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](https://github.com/bitnami/containers/tree/main/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:
|
||||
|
||||
```console
|
||||
kubectl create secret generic certificates-tls-secret --from-file=./cert.crt --from-file=./cert.key --from-file=./ca.crt
|
||||
```
|
||||
|
||||
- Then, use the following parameters:
|
||||
|
||||
```console
|
||||
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](https://github.com/kubernetes/kubernetes/issues/57923) 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.
|
||||
|
||||
```yaml
|
||||
# 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
|
||||
```
|
||||
|
||||
> **Note**: Deleting the PVC's will delete postgresql data as well. Please be cautious before doing it.
|
||||
### Metrics
|
||||
|
||||
The chart optionally can start a metrics exporter for [prometheus](https://prometheus.io). 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](https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml).
|
||||
|
||||
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](https://github.com/wrouesnel/postgres_exporter#adding-new-metrics-via-a-config-file) for more details.
|
||||
|
||||
### Use of global variables
|
||||
|
||||
In more complex scenarios, we may have the following tree of dependencies
|
||||
|
||||
```text
|
||||
+--------------+
|
||||
| |
|
||||
+------------+ 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:
|
||||
|
||||
```text
|
||||
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:
|
||||
|
||||
```text
|
||||
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](https://velero.io/), 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](https://docs.bitnami.com/tutorials/migrate-data-bitnami-velero/) for more information.
|
||||
|
||||
### NetworkPolicy
|
||||
|
||||
To enable network policy for PostgreSQL, install [a networking plugin that implements the Kubernetes NetworkPolicy spec](https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy#before-you-begin), 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:
|
||||
|
||||
```console
|
||||
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](https://hub.docker.com/_/postgres) 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](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity).
|
||||
|
||||
As an alternative, you can use of the preset configurations for pod affinity, pod anti-affinity, and node affinity available at the [bitnami/common](https://github.com/bitnami/charts/tree/main/bitnami/common#affinities) chart. To do so, set the `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters.
|
||||
|
||||
## Persistence
|
||||
|
||||
The [Bitnami PostgreSQL](https://github.com/bitnami/containers/tree/main/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](#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](https://github.com/bitnami/containers/tree/main/bitnami/postgresql). If you need to use those data, please covert them to sql and import after `helm install` finished.
|
||||
|
||||
## Parameters
|
||||
|
||||
@@ -560,233 +769,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/postg
|
||||
> 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](https://github.com/bitnami/charts/tree/main/bitnami/postgresql/values.yaml)
|
||||
|
||||
## 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](https://github.com/bitnami/charts/blob/main/bitnami/common/templates/_resources.tpl#L15). 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/).
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/tutorials/understand-rolling-tags-containers)
|
||||
|
||||
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:
|
||||
|
||||
```text
|
||||
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](https://github.com/bitnami/containers/tree/main/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:
|
||||
|
||||
```console
|
||||
kubectl create secret generic certificates-tls-secret --from-file=./cert.crt --from-file=./cert.key --from-file=./ca.crt
|
||||
```
|
||||
|
||||
- Then, use the following parameters:
|
||||
|
||||
```console
|
||||
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](https://github.com/kubernetes/kubernetes/issues/57923) 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.
|
||||
|
||||
```yaml
|
||||
# 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](https://prometheus.io). 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](https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml).
|
||||
|
||||
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](https://github.com/wrouesnel/postgres_exporter#adding-new-metrics-via-a-config-file) for more details.
|
||||
|
||||
### Use of global variables
|
||||
|
||||
In more complex scenarios, we may have the following tree of dependencies
|
||||
|
||||
```text
|
||||
+--------------+
|
||||
| |
|
||||
+------------+ 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:
|
||||
|
||||
```text
|
||||
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:
|
||||
|
||||
```text
|
||||
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.
|
||||
|
||||
### Persistence
|
||||
|
||||
The [Bitnami PostgreSQL](https://github.com/bitnami/containers/tree/main/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](#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](https://github.com/bitnami/containers/tree/main/bitnami/postgresql). If you need to use those data, please covert them to sql and import after `helm install` finished.
|
||||
|
||||
### 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](https://velero.io/), 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](https://docs.bitnami.com/tutorials/migrate-data-bitnami-velero/) for more information.
|
||||
|
||||
### NetworkPolicy
|
||||
|
||||
To enable network policy for PostgreSQL, install [a networking plugin that implements the Kubernetes NetworkPolicy spec](https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy#before-you-begin), 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:
|
||||
|
||||
```console
|
||||
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](https://hub.docker.com/_/postgres) 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](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity).
|
||||
|
||||
As an alternative, you can use of the preset configurations for pod affinity, pod anti-affinity, and node affinity available at the [bitnami/common](https://github.com/bitnami/charts/tree/main/bitnami/common#affinities) chart. To do so, set the `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
Find more information about how to deal with common errors related to Bitnami's Helm charts in [this troubleshooting guide](https://docs.bitnami.com/general/how-to/troubleshoot-helm-chart-issues).
|
||||
|
||||
Reference in New Issue
Block a user