SGShardedCluster

Sharded cluster initialization data options. Sharded cluster may be initialized empty, or from a sharded backup restoration.

This field can only be set on creation.

The profile allows changing in a convenient place a set of configuration defaults that affect how the cluster is generated.

All those defaults can be overwritten by setting the correspoinding fields.

Available profiles are:

• production:

  Prevents two Pods from running in the same Node (set .spec.nonProductionOptions.disableClusterPodAntiAffinity to false by default). Sets both limits and requests using SGInstanceProfile for patroni container that runs both Patroni and Postgres (set .spec.nonProductionOptions.disablePatroniResourceRequirements to false by default). Sets requests using the referenced SGInstanceProfile for sidecar containers other than patroni (set .spec.nonProductionOptions.disableClusterResourceRequirements to false by default).

• testing:

  Allows two Pods to running in the same Node (set .spec.nonProductionOptions.disableClusterPodAntiAffinity to true by default). Sets both limits and requests using SGInstanceProfile for patroni container that runs both Patroni and Postgres (set .spec.nonProductionOptions.disablePatroniResourceRequirements to false by default). Sets requests using the referenced SGInstanceProfile for sidecar containers other than patroni (set .spec.nonProductionOptions.disableClusterResourceRequirements to false by default).

• development:

  Allows two Pods from running in the same Node (set .spec.nonProductionOptions.disableClusterPodAntiAffinity to true by default). Unset both limits and requests for patroni container that runs both Patroni and Postgres (set .spec.nonProductionOptions.disablePatroniResourceRequirements to true by default). Unsets requests for sidecar containers other than patroni (set .spec.nonProductionOptions.disableClusterResourceRequirements to true by default).

Changing this field may require a restart.

Make the sharded cluster a read-only standby replica allowing replication from another sharded cluster and acting as a relay.

Changing this section is allowed to fix issues or to change the replication source.

Removing this section convert the sharded cluster in a normal sharded cluster where the standby leader of each SGCluster is converted into a primary instance.

This section allows to configure the global Postgres replication mode.

The main replication group is implicit and contains the total number of instances less the sum of all instances in other replication groups.

The total number of instances is always specified by .spec.instances.

Deprecated use workers instead.

The workers are a group of StackGres clusters where the partitioned data chunks are stored.

When referring to the cluster in the descriptions below it applies to any worker’s StackGres cluster.

The sharding technology that will be used for the sharded cluster.

Available technologies are:

• citus
• ddp
• shardingsphere

Citus

Citus is a PostgreSQL extension that transforms Postgres into a distributed database—so you can achieve high performance at any scale.

See also https://github.com/citusdata/citus

DDP

DDP (Distributed Data Partitioning) allows you to distribute data across different physical nodes to improve the query performance of high data volumes, taking advantage of distinct nodes’ resources. Using the entry point named coordinator in charge of sending/distributing the queries to different nodes named workers.

ShardingSphere

Apache ShardingSphere is an ecosystem to transform any database into a distributed database system, and enhance it with sharding, elastic scaling, encryption features & more.

StackGres implementation of ShardingSphere as a sharding technology uses the ShardingSphere Proxy as an entry point to distribute SQL traffic among the workers.

This implementation requires the ShardingSphere Operator to be installed and will create a ComputeNode

The workers are a group of StackGres clusters where the partitioned data chunks are stored.

When referring to the cluster in the descriptions below it applies to any worker’s StackGres cluster.

Number of StackGres instances for the cluster. Each instance contains one Postgres server. Out of all of the Postgres servers, one is elected as the primary, the rest remain as read-only replicas.

If sharding type is shardingsphere then, instead of an SGCluster a ComputeNode will be created.

See also https://shardingsphere.apache.org/oncloud/current/en/user-manual/cn-sn-operator/#computenode

Cluster pod’s configuration.

If sharding type is shardingsphere then this section will apply to the ComputeNode.

This section allows configuring vertical Pod autoscaling for the SGCluster’s Pods.

Vertical Pod Autoscaling will use cpu and memory usage as the metric to control the upscale or downscale of the Pod requests and limits resources. Vertical Pod Autoscaling requires the Vertical Pod Autoscaler operator to be installed in the Kubernetes cluster.

Name of coordinator StackGres cluster.

When this name is specified it will be used as the coordinator SGCluster name.

This field can only be set on creation.

This section allows referencing SQL scripts that will be applied to the cluster live.

If sharding type is shardingsphere then this section will be applied to the first cluster worker. In this case the database postgres will also provide a foreign server called shardingsphere and the superuser user mappings that will allow running DistQL queries using command like the following:

SELECT * FROM dblink('shardingsphere', 'SHOW STORAGE UNITS')
  AS _(name text, type text, host text, port int, db text,
    connection_timeout_milliseconds int, idle_timeout_milliseconds int,
    max_lifetime_milliseconds int, max_pool_size int, min_pool_size int,
    read_only boolean, other_attributes text);

See https://shardingsphere.apache.org/document/current/en/user-manual/shardingsphere-proxy/distsql

Metadata information from coordinator cluster created resources.

If sharding type is shardingsphere then this section is applied to the ComputeNode.

Name template of query router worker’s StackGres clusters.

The SGCluster name will be created using the name template and the index (starting at 0) as a suffix. For instance with a clusterNameTemplate set to myworker the first SGCluster name will be myworker0.

By default the query router cluster name template is <cluster name>-router.

This field can only be set on creation.

Number of query router StackGres clusters, each composed of a single instance.

Query routers are special workers that do not store sharded table data. Like the coordinator, query routers are StackGres clusters responsible for coordinating access to the workers but do not coordinate data storage. The instances created as query routers allow horizontal scaling of the entrypoints for read/write operations without overloading the workers that store the sharded table data.

Query router StackGres clusters inherit the same characteristics as the coordinator in their spec, with the exception of the instances which is fixed to one and the managedSql that requires an override to be set. This is because a query router, like the coordinator, is not meant to store data and is architecturally more similar to a coordinator than to a worker. Their values can still be overridden via .spec.workers.overrides. See also field queryRouterIndexOffset.

This parameter can only be set if .spec.type is citus.

This section allows to configure the global Postgres replication mode.

The main replication group is implicit and contains the total number of instances less the sum of all instances in other replication groups.

The total number of instances is always specified by .spec.instances.

If sharding type is shardingsphere then this section is ignored.

Name of the SGInstanceProfile.

A SGInstanceProfile defines CPU and memory limits. Must exist before creating a cluster.

When no profile is set, a default (1 core, 2 GiB RAM) one is used.

Changing this field may require a restart.

Pod’s persistent volume configuration.

If sharding type is shardingsphere then this section is ignored.

A list of custom application containers that run within the coordinator cluster’s Pods.

The name used in this section will be prefixed with the string custom- so that when referencing them in the .spec.containers section of SGInstanceProfile the name used has to be prepended with the same prefix.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#container-v1-core

A list of custom environment variables for the specified container.

Changing this field may require a restart.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#container-v1-core

A list of custom environment variables from source for the specified container.

Changing this field may require a restart.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#container-v1-core

A list of custom application init containers that run within the workers cluster’s Pods. The custom init containers will run following the defined sequence at the end of cluster’s Pods init containers.

The name used in this section will be prefixed with the string custom- so that when referencing them in the .spec.containers section of SGInstanceProfile the name used has to be prepended with the same prefix.

Changing this field may require a restart.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#container-v1-core

A list of custom environment variables for the specified init container.

Changing this field may require a restart.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#container-v1-core

A list of custom environment variables from source for the specified init container.

Changing this field may require a restart.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#container-v1-core

A list of custom volume mounts for the specified init container.

Changing this field may require a restart.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#container-v1-core

A list of custom volume mounts for the specified container.

Changing this field may require a restart.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#container-v1-core

A list of custom volumes that may be used along with any container defined in customInitContainers or customContainers sections for the coordinator.

The name used in this section will be prefixed with the string custom- so that when referencing them in the customInitContainers or customContainers sections the name used has to be prepended with the same prefix.

Only the following volume types are allowed: configMap, downwardAPI, emptyDir, gitRepo, glusterfs, hostPath, nfs, projected and secret

Changing this field may require a restart.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#volume-v1-core

If set to true, avoids creating a connection pooling (using PgBouncer) sidecar.

If sharding type is citus and .spec.configurations.citus.connectToPooler is true (the default) this field is ignored.

If sharding type is shardingsphere then this field is ignored.

Changing this field may require a restart.

If set to false, creates the envoy sidecar. This sidecar is used as the edge proxy for the cluster’s Pods providing extra metrics to the monitoring layer.

Changing this field may require a restart.

If set to true, avoids creating the postgres-util sidecar. This sidecar contains usual Postgres administration utilities that are not present in the main (patroni) container, like psql. Only disable if you know what you are doing.

If sharding type is shardingsphere then this field is ignored.

Changing this field may require a restart.

managementPolicy controls how pods are created during initial scale up, when replacing pods on nodes, or when scaling down. The default policy is OrderedReady, where pods are created in increasing order (pod-0, then pod-1, etc) and the controller will wait until each pod is ready before continuing. When scaling down, the pods are removed in the opposite order. The alternative policy is Parallel which will create pods in parallel to match the desired scale without waiting, and on scale down will delete all pods at once.

If sharding type is shardingsphere then this field is ignored.

Pod custom scheduling, affinity and topology spread constratins configuration.

Changing this field may require a restart.

This section indicates the strategy that the SGCluster controller will use to perform updates.

It includes any additional parameters necessary to perform the update for the indicated strategy.

When a change only require the Postgres instance to be restarted, and not the Pod to be re-created, the Postgres instances of the replicas are restarted first and a switchover to the ready replica with the least lag is then performed, so that the primary is demoted instead of being restarted.

The Postgres instance of the primary is restarted in place, without performing any switchover, only when any of the parameters max_connections, max_prepared_transactions, max_locks_per_transaction, max_wal_senders or max_worker_processes is decreased (a hot standby require those parameters to be set to a value greater than or equal to the value set on the primary, see https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-ADMIN) or when no replica is available to switchover to. Patroni only reports the parameters that are pending a change since version 4, when they are not reported a switchover is performed.

Size of the PersistentVolume set for each instance of the cluster. This size is specified either in Mebibytes, Gibibytes or Tebibytes (multiples of 2^20, 2^30 or 2^40, respectively).

If sharding type is shardingsphere then this field is ignored.

This section allows to define per-volume I/O limits for nodes using cgroup v2 io.max features.

NOTE: This is an alpha feature.

When multiple PostgreSQL clusters share the same local storage device on a Kubernetes node, a single cluster running a heavy workload (for example large COPY, aggressive VACUUM, or an unoptimized query) can saturate the device’s I/O bandwidth and degrade performance for every other cluster on that node. StackGres provides this mechanism to prevent this class of noisy-neighbor problem. The mechanism operates at the cgroup + block-device layer, not at the PVC abstraction. Since each pod has its own cgroup, limits are enforced independently across pods even when they share the same physical device — this is the core of the noisy-neighbor protection. However, if multiple volumes within the same pod share the same backing device, their limits target a single entry in that pod’s cgroup and cannot be enforced independently of each other.

This feature works on top of existing CSI drivers such as TopoLVM or OpenEBS LocalPV. The primary target is on-premises deployments where multiple StackGres clusters share local NVMe storage on the same node.

IMPORTANT: Setting any of the value above will require to create an init container named setup-io-limits in each SGCluster’s Pods running as root with only the CHOWN cabability set. Also both the setup-io-limits init container and the cluster-controller container will require to mount the host path /sys/fs/cgroup in order to be able to set owner of and write to the io.max file that will allows to set the io limits. For this reason this feature must be enabled globally by the operator administrator by adding the io-limits feature gate under .spec.featureGates of the SGConfig. Setting any of the value above without the io-limits feature gate enabled will be rejected.

Name of an existing StorageClass in the Kubernetes cluster, used to create the PersistentVolumes for the instances of the cluster.

If sharding type is shardingsphere then this field is ignored.

Name of an existing StorageClass in the Kubernetes cluster, used to create the PersistentVolumes for the instances of the cluster.

See https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/

When set to true the resources requests values in fields SGInstanceProfile.spec.requests.cpu and SGInstanceProfile.spec.requests.memory will represent the resources requests of the patroni container and the total resources requests calculated by adding the resources requests of all the containers (including the patroni container).

Changing this field may require a restart.

When enabled resource limits for containers other than the patroni container will be set just like for patroni container as specified in the SGInstanceProfile.

Changing this field may require a restart.

When set to true the reconciliation of the cluster will fail if disableResourcesRequestsSplitFromTotal is not set or set to false and the sum of the CPU or memory of all the containers except patroni is equal to or higher than the total specified in SGInstanceProfile.spec.requests.cpu or SGInstanceProfile.spec.requests.memory.

When false (the default) and disableResourcesRequestsSplitFromTotal is not set or set to false and the sum of the CPU or memory of all the containers except patroni is equal to or higher than the total specified in SGInstanceProfile.spec.requests.cpu or SGInstanceProfile.spec.requests.memory then the patroni container resources will be set to 0.

Claims lists the names of resources, defined in spec.resourceClaims, that are used by this container.

This field depends on the DynamicResourceAllocation feature gate.

This field is immutable. It can only be set for containers.

Claims lists the names of resources, defined in spec.resourceClaims, that are used by this container.

This field depends on the DynamicResourceAllocation feature gate.

This field is immutable. It can only be set for containers.

Node affinity is a group of node affinity scheduling rules.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#nodeaffinity-v1-core

Pod affinity is a group of inter pod affinity scheduling rules.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#podaffinity-v1-core

Pod anti affinity is a group of inter pod anti affinity scheduling rules.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#podantiaffinity-v1-core

If specified, the pod’s tolerations.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#toleration-v1-core

TopologySpreadConstraints describes how a group of pods ought to spread across topology domains. Scheduler will schedule pods in a way which abides by the constraints. All topologySpreadConstraints are ANDed.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#topologyspreadconstraint-v1-core

Node affinity is a group of node affinity scheduling rules.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#nodeaffinity-v1-core

Pod affinity is a group of inter pod affinity scheduling rules.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#podaffinity-v1-core

Pod anti affinity is a group of inter pod anti affinity scheduling rules.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#podantiaffinity-v1-core

If specified, the pod’s tolerations.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#toleration-v1-core

Indicates the method of the update strategy. Default is InPlace.

• InPlace: update will be performed on the existing instances.
• ReducedImpact: before an update is performed on the existing instances a new instance if created to reduce the impact on read-only replicas.

Indicates the type of the update strategy. Default is OnlyDbOps.

• Always: update will be performed as soon as possible.
• Schedule: update will be performed as specified in the schedule section where you can configure windows of time where the update can be performed.
• OnlyDbOps: update will be performed only when an SGDbOps of type restart, securityUpgrade or minorVersionUpgrade targeting the SGCluster is started.
• Never: update will never be performed (even if annotation stackgres.io/rollout is present with a different value) unless the Pods are deleted manually.

Alternatively to this configuration you may specify the following annotations:

• stackgres.io/rollout=always: Same behavior as Always.
• stackgres.io/rollout=schedule: Same behavior as Schedule.
• stackgres.io/rollout=never: Same behavior as Never (even if type has a different value).

Unless Never (or the annotation stackgres.io/rollout=never) is specified an SGDbOps of type restart, securityUpgrade or minorVersionUpgrade targeting the SGCluster will trigger an update of the Pods.

The update of the Pods will be performed only if Pods are pending any change. Changes in the configuration may not require restarting the Pod and, in such cases, only the Postgres instance will be restarted.

Allows enabling or disabling any of horizontal and vertical Pod autoscaling.

Possible values are:

• vertical: only vertical Pod autoscaling will be enabled (default)
• none: all autoscaling will be disabled

Allows specifying Patroni configuration that will extend the generated one

If sharding type is shardingsphere then this section is ignored.

Name of the SGPoolingConfig used for this cluster. Each pod contains a sidecar with a connection pooler (currently: PgBouncer). The connection pooler is implemented as a sidecar.

If not set, a default configuration will be used. Disabling connection pooling altogether is possible if the disableConnectionPooling property of the pods object is set to true.

If sharding type is shardingsphere then this field is ignored.

Changing this field may require a restart.

Name of the SGPostgresConfig used for the cluster. It must exist. When not set, a default Postgres config, for the major version selected, is used.

If sharding type is shardingsphere then this field is ignored.

Changing this field may require a restart.

Allows specifying Sharding Sphere Proxy configuration that will extend the generated one.

This section is required when sharding type is shardingsphere otherwise is ignored.

Allows specifying Patroni dynamic configuration that will overwrite the generated one. See https://patroni.readthedocs.io/en/latest/dynamic_configuration.html

The following configuration fields will be ignored:

• synchronous_mode
• synchronous_mode_strict
• postgresql
• standby_cluster

If sharding type is shardingsphere then this section is ignored.

Allows specifying Patroni configuration that will overwrite the generated one. See https://patroni.readthedocs.io/en/latest/yaml_configuration.html

The following configuration fields will be ignored:

• name
• namespace
• log
• bootstrap
• citus
• postgresql # with the exception of postgresql.callbacks, postgresql.pre_promote, postgresql.before_stop and postgresql.pg_ctl_timeout
• restapi
• ctl
• watchdog
• tags

If sharding type is shardingsphere then this section is ignored.

This field can only be set on creation.

Annotations that must be set on the generated SGClusters before Patroni is started. See SGCluster.spec.configurations.patroni.startGateAnnotations.

If sharding type is citus the operator also adds the annotation required to start the query routers only once they have been registered by the coordinator.

The pgbouncer.ini parameters that overwrite those specified in the referenced SGPoolingConfig.

Changing this field may require a restart.

The pgbouncer.ini (Section [databases]) parameters the configuration contains, represented as an object where the keys are valid names for the pgbouncer.ini configuration file parameters.

Check pgbouncer configuration for more information about supported parameters.

The pgbouncer.ini (Section [pgbouncer]) parameters the configuration contains, represented as an object where the keys are valid names for the pgbouncer.ini configuration file parameters.

Check pgbouncer configuration for more information about supported parameters

The pgbouncer.ini (Section [users]) parameters the configuration contains, represented as an object where the keys are valid names for the pgbouncer.ini configuration file parameters.

Check pgbouncer configuration for more information about supported parameters.

The postgresql.conf parameters that overwrite those specified in the referenced SGPostgresConfig.

Changing this field may require a restart.

Section to configure the postgres_exporter queries.yaml configuration.

The queries defined here will overwrite those created by the operator.

WARNING: Changing this may beak some of the functionality that depend on the query overwritten.

Properties that will be set in the ShardingSphere Proxy configuration.

Some properties will be overwritten with the configuration generated by the operator. In particular:

• server-lists

Section to configure ServiceAccount used by ShardingSphere operator.

You may configure a global value under operator configuration section SGConfig.spec.shardingSphere.serviceAccount.

Allows configuring the Sharding Sphere Proxy mode type. Options available are:

• Standalone
• Cluster

When Standalone only 1 coordinator instance may be set.

Properties that will be set in the ShardingSphere Proxy configuration.

Some properties will be overwritten with the configuration generated by the operator. In particular:

• proxy-frontend-database-protocol-type
• proxy-default-port

Allows configuring the Sharding Sphere Proxy repository type. Options available are:

• Memory
• ZooKeeper
• Etcd

When mode.type is standalone then repository.type must be memory. When mode.type is cluster then repository.type could be any of zooKeeper or etcd.

Properties that will be set in the ShardingSphere Proxy configuration for the Repository.

Some properties will be overwritten with the configuration generated by the operator. In particular:

• server-lists

Allows configuring extra users other than the superuser (by default superuser username is postgres).

See also https://shardingsphere.apache.org/document/current/en/user-manual/shardingsphere-proxy/yaml-config/authority/#authentication-configuration

Allows configuring the Sharding Sphere Proxy authority privilege type.

See also https://shardingsphere.apache.org/document/current/en/user-manual/shardingsphere-proxy/yaml-config/authority/#authorization-configuration

Allows configuring the mappings between users and databases.

See also https://shardingsphere.apache.org/document/current/en/user-manual/shardingsphere-proxy/yaml-config/authority/#database_permitted

The replication mode applied to the whole cluster. Possible values are:

• async (default)
• sync
• strict-sync
• sync-all
• strict-sync-all

async

When in asynchronous mode the cluster is allowed to lose some committed transactions. When the primary server fails or becomes unavailable for any other reason a sufficiently healthy standby will automatically be promoted to primary. Any transactions that have not been replicated to that standby remain in a “forked timeline” on the primary, and are effectively unrecoverable (the data is still there, but recovering it requires a manual recovery effort by data recovery specialists).

sync

When in synchronous mode a standby will not be promoted unless it is certain that the standby contains all transactions that may have returned a successful commit status to client (clients can change the behavior per transaction using PostgreSQL’s synchronous_commit setting. Transactions with synchronous_commit values of off and local may be lost on fail over, but will not be blocked by replication delays). This means that the system may be unavailable for writes even though some servers are available. System administrators can still use manual failover commands to promote a standby even if it results in transaction loss.

Synchronous mode does not guarantee multi node durability of commits under all circumstances. When no suitable standby is available, primary server will still accept writes, but does not guarantee their replication. When the primary fails in this mode no standby will be promoted. When the host that used to be the primary comes back it will get promoted automatically, unless system administrator performed a manual failover. This behavior makes synchronous mode usable with 2 node clusters.

When synchronous mode is used and a standby crashes, commits will block until the primary is switched to standalone mode. Manually shutting down or restarting a standby will not cause a commit service interruption. Standby will signal the primary to release itself from synchronous standby duties before PostgreSQL shutdown is initiated.

strict-sync

When it is absolutely necessary to guarantee that each write is stored durably on at least two nodes, use the strict synchronous mode. This mode prevents synchronous replication to be switched off on the primary when no synchronous standby candidates are available. As a downside, the primary will not be available for writes (unless the Postgres transaction explicitly turns off synchronous_mode parameter), blocking all client write requests until at least one synchronous replica comes up.

Note: Because of the way synchronous replication is implemented in PostgreSQL it is still possible to lose transactions even when using strict synchronous mode. If the PostgreSQL backend is cancelled while waiting to acknowledge replication (as a result of packet cancellation due to client timeout or backend failure) transaction changes become visible for other backends. Such changes are not yet replicated and may be lost in case of standby promotion.

sync-all

The same as sync but syncInstances is ignored and the number of synchronous instances is equals to the total number of instances less one.

strict-sync-all

The same as strict-sync but syncInstances is ignored and the number of synchronous instances is equals to the total number of instances less one.

An ISO 8601 duration in the format PnDTnHnMn.nS, that specifies how old an SGBackup have to be in order to be seleceted to initialize a replica.

When FromExistingBackup mode is set this field restrict the selection of SGBackup to be used for recovery newer than the specified value.

When FromNewlyCreatedBackup mode is set this field skip the creation SGBackup to be used for recovery if one newer than the specified value exists.

Allows specifying how the replicas are initialized.

Possible values are:

• FromPrimary: When this mode is used replicas will be always created from the primary using pg_basebackup.
• FromReplica: When this mode is used replicas will be created from another existing replica using pg_basebackup. Fallsback to FromPrimary if there’s no replica or it fails.
• FromExistingBackup: When this mode is used replicas will be created from an existing SGBackup. If backupNewerThan is set the SGBackup must be newer than its value. When this mode fails to restore an SGBackup it will try with a previous one (if exists). Fallsback to FromReplica if there’s no backup left or it fails.
• FromNewlyCreatedBackup: When this mode is used replicas will be created from a newly created SGBackup. Fallsback to FromExistingBackup if backupNewerThan is set and exists a recent backup newer than its value or it fails.

Postgres version used on the cluster. It is either of:

• The string ‘latest’, which automatically sets the latest major.minor Postgres version.
• A major version, like ‘14’ or ‘13’, which sets that major version and the latest minor version.
• A specific major.minor version, like ‘14.4’.

StackGres supports deploying extensions at runtime by simply adding an entry to this array. A deployed extension still requires the creation in a database using the CREATE EXTENSION statement. After an extension is deployed correctly it will be present until removed and the cluster restarted.

A cluster restart is required for:

• Extensions that requires to add an entry to shared_preload_libraries configuration parameter.
• Upgrading extensions that overwrite any file that is not the extension’s control file or extension’s script file.
• Removing extensions. Until the cluster is not restarted a removed extension will still be available.
• Install of extensions that require extra mount. After installed the cluster will require to be restarted.

Postgres flavor used on the cluster. It is either of:

• babelfish will use the Babelfish for Postgres.

If not specified then the vanilla Postgres will be used for the cluster.

This field can only be set on creation.

The repository base URL from where to obtain the extension to deploy.

This section is filled by the operator.

An ISO 8601 duration in the format PnDTnHnMn.nS, that specifies the duration of the auto-generated certificate.

If not specified the default duration will be of 13 months.

The certificate will be re-generated 1 day or, if more, 1/12th of its duration before it expires.

Allows enabling SSL for connections to Postgres. By default is true.

If true certificate and private key will be auto-generated unless fields certificateSecretKeySelector and privateKeySecretKeySelector are specified.

This section allows specifying the properties of Service Binding spec for provisioned service. If not specified, then some default will be used.

For more information see https://servicebinding.io/spec/core/1.0.0/

Allows specifying custom credentials for Postgres users and Patroni REST API

Changing this field may require a restart.

Continuous Archiving backups are composed of periodic base backups and all the WAL segments produced in between those base backups for the coordinator and each worker. This parameter specifies at what time and with what frequency to start performing a new base backup.

Use cron syntax (m h dom mon dow) for this parameter, i.e., 5 values separated by spaces:

• m: minute, 0 to 59.
• h: hour, 0 to 23.
• dom: day of month, 1 to 31 (recommended not to set it higher than 28).
• mon: month, 1 to 12.
• dow: day of week, 0 to 7 (0 and 7 both represent Sunday).

Also ranges of values (start-end), the symbol * (meaning first-last) or even */N, where N is a number, meaning ““every N, may be used. All times are UTC. It is recommended to avoid 00:00 as base backup time, to avoid overlapping with any other external operations happening at this time.

If not set, full backups are never performed automatically.

If specified SGBackup will create a backup forcing a fast start (by setting parameter fast to true when calling pg_backup_start) that will reduce the time the backups may take at the expense of more IO usage.

See also https://www.postgresql.org/docs/current/continuous-archiving.html#BACKUP-LOWLEVEL-BASE-BACKUP

The maximum number of retries the backup operation is allowed to do after a failure.

A value of 0 (zero) means no retries are made. Defaults to: 3.

The paths where the backups of coordinator and workers are stored. If not set this field is filled up by the operator.

When provided will indicate where the backups and WAL files will be stored.

The first path indicate the coordinator path and the other paths indicate the workers paths

WARNING: Most users should leave this field empty since having it manually set could be dangerous. If the value is repeated due to re-creating an SGShardedCluster or re-using the same value in another SGShardedCluster and you may get a mixed WAL history with unrecoverable backups.

The paths where the backups of the query routers are stored. If not set this field is filled up by the operator.

When provided will indicate where the backups and WAL files will be stored.

WARNING: Most users should leave this field empty since having it manually set could be dangerous. If the value is repeated due to re-creating an SGShardedCluster or re-using the same value in another SGShardedCluster and you may get a mixed WAL history with unrecoverable backups.

Allows setting a timeout for the reconciliation process that take place after the backup.

If not set defaults to 300 (5 minutes). If set to 0 it will disable timeout.

Failure of reconciliation will not make the backup fail and will be re-tried the next time a SGBackup or shecduled backup Job take place.

When an automatic retention policy is defined to delete old base backups, this parameter specifies the number of base backups to keep, in a sliding window.

Consequently, the time range covered by backups is periodicity*retention, where periodicity is the separation between backups as specified by the cronSchedule property.

Default is 5.

An ISO 8601 duration in the format PnDTnHnMn.nS, that specifies the initial delay used by the exponential backoff applied when a command run by the backup script is retried and in general by unbounded retries and in some cases without exponential backoff.

Defaults to: PT1S.

The maximum number of times a command run by the backup script is retried before failing.

Defaults to: 10.

An ISO 8601 duration in the format PnDTnHnMn.nS, that specifies the maximum delay the exponential backoff is allowed to reach when a command run by the backup script is retried.

Defaults to: PT1M.

Allows setting a timeout for the backup creation.

If not set it will be disabled and the backup operation will continue until the backup completes or fail. If set to 0 is the same as not being set.

Make sure to set a reasonable high value in order to allow for any unexpected delays during backup creation (network low bandwidth, disk low throughput and so forth).

If specified SGBackup will use VolumeSnapshot to create backups.

This functionality still require to store WAL files in an SGObjectStorage but could result in much faster backups and restore of those backups.

See also https://kubernetes.io/docs/concepts/storage/volume-snapshots/

The name of the VolumeSnapshotClass to use to create the VolumeSnapshot for backups.

See also https://kubernetes.io/docs/concepts/storage/volume-snapshots/

When true (the default) Citus connects to each node through the connection pooler (PgBouncer) running in its Pod instead of connecting directly to Postgres: the coordinator maintains pg_dist_poolinfo on the coordinator and on every worker and query router so that the port 6432 of PgBouncer (or the Envoy entry port 7432 when Envoy is enabled) is used instead of the Postgres port registered in pg_dist_node. Only the port is set, so the host keeps following the one that Patroni updates in pg_dist_node after a failover. Citus ignores pg_dist_poolinfo for the connections that can not go through a pooler (like the ones of the shard rebalancer).

When true the disableConnectionPooling fields of the coordinator, the workers, the query routers and their overrides (.spec.coordinator.pods.disableConnectionPooling, .spec.workers.pods.disableConnectionPooling and .spec.workers.overrides[].pods.disableConnectionPooling) are ignored and PgBouncer is always created.

When false the coordinator removes from pg_dist_poolinfo the entries it created.

When true the coordinator removes from pg_dist_node the nodes of the groups that are no longer part of the sharded cluster (after decreasing .spec.workers.clusters or .spec.coordinator.queryRouterClusters), as long as they hold no shard of a distributed table and can be reached.

Patroni only maintains the Citus groups that exist, so the nodes of a removed group would otherwise stay in pg_dist_node and, once they can not be reached, make Citus reject any node addition and distributed DDL.

Regardless of this setting, the SGCluster of a removed worker or query router is kept running while its group is registered in pg_dist_node (Citus can only remove a primary node that can be reached) and is scaled down to 0 instances once its group has been removed from pg_dist_node.

The interval at which the coordinator updates the nodes registered in pg_dist_node: it registers the query routers (with shouldhaveshards set to false, before their Patroni is started), fixes the shouldhaveshards flag of the query routers, activates the registered query routers and, if enableNodeAutoRemoval is true, removes the nodes of the removed groups.

An ISO 8601 duration in the format PnDTnHnMn.nS, truncated to seconds if lower than a minute, to minutes if lower than an hour and to hours otherwise (up to 23 hours). An interval that does not divide its unit restarts at the beginning of each minute, hour or day.

Defaults to: PT10S.

Kubernetes SecretKeySelectors that contains the credentials for patroni REST API.

Changing this field may require a restart.

Kubernetes SecretKeySelectors that contains the credentials of the users.

Changing this field may require a manual modification of the database users to reflect the new values specified.

In particular you may have to create those users if username is changed or alter password if it is changed. Here are the SQL commands to perform such operation (replace default usernames with the new ones and *** with their respective passwords):

• Superuser username changed:

CREATE ROLE postgres;

• Superuser password changed:

ALTER ROLE postgres WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN REPLICATION BYPASSRLS PASSWORD '***';

• Replication username changed:

CREATE ROLE replicator;

• Replication password changed:

ALTER ROLE replicator WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN REPLICATION NOBYPASSRLS PASSWORD '***';

• Authenticator username changed:

CREATE ROLE authenticator;

• Authenticator password changed:

ALTER ROLE authenticator WITH SUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN NOREPLICATION NOBYPASSRLS PASSWORD '***';

Changing this field may require a restart.

If set to true, avoids creating the Prometheus exporter sidecar. Recommended when there’s no intention to use internal monitoring.

Changing this field may require a restart.

Section to configure the postgres_exporter queries.yaml configuration.

The queries defined here will overwrite those created by the operator.

WARNING: Changing this may break some of the functionality that depend on the query overwritten.

Define a retention window with the syntax <integer> (minutes|hours|days|months) in which log entries are kept. Log entries will be removed when they get older more than the double of the specified retention window.

When this field is changed the retention will be applied only to log entries that are newer than the end of the retention window previously specified. If no retention window was previously specified it is considered to be of 7 days. This means that if previous retention window is of 7 days new retention configuration will apply after UTC timestamp calculated with: SELECT date_trunc('days', now() at time zone 'UTC') - INTERVAL '7 days'.

The backup fetch process may fetch several streams in parallel. Parallel fetching is enabled when set to a value larger than one.

If not specified it will be interpreted as latest.

It is possible to restore the database to its state at any time since your backup was taken using Point-in-Time Recovery (PITR) as long as another backup newer than the PITR requested restoration date does not exist.

Point In Time Recovery (PITR). PITR allows restoring the database state to an arbitrary point of time in the past, as long as you specify a backup older than the PITR requested restoration date and does not exist a backup newer than the same restoration date.

See also: https://www.postgresql.org/docs/current/continuous-archiving.html

Deprecated use workersPrimariesService instead.

Custom Kubernetes annotations.

Deprecated use workersPrimariesService instead.

Custom Kubernetes labels.

It is a best practice, on non-containerized environments, when running production workloads, to run each database server on a different server (virtual or physical), i.e., not to co-locate more than one database server per host.

The same best practice applies to databases on containers. By default, StackGres will not allow running more than one StackGres pod on a given Kubernetes node. Set this property to true to allow more than one StackGres pod per node.

This property default value may be changed depending on the value of field .spec.profile.

This property default value may be changed depending on the value of field .spec.profile.

It is a best practice, on containerized environments, when running production workloads, to enforce container’s resources requirements.

By default, StackGres will configure resource requirements for all the containers. Set this property to true to prevent StackGres from setting container’s resources requirements (except for patroni container, see disablePatroniResourceRequirements).

This property default value may be changed depending on the value of field .spec.profile.

It is a best practice, on containerized environments, when running production workloads, to enforce container’s resources requirements.

The same best practice applies to databases on containers. By default, StackGres will configure resource requirements for patroni container. Set this property to true to prevent StackGres from setting patroni container’s resources requirement.

This property default value may be changed depending on the value of field .spec.profile.

Deprecated this value is ignored and you can consider it as always true.

On containerized environments, when running production workloads, enforcing container’s cpu requirements request to be equals to the limit allows achieving the highest level of performance. Doing so, reduces the chances of leaving the workload with less cpu than it requires. It also allows setting static CPU management policy that allows to guarantee a pod the usage exclusive CPUs on the node.

By default, StackGres will configure cpu requirements to have the same limit and request for all the containers. Set this property to true to make StackGres set container’s cpu requirements request equals to the limit (except for patroni container, see enableSetPatroniCpuRequests) when .spec.requests.containers.<container name>.cpu .spec.requests.initContainers.<container name>.cpu is configured in the referenced SGInstanceProfile.

Deprecated this value is ignored and you can consider it as always true.

On containerized environments, when running production workloads, enforcing container’s memory requirements request to be equals to the limit allows achieving the highest level of performance. Doing so, reduces the chances of leaving the workload with less memory than it requires.

By default, StackGres will configure memory requirements to have the same limit and request for all the containers. Set this property to true to make StackGres set container’s memory requirements request equals to the limit (except for patroni container, see enableSetPatroniMemoryRequests) when .spec.requests.containers.<container name>.memory .spec.requests.initContainers.<container name>.memory is configured in the referenced SGInstanceProfile.

Deprecated this value is ignored and you can consider it as always true.

On containerized environments, when running production workloads, enforcing container’s cpu requirements request to be equals to the limit allows achieving the highest level of performance. Doing so, reduces the chances of leaving the workload with less cpu than it requires. It also allows setting static CPU management policy that allows to guarantee a pod the usage exclusive CPUs on the node.

By default, StackGres will configure cpu requirements to have the same limit and request for the patroni container. Set this property to true to make StackGres set patroni container’s cpu requirements request equals to the limit when .spec.requests.cpu is configured in the referenced SGInstanceProfile.

Deprecated this value is ignored and you can consider it as always true.

On containerized environments, when running production workloads, enforcing container’s memory requirements request to be equals to the limit allows achieving the highest level of performance. Doing so, reduces the chances of leaving the workload with less memory than it requires.

By default, StackGres will configure memory requirements to have the same limit and request for the patroni container. Set this property to true to make StackGres set patroni container’s memory requirements request equals to the limit when .spec.requests.memory is configured in the referenced SGInstanceProfile.

A list of StackGres feature gates to enable (not suitable for a production environment).

Available feature gates are:

• babelfish-flavor: Allows using the babelfish flavor.

Deprecated use workers instead.

Configuration for the workers services

Configure the coordinator service to any instance of the coordinator with the same name as the SGShardedCluster plus the -reads suffix.

If the sharding type is shardingsphere then the name of the service will be the same name as the SGShardedCluster.

It provides a stable connection (regardless of node failures) to any Postgres server of the coordinator cluster. Servers are load-balanced via this service.

See also https://kubernetes.io/docs/concepts/services-networking/service/

The list of custom ports that will be exposed by the coordinator services.

The names of custom ports will be prefixed with the string custom- so they do not conflict with ports defined for the coordinator services.

The names of target ports will be prefixed with the string custom- so that the ports that can be referenced in this section will be only those defined under .spec.pods.customContainers[].ports sections where names are also prepended with the same prefix.

Changing this field may require a restart.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#serviceport-v1-core

Configure the coordinator service to the primary of the coordinator with the name as the SGShardedCluster.

If the sharding type is shardingsphere then this service will be disabled.

It provides a stable connection (regardless of primary failures or switchovers) to the read-write Postgres server of the coordinator cluster.

See also https://kubernetes.io/docs/concepts/services-networking/service/

Configure the query routers service to any primary in the query router wokrers with the name as the SGShardedCluster plus the -routers suffix.

It provides a stable connection to read-write Postgres servers of any query router worker SGCluster. Read-write servers are load-balanced via this service.

See also .spec.coordinator.queryRouterClusters

See also https://kubernetes.io/docs/concepts/services-networking/service/

externalIPs is a list of IP addresses for which nodes in the cluster will also accept traffic for this service. These IPs are not managed by Kubernetes. The user is responsible for ensuring that traffic arrives at a node with this IP. A common example is external load-balancers that are not part of the Kubernetes system.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#allocateloadbalancernodeports-v1-core

IPFamilies is a list of IP families (e.g. IPv4, IPv6) assigned to this service. This field is usually assigned automatically based on cluster configuration and the ipFamilyPolicy field. If this field is specified manually, the requested family is available in the cluster, and ipFamilyPolicy allows it, it will be used; otherwise creation of the service will fail. This field is conditionally mutable: it allows for adding or removing a secondary IP family, but it does not allow changing the primary IP family of the Service. Valid values are “IPv4” and “IPv6”. This field only applies to Services of types ClusterIP, NodePort, and LoadBalancer, and does apply to “headless” services. This field will be wiped when updating a Service to type ExternalName.

This field may hold a maximum of two entries (dual-stack families, in either order). These families must correspond to the values of the clusterIPs field, if specified. Both clusterIPs and ipFamilies are governed by the ipFamilyPolicy field.

SessionAffinityConfig represents the configurations of session affinity.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#sessionaffinityconfig-v1-core

type determines how the Service is exposed. Defaults to ClusterIP. Valid options are ClusterIP, NodePort, LoadBalancer and None. “ClusterIP” allocates a cluster-internal IP address for load-balancing to endpoints. “NodePort” builds on ClusterIP and allocates a port on every node. “LoadBalancer” builds on NodePort and creates an external load-balancer (if supported in the current cloud). “None” creates a headless service that can be used in conjunction with .spec.pods.disableEnvoy set to true in order to access the database using a DNS. More info:

• https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
• https://kubernetes.io/docs/concepts/services-networking/service/#headless-services
• https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

externalIPs is a list of IP addresses for which nodes in the cluster will also accept traffic for this service. These IPs are not managed by Kubernetes. The user is responsible for ensuring that traffic arrives at a node with this IP. A common example is external load-balancers that are not part of the Kubernetes system.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#allocateloadbalancernodeports-v1-core

IPFamilies is a list of IP families (e.g. IPv4, IPv6) assigned to this service. This field is usually assigned automatically based on cluster configuration and the ipFamilyPolicy field. If this field is specified manually, the requested family is available in the cluster, and ipFamilyPolicy allows it, it will be used; otherwise creation of the service will fail. This field is conditionally mutable: it allows for adding or removing a secondary IP family, but it does not allow changing the primary IP family of the Service. Valid values are “IPv4” and “IPv6”. This field only applies to Services of types ClusterIP, NodePort, and LoadBalancer, and does apply to “headless” services. This field will be wiped when updating a Service to type ExternalName.

This field may hold a maximum of two entries (dual-stack families, in either order). These families must correspond to the values of the clusterIPs field, if specified. Both clusterIPs and ipFamilies are governed by the ipFamilyPolicy field.

SessionAffinityConfig represents the configurations of session affinity.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#sessionaffinityconfig-v1-core

type determines how the Service is exposed. Defaults to ClusterIP. Valid options are ClusterIP, NodePort, LoadBalancer and None. “ClusterIP” allocates a cluster-internal IP address for load-balancing to endpoints. “NodePort” builds on ClusterIP and allocates a port on every node. “LoadBalancer” builds on NodePort and creates an external load-balancer (if supported in the current cloud). “None” creates a headless service that can be used in conjunction with .spec.pods.disableEnvoy set to true in order to access the database using a DNS. More info:

• https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
• https://kubernetes.io/docs/concepts/services-networking/service/#headless-services
• https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

externalIPs is a list of IP addresses for which nodes in the cluster will also accept traffic for this service. These IPs are not managed by Kubernetes. The user is responsible for ensuring that traffic arrives at a node with this IP. A common example is external load-balancers that are not part of the Kubernetes system.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#allocateloadbalancernodeports-v1-core

IPFamilies is a list of IP families (e.g. IPv4, IPv6) assigned to this service. This field is usually assigned automatically based on cluster configuration and the ipFamilyPolicy field. If this field is specified manually, the requested family is available in the cluster, and ipFamilyPolicy allows it, it will be used; otherwise creation of the service will fail. This field is conditionally mutable: it allows for adding or removing a secondary IP family, but it does not allow changing the primary IP family of the Service. Valid values are “IPv4” and “IPv6”. This field only applies to Services of types ClusterIP, NodePort, and LoadBalancer, and does apply to “headless” services. This field will be wiped when updating a Service to type ExternalName.

This field may hold a maximum of two entries (dual-stack families, in either order). These families must correspond to the values of the clusterIPs field, if specified. Both clusterIPs and ipFamilies are governed by the ipFamilyPolicy field.

SessionAffinityConfig represents the configurations of session affinity.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#sessionaffinityconfig-v1-core

type determines how the Service is exposed. Defaults to ClusterIP. Valid options are ClusterIP, NodePort, LoadBalancer and None. “ClusterIP” allocates a cluster-internal IP address for load-balancing to endpoints. “NodePort” builds on ClusterIP and allocates a port on every node. “LoadBalancer” builds on NodePort and creates an external load-balancer (if supported in the current cloud). “None” creates a headless service that can be used in conjunction with .spec.pods.disableEnvoy set to true in order to access the database using a DNS. More info:

• https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
• https://kubernetes.io/docs/concepts/services-networking/service/#headless-services
• https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

The list of custom ports that will be exposed by the workers services.

The names of custom ports will be prefixed with the string custom- so they do not conflict with ports defined for the workers services.

The names of target ports will be prefixed with the string custom- so that the ports that can be referenced in this section will be only those defined under .spec.pods.customContainers[].ports sections where names are also prepended with the same prefix.

Changing this field may require a restart.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#serviceport-v1-core

Configure the workers service to any primary in the workers with the name as the SGShardedCluster plus the -workers suffix.

It provides a stable connection (regardless of primary failures or switchovers) to read-write Postgres servers of any worker SGCluster. Read-write servers are load-balanced via this service.

See also https://kubernetes.io/docs/concepts/services-networking/service/

externalIPs is a list of IP addresses for which nodes in the cluster will also accept traffic for this service. These IPs are not managed by Kubernetes. The user is responsible for ensuring that traffic arrives at a node with this IP. A common example is external load-balancers that are not part of the Kubernetes system.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#allocateloadbalancernodeports-v1-core

IPFamilies is a list of IP families (e.g. IPv4, IPv6) assigned to this service. This field is usually assigned automatically based on cluster configuration and the ipFamilyPolicy field. If this field is specified manually, the requested family is available in the cluster, and ipFamilyPolicy allows it, it will be used; otherwise creation of the service will fail. This field is conditionally mutable: it allows for adding or removing a secondary IP family, but it does not allow changing the primary IP family of the Service. Valid values are “IPv4” and “IPv6”. This field only applies to Services of types ClusterIP, NodePort, and LoadBalancer, and does apply to “headless” services. This field will be wiped when updating a Service to type ExternalName.

This field may hold a maximum of two entries (dual-stack families, in either order). These families must correspond to the values of the clusterIPs field, if specified. Both clusterIPs and ipFamilies are governed by the ipFamilyPolicy field.

SessionAffinityConfig represents the configurations of session affinity.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#sessionaffinityconfig-v1-core

type determines how the Service is exposed. Defaults to ClusterIP. Valid options are ClusterIP, NodePort, LoadBalancer and None. “ClusterIP” allocates a cluster-internal IP address for load-balancing to endpoints. “NodePort” builds on ClusterIP and allocates a port on every node. “LoadBalancer” builds on NodePort and creates an external load-balancer (if supported in the current cloud). “None” creates a headless service that can be used in conjunction with .spec.pods.disableEnvoy set to true in order to access the database using a DNS. More info:

• https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
• https://kubernetes.io/docs/concepts/services-networking/service/#headless-services
• https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

The list of custom ports that will be exposed by the workers services.

The names of custom ports will be prefixed with the string custom- so they do not conflict with ports defined for the workers services.

The names of target ports will be prefixed with the string custom- so that the ports that can be referenced in this section will be only those defined under .spec.pods.customContainers[].ports sections where names are also prepended with the same prefix.

Changing this field may require a restart.

See: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#serviceport-v1-core

Configure the workers service to any primary in the workers with the name as the SGShardedCluster plus the -workers suffix.

It provides a stable connection (regardless of primary failures or switchovers) to read-write Postgres servers of any worker SGCluster. Read-write servers are load-balanced via this service.

See also https://kubernetes.io/docs/concepts/services-networking/service/

externalIPs is a list of IP addresses for which nodes in the cluster will also accept traffic for this service. These IPs are not managed by Kubernetes. The user is responsible for ensuring that traffic arrives at a node with this IP. A common example is external load-balancers that are not part of the Kubernetes system.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#allocateloadbalancernodeports-v1-core

IPFamilies is a list of IP families (e.g. IPv4, IPv6) assigned to this service. This field is usually assigned automatically based on cluster configuration and the ipFamilyPolicy field. If this field is specified manually, the requested family is available in the cluster, and ipFamilyPolicy allows it, it will be used; otherwise creation of the service will fail. This field is conditionally mutable: it allows for adding or removing a secondary IP family, but it does not allow changing the primary IP family of the Service. Valid values are “IPv4” and “IPv6”. This field only applies to Services of types ClusterIP, NodePort, and LoadBalancer, and does apply to “headless” services. This field will be wiped when updating a Service to type ExternalName.

This field may hold a maximum of two entries (dual-stack families, in either order). These families must correspond to the values of the clusterIPs field, if specified. Both clusterIPs and ipFamilies are governed by the ipFamilyPolicy field.

SessionAffinityConfig represents the configurations of session affinity.

See https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.36/#sessionaffinityconfig-v1-core

type determines how the Service is exposed. Defaults to ClusterIP. Valid options are ClusterIP, NodePort, LoadBalancer and None. “ClusterIP” allocates a cluster-internal IP address for load-balancing to endpoints. “NodePort” builds on ClusterIP and allocates a port on every node. “LoadBalancer” builds on NodePort and creates an external load-balancer (if supported in the current cloud). “None” creates a headless service that can be used in conjunction with .spec.pods.disableEnvoy set to true in order to access the database using a DNS. More info:

• https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
• https://kubernetes.io/docs/concepts/services-networking/service/#headless-services
• https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

Configure replication from an SGObjectStorage using WAL shipping.

The file structure of the object storage must follow the WAL-G file structure.