gatsby-node.js
-
Paul Melnikow authored
* Typescripterize RequestMarkupButton * Typescripterize Customizer * Typescripterize MarkupModalContent (+ tweaks) * More TypeScript * More TS * Fix build * Remove prop-types dependency * More types * Update frontend/components/badge-examples.tsx * Update frontend/components/badge-examples.tsx * RequestMarkupButton: Fix weird formatting on click
Paul Melnikow authored* Typescripterize RequestMarkupButton * Typescripterize Customizer * Typescripterize MarkupModalContent (+ tweaks) * More TypeScript * More TS * Fix build * Remove prop-types dependency * More types * Update frontend/components/badge-examples.tsx * Update frontend/components/badge-examples.tsx * RequestMarkupButton: Fix weird formatting on click
Configuration parameters
There are two mutually-exclusive methods to set the Postgres Operator configuration.
- ConfigMaps-based, the legacy one
- CRD-based configuration
Variable names are underscore-separated words.
ConfigMaps-based
The configuration is supplied in a
key-value configmap, defined by the CONFIG_MAP_NAME
environment variable.
Non-scalar values, i.e. lists or maps, are encoded in the value strings using
the comma-based syntax for lists and coma-separated key:value
syntax for
maps. String values containing ':' should be enclosed in quotes. The
configuration is flat, parameter group names below are not reflected in the
configuration structure. There is an
example
For the configmap configuration, the default parameter values mentioned here are likely to be overwritten in your local operator installation via your local version of the operator configmap. In the case you use the operator CRD, all the CRD defaults are provided in the operator's default configuration manifest
CRD-based configuration
The configuration is stored in a custom YAML
manifest. The manifest is an instance of the custom resource definition (CRD)
called OperatorConfiguration
. The operator registers this CRD during the
start and uses it for configuration if the operator deployment manifest
sets the POSTGRES_OPERATOR_CONFIGURATION_OBJECT
env variable to a non-empty
value. The variable should point to the postgresql-operator-configuration
object in the operator's namespace.
The CRD-based configuration is a regular YAML document; non-scalar keys are simply represented in the usual YAML way. There are no default values built-in in the operator, each parameter that is not supplied in the configuration receives an empty value. In order to create your own configuration just copy the default one and change it.
To test the CRD-based configuration locally, use the following
kubectl create -f manifests/operatorconfiguration.crd.yaml # registers the CRD
kubectl create -f manifests/postgresql-operator-default-configuration.yaml
kubectl create -f manifests/operator-service-account-rbac.yaml
kubectl create -f manifests/postgres-operator.yaml # set the env var as mentioned above
kubectl get operatorconfigurations postgresql-operator-default-configuration -o yaml
The CRD-based configuration is more powerful than the one based on ConfigMaps and should be used unless there is a compatibility requirement to use an already existing configuration. Even in that case, it should be rather straightforward to convert the ConfigMap-based configuration into the CRD-based one and restart the operator. The ConfigMap-based configuration will be deprecated and subsequently removed in future releases.
Note that for the CRD-based configuration groups of configuration options below
correspond to the non-leaf keys in the target YAML (i.e. for the Kubernetes
resources the key is kubernetes
). The key is mentioned alongside the group
description. The ConfigMap-based configuration is flat and does not allow
non-leaf keys.
Since in the CRD-based case the operator needs to create a CRD first, which is
controlled by the resource_check_interval
and resource_check_timeout
parameters, those parameters have no effect and are replaced by the
CRD_READY_WAIT_INTERVAL
and CRD_READY_WAIT_TIMEOUT
environment variables.
They will be deprecated and removed in the future.
General
Those are top-level keys, containing both leaf keys and groups.
-
enable_crd_registration Instruct the operator to create/update the CRDs. If disabled the operator will rely on the CRDs being managed separately. The default is
true
. -
enable_crd_validation deprecated: toggles if the operator will create or update CRDs with OpenAPI v3 schema validation The default is
true
.false
will be ignored, sinceapiextensions.io/v1
requires a structural schema definition. -
crd_categories The operator will register CRDs in the
all
category by default so that they will be returned by akubectl get all
call. You are free to change categories or leave them empty. -
enable_lazy_spilo_upgrade Instruct operator to update only the statefulsets with new images (Spilo and InitContainers) without immediately doing the rolling update. The assumption is pods will be re-started later with new images, for example due to the node rotation. The default is
false
. -
enable_pgversion_env_var With newer versions of Spilo, it is preferable to use
PGVERSION
pod environment variable instead of the settingpostgresql.bin_dir
in theSPILO_CONFIGURATION
env variable. When this option is true, the operator setsPGVERSION
and omitspostgresql.bin_dir
fromSPILO_CONFIGURATION
. When false, thepostgresql.bin_dir
is set. This setting takes precedence overPGVERSION
; see PR 222 in Spilo. The default istrue
. -
enable_spilo_wal_path_compat enables backwards compatible path between Spilo 12 and Spilo 13+ images. The default is
false
. -
enable_team_id_clustername_prefix To lower the risk of name clashes between clusters of different teams you can turn on this flag and the operator will sync only clusters where the name starts with the
teamId
(fromspec
) plus-
. Default isfalse
. -
etcd_host Etcd connection string for Patroni defined as
host:port
. Not required when Patroni native Kubernetes support is used. The default is empty (use Kubernetes-native DCS). -
kubernetes_use_configmaps Select if setup uses endpoints (default), or configmaps to manage leader when DCS is kubernetes (not etcd or similar). In OpenShift it is not possible to use endpoints option, and configmaps is required. By default,
kubernetes_use_configmaps: false
, meaning endpoints will be used. -
docker_image Spilo Docker image for Postgres instances. For production, don't rely on the default image, as it might be not the most up-to-date one. Instead, build your own Spilo image from the github repository.
-
sidecar_docker_images deprecated: use sidecars instead. A map of sidecar names to Docker images to run with Spilo. In case of the name conflict with the definition in the cluster manifest the cluster-specific one is preferred.
-
sidecars a list of sidecars to run with Spilo, for any cluster (i.e. globally defined sidecars). Each item in the list is of type Container. Globally defined sidecars can be overwritten by specifying a sidecar in the Postgres manifest with the same name. Note: This field is not part of the schema validation. If the container specification is invalid, then the operator fails to create the statefulset.
-
enable_shm_volume Instruct operator to start any new database pod without limitations on shm memory. If this option is enabled, to the target database pod will be mounted a new tmpfs volume to remove shm memory limitation (see e.g. the docker issue). This option is global for an operator object, and can be overwritten by
enableShmVolume
parameter from Postgres manifest. The default istrue
. -
workers number of working routines the operator spawns to process requests to create/update/delete/sync clusters concurrently. The default is
8
. -
max_instances operator will cap the number of instances in any managed Postgres cluster up to the value of this parameter. When
-1
is specified, no limits are applied. The default is-1
. -
min_instances operator will run at least the number of instances for any given Postgres cluster equal to the value of this parameter. Standby clusters can still run with
numberOfInstances: 1
as this is the recommended setup. When-1
is specified formin_instances
, no limits are applied. The default is-1
. -
ignore_instance_limits_annotation_key for some clusters it might be required to scale beyond the limits that can be configured with
min_instances
andmax_instances
options. You can define an annotation key that can be used as a toggle in cluster manifests to ignore globally configured instance limits. The default is empty. -
resync_period period between consecutive sync requests. The default is
30m
. -
repair_period period between consecutive repair requests. The default is
5m
. -
set_memory_request_to_limit Set
memory_request
tomemory_limit
for all Postgres clusters (the default value is also increased but configuredmax_memory_request
can not be bypassed). This prevents certain cases of memory overcommitment at the cost of overprovisioning memory and potential scheduling problems for containers with high memory limits due to the lack of memory on Kubernetes cluster nodes. This affects all containers created by the operator (Postgres, connection pooler, logical backup, scalyr sidecar, and other sidecars except sidecars defined in the operator configuration); to set resources for the operator's own container, change the operator deployment manually. The default isfalse
.
Postgres users
Parameters describing Postgres users. In a CRD-configuration, they are grouped
under the users
key.