Examples of configuration v1.2.2

These examples are configuration files for setting up your EDB Postgres Distributed cluster in a Kubernetes environment.

Basics

• Flexible 3 regions

  flexible_3regions.yaml : provides a PGD cluster with two data groups and a global witness node spread across three regions, where each data group consists of two data nodes and a local witness node.

• Flexible 3 regions using physical join

  flexible_3regions_physical_join.yaml : provides a PGD cluster with two data groups and a global witness node just like Flexible 3 regions. The difference is the group join in this sample is using physical join. Group region-a is the first group to startup (spec.pgd.parentGroup.create=true), nodes in region-a join with each other using physical join. Group region-b define its spec.pgd.groupJoinMethod=physical, which means the first node in region-b will start and physical join a remote node, the join target is defined in spec.pgd.discovery section of group region-b, The remaining nodes in region-b will join with each other using physical join as spec.cnp.joinMethod=physical. region-c is a witness group which will always use logical join.

• Flexible 3 regions with pre-provisioned client secrets

  flexible_3regions_provisioned_secrets.yaml

  provides a PGD cluster with two data groups and a global witness node just like Flexible 3 regions. In each PGD group, the server TLS certificate is managed by the operator and cert-manager. The client replication certificate is pre-provisioned. Here are the steps to set up this sample:

1. Establish the self-signed issuer and certificate in target namespace. Since we are using a pre-provisioned client replication certificate, we can delete the client secrets, certificate, and issuer created by issuer-selfsigned.yaml.

   → WrapCopy

   kubectl -n <namespace> apply -f issuer-selfsigned.yaml
   kubectl -n <namespace> delete secrets/client-ca-key-pair \
       certificate/client-ca \
       issuer/client-ca-issuer

2. Create the PGD group. The pre-provisioned client certificate and its CA certificate are included in the flexible_3regions_provisioned_secrets.yaml file as well.

   → WrapCopy

   kubectl -n <namespace> apply -f flexible_3regions_provisioned_secrets.yaml

Flexible 3 regions in different namespaces

flexible_3regions_3ns.yaml

provides a sample that builds upon the Flexible 3 regions example. Each region is assigned a different namespace. The discovery and connectivity section are changed in accordance with the namespaces. To set up this sample, we need to pre-create the client-ca-key-pair and server-ca-key-pair secrets in each namespace utilizing private keys generated with the ECDSA algorithm. This ensures that the server TLS certificates and client replication certificates generated by cert-manager are signed from the same private key.

• Create the namespaces region-a, region-b and region-c.

• Create the CA secrets using issuer-ecdsa-key.yaml in each namespace for the certificates.

  → WrapCopy

  kubectl -n region-a apply -f issuer-ecdsa-key.yaml
  kubectl -n region-b apply -f issuer-ecdsa-key.yaml
  kubectl -n region-c apply -f issuer-ecdsa-key.yaml

• Create the self-signed issuer and corresponding certificate in each namespace. The CA secrets client-ca-key-pair and server-ca-key-pair will be refreshed with ca.crt.

  → WrapCopy

  kubectl -n region-a apply -f issuer-selfsigned.yaml
  kubectl -n region-b apply -f issuer-selfsigned.yaml
  kubectl -n region-c apply -f issuer-selfsigned.yaml

• Create the PGD group

  → WrapCopy

  kubectl apply -f flexible_3regions_3ns.yaml

parted group cleanup

flexible_cleanup.yaml

provides a sample of using PGDGroupCleanup to clean up the metadata of region-b. The cleanup is run from region-a. All nodes belonging to region-b need to be in PARTED status before running this CR.

Backup and restore

• sample group with two schedulers

  group_example_with_2schedulers.yaml

  provides a PGD group sample with two scheduled backups configured: one using volumeSnapshot, the other using barmanObjectStore.

• sample group with backup and restore using barmanObjectStore

  group_example_with_barman_backup.yaml

  provides a backup sample for a three-node PGD group. This setup includes scheduled backups and continuous WAL archiving to barmanObjectStore.

: group_example_with_barman_restore.yaml : offers a restore sample for three regions PGD groups. In the first region, group group-example-with-barman-restore-a is restored from backups, and parent group world is created in this group. In the second and third region, group group-example-with-barman-restore-b and group-example-with-barman-restore-c are created from scratch, and respectively join the restored group.

sample group with backup and restore using volumeSnapshot

group_example_with_vs_backup.yaml

specifies a three-node PGD group configured with scheduled volume snapshot backup and continuous WAL archiving to barmanObjectStore.

: group_example_with_vs_restore.yaml : defines full restore from volume snapshot backup.

: group_example_with_vs_pitr.yaml : defines restore from volume snapshot backup followed by point-in-time recovery.

Read node routing

sample group with read node routing enabled

group_example_with_readnode.yaml

offers a sample with read node routing enabled.

LDAP

• sample group using LDAP with bind and search

  group_example_with_ldap_bind_search.yaml

  provides an LDAP sample of PGD group configured to use bind and search for authentication.

• sample group use ldap with simple bind

  group_example_with_ldap_simple_bind.yaml

  provides an LDAP sample of PGD group to use simple bind for authentication.

Managed roles

sample group with managed roles

group_example_with_managed.yaml

provides a PGD group sample with managed roles and managed services.

TDE

sample group using tde

group_example_with_tde.yaml

provides a PGD group sample with TDE enabled. Since TDE requires PostgreSQL to be a specific flavor and version, the YAML file includes configurations for both the PGD and PGD proxy images.

Configurations

• sample group with mutations

  group_example_with_mutations.yaml

  offers a PGD group sample with always mutation configured.

• sample group with service template configured

  group_example_with_service_template.yaml

  offers a sample with groupSevriceTemplate, nodeServiceTemplate proxyServiceTemplate and proxyReadServiceTemplate configured.

• sample group with customized settings

  group_example_customized.yaml

  offers a PGD group sample with:

• pgd and proxy image customized

• postgres parameters customized

• data and witness nodes storage configuration customized separately

• data instance pod environments variables customized

• data and witness nodes WAL segment size customized

• enable the globalRouting, proxy now points to the writeLead of the global group

• sample group with operand image customized using ImageCatalog

  group_example_catalog.yaml

  offers a PGD group sample with pgd and proxy image customized using ImageCatalog.

• sample group with scale up using physical join

  group_example_with_physical_join.yaml

  offers a PGD group sample with physical join configured.

• sample group with witness configuration

  group_example_witness_config.yaml

  offers a PGD group having witness node configuration. Once the witness node is configured using spec.witness section, it will not share the configuration from spec.cnp section.

For a list of available options, see the "API Reference" page.