diff --git a/product_docs/docs/postgres_distributed_for_kubernetes/1/connectivity.mdx b/product_docs/docs/postgres_distributed_for_kubernetes/1/connectivity.mdx index 2ff89b384b9..0c112a9338e 100644 --- a/product_docs/docs/postgres_distributed_for_kubernetes/1/connectivity.mdx +++ b/product_docs/docs/postgres_distributed_for_kubernetes/1/connectivity.mdx @@ -140,7 +140,7 @@ using cert-manager (the recommended approach) or pre-provisioned using secrets. #### Dynamic provisioning via cert-manager The client certificates configuration is managed by the `.spec.connectivity.tls.clientCert.certManager` -section of the PGDGroup custom resource. +section of the `PGDGroup` custom resource. The following assumptions were made for this section to work: - An issuer `.spec.connectivity.tls.clientCert.certManager.issuerRef` is available @@ -171,7 +171,7 @@ service that routes the connection to the write leader of the PGD group. When connecting from inside the cluster, you can use the proxy service name to connect to the PGD group. The proxy service name is composed of the PGD group name and the optional -host suffix defined in the `.spec.connectivity.dns` section of the PGDGroup custom resource. +host suffix defined in the `.spec.connectivity.dns` section of the `PGDGroup` custom resource. For example, if the PGD group name is `my-group`, and the host suffix is `.my-domain.com`, the proxy service name is `my-group.my-domain.com`. diff --git a/product_docs/docs/postgres_distributed_for_kubernetes/1/recovery.mdx b/product_docs/docs/postgres_distributed_for_kubernetes/1/recovery.mdx index f98b1f7a48b..d2b873ec5ba 100644 --- a/product_docs/docs/postgres_distributed_for_kubernetes/1/recovery.mdx +++ b/product_docs/docs/postgres_distributed_for_kubernetes/1/recovery.mdx @@ -5,19 +5,19 @@ originalFilePath: 'src/recovery.md' In EDB Postgres Distributed for Kubernetes, recovery is available as a way to bootstrap a new PGD group starting from an available physical backup of a PGD node. -The recovery can't be performed in-place on an existing PGD group. -EDB Postgres Distributed for Kubernetes also supports point-in-time recovery, which allows you to restore a PGDGroup up to +The recovery can't be performed in place on an existing PGD group. +EDB Postgres Distributed for Kubernetes also supports point-in-time recovery (PITR), which allows you to restore a PGD group up to any point in time, from the first available backup in your catalog to the last archived -WAL. (Having a WAL archive is mandatory in this case.) +WAL. Having a WAL archive is mandatory in this case. ## Prerequisite -Before recovering from a backup, take care to apply the following considerations: +Before recovering from a backup: - Make sure that the PostgreSQL configuration (`.spec.cnp.postgresql.parameters`) of the - recovered cluster is compatible with the original one from a physical replication standpoint, . + recovered cluster is compatible with the original one from a physical replication standpoint. -- When recovering in a newly created namespace, remember to first set up a cert-manager CA issuer before deploying the recovered PGDGroup. +- When recovering in a newly created namespace, first set up a cert-manager CA issuer before deploying the recovered PGD group. For more information, see [EDB Postgres for Kubernetes recovery - Additional considerations](/postgres_for_kubernetes/latest/bootstrap/#additional-considerations) in the EDB Postgres for Kubernetes documentation. @@ -25,7 +25,7 @@ For more information, see [EDB Postgres for Kubernetes recovery - Additional con You can recover from a PGD node backup created by Barman Cloud and stored on supported object storage. -For example, given a PGDGroup named `pgdgroup-example` with three instances with backups available, your object storage contains a directory for each node: +For example, given a PGD group` named `pgdgroup-example` with three instances with backups available, your object storage contains a directory for each node: `pgdgroup-example-1`, `pgdgroup-example-2`, `pgdgroup-example-3` @@ -62,8 +62,8 @@ spec: !!! Important Make sure to correctly configure the WAL section according to the source cluster. - In the example, since the `pgdgroup-example` PGDGroup uses `compression` - and `encryption`, make sure to set the proper parameters also in the PGDGroup + In the example, since the `pgdgroup-example` PGD group uses `compression` + and `encryption`, make sure to set the proper parameters also in the PGD group that's being created by the `restore`. !!! Note @@ -73,12 +73,12 @@ spec: for this scenario and tune the value of this parameter for your environment. It makes a difference when you need it. -## Point-in-time recovery (PITR) from an object store +## PITR from an object store Instead of replaying all the WALs up to the latest one, after extracting a base backup, you can ask PostgreSQL to stop replaying -WALs at any given point in time. +WALs at any point in time. PostgreSQL uses this technique to achieve PITR. -The presence of a WAL archive is mandatory. +(The presence of a WAL archive is mandatory.) This example defines a time-base target for the recovery: @@ -123,7 +123,7 @@ The `.spec.restore.recoveryTarget.backupID` option allows you to specify a base which to start the recovery process. By default, this value is empty. If you assign a value to it, the operator uses that backup as the base for the recovery. The value must be in the form of a Barman backup ID. -This example recovers a new PGDGroup from a specific backupID of the +This example recovers a new PGD group from a specific backupID of the `pgdgroup-backup-1` PGD node: ```yaml diff --git a/product_docs/docs/postgres_distributed_for_kubernetes/1/samples.mdx b/product_docs/docs/postgres_distributed_for_kubernetes/1/samples.mdx index 19d8339982e..9f2323bb7dd 100644 --- a/product_docs/docs/postgres_distributed_for_kubernetes/1/samples.mdx +++ b/product_docs/docs/postgres_distributed_for_kubernetes/1/samples.mdx @@ -4,7 +4,7 @@ originalFilePath: 'src/samples.md' --- !!! Important - The available dxamples are for demonstration and + The available examples are for demonstration and experimentation purposes only. These examples are configuration files for setting up diff --git a/product_docs/docs/postgres_distributed_for_kubernetes/1/security.mdx b/product_docs/docs/postgres_distributed_for_kubernetes/1/security.mdx index 5aa8620b0ef..cd039bb084b 100644 --- a/product_docs/docs/postgres_distributed_for_kubernetes/1/security.mdx +++ b/product_docs/docs/postgres_distributed_for_kubernetes/1/security.mdx @@ -14,7 +14,7 @@ analyzed at three layers: code, container, and cluster. !!! Seealso "About the 4C's Security Model" See [The 4C's Security Model in Kubernetes](https://www.enterprisedb.com/blog/4cs-security-model-kubernetes) - blog article to get a better understanding and context of the approach EDB + blog article for a better understanding and context of the approach EDB takes with security in EDB Postgres Distributed for Kubernetes. ## Code @@ -25,8 +25,7 @@ including security problems. EDB uses a popular open-source linter for Go called GolangCI-Lint can run several linters on the same source code. One of these is [Golang Security Checker](https://github.com/securego/gosec), or `gosec`. -`gosec` is a linter that scans the abstract syntactic tree of the source against a set of rules aimed at -the discovery of well-known vulnerabilities, threats, and weaknesses hidden in +`gosec` is a linter that scans the abstract syntactic tree of the source against a set of rules aimed at discovering well-known vulnerabilities, threats, and weaknesses hidden in the code. These threads include hard-coded credentials, integer overflows, SQL injections, and others. !!! Important @@ -36,7 +35,7 @@ the code. These threads include hard-coded credentials, integer overflows, SQL i ## Container -Every container image that's part of EDB Postgres Distributed for Kubernetes is automatically built by way of CI/CD pipelines following every commit. +Every container image that's part of EDB Postgres Distributed for Kubernetes is built by way of CI/CD pipelines following every commit. Such images include not only those of the operator but also of the operands, specifically every supported PostgreSQL version. In the pipelines, images are scanned with: @@ -65,16 +64,16 @@ The following guidelines and frameworks were taken into account for container-le ## Cluster Security at the cluster level takes into account all Kubernetes components that -form both the control plane and the nodes, as well as the applications that run in -the cluster (PostgreSQL included). +form both the control plane and the nodes as well as the applications that run in +the cluster, including PostgreSQL. -### Role Based Access Control (RBAC) +### Role-based access control (RBAC) The operator interacts with the Kubernetes API server with a dedicated service account called pgd-operator-controller-manager. In Kubernetes this account is installed by default in the `pgd-operator-system` namespace. A cluster role binds between this service account and the pgd-operator-controller-manager -cluster role that defines the set of rules/resources/verbs granted to the operator. +cluster role that defines the set of rules, resources, and verbs granted to the operator. RedHat OpenShift directly manages the operator RBAC entities by way of [Operator Lifecycle @@ -105,12 +104,12 @@ namespaced resources. `secrets` : Unless you provide certificates and passwords to your data nodes, the operator adopts the "convention over configuration" paradigm by - self-provisioning random-generated passwords and TLS certificates, and by + self-provisioning random-generated passwords and TLS certificates and by storing them in secrets. `serviceaccounts` : The operator needs to create a service account to - enable the PGDGroup recovery job to retrieve the backup objects from + enable the `PGDGroup` recovery job to retrieve the backup objects from the object store where they reside. `services` @@ -164,8 +163,8 @@ EDB Postgres Distributed for Kubernetes doesn't require privileged mode for cont The PostgreSQL containers run as the postgres system user. No component requires running as root. Likewise, volumes access doesn't require privileged mode or root privileges. -Proper ermissions must be assigned by the Kubernetes platform or administrators. -The PostgreSQL containers run with a read-only root filesystem (that is, no writable layer). +Proper permissions must be assigned by the Kubernetes platform or administrators. +The PostgreSQL containers run with a read-only root filesystem, that is, no writable layer. The operator explicitly sets the required security contexts. @@ -180,7 +179,7 @@ and SELinux context. article. !!! Warning "Security context constraints and namespaces" - As stated by [Openshift documentation](https://docs.openshift.com/container-platform/latest/authentication/managing-security-context-constraints.html#role-based-access-to-ssc_configuring-internal-oauth), + As stated in the [Openshift documentation](https://docs.openshift.com/container-platform/latest/authentication/managing-security-context-constraints.html#role-based-access-to-ssc_configuring-internal-oauth), SCCs aren't applied in the default namespaces (`default`, `kube-system`, `kube-public`, `openshift-node`, `openshift-infra`, `openshift`). Don't use them to run pods. CNP clusters deployed in those namespaces @@ -207,7 +206,7 @@ The current implementation of EDB Postgres Distributed for Kubernetes creates passwords for the postgres superuser and the database owner. As far as encryption of passwords is concerned, EDB Postgres Distributed for Kubernetes follows -the default behavior of PostgreSQL: starting from PostgreSQL 14, +the default behavior of PostgreSQL: starting with PostgreSQL 14, `password_encryption` is by default set to `scram-sha-256`. On earlier versions, it's set to `md5`. diff --git a/product_docs/docs/postgres_distributed_for_kubernetes/1/ssl_connections.mdx b/product_docs/docs/postgres_distributed_for_kubernetes/1/ssl_connections.mdx index fb846825804..23eaed7105d 100644 --- a/product_docs/docs/postgres_distributed_for_kubernetes/1/ssl_connections.mdx +++ b/product_docs/docs/postgres_distributed_for_kubernetes/1/ssl_connections.mdx @@ -1,5 +1,5 @@ --- -title: 'Client TLS/SSL Connections' +title: 'Client TLS/SSL connections' originalFilePath: 'src/ssl_connections.md' --- diff --git a/product_docs/docs/postgres_distributed_for_kubernetes/1/use_cases.mdx b/product_docs/docs/postgres_distributed_for_kubernetes/1/use_cases.mdx index eddf486e993..4b992ca6b69 100644 --- a/product_docs/docs/postgres_distributed_for_kubernetes/1/use_cases.mdx +++ b/product_docs/docs/postgres_distributed_for_kubernetes/1/use_cases.mdx @@ -13,7 +13,7 @@ at the same time and need to run in a traditional environment such as a VM. The following is a summary of the basic considerations. See the -[EDB Postgres for Kubernetes documentation](https://www.enterprisedb.com/docs/postgres_for_kubernetes/latest/use_cases/) +[EDB Postgres for Kubernetes documentation](/postgres_for_kubernetes/latest/use_cases/) for more detail. ## Case 1: Applications inside Kubernetes @@ -24,7 +24,7 @@ namespace inside a Kubernetes cluster. ![Application and Database inside Kubernetes](./images/apps-in-k8s.png) The application, normally stateless, is managed as a standard deployment, -with multiple replicas spread over different Kubernetes node, and internally +with multiple replicas spread over different Kubernetes nodes and internally exposed through a ClusterIP service. The service is exposed externally to the end user through an Ingress and the @@ -32,12 +32,12 @@ provider's load balancer facility by way of HTTPS. ## Case 2: Applications outside Kubernetes -Another possible use case is to manage your Postgres Distributed database inside +Another possible use case is to manage your PGD database inside Kubernetes while having your applications outside of it, for example, in a -virtualized environment. In this case, Postgres Distributed is represented by an IP +virtualized environment. In this case, PGD is represented by an IP address or host name and a TCP port, corresponding to the defined Ingress resource in Kubernetes. -The application can still benefit from a TLS connection to Postgres Distributed. +The application can still benefit from a TLS connection to PGD. ![Application outside Kubernetes](./images/apps-outside-k8s.png) diff --git a/product_docs/docs/postgres_distributed_for_kubernetes/1/using_pgd.mdx b/product_docs/docs/postgres_distributed_for_kubernetes/1/using_pgd.mdx index c52d60a2e46..ebd37d31d23 100644 --- a/product_docs/docs/postgres_distributed_for_kubernetes/1/using_pgd.mdx +++ b/product_docs/docs/postgres_distributed_for_kubernetes/1/using_pgd.mdx @@ -1,11 +1,11 @@ --- -title: 'Managing EDB Postgres Distributed databases' +title: 'Managing EDB Postgres Distributed (PGD) databases' originalFilePath: 'src/using_pgd.md' --- As described in the [architecture document](architecture.md), EDB Postgres Distributed for Kubernetes is an operator created to deploy -Postgres Distributed (PGD) databases. +PGD databases. It provides an alternative over deployment with TPA, and by leveraging the Kubernetes ecosystem, it can offer self-healing and declarative control. The operator is also responsible of the backup and restore operations. @@ -13,7 +13,7 @@ See [Backup](backup.md). However, many of the operations and control of PGD clusters aren't managed by the operator. -The pods created by EDB Postgres Distributed for Kubernetes come with +The pods created by EDB Postgres Distributed for Kubernetes come with the [PGD CLI](https://www.enterprisedb.com/docs/pgd/latest/cli/) installed. You can use this tool, for example, to execute a switchover. @@ -41,7 +41,7 @@ location-a-proxy-0 1/1 Running 0 2h location-a-proxy-1 1/1 Running 0 2h ``` -The proxy nodes have `proxy` in the name. Choose one and get a command +The proxy nodes have `proxy` in the name. Choose one, and get a command prompt in it: ```shell @@ -91,19 +91,19 @@ location-a-3 1403922770 location-a data ACTIVE ACTIVE Up 3 ## Accessing the database -In the [use cases](use_cases.md), you can find a discussion on using the +In [Use cases](use_cases.md) is a discussion on using the database within the Kubernetes cluster versus from outside. In [Connectivity](connectivity.md), you can find a discussion on services, which is relevant for accessing the database from applications. However you implement your system, your applications must use the proxy -service to connect to reap the benefits of Postgres Distributed and +service to connect to reap the benefits of PGD and of the increased self-healing capabilities added by the EDB Postgres Distributed for Kubernetes operator. !!! Important As per the EDB Postgres for Kubernetes defaults, data nodes are - created with a database called `app`, owned by a user named `app`, in + created with a database called `app` and owned by a user named `app`, in contrast to the `bdrdb` database described in the EDB Postgres Distributed documentation. You can configure these values in the `cnp` section of the manifest. @@ -121,7 +121,7 @@ kubectl exec -n my-namespace -ti location-a-1-1 -- psql ``` In the familiar territory of psql, remember that the default -created database is named `app` (see warning above). +created database is named `app` (see previous warning). ```terminal postgres=# \c app